This page and its child pages have now moved to the ADL space. Please change any stored URLs to the new location.
Are data instances (as in, an instance of the reference model) conformant with an operational template
purely by passing the constraints contained within in, or do they somehow expressly indicate that they should be evaluated against a particular operational template?
For example, an instance of a composition has an archetype_node_id within in with
a value such as openEHR-EHR-COMPOSITION.encounter.v1. We can say whether any
instance is valid if it meets its specified archetypes' constraints.
For a template, there is no data in the instance mentioning the ID of the operational
template? So all running operational templates that match up on the archetype_node_id
may or may not apply to the instance? I'm just wondering how a system can receive
instance data from an outside system and know which operational template is intended
to apply, not just which operational templates happen to apply at this point?
See http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109318114715_211173_0Report.html - the ARCHETYPED.template_id attribute is used to record the template id at the root of the data instance (COMPOSITION etc).
A composition can have a template ID associated with it. The real point however is that there will be lots of different templates - local, regional etc. If a template must apply to data to be transfered then it has to be validated against that template (even if it is not provided in the composition). Sam Heard
Sam, I don't understand your comment - are you saying that an instance may be validated
against a particular template even if the template is NOT listed as the ARCHETYPED.template_id
of the instance? This was what I was getting at in my original post - is
conformance to a template an explicit decision of the data instance (i.e. recorded
in ARCHETYPES.template_id), or implicit (i.e. the data matches the constraints
of template X, Y and Z and therefore can be said to meet all these operational
Hi Andrew - missed this. Templates, unless specified in the shared space for say, a post-natal discharge summary or the like, will be local. The semantic interoperability has to be based on a shared set of archetypes. It will be possible to edit a composition when you do not have access to the orginal template - is the result still conformant?
Sam, I don't think you've quite got what I was trying to get at.
Let's imagine we have two templates
which constrains the blood pressure to 'sitting' and 'exertion' of 0
which constrains the blood pressure to 'sitting'
I am running a system in NSW that receives a blood pressure
instance, where the recording was taken in a sitting position with
no exertion data.
What can I as a receiving system say about this instance? If the
instance explicitly mentions racgp-blood-pressure.oet in
its ARCHETYPES.template_id, can I also say
that I am also valid against nsw-blood-pressure.oet? What about
vice-versa? If no template is mentioned at all, can I implicitly
say I am valid against both (because I meet the criteria of
What about if someone now wants to
make a correction to the instance? Can I now let them say the
blood pressure was actually taken 'standing' if I have already
implicitly said this instance was valid against these templates?
What is the practical results of 'unconforming' an instance
Wasn't more or less decided that there would be a separated clinical template & a visualization template? In my opinion, 'pass_through' flag should not exist here
Although strictly speaking, pass-through is a GUI directive, it is actually quite important in tidying up the visuals of a template in clinical review and authoring tools, not just in the runtime GUI environment. For that reason, I think we should keep it in the proposed 1.5 .opt definition but other new directives should definitely be in a separate visualisation layer.
So tooling over models? 'Tidying up' seems a weak reason for a change with that implications. If we agree that there are two models, then everything should go into his rightful place. If not, everything should end up in this model, not only pass_through.
Any updates to grammar files ? ;)
Maybe this is a good opportunity to change the name of the "ontology" section to something more like "vocabulary", IMO is more appropriate.
Powered by a free Atlassian Confluence Community License granted to The openEHR Foundation . Evaluate Confluence today.