For the modelling of templates for a (status) report we are unsure about which archetypes to use. The report consists of many individual findings/symptoms, most of them only recorded as present/absent. So far, we have mostly modelled them using the generic Physical examination findings archetype(s). Now we are considering using the Symptom/sign screening questionnaire instead, as the structure and elements match our requirements well. However, we have some concerns regarding correct usage. Are the Screening questionnaire archetypes specifically meant for questions directed at the patient, or can it be extended to this use case for recording simple present/absent data?
Hi Jonas,
If you wish to very simply record whether a predetermined list of symptoms are present, absent or unknown/unsure, I’d recommend using the Symptom/sign screening questionnaire archetype. However, it depends a bit on the actual context of the clinical situation. If the context is the clinician actually examining the patient and recording findings, the Physical examination findings is probably more appropriate.
Hi Silje, thanks for your answer!
So we do have a long predetermined list of symptoms, with the answers being recorded by a clinician screening for those. From your answer I am still unsure how to go forward, as I still feel that both options kind of fit, but it is neither a “proper“ physical examination or a questionnaire (but rather a screening). Do you feel that using Symptom/sign screening questionnaire instead of Physical examination findings is justifiable, despite it being simply a list of symptoms without specific questions attached? We are leaning towards that option, as it would simplify and decrease the work for the various similar reports we will need to model.
- Does the clinician ask the patient “do you have this or that symptom?”, or do they examine them?
- Are yes/no(/unsure/unknown) responses a necessary part of the data you wish to record, or would the presence or absence (and potentially much more details) of specific findings on examination fit better with your requirements?
- The clinician does not ask the patient, it’s a brief examination (screening) for signs in a status on admission report consisting of 100+ elements
- most signs are recorded as present/absent, some of them consist of a small list of possible values, for example:
General state of health: Good / poor / poor due to pain
Oriented to time: Yes / no / partially
Sensibility upper extremity left: Normal / pathological
To me this looks like variations of “Clinical interpretation” in the CLUSTER.exam archetype.
Hi Jonas,
I’d be very interested to see more examples. In fact, if you could share the full report it would inform current work where Editors are in an active phase of investigating and documenting the next level of patterns within the CLUSTER exam findings archetypes. It has been anticipated that there may well be a Present/absent/indeterminate pattern for significant positive and negative findings.
For example: see https://ckm.openehr.org/ckm/archetypes/1013.1.3914. In this nearly 10 year old example, recording ‘present’ and ‘absent’ for a variety of related findings is potentially a valid way to record physical examination, rather than just used for screening purposes.
Kind regards
Heather
Hi Heather,
The full status report as pdf: Status.pdf (687.8 KB)
Roughly translated to English (using AI): Medical_Status_Report_Translated.pdf (4.5 KB)
Hope this gives you a better idea of what we are working on.
Hi Jonas,
Yes, thanks for that. Very helpful.
Like most questionnaires and screening tools developed de novo, they reflect the best resources and intentions of their creators at the time. As we build richer patterns of documentation within archetypes, we repeatedly uncover inconsistencies, such as mixing screening constructs with measurements or clinical findings. Without a strong semantic anchor, this kind of drift is entirely understandable. Hopefully, as archetype standardisation matures, it will begin to influence how these reports are designed in the future. In the meantime, our focus is on creating clear, consistent models that help reveal these inconsistencies and guide better practice.
It is unclear to me if this is a custom report for secondary purposes or if it is intended for primary documentation.
If we break it down to identify various component archetypes that could be included in a template for this report:
- General - unusual value set, no current archetype
- Nutrition status - suggest EVALUATION.food_nutrition_summary>Nutrition status
- Height/Weight/BMI - use corresponding purpose specific archetypes
- Orientation - may be added as discrete data elements to the current MSE draft archetype: Observation Archetype: Mental state examination (MSE) [openEHR Clinical Knowledge Manager]
- GCS - Observation Archetype: Glasgow Coma Scale (GCS) [openEHR Clinical Knowledge Manager]
- Alertness
- Mental status - ‘unremarkable’. Seems a conclusion , rather than an assessment or finding. I think adding ‘Clinical interpretation’ as an addition to the MSE OBSERVATION for this purpose would be useful for all.
- Eyes - consider the CLUSTER exam family for both eyes (to compare) and a single eye for discrete left and right findings.
- Lips - Color is a reasonable observation; cyanotic is an interpretation of the color. No current archetypes for this purpose. Need a specialised archetype for both lips for this purpose. Based on the parent https://ckm.openehr.org/ckm/archetypes/1013.1.6153
- Teeth - value set reflects conclusions, ie a clinical interpretation, not actual findings. Need a specialised archetype for both lips for this purpose. Based on the parent https://ckm.openehr.org/ckm/archetypes/1013.1.6153
- Tongue - value set reflects conclusions. Record in https://ckm.openehr.org/ckm/archetypes/1013.1.3902>Clinical interpretation
- Hearing - this is odd to record this as a finding of a ‘hearing examination’, given that usually requires formal testing and result reporting. Normal/Deaf is more likely to be recorded as a Diagnosis.
- Heart - consider Exam of the heart archetype: https://ckm.openehr.org/ckm/archetypes/1013.1.3928
- Heart sounds ‘Normal’ is a conclusion but may be appropriate to record in ‘Heart sounds description’ for now. I suspect a detailed archetype for documenting the intricacies of heart sounds may become a future cluster or separate CLUSTER archetype that would be nested in this one.
- Heart murmurs - as above
- JVP - ‘Clinical interpretation’ within the JVP archetype - https://ckm.openehr.org/ckm/archetypes/1013.1.3556
- Hepatojugular reflex is not currently represented in any archetype, but present/absent is a valid way to record as part of physical exam findings. You can see a similar representation of a Present/Absent pattern represented in the External Auditory Canal archetype - https://ckm.openehr.org/ckm/archetypes/1013.1.3914. This may be a useful way to add significant findings to existing or new specialised CLUSTER exam findings. And often associated with a description to provide more detail.
- Oedema - https://ckm.openehr.org/ckm/archetypes/1013.1.117 may be useful for you, but it is not oriented for recording in quite the way in your proposed form.
Rather than work through every element of the form in detail, I hope you can see that many of your requirements are already well covered by our existing archetypes. More importantly, this comparison highlights the varied approaches that the form takes in documenting findings, conclusions, and interpretations, often intermingling them in ways that can be difficult to untangle, especially to non-clinicians.
This is the interesting insight for me. By converting legacy paper forms into digital representations built on standardised and structured patterns, we consistently uncover issues and insights that were not previously obvious. This includes clarifying the real intent behind each documentation element. It is one of the strengths of structured modelling. If we were to redesign this report from scratch using the established archetype patterns, and only develop new ones where necessary, the resulting iteration would be more systematic and consistent. Translating forms in this way does more than digitise them. It also brings to light implicit assumptions and design inconsistencies that may have remained hidden for years.
Regards
Heather
Hi Heather,
Thank you for the detailed response. I feel that we can represent most elements using “Clinical interpretation”. In this case, would you recommend creating specializations of the CLUSTER exam archetype for each concept? So far, we have regularly used the given unspecialized physical exam archetypes and adapted the template instead. Is there a critical drawback to that approach that I might be missing, given that we are creating small templates to be reused as building blocks in other (report) templates?
See: Linking multiple compositions with a "compound composition"
This is the intent. You can see this CLUSTER pattern slowly evolving for both the physical exam and imaging exam archetypes.
This is an option but the parent/unspecialised CLUSTER needs to be adapted for each version of the template and then governed locally. If we gradually build up a published library of very specific exam CLUSTERs which are optimised for systematic and consistent reuse. Your approach can work nicely locally but has no interoperability with other systems and replicates the increasing problem in FHIR of ‘profiliferation’!
The original intent of the parent exam CLUSTER is for generic use where no specific CLUSTER exists. This is useful now, but over time, its use should diminish.
That said, the design and use of composable ‘embedded templates’ is a great approach to standardisation of local ‘chunks’ of data. This is underpinning the templates found in the Public health surveillance incubator featuring a Master template, data collection (document) level templates per infectious disease and nearly 100 embedded templates designed for reuse across different data collections.
Regards
Heather
I agree with this assessment, Heather but would also think that there is an argument for both specialising, and then wrapping in an embedded template, to fill slots and add the local term constraints. As we move to ADL2 , templates essentially become specialised archetypes but with the ability to fill slots , and to define local termsets/valuesets.