Keeping a clinical list up-to-date in a local EHR current is not a trivial task. Keeping it up-to-date and accurate in a shared environment - well... Read on. It is not easy. The classic lists are:
- Allergies/Adverse Reactions;
- Problem/Diagnosis;
- Medications;
- Procedures; and
- Family History.
At very least, in a shared environment we need common data models and curation, usually by a trusted physician in close consultation with the patient - technical and human factors. For example, the only person who *really* knows what medicines the patient is taking, is the patient themselves. Without the patient front and centre, involved and contributing, a true 'current' medicine list is impossible.
And so the data that underpins an accurate list is critical. I've already posted once about this - Unambiguous Data: Positive Presence, Positive Absence. The openEHR preferred approach is to record the positive presence of information AND the positive absence of information separately, using specific archetypes for each purpose.
If we use Adverse Reactions as a working example (which we will assume includes allergies, hypersensitivities and intolerances as well), we need to be able to be certain about each of the following types of data:
- Following enquiry or investigation, we need the ability to record explicit and general statements about the the absence of any adverse reactions, allergies, hypersensitivities or intolerances in the patient's history to date, using the EVALUATION.exclusion-adverse archetype. For example, "No known adverse reactions" which is only accurate and up-to-date at the exact time of recording. A split second after recording, it may be out-of-date as an adverse reaction to an administered medicine might occur immediately, thus rendering the statement obsolete and triggering recording of the patient's first ever reaction to a medication. Generic exclusion statements should be reviewed regularly and this can be prompted by the 'Last updated' data element in each archetype. Some would argue that generic exclusions should only be recorded in event-based data (for example, as part of a consultation note) as it is only accurate at the time of recording, but it depends on how the persistent lists are managed in the clinical system.
- Following enquiry or investigation, again, the ability to record explicit and specific statements about absence, using the same EVALUATION.exclusion-adverse archetype. For example, "No known adverse reaction to Penicillin". As above, regarding accurate only at the time of recording. Again, specific exclusion statements should be reviewed regularly and this can be prompted by the 'Last updated' data element in each archetype. Some would argue that this should only be recorded in event-based data as it is only accurate at the time of recording, but it depends on how the persistent lists are managed in the clinical system. As above, some would argue that specific exclusions should also only be recorded in event-based data.
- Following the occurrence of an adverse reaction from any physiological mechaism, the ability to record specific inclusion statements about the explicit knowledge that a reaction to a known medicine or class of medicines has occurred - no matter if minutes ago, years or decades. For example, a rash in response to administration of Penicillin, using the EVALUATION.adverse_reaction archetype - typically recording the name or class of the medicine, substance or agent plus supporting details about the reaction manifestation.
Thus, three types of data:
- General exclusions
- No past problems or diagnoses
- No relevant surgical history
- No significant family history
- Specific exclusions:
- No history of diabetes
- No previous appendicectomy
- No family history of diabetes
- Inclusions
- Diagnosis of diabetes mellitus type II
- Appendicectomy, 1998
- Family history of heart disease, epilepsy
Each of these kinds of information clearly needs to be recorded and persisted in an electronic health record as per each of the examples above. A clinical list may be updated automatically by the computer system where it is clinically absolutely safe to do so, but must be curated and updated by a clinician expert where in situations where clinical knowledge or discernment is required.
It could be argued that simple business rules in a standalone clinical system could ensure that in a new record for a new patient, and where no entries are stored regarding the presence or absence of any adverse reactions, that the system:
- can reasonably infer no information is available;
- should display some kind of clear message to the clinician that there is "no information available", neither present or absent, about the patient's adverse reaction status; and
- prompt the clinician to record appropriate explicit statements of presence or absence during the next clinical consultation.
'No information available' is quite a different statement to previously noted assertion that there are "No known adverse reactions" which follows careful inquiry and evaluation by a clinician.
It is probably good practice that a new patient record in a clinical system should start with a default statement such as "No information about adverse reactions is available", rather than just inferring that no information is available based on no recognised data entries about explicit presence or absence. This is therefore the fourth type of list that is relevant to persistent clinical lists
There is a 'grey zone' when information needs to be exchanged between systems or aggregated into a central system. To receive in a message an explicit statement that there is 'no information about adverse reactions available' enables the receiving system to understand the adverse reaction data situation unambiguously and reflect that in the receiving record appropriately. If no explicit information is sent in the message, the receiving system does not actually know if that reflects a true absence of data; a positive exclusion of data; or that there is an error in the message. The apparent absence of data for the clinician, no matter if not available or missed in error, will not change their clinical practice - they will still need to ask about adverse reactions prior to prescribing. If the patient can provide the information, then inappropriate medicine administration is averted, but if not, then there is a potential clinical safety risk to the patient.
Other arguments for explicitly stating that there is no known information occur in situations where the patient is not able to answer, for example if unconscious. Clinical management will still proceed, based on whatever information can be gleaned and with the clinicians needing to be prepared for anything! A slightly more complicated scenario ,which is medicolegally significant, occurs when an uncooperative patient, will benefit from the recording/exchange of 'no information available' as data plus the corresponding 'reason for no information'. Similarly, other knowledge related activities, such as clinical decision support, will also benefit from explicit and consistent use of statements of inclusions/presence, exclusions and absence/no information.