Naked-FHIR. Code-Generierung auf Basis von HL7 FHIR Andreas Schuler, MSc. Textmasterformate durch Klicken bearbeiten

Transkript

1 Naked-FHIR Code-Generierung auf Basis von HL7 FHIR Andreas Schuler, MSc. HL7 Jahrestagung März 2015

2 Einführung HL7 FHIR stellt eine Reihe an Basis-Ressourcen zur Verfügung Über Zweite Conformance Ebene Ressource erhalten Clients Conformance Statement > beschreibt Dritte Ebene angebotene Ressourcen (Profile), Operationen, ValueSets, etc. > Anforderungen an Clients bzw. Contract zwischen Server und Client I allow these Operations I support the following Resources Always use these ValueSets when talking with me Supplied Resources must conform to one of these Profiles Wie kann eine komplette Anwendung (Client) aus einem Conformance Statement generiert werden? 2

3 Klassische Architektur von Anwendungen Domänenobjekte werden über Anwendungslogik an Benutzerschnittstelle Zweite Ebene gebunden Für > Dritte automatische Ebene Code-Generierung ungeeignet > zusätzliche Information erforderlich, um Abbildung der Fachobjekte (FHIR-Ressourcen) auf Anwendungslogik zu ermöglichen FHIR Ressourcen 3 [Quelle: nach

4 Naked Objects Architekturmuster Benutzerschnittstelle als direkte Abbildung der Domänenobjekte Zweite Ebene Benutzerschnittstelle zu 100% aus Definition von Domänenobjekten generierbar Metainformation für Generierung erforderlich FHIR Ressourcen 4 [Quelle: nach

5 Konzept Abstraktion von Naked Objects Pattern hinsichtlich der Unterstützung beliebiger Zweite Ebene FHIR-Ressourcen Automatische Generierung von Client-Anwendungen anhand der Informationen, die über die Ressourcen Conformance, Profile, etc. abgefragt werden können > Struktur von Ressourcen (Elemente, Datentypen, Kardinalitäten) > Operationen auf Ressourcen (Read, Create, Search, etc.) 5

6 Konzept Code-Generierungsprozess 1. Retrieve Conformance > Abfrage der Ressource Conformance eines FHIR-Servers GET [base]/metadata {?_format=[mime type]} 2. Select Supported Profiles > Auswahl jener Profile, die in der generierten Applikation unterstützt werden sollen 6 Application

7 Konzept Code-Generierungsprozess 3. Model Transformation (M2M) > Abbildung und Transformation selektierter Profile auf ApplicationModel aggregiert gewählte Profile sowie Informationen hinsichtlich Struktur der Zielanwendung Stellt abstrakte Repräsentation des Naked Objects Pattern dar 7 Application

8 Konzept Code-Generierungsprozess 4. Generate Code (M2C) > Erzeugt Quellcode für Zielanwendung aus ApplicationModel > Templates als Basis für das Mapping der Konzepte aus dem Modell auf eine Benutzerschnittstelle 8 Application

9 Konzept Mapping von FHIR-Ressourcen auf die Benutzerschnittstelle Kombination aus Ressource und Operation bestimmt Aufbau einzelner Ansichten Zweite Ebene einer Applikation Einzelne Elemente der Ressource bestimmen Zusammensetzung der Benutzerschnittelle Operation bestimmt Interaktionsmöglichkeit Erzeugen, Bearbeiten, Löschen, etc.? 9

10 Konzept Mapping von FHIR-Ressourcen auf die Benutzerschnittstelle Ressource besteht aus Elementen > Zweite Elemente Ebene besitzen Typ (Datentyp, Ressource, Element) und Kardinalität Datentypen als kleinste gemeinsame Einheit von Elementen Bereitstellen von Templates für Kombination aus > Datentypen (Primitive, Complex) und > anwendbarer Operationen (Read, Search, Create, etc.) Benutzerschnittstelle für eine Ressource ergibt sich aus Aggregation entsprechender Templates 10 [Quelle: [Quelle:

11 Konzept Mapping von FHIR-Ressourcen auf die Benutzerschnittstelle Bsp.: Operation READ in Kombination mit Ressource Patient HumanName + Operation [Quelle: [Resultat der Generierung (Android)] 11

12 Beispiel Ressource Patient Bsp: Generieren eines Android Client für die Ressource Patient und die Operationen Zweite Ebene READ und SEARCH 12

13 Beispiel Ressource Patient Auswahl zu generierender Ressourcen Auswahl unterstützter Operationen 13

14 Beispiel Ressource Patient Resultat der Code-Generierung > Je eine Android Activity für die Suche (SEARCH) und die Anzeige (READ) der Ressource Patient Operation SEARCH Operation READ HumanName HumanName Contact 14

15 Einsatzbereiche Rapid Application Development (RAD) > Basis für einfache erste Prototypen als Teil eines iterativ inkrementellen Vorgehensmodells > Einfache Adaptierungen am erzeugten Quellcode möglich Aufgrund der Abstraktion weitere Anwendungsbereiche durch Ergänzung von Templates denkbar > Bspw.: generieren automatischer Tests Prüfen, ob ein FHIR-Server entsprechend dem publizierten Conformance Statement agiert 15

16 Status Naked FHIR Prototyp unterstützt FHIR DSTU1 > Adaptierung auf aktuellere Versionen durch Bootstraping Application Model V.2.0 Problem bei Elementen von Ressourcen ohne Typ > Bspw.: PatientAnimal Vorrangig Unterstützung für REST Derzeit nur Templates für Android Fehlende Unterstützung für Search-Queries [Quelle: 16

17 Fragen? 17 Andreas Schuler, MSc. Wissenschaftlicher Mitarbeiter e-health Integrierte Versorgung FH OÖ F&E GmbH