CKM Editors are currently working hard to clearly separate Medication EVAL data (persistent, evolving summary) from OBS data (questionnaire-style). We are teasing it out and the result will be seen in the next iteration of the Medication Summary (EVAL) as it emerges from the recent review.
The successful pattern for representing ‘Status’ in many of the EVAL archetypes is ‘past user’/‘current user’/‘never used’.
‘Ever used?’ applies to both current or past/ex and tends to be used in questionnaires with a Yes/No answer.
If I am not using a med today but start tonight, my answer to ‘ever used’ goes from No to Yes. If I am using a med today but stop tonight, my answer to ‘ever used’ is unchanged as Yes.
In the same sequence of scenarios, the Status data element changes from Never used to Current user to Past user.
Quite different semantics.
In the real world, the data is messy and often questionnaire-like data sits with summary data and unless you choose to frame it in ENTRY classes, most people don’t even notice the subtlety. So it’s often tempting to model the mess as it is rather than tease it out, but this approach is a compromise. If the consequences of the compromise is understood then it is made as an informed decision, but I suspect it is not helping to provide a road map for good future modelling. The more I explore and understand the ENTRY classes, the more I appreciate the science and ontology that sits behind them and it helps me to model better quality archetypes. The classes may have been designed in theory but I’m appreciating their value and elegance in my modelling practice.
My increasing conviction is that Yes/No or Boolean answers usually belong in a screening questionnaire (OBS) rather than persistence in a health record.
The semantics are subtle but we’ve gradually teased this pattern out and it seems to have been working well in widespread testing and implementation, especially during COVID. The changes that have been added to your specialisation munges both questionnaire and persistence. I’d model it as two archetypes about the medication but for different purposes, sitting alongside and complementing each other in a template.
The many facets of managing Medications are complex and as a result, is represented using a number of classes. Editors are currently working on clarifying the scope of each Medication-related archetype to ensure the scope and purpose of each is clearly demarcated to avoid both semantic overlaps and gaps, and clearly documented/described to support modellers. The INSTRUCTION and ACTION are pretty simple to understand when and where to use, so the focus is currently on adding clarity to:
- EVAL.medication_summary (currently emerging from a review and about to be committed back to the trunk) as a summary or persistent information about the use of a single medication or group of medications where the pattern of use or cumulative dosage needs to be monitored;
- OBSERVATION.medication_statement as a snapshot of what is being taken or to be today, especially for use in situations of transfer of care, eg last dose administered; and
- OBSERVATION.medication_screening to support screening questionnaires for use in systematic questioning in history taking or disease registries or questionnaires.
It is a work in progress.