Status by 30 th November 2017

Transcription

1 Status by 30 th November 2017

2 The project - time lapse : Further automatic text generation and integration of verapdf validation engine : Support of IHE PHARM content profiles and de-/serializing of CDA-CH-MTPS : Support of IHE PCC and LAB content profiles, de-/serializing of CDA-CH-EDES, CDA-CH-LRPH, CDA-CH-LRQC, CDA-CH-LRTP, CDA Validation and moving to Maven : Support of some more IHE ITI integration profiles: MPI Client PDQ V3, IHE XDS Document Consumer Actor, IHE XDM Cross-Enterprise Document Media Interchange, update for CDA-CH-VACD De-/Serializing : Support of some IHE ITI integration profiles: MPI Client PIX V3, IHE XDS Document Source Actor, CDA-CH-VACD De-/Serializing : Proof of Concept : Konzept zur Implementierung und API Spezifikation : HL7 CDA in Arztpraxissoftware - Konzept zur Integration See also: ehc Wiki: Documents in German, only:

3 Architecture

4 Features in release

5 Features in release

6 Features in release

7 Features in release

8 New features in the current release R All bug fixes and smaller enhancements since R (a detailed list is published on the Wiki). Automatic narrative text generation for observations, vital signs, blood group in German, French, Italian and English. See DemoEDES, DemoLRPH, DemoLRQC, DemoLRTP, DemoVACD. verapdf v1.8.1 as additional component for PDF/A validation of PDF's that are embedded in CDA documents. See CDA Validation, section "Notes to the verapdf Validator" Many thanks to - ELGA, Austria - IHE Suisse, Switzerland - Viollier AG, Switzerland

9 Features in release

10 The project - tomorrow Release R Planned features for spring release 2018 (planned for April, 2018): Update of verapdf library - thanks to ELGA, Austria PDF generation from CDA documents - thanks to Mathias Aschhof, ZTG, Germany and medshare, Switzerland Update for CDA-CH-MTPS - Medication treatment plan sharing - thanks to University Hospitals of Geneva, Switzerland Automatic generation of narrative text Enhancement of the Convenience API FHIR resources for sample CDA creation Other contributions currently in discussion (not for the autumn release, but for later - contributors are welcome): Support for IHE SVS and ehealth Connector release independent Value-Set management Support for IHE XUA and Swiss Requirements on XUA Profile for Authentication and User Assertion Server side usage of the ehealth Connector

11 The project - incubator The incubator is the entry path into ehealth Connector for projects and codebases wishing to become part of an official ehealth Connector release All external organizations and projects get access to the incubator on demand if they intend to contribute to the ehealth Connector The incubator has the following goal: Publication of efforts to a wide community Contributors provide as is, profiteers extend or adopt to their needs on their own costs Ideas may mature to features Please contribute populate our incubator

12 Who is on stage? Head medshare Ltd., Thun, Switzerland Project Team - Tony Schaller, medshare, Switzerland (Project Manager) - Franz Marty, Medizinisches Zentrum gleis d, Switzerland (Health Professional) - Oliver Egger, ahdis, Switzerland (Developer) - Axel Helmer, Open Connections, Germany (Developer) - Thomas Huster, Medevit, Austria (Developer) - David-Zacharie Issom, University Hospitals of Geneva (HUG), Switzerland (Developer) - Patrick Kistler, Arpage, Switzerland (Developer) - Igal Levy, Inselspital, Switzerland (Developer) - Roeland Luykx, Arpage, Switzerland (Developer) - Michael Onken, Open Connections, Germany (Development) - Stéphane Spahni, University Hospitals of Geneva (HUG), Switzerland (Developer) - Adrian Suter, smaps, Switzerland (Developer) Promoter - ELGA, Austria - IHE Suisse - «ehealth Suisse»

13 Why this project? Usage of standards is widely welcome, accepted and also recommended by ehealth Suisse But Required know-how for software vendors is extremely high In-depth knowledge of known standards are often missing Thus, the entry barrier is too high right now The ehealth Connector should encapsulate as much functionality as possible

14 The project - spirit Free and Open Source Software (FOSS) Give and take Enable interoperability Reduce barriers

15 Reasons for using the ehealth Connector OHT/MDHT inconvenience MDHT uses models to generate Application Programming Interface (API) Validators Documentation (Spec., Javadoc) Implementation Example: Available Methods for the PN Object Example: Available Javadoc for the Method PN.addDelimiter() Knowledge you should have RIM, CDA, HL7v3, Clinical Terminology, IHE, UML Modeling, Ecore Modeling, MDD, MDHT Not convenient but mighty

16 Reasons for using the ehealth Connector ehc convenience Convenience API Fast results API is very easy to use Recommendation what should be implemented Guidance for application developers Javadoc explains what you need to know Javadoc sometimes even in your language Demo application for every template As few expert knowledge as possible Hide the complexity of CDA and MDHT But you can access underlying MDHT Objects at any time Convenient and mighty

17 Integration scenario for CDA import

18 Integration scenario for CDA export

19 Understanding and using the project logos Main project logo: Contributor indication: User indication: Disclaimer: ehealth Connector is a trademark, registered by medshare Ltd., Switzerland. The logo may be used under the Creative Commons Attribution-NoDerivatives 4.0 International License as long as it is used in conjunction with the ehealth Connector Open Source project. The usage for other products, services or projects is prohibited.

20