Skip to end of metadata
Go to start of metadata


Cambio office, Drottninggatan 89, Stockholm

Physical Attendees

  • Rong Chen
  • Erik Sundvall
  • Thomas Beale
  • Bjørn Næss (DIPS ASA)
  • Sebastian Iancu
  • Bostjan Lah

Planned Outcomes

  • agreed plan to release RM 1.0.4
  • agreed plan to release ITS for RM 1.0.4
  • agreed plan to release AM 2.0
  • SM - APIs progress

Agenda Suggestions

  • Specifications Releases
    • RM Release 1.0.4 to fix minor 1.0.3 bugs? - Thomas Beale
    • AM 2.0 release - Thomas Beale
    • ITS release strategy - Sebastian Iancu
      • does ITS continually accumulate mutually consistent sets of resources, e.g. XSDs, Java code etc etc? It should be the case that the ITS project has ITS for every other component that has something available at any time.
    • ITS - specific discussion on XSDs
    • RM Release 1.1 - move most of Common to BASE
    • SM first release timetable
    • status of UML tooling, extractor, documentation approach, global UML site to replace broken MD one?
  • GDL & ADL rules
    • GDL UML models need to be converted to MagicDraw - then can use class extraction documentation approach.
    • need to rationalise AOM2 rules and GDL rules.
  • SM & REST APIs - Boštjan Lah
    • Algorithm for converting archetype paths => URIs for REST - Thomas Beale
  • ADL2 - IM/RC/TB
    • adoption pathway for industry
    • open tooling project; multi-vendor collaboration; possible funding; Maybe also Google Summer of Code (org application deadline Feb 19)
    • How should the openEHR community organize the development of the needed tools for clinical modelling? 
  • TDS3 - wiki dev page
    • we need a formal specification - where does it live?
    • TDD => canonical converter specification
  • How to formalize AQL
    • Proposed syntax for AQL syntax for status of INSTRUCTION/ACTIVITY
    • Proposed syntax to allow AQL querying across links/ references (possibly relates to item above)



Thursday 11 Feb WhoActions
09:30 - 10:00Informal - get set up with Jira, screens, GTMAll 
10:00 - 10:30


Git strategy / workflow

Review workflow - BN

10:30 - 11:00

Documentation tooling update - show everyone how tooling is working at the moment; solicit suggestions for improvement.


Thomas Beale 
11:00 - 11:30Global review
11:45 - 12:15ITS release strategyAll 
12:15 - 13:15LUNCH  
13:15 - 14:15ITS release strategy - Sebastian Iancu
  • does ITS continually accumulate mutually consistent sets of resources, e.g. XSDs, Java code etc etc? It should be the case that the ITS project has ITS for every other component that has something available at any time.
  • ITS specifics - RM 1.0.3 XSDs
14:15 - 15:15Specifications Releases  
15:15 - 15:30C O F F E E  
15:30 - 16:30Specifications Releases
  • RM Release 1.1 - move most of Common to BASE
  • SM first release timetable
16:30 - 17:30ADL2 migration strategyTB 
17:30 - 18:00Cambio - GDL state of the artRong 
20:30 -Dinner  
Friday 12 Feb   
09:00 - 10:15TDS3  
10:15 - 10:30C O F F E E  
10:30 - 11:00REST APIs  
11:30 - 12:00AQL - functions - Bjørn Næss  
12:00 - 12:30Demographics model general model issues - Sebastian Iancu  
12:15 - 13:15LUNCH  
13:15 - 14:30release specifics - dates, agree forward plan  
14:30 - 15:00GDL / ADL rules  
15:00 - 15:30Next gen ADL tooling ; user experience for e.g. nurses; ADL2 adoption  
15:30 - 16:00   
 drinks? :)  



Create list of instructions for vagrant provisioning script for documentation / publishing env. Sebastian to build and test.


Do a test to see if MD XMI includes all model content including diagrams.

Do a test to transfer full model to another tool.


ROng - send TB XMI of GDL model.

Publishing / Workflow

Asciidoc or other generic small types - use a 'collector' CR on each release e.g. 'Correct Asciidoc syntax errors' - e.g. SPECPUB JIRA project.

Signficant CR-driven changes:

  • agree on private fork + change + pull request + merge
  1.  Changes is done one personal fork 
  2.  Pull request is sent to main repository 
  3. Owner of that specification Git repo will do the merge 
  4. Each commit must be assigned with a prefix for the JIRA item (e.g. SPECRM-35)

UML changes - discuss/agree in JIRA, then component owner does or delegates UML changes to one person - avoid competing UML model changes.

Review workflow options - e.g. external reviewers:

  • Component owner does
    • AsciidoctorFX export to ODT
    • generate HTML in the normal Asciidoctor way
  • reviewer uses e.g. OpenOffice to markup - comments & changes, then returns to owner who then processes manually.

Git branch philosophy

  • option #1 - single master
  • option #2 - master = dev branch; create interim branches on demand if need to apply selected later commits at an earlier point.

ITS strategy

Per-component ITS-RM, ITS-AM, etc Git repos with file structures like:

ITS-RM repo:

  • tag point: 1.0.2
    • CHANGELOG.txt
    • xml
      • xsd
  • tag point: 1.0.3
    • CHANGELOG.txt
    • xml
      • xsd
        • 6 files
      • xslt
  • tag point: 1.0.4
    • CHANGELOG.txt
    • doc
      • sdfsdfdf
    • xml
      • xsd
        • 6 files
      • schematron
        • 2 files
      • xslt
        • xxx
      • examples
        • xxxx
    • json 
      • xxx

Each repo would use same tags as SPECIFICATION-xx repos, e.g. 'Release-1.0.3'. 

To add updates to an earlier release, e.g. fix 1.0.2 XSD bug, or add JSON schema to 1.0.2, then do a branch off the relevant tag point and use tags like 'Release-1.0.3-R2' etc.

Can also add secondary 'bundle-based' tags e.g. '2016.3', '2017.6' etc.

Manually maintained CHANGELOG.txt file in root - enables consumers to easily find out what has changed.


Long term release?


Additionally, a 'whole of system' ITS repo containing e.g. whole of system documentation, packaging scripts etc.


Release naming: use e.g. openEHR-2016.3?

Question: how to connect conformance resources/test plans etc to ITS artifacts.

Idea of 'conformance to openEHR-2016.3'...

AQL functions

Generic need for 'functions' in AQL / extension mechanism

Need to show how to define RM-independent functions e.g. math functions, 

Then need ability to define RM-specific functions e.g. instruction-aggregate-state() , etc see pres from Bjørn Næss 

Functions defined as: 

  • instruction-aggregate-state(instruction_identifier)
    • Returns the aggregated state of the given INSTRUCTION as a String 
  • current-state(activity_identifier) 
    • Returns the current state of the given ACTIVITY as a String

Some examples: 

WHERE instruction-aggregate-state(i) = 'ACTIVE'

WHERE current-state(ac) = 'ACTIVE'

Latter would be specified .... where?

Implementation guidance for AQL service implementers

also consider 'service view' of functions, i.e. REST access as well as AQL access.


Need to represent 'function' i.e. 'position' concept as well as 'role'. 

In Code24 system all 'relations' are PARTY_RELATIONSHIPs

What is the appropriate way to model 'legitimate relationship' i.e. current carers.

Types of real world 'role'

  • what am I?: a GP, oncologist etc, by professional formation / training / certification
    • PERSON.roles → ROLE 'GP', defined by capabilities
  • who do I work for?: employment relation with an organisation, in a specific kind of post/function
    • PARTY_RELATIONSHIP between PERSON (who has ROLE GP) and employing ORGANISATION
  • who do I work with? Team / department level working.
    • PARTY_RELATIONSHIP between employment ROLE and other ROLEs or a GROUP
  • who do I care for?: relationship from carers to patient i.e. the legitimate relationship
    • this has to be a PARTY_RELATIONSHIP between employment-based ROLE and 'patient' ROLE of PERSON

What about generic roles? These are like job posts.

Is a patient  PERSON in a 'patient' ROLE?

Other problem: medical secretary / other staff doing direct entry into EHR instead of doc at busy times.

Identifiers - where should they be modelled? Currently inside PARTY.details ITEM_STRUCTURE, but this is dependent on knowing archetype paths. Possible suggestion (Sebastian Iancu) - add PARTY.identifiers: PARTY_IDENTIFIER, where PARTY_IDENTIFIER would have a DV_IDENTIFIER, time_validity, ?validated/checked optional attribute.

Various possibilities:

  • Erik Sundvall: extend the scope of PARTY.identities to cover externally assigned ids as well as names
  • Thomas Beale: maybe it't better to make identities (names) and external identifiers distinct
  • Bjørn Næss: just use PARTY.identities and use the PARTY_IDENTITY.type to distinguish between 'name' and 'ssn' etc

Consider adding ROLE.type to indicate type of role: professional capability | employment position | employer responsibility | 


  1. simplify AOM2 rules down to simple expressions only
  2. move core generic expression tree model / syntax? to BASE
  3. sync GDL with BASE model, also AUTHORED_RESOURCE
  4. move GDL to AOM2 (when?)

ADL2 Adoption pathway

Agree on OPT1.4 support in ADL2 tooling as main enabling condition.

Impact areas:

  • AQL queries
  • AQL queries built on the fly in code
  • AQL engine
  • Generated User interfaces (e.g. JSON precursor artefacts for UI generated from OPT).
  • .oet templates need a converter

Consider discussing value of specialisation in archetypes w.r.t. querying etc with clinical modelling group(s).



  • No labels


  1. I would like to be involved in the TDS discussion, I have a new version that simplifies the XML instance. Unfortunately I am unavailable Thursday.

    1. I'm also interested in TDS discussion. Heath, is your proposal RM independent?

  2. I know it is usually such a pain to broadcast these things, but if anybody is willing to give it a try, things like Periscope may do the job maybe? It should be as simple as putting a mobile phone/laptop on a table. If it works, it would let others to join in if/when they can and watch, and even comment over twitter. Just my 2 pennies.