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.