Archetype Specifications ADL & AOM 1.5 home page
Skip to end of metadata
Go to start of metadata

Project Overview

This page and its child pages have now moved to the ADL space. Please change any stored URLs to the new location.


  1. 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?

  2. See - the ARCHETYPED.template_id attribute is used to record the template id at the root of the data instance (COMPOSITION etc).

  3. Anonymous

    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

  4. 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

  5. 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?

  6. 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
    the constraints)?

    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
    like this?

  7. 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

  8. Hi Diego,

    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.


  9. 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.

  10. Any updates to grammar files ? ;)

  11. Maybe this is a good opportunity to change the name of the "ontology" section to something more like "vocabulary", IMO is more appropriate.