...
The intent is to develop specific archetypes for each examination finding. Yes, that will be a lot of archetypes, but probably not as many as you may first think.
The reasoning behind this is that while base pattern of the single OBSERVATION /+ multiple CLUSTER pattern appears sound and has withstood early implementations. Admittedly, these implementation initial implementations have largely been simple or free text based, so that detailed CLUSTER content has not been required fairly light on requirements for exam detail, and using SNOMED to define the 'System or structure examined' in the generic CLUSTER.exam has been adequate.
We are rapidly moving into a situation where we need to create archetypes that contain specific clinical examination content - this generic pattern is no longer enough.
We either need to build specific archetypes for each finding that can represent the specific findings accurately OR we need to build additional CLUSTERs that will expand this generic archetype. Either way we will need an additional archetype for each specific finding.
In recent months the CKM Editors have been discussing how best to solve this issue.
On the CKM today you will see the result of our first foray into building some of these specific exam-related archetypes, created over the past couple of years. Rightly or wrongly, they were each built as independent archetypes that effectively 'mirrorredmirrored' the generic CLUSTER.exam, but in reality have no technical connection apart from an intent to have identical atcodes where possible. This choice was made largely because of the technical issues with managing specialisations of ADL 1.4 in the current tooling. But let's not get distracted by the pros and cons of ADL 1.4 vs 2.0 here because we have to resolve the issues only with the tooling we currently have at hand. And yes, despite best human efforts, the resulting archetypes do have some inconsistencies.While there are pros and cons with these archetypes as is, they have definitely demonstrated that the fractal patterns work well from a clinical documentation point of view. For example: Exam of both eyes > Exam of an eye > Exams of lens; retina etc. Also Exam of abdomen > Exam of uterus > Exam of fetus.We now feel confident that the pattern principle of a single OBSERVATION with our ability to mix and match various exam CLUSTERS will allow us to eventually represent the full scope of clinical examination. This is a significant discovery, and many thanks to all those who have been involved on that journey of discovery! Most people won't comprehend the amount of trial and error that underpinned the evolution of this pattern!
Feedback required...
The reason why we haven't continued to develop more independent archetypes is related to implementer concern re querying, even with SNOMED embedded in the 'System or structure examined' data field in each CLUSTER.
In summary, so far we have established the following as a forward path:
- Base clinical pattern consists of the 'Physical examination findings' OBSERVATION.exam nesting 1..* one to many CLUSTER.exam archetypes within the 'Examination detail' SLOT. Note: if the state of the patient changes, or a different devices are used, then this pattern may need to be represented for each state or device variation.
- Clinical pattern for the minimum generic content for the CLUSTER.exam, now agreed and published. SNOMED, or similar, bindings to be applied to the 'System or structure examined' data element where possible.
- Acknowledgement that we will need to create archetypes that capture additional detailed content that is specific for each examination.
Unresolved is the best approach for representing the detailed content for exam findings . Our choices:
...
We now feel confident that the pattern principle of a single OBSERVATION with our ability to mix and match various exam CLUSTERS will allow us to eventually represent the full scope of clinical examination. This is a significant discovery, and many thanks to all those who have been involved on that journey of discovery! Most people won't comprehend the amount of trial and error that underpinned the evolution of this pattern!
The current issue and proposed solution...
We are rapidly moving into a situation where we need to create archetypes that contain specific clinical examination content - this generic pattern is no longer enough.
Two options have been identified as a way to represent each exam specific finding:
- build specific CLUSTER archetypes for each exam finding, specialised from the generic Exam archetype despite the limitations of ADL1.4, that can carry the specific findings accurately;
OR
2. build CLUSTER archetypes for the specific content to be inserted into the 'Examination findings' SLOT within the generic CLUSTER.exam.
No matter which way we jump, either way we will need us to build an archetype per specific finding.
Some examples of use cases for the family of CLUSTER.exam specialisations are represented in the following files to further illustrate the modelling pattern intent:
Based on our discussions with a limited group, we recommend the first option, but seek broader feedback.In the meantime we started to move forward with investigating the first option.
In this modelling there is an inherent assumption that in most situations 'examination' refers to all modalities of physical examination applicable - ie any/all combinations of inspection, palpation, auscultation and/or percussion. This covers most clinical examination well - except where it doesn't!
In response to implementer requests we have created some new archetypes to test the specialisation approach in recent weeks - Examination findings (CLUSTER.exam) has been specialised to create both a generic Inspection findings archetype (CLUSTER.exam-inspection) and a generic Palpation findings archetype (CLUSTER.exam-palpation), to support querying on a fairly limited number of examinations where Inspection or Palpation are the only methods used. The use cases that we have identified so far are limited to the vagina, cervix or rectum. For examination, recording inspection of any of these sites using a specific device. If the clinician also palpates these sites as part of examination, then they will usually do it using another instance of the OBSERVATION because of the change in device or patient state.
...
- We have not yet identified a use case for a generic auscultation archetype - CLUSTER.exam-auscultation - so at present we are not intending to create this archetype for future specialisation purposes.
- Auscultation of heart sounds will likely be modelled as part of the proposed CLUSTER.exam-heart as we have not identified a use case where this will be reused elsewhere or recorded in isolation to other types of heart examination.
- Archetypes for breath and abdominal sounds are specific use cases which will need to be represented as separate CLUSTERs so they can be re-used within either of CLUSTER.exam-chest and/or CLUSTER.exam-abdominal examinations. We haven't been able to identify any value in specialising them from a generic CLUSTER.exam-auscultation.
Some examples of use cases for the family of CLUSTER.exam specialisations are represented in the following files to further illustrate the modelling pattern intent:
Please note that the only CLUSTER archetypes currently on CKM that represent this proposed pattern are CLUSTER.exam, CLUSTER.exam-inspection and CLUSTER.exam-palpation.
...