2017-08-29 SEC Meeting, Alkmaar
Location
Dates
August 29, 30, 31 (Tuesday - Thursday)
Agenda Suggestions
Add any item here you feel should be discussed during the meeting.
PR & CR processing
FOLDERs - use cases (DIPS, Erik, Code24, HiGHmed...); what is a FOLDER? are they useful for clinical trials? do we need a more flexible structure? update of subfolders
RM 1.1 planning review
REST API complete to first draft
Conformance spec review
discuss structure of ITS area / repos
Terminology service for openEHR; integration with AQL (Daniel Karlsson, terminology binding expert, can join the terminology discussion remotely on wednesday after 10 or thursday after 10.)
ADL2 adoption
review GDL; Cambio; DIPS has some impl; - Iago C; Birger
TDS3 - @Heath Frankel (Unlicensed)/ Erik
review RM DEMOGRAPHICS usage - @Sebastian Iancu; Birger - analytics query strategy; virtual layer needed (Ian McN)?
Episodes of care; clinical process entities - Bjorn
Task Planning update to group - @Thomas Beale
Workflow additions to RM to support order management and tracking - @Thomas Beale / @Heath Frankel (Unlicensed)
Report additions to RM - support mixed content including coping, linked, query result etc - @Bjørn Næss / @Former user (Deleted) / @Thomas Beale
citation archetype - Erik; maybe use 'resource classes' idea here (Ian)
Possible items
review Expression spec draft - @Thomas Beale
proposal for openEHR 'resources' for use with REST APIs - formal class definitions based on RM classes - @Thomas Beale
stored queries behind APIs
Agenda
Note on times: all times shown in CEST;
Columns DB, CC and HF are marked by the webconf attendees with a 'y' to indicate they can be online at those times.
Columns BH and SG for part-time attendees.
Programme | ||||||||
|---|---|---|---|---|---|---|---|---|
Tue 29 Aug | DB* | CC* | HF* | BH | SG |
| Who | Actions |
09:15 - 09:40 | y |
|
| y | y | Arrival, set up, web-conf | SI/TB |
|
09:40 - 10.00 | y |
|
| y | y | SEC formalities, intros, agenda, house-keeping | TB |
|
10:00 - 11:00 | y | y | y | y | y | PR/CR survey | TB |
|
11:00 - 11:30 | y | y | y | y | y | REST API work | BL |
|
11:30 - 12:30 | y | y | y | y | y | REST API work | BL |
|
12:30 - 13:30 |
|
|
|
|
| LUNCH |
|
|
13:30 - 14:30 | y |
|
| y | y | REST API work | TB |
|
14:30 - 15:15 | y |
|
| y | y | REST API work | All |
|
15:15 - 15:30 |
|
|
| y | y | ------------- C O F F E E ------------- |
|
|
15:30 - 16:30 |
|
|
| y | y | REST API work |
|
|
16:30 - 17:30 | y |
|
| y | y | REST API work |
|
|
19:00 - 21:00 |
|
|
|
|
| Alkmaar evening's Cheese Market |
|
|
2x:xx - |
|
|
|
|
| Dinner |
|
|
|
|
|
|
|
|
|
|
|
Wed 30 Aug |
|
|
|
|
|
|
|
|
09:00 - 09:15 | y |
|
| y | y | Agenda check | All |
|
09:15 - 10:45 | y |
|
| y | y | AQL; funcs to add; result set; | All |
|
10:45 - 12:30 | y | y | y | y | y | REST API work |
|
|
12:45 - 13:50 |
|
|
|
|
| LUNCH |
|
|
13:50 - 15:00 | y |
|
|
| y | REST API work |
|
|
15:00 - 16:00 |
|
|
|
|
| Conformance spec |
|
|
16:00 - 16:20 |
|
|
|
| y | ------------- C O F F E E ------------- |
|
|
16:20 - 18:00 |
|
|
|
| y | PR/CR processing - ADL/AOM |
|
|
19:30 - 23:00 |
|
|
|
|
| Walking Dinner Alkmaar (+guide) |
|
|
|
|
|
|
|
|
|
|
|
Thu 31 Aug |
|
|
|
|
|
|
|
|
09:00 - 09:15 | y |
|
|
|
| Agenda check | All |
|
09:15 - 10:15 |
|
|
|
|
| PR/CR processing |
|
|
10:15 - 11:45 | y |
| y |
|
| Terminology + AQL; | D Karlsson / |
|
11:30 - 12:30 | y |
| y |
|
| PR/CR processing |
|
|
12:30 - 13:30 |
|
|
|
|
| LUNCH |
|
|
13:30 - 14:30 | y |
|
|
|
| REST API |
|
|
14:30 - 15:15 | y |
|
|
|
| Task Planning review |
|
|
15:15 - 15:30 | y |
|
|
|
| -------------- C O F F E E ------------- |
|
|
15:30 - 17:00 | y |
|
|
|
| RM: FOLDERs / ?REPORT / |
|
|
17:00 - 17:30 |
|
|
|
|
|
|
|
|
beer @ pub | ||||||||
Actions
Planned Outcomes
Intended or desired results by end of meeting.
baseline openEHR REST API
baseline AQL spec
baseline Base Types spec
baseline conformance spec draft
Comments
I have a late plane back (21:35). So we can have some more program on Thursday
Me too, 21:30 or so. I have added more time for Thursday. I know for sure there will still be work to do...
We've now booked flights to return 2140 from Amsterdam, so we'll also be around till late on the Thursday.
I have impression the often RM Demographics is quite 'neglected' by different openEHR implementation. I thought we should spent a bit of time to speak about usecases and think about its future, therefore I added as suggestion to agenda.
Good idea.
I'm not sure if this is appropriate for this meeting. However, these are some of the topics we have identified as crucial for our use-case:
Standardization of AQL result sets
Standardized integration of terminology services within AQL (e.g. FHIR Terminology Service)
New AQL functions (union, intersect, minus, group by)
REST-API: physical delete of EHRs and/or compositions
I can only say +1 to all that
I think for physical delete, we need to consider a different API component, which I have called 'CDR' (Clinical Data Repository) in the CONF spec. It doesn't matter what we call it, but the idea is that it groups 'power' / admin operations. I think real deletions have to go there.
It should include also demographics, not only clinical. This is at least the rule in NL, might be in other countries also. We'll discuss it in the meeting.
Another thing reagarding the REST-API: I'm not sure if this should be part of the specification or up to the particular vendors but it would be handy if there was an optional parameter for "POST composition" to avoid unwanted duplicates of a composition in the CDR (I know that this has some implications for the persistence layer).
I am not sure if I understand the use-case. What kind of duplicates are we talking about? Is it the content or same uid?
I'm talking about the content. There might be situations where you receive identitical data or messages more than once from "legacy" systems (faulty communication server or incorrect data integration scripts). One manual approach could be to use AQL and entries from the feeder audit to identify if a composition has already been submitted before doing the post request. However, from a database management system perspective, I think there are good reasons that unique constraints should exist on the DB-level and are not delegated to client software.
That's an interesting idea but might be very difficult to accurately distinguish a true duplicate from a legitimate update, or more likely where the same data e.g an allergy record, finds its way into several messages which otherwise are not identical. I'm not sure I can see a means of doing this generically, without significant knowledge of feeder systems and overall architecture/ data flows.
One challenge that we all have (at least all of us who will be using FHIR) is how to provide a unique reference for each ENTRY (or indeed each event in an Observation). I am aware of some different approaches to this problem which might be usefully aligned. Would that help at all with the problem you describe?
Agree that it could be tricky to define semantics of clinically relevant duplication detection, especially partial duplication, in currently discussed REST API. I suggest we take that discussion later. I guess it is a problem only when importing from non-openEHR sources since the openEHR versioning would take care of when openEHR systems are communicating.
Regarding FHIR resources I think we can define some useful stored queries. Especially if we define a possibility for a path pre-processing step that can turn path parts into variable content (perhaps a subset of URI-template spec https://tools.ietf.org/html/rfc6570 ). Example: api/v1/query/(possibly-some-prefix)/fetchentry/{composition-id}/{path-to-entry-or-event} where composition-id and path-to-entry-or-event would be dynamic variables available for the underlying AQL (and "fetchentry" would be the name of a stored query). An more verbose alternative is a ..fetchentry/?cid=123468374912387&path=/lorem/ipsum
We can talk about during a coffee break. I'm definitely ok if this is not part of the "official" schedule
@Birger Haarbrandt - I think all those topics are of high interest for the meeting. Good points
Were we intending to finish at lunchtime on Thurs 31st , or is the agenda just incomplete?
Sorry can't find original discussion