I wonder if there is case for rationalising the current Medication summary archetype and Medication screening. THe use case we have from Wales, for a couple of different projects looks very like Summary - including episodic use but also aspects of screening particularly the 'overall use 'type status.
This is the specialised archetype we are currently using.
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:
It is a work in progress.
Thanks Heather,
Very helpful. We’ll take another look at the requirements with these suggestions in mind.