Status by 30 th April 2017

Transcription

1 Status by 30 th April 2017

2 The project - time lapse : 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 New features in the current release R All bug fixes and smaller enhancements since R (a detailed list is published on the Wiki). Support for IHE PHARM content profiles Support of the following CDA-CH specification (Serializing to file and Deserializing from file): CDA-CH-MTPS - Medication treatment plan sharing restrictions: Automatic generation of narrative text will follow in the next release FHIR resources for sample CDA creation will follow in the next release Enhancement of the existing IHE ITI features Support of IHE XDS.b Folders Many thanks to - ARPAGE, Switzerland - ELGA, Austria - Geneva University Hospitals - IHE Suisse, Switzerland

8 Features in release

9 The project - tomorrow Release R Autumn release 2017 (planned for November, 2017) Update for CDA-CH-MTPS - Medication treatment plan sharing Automatic generation of narrative text Enhancement of the Convenience API FHIR resources for sample CDA creation Other contributions currently in discussion (contributors are welcome): PDF generation from CDA documents Automatic generation of narrative text for Lab reports (CDA-CH-LRxx) 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

10 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

11 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) - Patrick Kistler, Arpage, Switzerland (Developer) - Igal Levy, Inselspital, Switzerland (Developer) - Roeland Luykx, Arpage, Switzerland (Developer) - Michael Onken, Open Connections, Germany (Development) - David-Zacharie Issom, University Hospitals of Geneva (HUG), Switzerland (Developer) - Stéphane Spahni, University Hospitals of Geneva (HUG), Switzerland (Developer) Promoter - IHE Suisse - «ehealth Suisse»

12 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

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

14 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

15 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

16 Integration scenario for CDA import

17 Integration scenario for CDA export

18 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.

19