What would be the composition archetype recommended for a template to record summaries such as Smoking & drinking? The best that I could think of is the encounter composition. Do let me know if any other is better suited.
On a related note, are there any rules or best practices in choosing the appropriate composition archetype to use for building templates? Are we planning to have more composition archetypes such as Medication list & problem list for use with all kinds of different templates?
The Lifestyle factors COMPOSITION is the one that has been built to carry smoking and alcohol data, plus other lifestyle related data such as physical exercise, nutrition etc – see https://ckm.openehr.org/ckm/archetypes/1013.1.1648
The intent for COMPOSITION design is to build ones that will support querying for the broad types of clinical data that we store. For example, Report has been specialised for a couple of extremely commonly used type of reports but I would not advise building one for every type of report, rather query on the Report COMPOSITION plus relevant ENTRY archetypes.
This is not a precise science but we are trying to be pragmatic – to balance the reuse of generic archetypes with clear and safe querying.
Thanks for your response. Your point of a composition being designed to record a complete encounter is worth another discussion.
I personally feel that it is one way of implementing your CDR, but there could be other equally effective approaches that work better in other situations. For example in the CDR service component of our platform (EHR.Network), we have gone with generic reusable templates such as complaints, diagnosis, medication summary, medication order etc. The application can compose the complete schema for different encounter/event use cases using a combination of these generic templates. The data gathered in any event is grouped together under episodes and events using the virtual folder service.
This approach ensures the generic nature of the platform, while maintaining it’s extensibility over time. It also helps us contain the proliferation of templates and keeps our library of commonly used stored queries to a manageable level.
May be there are other better approaches than either of these that are already being used by others. I feel the approach to choose will depend upon the requirements and so maintaining flexibility for the implementer will be crucial.
I would call my contribution as a question to the bones, end to name what we call skeletons in the closet or elephants in the room.
I was attracted to openEhR in last century when attending a HL7 WGM in 2007 in San Diego. By that time I was so convinced that CDA would solve my problems. Then I met Sam Heard and that meeting changed my whole picture.
Since that I am a fiercely openEHR advocate.
When talking about documents though, there are too many standards to describe them, and I really hate waste of time calling differents names for the same thing. Snomed ct has a hierarchy describing records artifacts, why don’t we simply adopt them?
Hope we can have a discussion on convergence and harmonization. I am all ears to listen to other’s opinion
Look at the metadata at the Composition level and you know what its purpose is.
This is the text describing the OpenEHR COMPOSITION A Composition is considered the unit of modification of the record, the unit of transmission in record extracts, and the unit of attestation by authorising clinicians. In this latter sense, it may be considered equivalent to a signed document.
it would be interesting if you could publish anything about your virtual folder design, because more is being added to the RM to standardise how FOLDERs are used to represent episodes, mainly based on how DIPS (Norway) and Code24 (NL) do it. See SPECRM-55 and SPECRM-56. THis is certainly not complete, and indeed we have not yet published a guide for how to use Folders to do this (there probably is not yet full agreement anyway). Nevertheless, both these vendors have sophisticated approaches to using FOLDERs for episodes, and it would be good to have any other ideas to add to the mix so that we could either standardise a single approach, or else describe a small number of extant approaches such that client software can figure out what kind of episode representation it is dealing with.
ANother thing, just for reference: from a formal point of view, what gets committed due to an encounter is always be a Contribution, i.e. an openEHR change set (thinking in DVCS, e.g. Git terms). A Contribution can contain any / all of:
completely new TLO(s)
new version(s) of any existing TLO(s)
change(s) to any existing TLO(s)
logical deletion(s) of any TLO(s)
changes to path structure of any TLO with such a structure (= directory)
Here, TLO = ‘top-level object’, which can be the following from the EHR model:
It is of course very common that the result of an encounter is just one new COMPOSITION, or one new version of one existing COMPOSITION - but just as with Git or any other versioning system, this requires a Contribution since it is still a change set.
Ultimately this is going to be about the context if use, and what you are trying to do. Smoking history will be asked in many different places and in many potentially different applications.
If you are working with a single app, then the lifestyle_factors composition is probably the sensible place as a default but in a multi-app platform environment, you may want people to be able to ask about smoking status in the context of a condition or disease pathway composition. Ultimately it is really about your wish/ability to maintain a single source of truth about smoking status
Here is an approach we took for a coProduced Patient Health Record
but we took a different approach for a condition focussed pathway document on Acute coronary syndrome - the key thing is that the archetype is identical in both cases.