This post is inspired by a slightly out-of-control discussion among people in the CIMI group. It’s a good discussion. The latest question that has come up is whether a DCM (Detailed Clinical Model) is a ‘model of use’ (i.e. some kind of data set) or a ‘model of meaning’ (i.e. some kind of ontological definition).
I guess I don’t want to get into what a DCM is, since that seems to be topical, but certainly an archetype is a model of use, not a model of meaning. I would expect DCMs to be the same – they don’t need to replicate the function of SNOMED CT, OGMS, FMA or other terminology / ontology that defines meaning.
HOWEVER… it’s not quite as simple as it sounds. One archetype, e.g. the Adverse Reaction one, is not itself a ‘model’ of a data set corresponding to a particular use. It is instead a group of data points to do with the topic ‘adverse reaction reporting’, any of which might be used in an actual data set – an ADL template.
Isn’t this a rather fine distinction, I hear you ask?
Actually, it’s unavoidable. There are 3 levels of modelling we need in order to achieve re-usability (i.e. every message or document between two systems is not a completely de novo design):
- the (reference) information model – definition of data types, basic data structures, any container types, context information.
- Regardless of what your content is, this stuff doesn’t change
- Examples: ISO 13606, openEHR RM, CDA Clinical Statement Pattern (but probably not the HL7 RIM – its function is different)
- clinical element definitions– re-usable definitions of what a systolic BP measurement looks like, what lab analytes for cholesterol test result look like, what data groups are useful for recording diagnosis information.
- Regardless of what combination your actual content comes in, these definitions don’t change
- Think of the models on this level as a kind of shop full of spare parts, arranged in groups for convenient management and use
- These ‘models’ contain items arranged around topic, and can be thought of as a development and governance unit
- Examples: 13606/openEHR Archetypes; Intermountain CEMs; probably at least some DCMs?
- clinical data set definitions– definitions of data sets consisting of specific combinations of clinical element definitions, for a particular use case or purpose, e.g. ’12 month diabetic checkup note’, ‘6 month antenatal check’.
- Often these data sets correspond to what may be found on a UI screen, or in a complete document like a national standard discharge summary form etc.
- Examples – ADL Templates; CDA templates
If you still don’t agree that the last two levels are different, ask yourself the following question:
- do I expect to define de novo ‘systolic BP measurement’ every time I create a form / document / data set / template that happens to include patient BP recording?
Hopefully you agree that the answer to that is ‘no’. If so, then you agree that the level implemented by archetypes and also the Intermountain Healthcare CEMs needs to exist. Hopefully you also agree that real information is collected and managed in what I am calling ‘data sets’ i.e. groups of elements need for a specific purpose. And hopefully we all agree on the need for an underlying information model to supply standard definitions of data types, basic containers, context etc.
So that’s 3 layers.
wolandscat
Woland's cat 
Hi Thomas,
I fully agree that we should be stressing the importance of the 3 layers. I have never been quite comfortable using “Models of Use” to describe archetypes, though this is quite appropriate to describe Templates.
I have been totyng with the the phrase “Models of Practice” to describe the archetype layer. Not sure this is quite right but it does capture the fact that these describe a small aspect of the practice of mediciane (some people might call this workflow), bringing together the biomedical aspects with those of the needs of doing and recording the job, which are often orthogonal to a biomedical view of the world.
I agree to the the size of the governance unit is important. Historically governance of the clinical information models tends to have been at single data point level (the data dictionary) which is very difficult to govern, (shades of trying describe a nice curry recipe in terms of basic chemistry). Alternatively we have message or domain level governance which is like a curry recipe where the ingredients are redefined each time and not safely reusable in other cooking domains. In other words the ‘Currys’ definition of mango cannot be reused in the ‘Sweets” definition of mango.
Being able to engage clinicians and other domain experts at the right level of governable granularity is vitally important, both in terms of comprehension but just the practicality of large-scale review and professional assurance
Ian
I strongly support the three-layer approach. My personal view however is that if clinicians tell me they want to see certain things together on one screen, they are describing a template, not an archetype. At CompuGroup, I take that approach and then extract the archetypes which support the required templates (views). This, together with other design principles, leads to much smaller archetypes than openEHR has. Our clinicians as well as software architects are happy with the result.
Could it be that openEHR archetypes have grown that big just because the template mechanism was introduced somewhat late?
Jörg
Hi Jorg, yes, what the clinician describes is certainly a template. It sounds as if you reverse engineer what the likely archetypes are from those requirements, which probably means you have quite a lot of small archetypes.
On the other hand, openEHR archetypes did come before templates, and were designed more ‘in-principle’. Over the years, clinical modellers have started to refactor these archetypes in order to get better reuse, so the number of data points per archetype is dropping. Currently the average in CKM is 20 substantive data point nodes per archetype. I suspect this will go down.
On the governance side, archetypes with (say) just one data point each are not desirable, because of the huge governance overhead it creates.
So I think some confluence of 3 factors – optimal size for a) ‘use’ (in templates), b) reuse (by other archetypes), and c) governance – is needed. The overall community doing this is learning all the time, and different orgs doing modelling tend to come from different requirements. Another direction is the need to replicate e.g. HL7v2 message structures.
Maybe another post is in order 😉