I am trying to work out the most appropriate way to represent the progression and lifecycle of a condition/diagnosis using OpenEHR.
I’m a developer working on a team with clinicians, but I don’t have a medical background myself so please forgive my naivety. Some contrived examples I’m trying to work out how to represent are:
A skin condition that spreads to new body sites over time.
A cancer that changes “stage” over time and also spreads to new body sites. It may also go into remission, but may also come back.
A single burn incident with different severities (e.g. full thickness, partial thickness) across different body sites that is evaluated on multiple occasions.
Distinct (i.e. unrelated) occurrences of the same type of condition (e.g. flu, burns, broken bones, etc.)
The problem/diagnosis archetype seems appropriate to store any of the above for a single point in time, but it’s not clear to me how to represent the change over time.
The approaches I’ve considered so far are:
1. Amended the problem/diagnosis as needed in order to represent the current state.
The fact that the problem/diagnosis archetype has a “Date/time of resolution” implies to me that this may be the correct approach, but then how would you represent the previously evaluated states to see the progression.
2. Create a new problem/diagnosis for each progression.
But then how would you connect these all together in a way that the cancer progressions are linked together as events of the same condition, with the most recent being “current” while the rest are historical/superseded. While at the same time not inherently linking every occurrence of the flu as one long condition, particularly when these may never be marked as resolved because the patient doesn’t return when it has cleared up.
I’m aware I can distinguish between acute and chronic conditions which I think gives important clinical context to the above flu scenario, but even an acute condition may have several evaluations connected to one occurrence.
3. Look at other archetypes like "Story/History"
I haven’t come across any that seem to quite fit. Story/History for example is described as subjective information reported by the patient.
Besides what you can model in compositions, remember your can always use folders to group compositions, for instance about a certain condition or health problem.
Problem/Diagnosis has the ‘Last updated’ data element in Protocol, so intended to be entered once per problem or diagnosis and evolve/be revised over time. Part of that evolution might be adding new body sites for the skin condition. The course data element will allow the narrative of progress to be recorded and grow in detail as necessary
The problem/diagnosis qualifier, nested in the ‘Status’ SLOT in Problem/diagnosis may also have some useful things for you - allows you to say first ever diagnosis; new diagnosis (eg acute ear infection) or ongoing (the previous one persists, may be chronic and require different treatment); resolution phase and remission variables - Cluster Archetype: Problem/Diagnosis qualifier [openEHR Clinical Knowledge Manager]
I agree with Heather’s advice regarding your first two examples. Regarding the last two I don’t think it’s necessarily a good idea to update the same instance of the Problem/diagnosis archetype, though.
This example would in my thinking also involve recording more detailed examinations of skin (for which we have an archetype: https://ckm.openehr.org/ckm/archetypes/1013.1.3933), and examinations of identified lesions/wounds/burns (for which we’re in the early phases of modelling). If you need to follow specific lesions across the body surface as a problem list entry, this may warrant multiple parallel instances of the Problem/diagnosis archetype.
For this example I would have thought you would want a specific date of occurrence and resolution for each occurrence of the disorder. So maybe a series of instances of Problem/diagnosis archetypes would work better for this?
Correct me if I’m wrong, but this is a text field, so while it would be very useful for recording notes, it wouldn’t be “structured” data that could be queried. It would also require that data is entered multiple times i.e. in the “structured” location as well as the narrative. Presumably there is also the likelihood that the clinician may not narrate everything that they changed in the structured data.
My concern with amending the same record is that I’m assuming we’d lose the ability to perform queries such as “what is the average time between stage 1 and stage 2”, “how often is cancer initially diagnosed at stage 1”, and “how often and quickly does a particular skin condition spread to other body sites”.
Even going beyond the problem/diagnosis, I imagine it would be valuable to know the exact state of a condition at the time an action, such as a surgery or prescription, occurs. E.g. “how often is an action undertaken at stage 1 compared with stage 2”.
There are technical solutions to some of these problems, such as Event Sourcing, but I want to make sure I take full advantage of the structured data as much as possible.
Yes, it is intended as free text. We often not only need structured data (and then only where it makes sense) but a narrative to hold the subtler nuances that can’t be captured in structured data. Structured data should not be captured for data’s sake, so finding the balance between the two is important, and our philosophy is only to structure data when we have a real-life use case. If you have requirements that are new, please feel free to discuss it here or make a change request to the appropriate archetype in CKM.
We’re not suggesting amending or overwriting, but creating a new revision, so that you could query the of previous revisions that might have been recorded as part of prior consultations.
I’m a bit concerned about this. This is a secondary use of the data recorded in the EHR, and implies queries across patients, while openEHR is mainly for the documentation of the medical record for the individual. Imposing requirements for research in the EHR is a double-edged sword, and might overload clinicians, and hence lead to poor data quality due to “click-fatigue”.
An other way to deal with this is to export data to another db, more suitable for cross-patient queries, i.e. a research repository.
Oh, while I’m at it: Clinical representatives involved in describing requirements for the EHR, are often “into IT” in a way, and very often also interested in using the structured data for other purposes. Which is good, but there is a similarity to the lyrics in the Swedish rapper Timbuktu, which is translated to “Everyone wants to go to heaven, but no one wants to die” - transformed to health IT: “Everyone wants research data, but no one wants to record them”. As a health informatician/developer, you must ask: “Is this piece of data something you need for your treatment, or is it ‘nice to have, some day’?”
(Sorry for ranting, been working in the area for 24 years…)
Really good point about not trying to develop an EHR with imposed secondary use requirements - I completely agree with that approach.
Perhaps another example along those same lines would be the need to track the speed of progression of a disease, in order to provide clinical decision support recommendations.
As a made up example for Diabetic Retinopathy, if the patient progresses from stage 2 --> stage 3 in under 12 months, they should be seen by a specialist.
The other responses above seem to provide a solution (thanks Heather/Silje/Pablo!), but I’m interested in hearing your thoughts on how to approach the storage of this data.
Great point, Vebjørn. I completely agree. Don’t get me started on non-medical services that require irrelevant information like age and sex!
The examples I used were just plucked from my head as a medical layperson and I would certainly hope that any data collected and reported on would be for the benefit of the patient. I think Kieran provided a great example that is probably a lot closer to reality. I certainly wouldn’t want to put any burden on the clinician or the patient and believe the tools should be designed foremost for them.
My concerns are mostly around not overwriting previously entered data with new values so that the previous values are no longer accessible. Not only for reporting and research, but also from an auditing perspective. I can’t see sense in losing historical medical data.
I can also think of a few ways to solve this from a technical perspective, but I really just want to make sure I’m not overlooking any idiomatic approaches in OpenEHR and not reinventing the wheel.
Are you implementing this using an openEHR CDR, or other development methods? With a CDR, keeping a revision history and auditing should be handled as part of the platform, IIRC.
We are also right in the mix with this around Cancer pathways and happy to share emerging thoughts. Basically I agree that Problem/diagnosis with staging handled via TNM or other appropriate condition-specific cluster archetypes is the right way to do this. The burns example feels more like repeated observation-based assessments, with only a headline Problem-diagnosis with ‘Extensive full thickness burns’ - too much detail to really carry in the Problem per-se.
John Meredith and I would call that a contextual Problem list (same for cancer pathway) - a Primary problem then co-morbidities, complications etc. Constructed to support care for a specific condition or admission event. In a perfect world that would be drawn from a universal problem list but that is pretty hard to govern.
I’d slightly disagree with @varntzen. Completely agree that this is about patient-care but… I would hope /expect that the information
My concern with amending the same record is that I’m assuming we’d lose the ability to perform queries such as “what is the average time between stage 1 and stage 2”, “how often is cancer initially diagnosed at stage 1”, and “how often and quickly does a particular skin condition spread to other body sites”.
I think this is legitimate as information that can be derived directly from patient-focused records. As Silje says, with a CDR and careful query creation you should be able to answer these questions. I agree with Vebjorn that it might be sensible to export some of the data to a separate database for either privacy or performance reasons but I would hope and expect openEHR to collect the data for secondary use (as long as the tail does not wag the dog).
Some great responses already. Problem oriented records can also help with these issues of morphing knowledge but there is whole other world of both clinical and technical complexity.
Is your environment essentially secondary care, where the records are generally maintained in a contextual way (condition / admission) or in a more longitudinal record, like a GP or community system?
Assuming a CDR with revision history, where would you store the date that a condition progressed?
The Problem/Diagnosis archetype has “Date/time of onset” and “Date/time clinically recognised”, however my understanding is that these are the onset/recognition of the overall diagnosis (e.g cancer) and not the onset/recognition of a progression within that, such as going from stage 1 to stage 2.
A revision history would record the date/time of the revision itself, but that wouldn’t necessarily be the same date/time that the problem/diagnosis changed from a clinical perspective, depending on how and when the revision is entered.
In a clinical record as you make a reassessment and record it in the consult notes it would be recorded as ‘Last updated’ in the EVAL.problem_diagnosis and also in the COMPOSITION as it gets committed.
The notion of a ‘date changed’ is not a usual data point in a health record per se.
If you’re working in a registry, you may need to create a CLUSTER archetype for your own local use, to carry these registry-specific data points.
If I’ve made incorrect assumptions, you might need to fill me in more on the context…
