Cambio office, Drottninggatan 89, Stockholm
Programme | |||
---|---|---|---|
Thursday 11 Feb | Who | Actions | |
09:30 - 10:00 | Informal - get set up with Jira, screens, GTM | All | |
10:00 - 10:30 | Tooling Git strategy / workflow Review workflow - BN | All | |
10:30 - 11:00 | Documentation tooling update - show everyone how tooling is working at the moment; solicit suggestions for improvement. MagicDraw?! | ||
11:00 - 11:30 | Global review
| ||
11:45 - 12:15 | ITS release strategy | All | |
12:15 - 13:15 | LUNCH | ||
13:15 - 14:15 | ITS release strategy - Sebastian Iancu
| Sebastian | |
14:15 - 15:15 | Specifications Releases
| ||
15:15 - 15:30 | C O F F E E | ||
15:30 - 16:30 | Specifications Releases
| ||
16:30 - 17:30 | ADL2 migration strategy | TB | |
17:30 - 18:00 | Cambio - GDL state of the art | Rong | |
20:30 - | Dinner | ||
Friday 12 Feb | |||
09:00 - 10:15 | TDS3 | ||
10:15 - 10:30 | C O F F E E | ||
10:30 - 11:00 | REST APIs | ||
11:30 - 12:00 | AQL - functions - Bjørn Næss | ||
12:00 - 12:30 | Demographics model general model issues - Sebastian Iancu | ||
12:15 - 13:15 | LUNCH | ||
13:15 - 14:30 | release specifics - dates, agree forward plan | ||
14:30 - 15:00 | GDL / ADL rules | ||
15:00 - 15:30 | Next 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.
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:
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:
Per-component ITS-RM, ITS-AM, etc Git repos with file structures like:
ITS-RM repo:
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'...
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:
Some examples:
SELECT i
FROM INSTRUCTION i
WHERE instruction-aggregate-state(i) = 'ACTIVE'
SELECT ac
FROM INSTRUCTION i CONTAINS ACTIVITY ac
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 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:
Consider adding ROLE.type to indicate type of role: professional capability | employment position | employer responsibility |
Agree on OPT1.4 support in ADL2 tooling as main enabling condition.
Impact areas:
Consider discussing value of specialisation in archetypes w.r.t. querying etc with clinical modelling group(s).