The COMPOSITION class has several top level attributes, including category (1…1), composer (1…1), context (0…1) and content (0…1).
It makes sense that you can’t persist a composition with no composer or category, but to my mind that goes for context and content as well. So my question is, are there specific reasons why context and content aren’t mandatory?
Technically you could have a compo with context and without content and vice versa. Then a template should specify if any of those is required at runtime.
Do you have a real world use case for that? I can’t think of any.
Re context, see see the following two extract from
Event Context Overview and Event context: Occurrence in data
Situations in which Event context is not used include:
Any modification to the EHR which corrects or updates existing content, including by administrative staff, and by clinical professionals adding or changing evaluations, summaries etc. Patient-entered data where no interaction with health professionals took place; typically readings from devices in the home such as weighing scales, blood glucose measuring devices, wearable monitors etc.
In this example, a Contribution is made to the EHR, consisting of one or more Compositions that were each created or modified due to some clinical activity. Within such a set, there will usually be one Composition relating directly to the event, such as the patient contact - this is the Composition containing the doctor’s observations, nurses’ activities etc, during the visit, and is therefore the one which contains the
EVENT_CONTEXTinstance. Other Compositions changed during the same event (e.g. updates to medication list, family history and so on) do not require an Event context, since they are part of the same Contribution, and the event context of the primary Composition can always be retrieved if desired.
So far what the specs offer on context being optional…I assume however this could also have been modelled differently in a way that the context is always mandatory.
Re content, see the following extract from
Composition Content
it may be empty. Although for most situations, there should be content in a Compostion, there are at least two cases where an empty Composition makes sense:
the first is a Composition in 'draft' editing state (VERSION.lifecycle_state = 'incomplete') the second is for systems that are only interested in the fact of an event having taken place, but want no details, such as so-called clinical 'event summary' systems, which might record the fact of visits to the doctor, but contain no further information. This can be achieved using Compositions with event context, and no further content.
My take is that the first use case is a general one and would not justify content to be optional. The second one is a use case I guess, albeit a somewhat feeble one.
We do actually have one. Where (and arguably lousy modelling!!) all of the data was essentially pseudo-demographic clusters , so put in context. I guess there was some future expectation to have items in content as well.
Does it matter?
When a partial composition is stored without data would be a real world use case, if a system supports that.
But wouldn’t a partial (I assume here that means not finalised) composition need to be persistable whether it validates or not?
It is - a change was introduced to the RM recently allow ‘incomplete’ compositions to be persisted even if they do not validate.
Good! But then that use case isn’t a requirement for keeping content optional?
That’s a fair point but I can also imagine some cases where a composition is just a minimal wrapper around some RM data plus e.g. feeder_audit.
What’s the counter argument to prevent content being empty? I’m happy to agree it is probably not best practice but what problem does it cause to allow it to be empty.
That’s a design/implementation decision. The model allows 1. to have incomplete commits, 2. to have no content on a compo, 3. to have no context on a compo. Then how we use those rules, is up to us.