Medical Diagnosis with

The Literary Machine Professional



Project Background


"I would like to use literarymachine for a new project. I am a medical doctor, treat about thousand patients. each patient has several appointments, at each appointment I make a list of problems that I formulate spontanously. Then I decide of the treatment, out of a list of 4000 possible treatments, coded by short-names.


On the other hand I have other problem-lists coming from book-descriptions related again to these treatments.


At the end I would like to publish the relationships between problems and treatments and the possible success. For this I need to relate each problem to a thesaurus, that is build hierarchically.


Do you see any solution how I can handle this with literarymachine. Up to now I used Personalbrain, but it doesn't allow me to get out of it, it's on the other hand very easy to put in the data by the multirelational database that allows me multiple parents, children and jumps."



Initial Analysis


The first step in this project is to adapt LM Pro to the requirements. In a second step we will add extra programs for input, report and analysis.


Doctors have designed medical treatment programs since long. I had such programming cases already 15 years ago. So when it goes about efficient patient and treatment planning systems in general I think that it would be unwise to reinvent the wheel.


In this case the customer's interest lies in the innovative ("fuzzy") structure that is difficult to capture in an ordinary computer application. What LM can offer is probably the role of an extra "brainstorming " tool that can be teamed with basic medical software.


Summing up: We should devise a tool that offers the free structuring of LM. As to regular data administration the objective should be modest, looking for a robust and realistic connection with other mainstream tools.


Analysing the data structure I get the solution described by the picture.


Proposed data structure for the LM diagnosis tool



Patients are listed in the XML ("References") section. The XML storage is like a mini-version of and old-fashioned one-file database:

1. XML allows you to define a suitable record structure

2. Records are sorted by patient name or other selected field

3. Data can be searched, also with complex and/or queries.

4. Data is easily imported.

5. However, data cannot be updated by key in subsequent imports.

6. Furthermore, LM cannot be extended to full time-planner, patient administration tool.


The size 1000 is manageble in the Project/XML system.


Problems are LM words in this structure. It is possible to mix several datatypes in the LM Word file (separating them by prefixes), but I suggest that this is not used. LM Words should be used for a continuum of words from diagnoses/diagnosis-groups to ordinary language words.


LM Words will have two formal uses

a) The keyword assignment of LM Item texts

b) Arrangement in a hierarchy ("Thesaurus")


Of course free-text search is always available.


What about the 4000 treatments and equally big lists of formalized diagnoses?

They are coded by short strings and therefore simple to transfer manually to the LM application. Storage and selection management is a big task, probably excellently developed in existing medical programs.


Leaving them outside the LM database and using codes only makes the analysis and reporting an open question. However, this is the principal consequence of choosing a free structure program. We will focus on this later in the project.


Texts is straightforward. Texts will be both patient annotations and excerpts from literature. Patient texts will be connected to the patient. All texts will be connected to LM Words/Problems. Some "excerpt" texts may be connected to patients. However texts may not have more than 24 patients, or 24 words(problems).


Other uses not mentioned here are possible.


LM Words in tree is the Version 2.2 feature to arrange LM Words in outlines. You could have a general hierarchy, or many hierarchies (one for each word for instance). The LM Items can be retrieved from the tree in the same way as from the Dictionary window.


The databases to the right of the line cannot be implemented in LM proper. They are either managed in other programs or in the additional helping LM application. Management here means either communication with other systems or data base management in the additional tool.


The following images show a minimal model for the LM Pro implementation.



The patient record is defined by a XML file. It can easily be imported.




The problem/diagnosis hierarchy.




The desktop with ordinary LM word-work.




Using the LM Table cross-referencing feature.



I will report more from this project as it proceeds.



Gunnar Sommestad