Skip to end of metadata
Go to start of metadata

Project Overview

This is the home page of the ADL / AOM 1.5 project. ADL = Archetype Definition Language, AOM = Archetype Object Model. For newcomers, here is a primer on archetypes.

Team

The following people are involved in the work reported on this page. Please email the project leader if you would like to be involved, or post on the openehr-technical mailing list.

Project LeadThomas Beale
EditorsThomas Beale
Contributors 
/ Reviewers* 
Koray Atalag, MD, PhD, Sen. Researcher, National Institute for Health Innovation (NIHI), NZ
Diego Boscá, Technical University Valencia, VeraTech for Health, Spain
Rong Chen MD, PhD, CMO Cambio Healthcare Systems, Sweden
Borut Fabjan, Program Manager, Marand, Slovenia
Sebastian Garde, Ocean Informatics UK
Peter Gummer, Ocean Informatics
Sam Heard MD, Ocean Informatics UK
Shinji Kobayashi PhD, Kyoto University EHR research unit
Bostjan Lah, Software developer at Marand
Ian McNicoll MD, Ocean Informatics UK
David Moner, Technical University Valencia, VeraTech for Health, Spain
Pablo Pazos Gutierrez, Tarmac IT, CaboLabs, Uruguay
Harold Solbrig, Mayo Clinic
Erik Sundvall PhD, Linkoping University, Sweden
Alessandro Torrisi, Code24, Netherlands 

*please add yourself if we missed you (also feel free to correct any errors)!

Development history

The specifications proposed on this page have been developed after some years of experience of building archetype tools (based on ADL 1.4, aka ISO 13606-2) and template tools (using the de facto .oet XML standard) by various organisations, including:

  • Cambio Healthcare Systems (Sweden), 
  • Kyoto university, Japan
  • Ljubljana medical centre
  • Ocean Informatics (Australia & UK), 
  • Technical University of Valencia (Spain), 
  • Linköping University (Sweden), 
  • the UK NHS, 
  • Queensland Health (Australia), 
  • Victorian Dept. Health (Australia).

[please add your organisation]

Clinical modellers and users of the Clinical Knowledge Manager (CKM) (at openEHR.org and in various countries) have provided crucial feedback on the challenges of identification, lifecycle management, versioning and namespacing. This has been captured in the Knowledge Artefact Identification specification, as well as the AOM and ADL specifications.

During 2011 - 2013, input and review feedback has also been obtained from participants in the Clinical Information Modelling Initiative (CIMI) forum, set up by Dr Stan Huff at Intermountain Healthcare, and including US DoD, VA, Nehta (Australia), CHI (Canada), Singapore MOHH, Mayo Clinic, Intermountain, GE Health, openEHR, HL7, 13606 Association, and others. CIMI chose ADL 1.5 as its default content modelling formalism in 2011. Due to CIMI, the OMG RfP 'Archetype Modelling Language (AML)' was created, and the work performed to ready this RfP has also resulted in detailed review of the ADL and AOM specifications. These two sources of input have been invaluable, and have led to a series of innovations which make the archetype formalism truly reference model independent, and more terminologically capable.

During the process of developing the new specifications, the models and syntax for ADL 1.5 archetypes and templates has been implemented in the Archetype Workbench so that a) the specifications can be validated and b) the community can see them in action.

Current status

The ADL and AOM specifications have been replublished in a close to final form in Q2 2014, containing what are considered to be all of the changes. The ADL Workbench includes all of the semantics documented in these specifications.

Specification Resources

Tooling Resources

Archetype Resources

Numerous archetypes can be found at openEHR / adl-archetypes Github. These can all be downloaded in one go by doing a Git clone of the whole repository in the normal fashion. If you just want to browse archetypes to get an idea of what they look like, the following direct links will help:

ADL 1.4 archetypes can be found in various locations, including the following (some of which have live tracking mirrors on Github):

 

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

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

  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

    racgp-blood-pressure.oet
    which constrains the blood pressure to 'sitting' and 'exertion' of 0

    nsw-blood-pressure.oet
    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.

    Ian

  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.