Hi,
The standard RM attributes for composition and entry classes include the subject and participations in all of them. When we model templates(for 1.4 OPTs), the entry archetypes always goes inside a composition(such as encounter). In a template with more than one entry archetypes, while the participations could be different for the encounter and the entries, the subject is always the same.
What is the recommended practice in recording the subject? do we do it at the composition level or at the level of each entry? Does either approach have any implication while using AQL?
Also in the 2.0 OPTs, as I understand, any entry archetype can be specialized as a template and do not need a composition holder. If that is the case, do the standards RM attributes for entry get extended to include the missing composition RM attributes (author, healthcare facility, event start time etc) when they are specialized into a template?
An Entry archetype can be set up as a source template, but an OPT will only be generated for a committable structure (at the moment at least), i.e. a Composition, or a Party subtype if you’re doing demographics.
We are looking at more flexible retrieval information structures such as an Entry associated with its owning Composition’s context data.
Hi Dileep, as Thomas has said there is no change to the requirement to commit compositions. The idea of the Entry level templates is to allow to configure constraints that are easy to reuse across compositions eg a constrained blood pressure archetype that only has systolic and diastolic exposed but also has a device cluster plugged in. We can easily reuse this pattern in multiple compositions. The tools just show it as another component that can be dragged in to the composition template.
Thank for the link to the composition UML which does not include the subject of care attribute. However in the CKM, the Reference model tab of the encounter (and all composition) archetype shows a Subject of care attribute (see screenshot attached).
I was unaware of that. I am not sure why that is there, because it is somewhat misleading. The ‘subject of care’ in EHR_STATUS (this bit of the model) is a global (for the whole EHR of one patient) and optional. If it is set, it identifies the subject being indicated by instances of PARTY_SELF in ENTRYs. There is still no ‘subject’ as such, in a COMPOSITION - indeed a COMPOSITION can contain ENTRYs referring to different subjects.
Secondly, the EHR_STATUS.subject is often not set, if full EHR/demographic separation is being observed, and in that case, the subject of an EHR is only knowable by resolving the EhrId through a service to obtain the subject.
I imagine that this ‘subject of care’ item has been included in the COMPOSITION RM attributes to remind clinical modellers that they don’t need to model subject in each COMPOSITION. Personally I would prefer to see this done in another way.
@Dileep_V_S - apologies I missed this when you first asked.
This my fault!! Years ago I wrote some stuff to be included on the CKM RM attribute tabs, as a way of giving clinicians some idea of what RM attributes might be available.
Either I just got this wrong , or was (badly) trying to convey that the subject is always available via the parent EHR object -either way it needs fixed!!
The RM tab in CKM was an attempt with the primary aim to convey the bits and pieces a clinical modeller or reviewer does NOT need to worry about.
I remember some discussions about how ‘flexible’ we should be with this regarding the RM - but in it’s current state, it’s neither necessarily a complete list of attributes for each class nor is it necessarily directly restricted to it.
That’s one reason why we also link to the specs directly and clearly indicate the actual RM attribute described in the text, in this case: (RM: ehr/ehr_status/subject)
This is a few years old (and also the general understanding of the RM has improved) so this is worth revisiting.
We can easily change the wording or remove this “attribute” completely.
