Iota Domain Analysis
As is simply too painfully obvious, current EHR systems aren't fit for purpose. There is a serious defect in the domain analysis, so that fundamental concepts such as "disease" and "clinical guideline" are simply missing from the EHR domain analysis.
We'll have to do this over a number of diagrams and pages. Here we start with the general overview, and at the bottom of this page, you'll find links to other more detailed diagrams.
Let's discuss the parts in this highly simplified diagram. The objects in green are unique to iotaMed and are missing in current EHR systems. Note that the objects below the dashed line are not normally seen when working in iotaPad or any other iotaMed client software. You can always retrieve the details of the encounter and doctor if you must, but normally you wouldn't wish to clutter up your visual workspace with them.
The patient object is the root of the tree. We're assumed to already have created or chosen the patient here.
A patient has zero, or any number of "issues". An "issue" is a disease, for instance "diabetes" or a symptom such as "headache" or "vertigo".
Access control is contained in the "privacy" object and the privacy object is connected to the issue. This is a major departure from how access control is normally done in EHR systems. Regular EHR systems tie the access control to the department or doctor that handles the patient, starting with the assumption that the information that the patient desires to protect is tied to the department or doctor that created or recorded the information. This is often the case, but not always, and when it is, it is by coincidence and not an essential attribute. For example: most of what a psychiatrist says belongs in the psychiatric domain so at first blush it seems only reasonable to limit access to records originating with the psychiatrist. But if the psychiatrist now treats the patient for a cold, which he can, then the cold becomes protected information, which is clearly absurd.
Another example is if a psychiatrist treats two different diseases, such as parkinsonism and depression, and the patient wishes for the depression to be protected but not parkinsonism. In that case, it becomes very difficult for the psychiatrist to keep the access control masks correct. We're clearly using the wrong concepts and entities here.
Obviously, the privacy in real life is attached to the "issue". If a patient wants to keep his depression a secret, it doesn't matter which doctor is involved, it's the depression itself that should be privacy protected. Hence the iotaMed design where the privacy record attaches to the issue.
A "Clinical Guideline" is a template maintained by the medical authorities, which describes in outline form how a particular disease or symptom should be worked up and managed. It also contains differential diagnoses, treatments, new scientific discoveries, links to external documentation, reporting sheets, etc. Whenever an "Issue Worksheet" is created, one "Clinical Guideline" is attached and its contents copied into the "Issue Worksheet". The relationship between the "Clinical Guideline" and the "Issue Worksheet" is maintained so that changes in the "Clinical Guideline" can be propagated to the already instantiated "Issue Worksheets" in use. An example would be if a new drug of choice has been selected for a particular disease, then the iotaMed system can alert the physician at next encounter that he should consider if that change should be done for the individual patient or not. This link-back allows effective distribution of new evidence-based knowledge into clinical practice without undue delay.
An issue that is not easily identifiable with a known condition, or if no clinical guideline exists that is suitable, the issue worksheet is connected to a dummy clinical guideline that does not contain any items.
The "Issue Worksheet" is an interactive instance of the clinical guideline template. On this sheet, observations can be added or removed. Entire items can be added or deleted, such that any clinical guideline that is preloaded can be rearranged for the particular patient.
If the user creates an issue with an empty (dummy) clinical guideline, the issue worksheet starts out empty, so the user needs to add items to it before proceeding. This way, the user forms his ad hoc issue worksheet, which can later be replaced with a "real" issue worksheet based on a real clinical guideline as the narrowing down of the diagnosis proceeds.
An issue worksheet contains a number of items. Each item is a clinical data point such as history, an allergy, a lab result, a blood pressure. The issue is a variable, not the value itself, which is an "observation".
An observation is one data point in the clinical work. It is, for example, a blood pressure, a lab value, a description of the palpation of the abdomen, a description of the auscultation of heart sounds, or the patient subjective history for the encounter. For each item in an issue worksheet, there can be zero or any observations per encounter. In other words, for each encounter you can have none, one, or several blood pressures taken. Each observation allows free text comments as well.
An encounter has a date and time of examination or conclusion. Each observation may belong to an encounter, but doesn't have to. A lab result, for instance, is not encounter related. An observation never belongs to more than one encounter. Also, each encounter is related to one doctor, the responsible physician. In some cases, such as in training situations or operations, there may be multiple doctors.