2019-09-30 SEC Meeting, Valencia
Place and Date
Ciudad Politécnica de la Innovación
ITACA Assembly Room
Green Cube - Building 8G
Access B - 3rd floor
UNIVERSITAT POLITÈCNICA DE VALÈNCIA
(Details)
Sep 30, 2019 - 01 Oct 2019
Participants
SEC Physical | SEC Remote | Guests | Won’t attend |
|---|---|---|---|
|
|
|
|
Goals
Follow-up Terminology Server specification development
Suggestions (by @Sebastian Iancu):
progress on RM 1.1
initiate REST API 1.1
review/accept/release ITS JSON and XML Schema
SM & conformance testing ?
JDT (flat json) ?
progress on AQL ?
Agenda
Time | Item | Who | Notes | Remote |
|---|---|---|---|---|
Monday 30 Sep 2019 | ||||
09:00 - 10:00 | Review goals, agenda, previous meeting actions | All |
|
|
10:00 - 10:15 | Governance | @Thomas Beale | Component ownership, resignations, general |
|
10:15 - 11:15 | Meta review on PRs Target releases: | @Thomas Beale |
|
|
11:15 - 12:45 | REST APIs part 1 | @Sebastian Iancu |
|
|
~~~~ L U N C H ~~~~ | ||||
13:45 - 14:30(?) | RM 1.1.0 CRs |
|
|
|
14:30 - 15:30 | RM 1.1.0 CRs | all |
|
|
15:30 - 17:00 | PR processing | all |
|
|
19:30 → | Dinner |
|
|
|
Tuesday 01 Oct 2019 | ||||
09:00 - 10:00 | REST APIs | all |
|
|
10:00 - 11:00 | REST APIs | all |
|
|
11:00 - 11:20 | Cistec - short pres |
|
|
|
11:20 - 12:15 | JSON Data Template | @Thomas Beale , all |
|
|
~~~~ L U N C H ~~~~ | ||||
13:15 - 14:00 | Conformance testing | @Pablo Pazos |
|
|
14:00 - 15:00 | Terminology server, mapping tooling, folder for clinical research | @Luis Marco-Ruiz |
|
|
15:00 - 16:00 | SEC group calendar for 2019/2020 | @Bjørn Næss | See below |
|
16:00 - 17:00 | openEHR and messaging specifications | ALL | See below |
|
Useful information
SEC Group “calendar”
The question is: How to perform best as a SEC group?
If we look at previous meeting, there was a lot ot actions to follow up. We didn't succeed in the executions of these. We need a way to follow up the actions
#slack - what if you where unable to follow channels, discussions and threads? It's hard to get in again. You need to read a lot backward and through threads. Is this working fine with you? Do we need a way to summarise important decisions? Is this handled by the PR/CR process?
How many physical meetings and where to meet?
In the beginning of the year we had several web-meetings using Skype. They where short meetings involving those actively working on tasks. I think this worked well. Is this a way to do the PR processing? I.e. if we took 5 PR’s every 2 weeks?
The proposal is the following:
We plan for 2-3 physical meetings during one work year (august - June)
There will be a regular web-meeting every 3 weeks to track the progress of SEC group activities
There will be ad-hoc web-meetings working on specific task within preparing for the next 3-week web-meeting.
openEHR and messaging specifications
Integration with other systems is needed. There is a lot of non-openEHR systems out there. Many hospitals, GP’s, municipalities, regions, countries, etc. has requirements on how to exchange data. These requirements may be local, regional, national and in some situations global based on international standards. Vendors implementing openEHR systems must follow these requirements to compete in the market.
FHIR is the most popular messaging pattern these days. We all know that “FHIR is a standard for health care data exchange, published by HL7®” according to their web-page. Still we also know that the FHIR profiles and resources are adopted and adjusted to local and national needs.
The models (archetypes) developed by the openEHR community (both by openEHR International and national CKM’s) is currently mostly facing the clinical content of the EHR. openEHR has a powerful demographics reference model used by a few vendors like CODE 24. Demographics is an absolute requirement to make real enterprise health information systems. Historically the demographics (patient administrative) part of eHealth is already taken care of by software systems developed decades ago. This is where FHIR has it’s momentum to define the API or Interface to these legacy systems. All around the world this seems to work reasonably well since every hospital has it’s own singular source of truth for the patient administrative (demographics) data.
The openEHR CDR and clinical models is actually a single source of truth for the clinical data in the EHR for a continuum of care. We should be able to share these data through every messaging specifiation “thrown at us”. It would be for the best for eHealth and not at least the openEHR community if we had a way to define the transformations from the Compositions in the CDR into messaging specifications. Having such a facility we could speed up the implementations of systems and their integrations.
Action items
Subtasks:
Add the simplified component diagram to the start page
Add GitHub links
Make class names clickable (linked to class descriptions in specs)
Add class diagram containing links to the spec (or was this the component diagram?)
- add last two tickets on 1.0.1, fix last small errors, typos etc
- introduce relaxed schemas for 1.1
- rest api specs should be for consumers (not for implementors)
- use present (i.e. "is" instead of “will”, “should“, etc)
- relax some of the capitals (MUST, SHOULD), use it more carefully, consider that this spec is for consumers centric
- gdl/guide not ready for REST
- add definition/archetypes (needed for GDL)
- what is a logical 'container' for parties?
- need a bit of a definition
- this system (suggested by Sebastian)
- uris:
- /party/{version_uid} ? better use 'namespace'
- /demographics/party/{version_uid} ? usefull when the type is not know
- /demographics/person/{version_uid} ? prefered choice, concrete classes
- Review team: @Erik Sundvall; @Diego Bosca , @Ian McNicoll, @Matija Polajnar
- more detailed rules coming from Bostjan
- consider 2 new flat forms as options from a conformance POV
- aim to have a spec done by / with REST APIs 1.1.0
- see #flat-json channel on slack
Documents to modify and synchronize:
- the data types for “Alternative JSON data formats“ in https://openehr.github.io/specifications-ITS-REST/#design-considerations-data-representation (urgent, deadline october 3?)
- https://specifications.openehr.org/releases/ITS-REST/latest/json_data_template.html
- https://specifications.openehr.org/releases/SM/latest/simplified_im_b.html
- Synthea - consider as a useful source of test data: @Ian McNicoll / @bjorn
- open sourcing of conformance tool: @Birger Haarbrandt /Highmed/Vita
- future work on conformance spec: @Thomas Beale / @pablo
- business basis: openEHR runs certification; only Bronze or higher IPs can get it; openEHR pays for expert time to perform a certification;
- what basis / rules for certification over time as a product (and certification process) changes
Decisions
- We agree to have monthly meetings to process tasks and items in between physical SEC meetings
- The “landing page” for specifications should be improved to make it easier to get newbies into the right specification and/or area of interest
- Release REST v1.0.1 a.s.a.p., than start on v1.1 and try to correlate with RM 1.1