2016-06-17 SEC call notes

10 mins

New member invitations

@Ian McNicoll

Invitees:

• Sebastian Garde (Ocean; CKM)

• Christian Chevalley (adoc)

Also talk to Pieter Bos.

5 mins

New permanent call time

All

10 mins

Outstanding action items from previous calls

All

• TDS3 - Erik w/ Heath resources

15 mins

Terminology recap

@Ian McNicoll

https://github.com/openEHR/terminology/tree/draft

Questions:

1. Change tree structure?

2. Change schema?

Diego: better to have single file with all langs?

TB: treat multi-lang file as authoring source?

5 mins

AM 2.0 release

@Thomas Beale

CRs are ready to go here.

15 mins

Services API recap

@Former user (Deleted)

Apiary.io v0.1 openEHR API
https://github.com/openEHR/specifications-ITS/issues/
http://docs.mytest49.apiary.io/#reference/ehr_status 

Main Q: include or exclude Template import / export related calls.

• Ian - need this to reduce need for other components for new implementers

• Bjorn - (virutal) connectathon?

RM - remove persistent COMP context constraint

@Heath Frankel (Unlicensed)

See SPECPR-78.

RM - COMP.persistence scope:

@Heath Frankel (Unlicensed), @Bjørn Næss

Bjorn - DIPS has functionality already, but standardised; retrieves existing version of that 'scope'.

DIPS values: event | care episode | condition episode | contact | 'folder' scope | life/patient. E.g. Surgery = a folder. Also - folder = capture everything for Cancer trajectory. Folder - has start time, end time; Folder can be officially 'closed'.

Terminology - types of participants needed

@Heath Frankel (Unlicensed)

Heath: The other thing that would be useful is a standard set of terms for kinds of participants rather than having them redefined in each archetype using an at-code, this is particularly highlighted in the case of requestor and receiver, but I think there are others like registrar and consultant, etc.

RM - Order and request meta-data on ENTRY

@Thomas Beale, @Ian McNicoll

Currently archetype modellers are recording this information CARE_ENTRY.protocol, which is not documented for this purpose. See various SEC emails. Basic idea:

Addition of some structure under ENTRY.workflow do the job? Assume things like:

• requestor id - id / name of requestor org / party

• requestor order id - id the requestor side uses for this order

• receiver id - id / name of receiver / filler org / party

• receiver order id - id the receiver uses for this order

• other_details - extension elements

RM - 'report' type - consider new RM container type that can hold copies of anything, including COMPOSITIONs

@Thomas Beale

TB: Could this make sense: new RM class called REPORT, which can contain a) original data, b) complete copies of things and c) links to things. It could contain whole COMPOSITIONs if necessary. Also having a dedicated RM class would make it easy-ish to exclude it from querying, or at least detect copies of other items easily, and exclude them.

DIPS: mark COMPOSITIONs with a special category to be excluded from querying. BJORN - add more detail.

ES: see FHIR bundles

Ian - reports in a Folder; new report = new Folder.

Bjorn: need tooling - should be able to have a template for a Report; order is important.

Ian: do we need Composition in Composition - really we just need to suck in the Comp. metadata into the report with the Entries of interest. Could a template have a 'virtual inclusion' of archetype(s) in a Composition template? TB: would need AOM to have virtual marker on C_OBJECT.

Ian/TB - main need to solve problem of referring to e.g. Allergies (already existing) from a new Composition - e.g. an 'Allergies list'. Problems is that referring just to the allergy Entry doesn't get the Composition meta-data.