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)
- 01 Oct 2019
SEC Physical | SEC Remote | Guests | Won’t attend |
---|---|---|---|
|
|
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 ?
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 | Component ownership, resignations, general | ||
10:15 - 11:15 | Meta review on PRs Target releases: | |||
11:15 - 12:45 | REST APIs part 1 | |||
~~~~ 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 | |||
14:00 - 15:00 | Terminology server, mapping tooling, folder for clinical research | |||
15:00 - 16:00 | SEC group calendar for 2019/2020 | See below | ||
16:00 - 17:00 | openEHR and messaging specifications | ALL | See below |
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.
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.
Add action items to close the loop on open questions or discussion topics:
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?)
Type /decision to record the decisions you make in this meeting: