Systematische Analyse von existierenden semantischen Standards und deren möglicher Harmonisierung in Gesundheitsakten.

Größe: px
Ab Seite anzeigen:

Download "Systematische Analyse von existierenden semantischen Standards und deren möglicher Harmonisierung in Gesundheitsakten."

Transkript

1 Systematische Analyse von existierenden semantischen Standards und deren möglicher Harmonisierung in Gesundheitsakten. Bakkelaureatsarbeit von: Memelink Michael Im Rahmen des Studiums Biomedizinische Informatik an der Privaten Universität für Gesundheitswissenschaften, Medizinische Informatik und Technik, am Institut für Informationssysteme des Gesundheitswesens. Betreuer: Univ. Prof. Dr. Elske Ammenwerth Univ. Ass. Dr. Thomas Schabetsberger Msc. Hall in Tirol, November 2007

2 Betreuerbestätigung Hiermit bestätige ich, die vorliegende Abschlussarbeit betreut zu haben, und ich befürworte damit die Abgabe der von mir insgesamt positiv benoteten Arbeit. (Datum und Unterschrift des Betreuers) (Name des Betreuers in Blockbuchstaben) Annahme durch das Studienmanagement am: von: 1

3 2 Zusammenfassung Einleitung: Steigende Lebenserwartung und komplexe Krankenheitsbilder erfordern eine Vielzahl an Untersuchungen in verschiedenen medizinischen Disziplinen durch spezialisierte Fachärzte. Für eine reibungslose Zusammenarbeit ist es unabdingbar, dass die einzelnen, oft proprietären IT-Werkzeuge miteinander kommunizieren können. Dafür sind eine gemeinsame elektronische Gesundheitsakte und adäquate Standards zur Interoperabilität notwendig. Es existiert zwar eine Vielzahl an semantischen Standards, diese sind jedoch nur bedingt miteinander kompatibel. Werkzeuge zur Harmonisierung stehen nicht zur Verfügung. Diese Arbeit analysiert semantische Standards wie openehr, CEN pren und HL7 CDA R2 und erarbeitet einen Lösungsvorschlag zur Harmonisierung dieser zwei grundsätzlich unterschiedlichen, aber zueinander kompatiblen semantischen Standards. Methoden: Die Arbeit wird gemäß der 5-Stufen-Methode umgesetzt, mittels systematischer Literaturanalyse in wissenschaftlichen Quellen und Internetrecherche sowie Brainstorming werden Inhalte erarbeitet. Ergebnisse: openehr ist eine Gruppe, die sich auf die Entwicklung offener Spezifikationen, Software- und Wissensresourcen für Gesundheitsinformationssysteme und insbesondere für die elektronische Gesundheitsakte (EHR) spezialisiert hat. Die openehr Spezifikationen sind streng genommen keine Standards, sondern beruhen vielmehr auf Basis anerkannter Standards, wie z.b. HL7 oder CEN. CEN pren ist ein 5-teiliger europäischer EHR Kommunikationsstandard der den Austausch semantisch-interoperabler EHR Inhalte zwischen Informationssystemen beschreibt. Dieser Standard basiert auf einem Zwei-Schichten-Modell, welches Information und Wissen trennt. HL7 CDA ist ist ein XML Dokument-Markup Standard, der die Struktur und die Semantik von klinischen Dokumenten spezifiziert. Ein CDA Dokument ist ein definiertes und komplettes Informationsobjekt, welches Text, Bilder und andere multimediale Daten enthalten kann. Obwohl diese Standards grundsätzlich unterchiedlich sind, kann zwischen HL7 CDA R2 und CEN pren (EHRcom) eine Harmonisierung hergestellt werden. Dies ist durch Templates und Archetypen möglich, die sich aus dem selben Reference

4 3 Information Model ableiten und mittels einer Ontologie darstellen lassen und mit Hilfe spezifischer Mapping Algorithmen in eine unterschiedliche EHR Instanz überführbar sind. Diskussion: Die Bedeutung der Harmonisation der vorgestellten Standards kann nicht unterschätzt werden. Die ISO/TC 215 spielt eine wichtige Funktion im Prozess der Harmonisierung vieler Standards auf internationalem Wege. Gerade bei den zwei größten Gruppen im EHR Standardisierungsbereich ist es von enormer Wichtigkeit, eine engere Zusammenarbeit und eine höhere Interoperabilität zu schaffen. CEN und HL7 haben einen Memorandum of Understanding (MOU) unterschrieben, das festlegt, in weiterer Zukunft eine engere Zusammenarbeit bezüglich einer Harmonisierung beider Organisationen einzugehen. Die erreichten Ergebnisse werden im Rahmen des Forschungsprojekts an der UMIT bereits eingesetzt. Gründsätzlich sind für Interoperable Systeme Standards unabdingbar. Für den praktischen Einsatz von Standards ist es jedoch notwendig, dass diese praktikabel handhabbar und gut zugänglich sind. Heutige Standards werden oft von Universitäten erarbeitet, sind teilweise sehr theoretisch gehalten und werden aufgrund der unpraktikabilität von der Industrie kaum eingesetzt. Stattdessen kommt es vor, dass die Industrie eigene Standards entwickelt, die ihren Bedürfnissen besser entsprechen. Ein Verbesserungsansatz könnte hier sein, dass vor Entwicklung neuer Standards zuerst existierende analysiert werden, ob sie nicht verwendet werden könnten, und Standards grundsätzlich von Industrie und Wissenschaft in engerer Kooperation entwickelt werden.

5 Inhaltsverzeichnis 4 Inhaltsverzeichnis 1 Einführung Gegenstand und Motivation Problemstellung Zielsetzung Fragestellung Grundlagen und Definition Informationssysteme Medizinische Akten Krankenakte, Patientenakte (EPA) Virtuelle elektronische Patientenakte(vEPA) Elektronische Gesundheitsakte (EGA, ELGA) Interoperabilität Semantische und syntaktische Standards Extensible Markup Language (XML) Methoden Einführung der allgemeinen Methoden Stufen-Methode zur systematischen Strukturplanung Literaturanalyse Brainstorming Unified Modeling Language Web Ontology Language (OWL) Durchführung Durchführung der Literaturanalyse Erstellen und übersetzen der R-MIMs in OWL Ergebnisse Ergebnisse zu Ziel

6 Inhaltsverzeichnis openehr CEN Health Level 7 (HL7) Clinical Document Architecture (CDA) Ergebnisse zu Ziel Ergebnisse zu Ziel Diskussion und Ausblick Diskussion der Methoden Diskussion der Ergebnisse Ausblick Appendix OWL-Repräsentationen

7 Abbildungsverzeichnis 6 Abbildungsverzeichnis 1 HL7-RIM mit EHRcom R-MIM und CDA R-MIM Struktur des openehr Spezification Project Paketstruktur des openehr Reference Models openehr Reference Model als Teilmodell mit EHR und Composition CEN Reference Model EHR EXTRACT Klasse des pren Reference Model EHR EXTRACT Klasse der pren RM und Assoziationen Archetyp Model Teil1 der pren Spezifikation Archetyp Model Teil2 der pren Spezifikation openehr Datentypen Strukturaufbau eines Archetypen HL7-RIM Model mit Hauptklassen Standard CDA Dokument Ausschnitt einer HMD

8 Tabellenverzeichnis 7 Tabellenverzeichnis 1 Internationale Standards Abgrenzung der EHR Standards EHR Standards: Marktübersicht EHR Standards: Struktur und Inahlt Vorteile der relevanten Standards (HL7-CDA R2 und CEN pren 13606) Ableitungsregeln der EHRcom R-MIM Klassen Ableitungsregeln der HL7 CDA R-MIM Klassen Notationen des Mapping Algorithmus Mapping Algorithmus

9 1 Einführung 1 1 Einführung 1.1 Gegenstand und Motivation In hoch entwickelten Industrieländern ist eine Tendenz in Richtung steigender Lebenserwartung erkennbar. Unmittelbar damit ist ein deutlicher Anstieg von Erkrankungen im höheren Lebensalter verbunden. Die dabei entstehenden multimorbiden Krankheitsbilder erfordern eine Vielzahl an Untersuchungen in verschiedenen medizinischen Disziplinen durch spezialisierte Fachärzte. Um eine erfolgreiche Diagnostik und Therapie gewährleisten zu können, wird es immer wichtiger, dass Ärzte verschiedener Fachgebiete im Rahmen medizinischer Kooperationen miteinander interoperieren und patientenbezogene Daten und Informationen untereinander austauschen können. Diese komplexen Interaktionsansprüche implizieren den Einsatz flexibler IT-Werkzeuge und unterstützender Informationssysteme. Für einen effizienten Daten- und Informationsaustausch ist es unabdingbar, dass die einzelnen, oft propraitären IT-Werkzeuge miteinander kommunizieren können. Für die erforderliche Interkommunikation sind adequate Standards zentral. Zum jetzigen Zeitpunkt existiert eine Vielzahl an semantischen Standards, die jedoch nur bedingt miteinander kompatibel sind. Hinzu kommt, dass keine einsatzfähigen Werkzeuge für eine Harmonisierung solcher Standards zur Verfügung stehen. Zur Lösung dieser beschriebenen Problematik, beispielsweise im Rahmen einer elektronischen Gesundheitsakte (EHR, Electronic Health Record), ist die Harmonisierung bestehender Standards ein wesentlicher Teilschritt. Aus diesem Grund befasst sich die vorliegende Arbeit mit der Interoperablilität relevanter semantischer Standards (CEN pren und HL7 CDA R2). Dies umfasst einerseits die Untersuchung und Gegenüberstellung häufig verwendeter und international eingesetzter Standards, und andererseits einen konkreten Lösungsvorschlag zur Harmonisierung zweier grundsätzlich kompatibler semantischer Standards.

10 1.2 Problemstellung Problemstellung P1: Es existieren viele semantische Standards in der Medizin, jedoch ist es unklar, welche semantischen Standards für eine elektronische Gesundheitsakte relevant sind. P2: Es ist unklar, wie relevante semantische EHR Standards miteinander harmonisieren. P3: Es sind keine Werkzeuge bekannt, um die Harmonisierung semantische Standards zu unterstützen. 1.3 Zielsetzung Z1: Ziel ist es, relevante semantische Standards für eine elektronische Gesundheitsakte zu analysieren. Z2: Ziel ist es, Affinitäten zwischen verschiedenen semantischen EHR Standards zu finden. Z3: Ziel ist es, Werkzeuge zu finden oder zu erstellen, die exemplarisch semantische Standards harmonieren können und exemplarisch darstellen zu können. 1.4 Fragestellung F1: Welche semantischen Standards sind relevant? F2: Welche Affinitäten zwischen semantischen Standards gibt es? F3: Welche Werkzeuge zur Harmonisierung semantischer Standards gibt es?

11 2 Grundlagen und Definition 3 2 Grundlagen und Definition 2.1 Informationssysteme Die Datenverarbeitung im Gesundheitswesen und im Speziellen in Krankenhäusern ist von enormer Wichtigkeit. Deshalb besitzt jede Organisation bzw. Abteilung ihr eigenes, auf sie angepasstes Informationssystem. Ein Informationssystem lässt sich wie folgt definieren: Ein Informationssystem ist das (sozio-technische Teilssystem einer Einrichtung, das aus den informationsverarbeitenden Aktivitäten und den an ihnen beteiligten menschlichen und informationstechnischen Handlungsträgern in ihrer informationsverarbeitenden Rolle besteht. Es ist damit das gesamte informationsverarbeitende und informationsspeichernde Teilsystem in einer Einrichtung. [1] Es existieren somit eine Vielzahl an verschiedenen Informationssystem in der Einrichtung Krankenhaus. Beispiele hierfür sind das RIS (Radiologie-Informationssystem), LIS (Labor-Informationssystem) und viele andere. 2.2 Medizinische Akten Krankenakte, Patientenakte (EPA) Eine Patientenakte ist die Zusammenfassung aller verfügbaren Informationen zu einem Patienten. Die wohl bekannteste und am weitesten verbreitete Variante einer Patientenakte ist die papierbasierte Krankenakte. In dieser Form der Patientenakte werden alle papierbasierten Dokumente als auch digitale Bilder von einem Patienten zusammengeführt und in einer Aktenmappe oder Kartei abgelegt. Je nach Art des Dokumententräger, der für die Ablage bzw. Speicherung der einzelnen Dokumente zuständig ist, unterscheidet man üblicherweise zwischen einer konventionellen und einer elekronischen Patientenakte. Der Inhalt einer Patientenakte umfasst eine ganze Reihe von medizinischen Teildokumenten die wie folgt zusammengesetzt sind.

12 2.2 Medizinische Akten 4 Die elektronische Patientenakte, welche wie der Name schon andeutet auf einem elektronichen Datenträger abgelegt ist, ist eine partielle Krankenakte. In dieser Form der Patientenakte werden alle patientebezogenen Daten einzelner Informationssysteme zusammengefasst und zu einer umfassenden Krankenakte zusammengeführt. Es existiert bereits eine Vielzahl an realisierten elektronischen Patientenakte und wird von fast allen Anbiertern einer Praxis- und Kliniksoftware angeboten. Ein wichtiger Punkt bei der elektronischen Patientenakte ist die Datenobheit. Diese liegt lediglich beim Arzt, nicht aber beim Patienten. [2] Virtuelle elektronische Patientenakte(vEPA) Eine virtuelle elektronische Patientenakte ist, im Gegensatz zur elektronischen Patientenakte, eine einrichtungsübergreifende Akte, die aus einzelnen Teilakten verschiedener Leistungserbringer besteht. Bei dieser Form der Patientenakte ist es dem Patienten möglich zu bestimmen, welche peronenbezogenen Informationen gespeichert werden und welcher Arzt auf diese zugreifen darf. Jedoch besteht aus Sicht des Patienten ähnlich der elektronischen Patientenakte keine Möglichkeit die vorhandenen Daten zu manipulieren oder zu entfernen. Ein wichtiger Aspekt bei der virtuellen elektronischen Patientenakte ist die Verteilung der Daten. Die Patientendaten bleiben zu jeder Zeit in der Einrichtung in der sie erstellt wurden und werden lediglich über ein entsprechendes Rechtekonzept den Ärzten online zur Verfügung gestellt. [2] Elektronische Gesundheitsakte (EGA, ELGA) Die elektronische Gesundheitsakte wird nach Warda wie folgt definiert: Eine elektronische Gesundheitsakte, abgekürzt EGA, soll verteilt bei Leistungserbringern und Patienten anfallende klinische und gesundheitsbezogene Daten eines Menschen zusammenfassen und diese omnipräsent, lebenslang, unabhängig von Ort und Zeit allen am Behandlungsprozess Beteiligten (inkl. der Patienten) bedarfsgerecht präsentieren. [2]

13 2.3 Interoperabilität 5 Der bedeutenste Unterschied zur elektronischen Patienteakte liegt bei der alleinigen Verfügungsgewalt des Patienten über seine Akte. Dies bedeutet, dass nur der Patient darüber entscheidet, wer auf seine Akte Zugriff hat und wer welche Daten in seiner Akte ändern oder speichern darf. Zudem ist es dem Patienten möglich eingene Einträge in seine elektronische Gesundheitsakte hinzuzufügen. 2.3 Interoperabilität Der Begriff der Interoperabilität wird meist bei der Übermittlung von Daten zwischen Informationsystemen verwendet. Dabei spielt die Einhaltung von Normen und Standards einen wesentlichen Faktor. Grundsätzlich ist Interoperabilität die Fähigkeit eines Informationsystems mit anderen Informationssystemen und Softwareprodukten zu kommunizieren, Daten auszutauschen und Daten folgerichtig bereitzustellen. Dies ist mit Hilfe von speziellen Schnittstellen erreichbar. Generell unterscheidet man drei Arten von Interoperabilität: technische Interoperabilität: ist die Fähigkeit von zwei oder mehreren System Daten untereinander zu übermitteln. syntaktische Interoperabilität: ist die Fähigkeit den Austausch von Daten auf Basis von vordefinierten und exakt abgesprochenen Strukturen zu gewährleisten und semantische Interoperabilität: ist die Fähigkeit Bedeutungen einzelner Informationen übertragen zu können. Hierzu müssen präzise Absprachen getroffen werden, wie diese Bedeutungen auszudrücken und zu interpretieren sind. [3] Eine wichtige Rolle bei der Übermittlung von komplexen medizinischen Sachverhalten stellen einheitliche Datenmodelle dar. Diese sind notwendig, um bereits bei der Erfassung von medizinischen Dokumententationen einheitliche Normen, Nomenklaturen und Klassifikationssysteme zu berücksichtigen. Genau jene Anforderungen finden sich z.b. im Reference Information Model (RIM) von HL7.V3, im openehr-projekt und bei der Weiterentwicklung von prenv13606, der Europäischen Vornorm für die Elektronische Patientenakte.

14 2.3 Interoperabilität 6 Somit ist die Fähigkeit einer verlässlichen Kommunikation und Interaktion eine wichtige Voraussetzung für alle Entwickler und Hersteller eines Informationssystems sowie deren Anwender. Eine Initiative die die Interoperabilität zwischen Informationssystemen beschreibt lautet Integrating the Healthcare Enterprises 1 (IHE). IHE ist eine internationale Initiative, die hersteller- und systemübergreifend Interoperabilität zwischen IT-Systemen schafft. Unter Berücksichtigung der allgemein gültigen Standards wird von Anwendern und Herstellern gemeinsam ein technisches Rahmenwerk entwickelt, das eine präzise Definition von system und abteilungsübergreifenden Arbeitsabläufen vorgibt. IHE nutzt bestehende Standards (HL7, DICOM 2, etc.) und schafft eine sichere systemübergreifende Interoperabilität zwischen IT-Produkten verschiedener Hersteller, wie z.b. KIS, PACS, spezialisierten Abteilungslösungen oder auch im Bereich der einrichtungsübergreifenden elektronischen Patientenakte. [4] 1 Weitere Informationen über IHE Aktivitäten und Spezifikationen unter 2 DICOM... Digital Imaging and Communications in Medicine ist ein weltweiter Standard zum Austausch von digitalen Bildern in der Medizin

15 2.4 Semantische und syntaktische Standards Semantische und syntaktische Standards In fast allen medzinischen Abteilungen eines Krankenhauses werden heutzutage Daten elektronisch generiert, bearbeitet und weitergeleitet. Daher ist es speziell in der Telemedizin notwendig, dass medizinische Daten, die innerhalb einer Einrichtung für verschiedene Anwendungsprogramme bereitgestellt werden, gewisse Kommunikationsstandards einhalten. Semantische und syntaktische Standards bilden hierbei eine Schnittstelle, die auszutauschende Daten in ein für Anwendungsprogramme lesbares bzw. interpretierbares Format bringt. Ein Beispiel für einen syntaktischen Standards ist XML Extensible Markup Language (XML) Das World Wide Web Consortium(W3C), die weltweit führende hersteller unabhängige Organisation für die Weiterentwicklung von Internet Technologie mit mehr als 400 Mitglieds organisationen, bezeichnet XML als das universelle Format für strukturierte Dokumente und Daten im Internet. XML ist wie HTML eine sogenannte Markup Language, welche im eigentlichen Sinne einen Mechanismus darstellt, der eine Struktur in einem vorgegebenen Dokument feststellen kann. Im Unterschied zu HTML, kann XML praktisch beliegig erweitert werden. Mittels einer sogenannten DTD (document type definition) bzw. einem XML-Schema wird festgelegt, welche Elemente in einer XML-Datei vorkommen dürfen. XML eignet sich bersonders für die von verschiedenen Rechnertypen bzw. Plattformen unabhängige Beschreibung von komplexen, hierarchischen Strukturen und wird aus diesem Grund für die Beschreibung von medizinischen Datenmodellen eingesetzt. Zur Erstellung und Auswertung von XML-Dateien existieren eine Reihe von etablierten Softwarewerkzeugen wie z.b. sog. XML-Parser, die bereits in den verschiedensten Programmiersprachen und deren Bibliotheken integriert sind. [5] XML Schema XML Schema ist eine Sprache zur Beschreibung eines XML-Typsystems. In diesem XML- Typsystem werden XML-Elemente, deren Attribute, sowie deren Kindelemente eigens

16 2.4 Semantische und syntaktische Standards 8 spezifiziert. Im Gegensatz zu DTDs 1 kann bei Verwendung von XML Schema zwischen dem Namen des XML-Typs und dem in der Instanz verwendeten XML-Tagnamen unterschieden werden. Das folgende Beispiel definiert einen neuen XML-Datentypen mit dem Namen monatint sowie eine Liste desselben Typs. <xsd:simpletype name="monatint"> <xsd:restriction base="xsd:integer"> <xsd:mininclusive value="1"/> <xsd:maxinclusive value="12"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="monate"> <xsd:list itemtype="monatint"/> </xsd:simpletype> 1 DTD... Document Type Definition. Ist ein Satz an Regeln, der benutzt wird, um Dokumente eines bestimmten Typs zu repräsentieren.

17 3 Methoden 9 3 Methoden 3.1 Einführung der allgemeinen Methoden Stufen-Methode zur systematischen Strukturplanung Jedes Projekt bedarf einer genauen und zielorientierten Planung. Projektpläne müssen mit den vorgegebenen Zielen des Projektes und dessen Verlauf abgeglichen werden und zu jedem Zeitpunkt überwacht werden. Ziel der 5-Stufen-Methode ist es,... ein Projektziel systematisch und nachvollziehbar im Top-down-Vorgehen in überschaubare Arbeitspakete und Meilensteine zu gliedern. [1] Die 5-Stufen-Methode beschreibt folgende fünf Aspekte: 1. Gegenstand und Motivation Im ersten Teil wird der Gegenstand des Projektes beschrieben und die Bedeutung für das Umfeld dargestellt. Zudem werden mit der Problematik und der Motivation die Hintergründe erläutert, die zu dem Projekt geführt haben. Der erwartete Nutzen durch das Projekt wird in der Motivation angegeben. 2. Problemstellung In diesem Schritt werden jene Probleme spezifiziert, die mit Hilfe des Projekts gelöst werden sollen. Probleme können in mehere Teil-Probleme unterteil werden, jedoch ist darauf zu achten, dass diese kurz und verständlich dargestellt werden. 3. Ziele Im dritten Schritt werden die Projektziele beschrieben, die sich aus den genannten Problemen ableiten lassen. Es ist darauf zu achten, dass bei einer Aufspaltung in Unterziele die Gliederung nicht zu fein dargestellt wird. Es ist sinnvoll, die wesentlichen Ziele knapp und klar darzustellen. 4. Aufgaben Für jedes definierte Ziel wird eine Aufgabe definiert, die beschreibt, wie das vorgebe-

18 3.1 Einführung der allgemeinen Methoden 10 ne Ziel zu erreichen ist. Dafür werden Arbeitspakte benötigt, welche die detailierte Vorgangsweise zur Lösung der Aufgabe beschreiben. Jede Aufgabe muss sich aus einem Ziel, welches zuvor definiert und analysiert wurde, ableiten lassen. Ein Ziel kann mit einer oder mehrerer Aufgaben beschrieben werden. 5. Arbeitspakete und Meilensteine Im letzten Schritt werden aus den formulierten Aufgaben konkrete Arbeitspakete abgeleitet. Arbeitspakte beinhalten eine detailierte Beschreibung zur Lösung der im Vorhinein definierten Aufgaben, um die Ziele des Projekts zu erreichen. In diesem Schritt wird der Ablaufplan mit Hilfe von Werkzeugen und Methoden analysiert und Abgabetermine für jedes Arbeitspaket berechnet. [1] Literaturanalyse Die Literaturanalyse ist eine spezielle Form der Datenbstandsanalyse von vorhandenen Daten in Bezug auf ein spezifisches Thema. [1] Eine Literaturanalyse wird durchgeführt, indem zu einem bestimmten Thema oder zu einer Fragestellung Literatur gesucht und analysiert wird. Ziel dieser Analyse ist es, soviele relevante Informationen wie möglich zu einem bestimmten Thema zu finden. Ideen zur Durchführung und Lösung eines bestimmten Problems können aus der gewonnenen Literatur und deren enthaltenen Information entnommen werden. Durch eine Literaturanalyse ist es möglich, gefundene und verwendete Lösungsansätze zu beschreiben. Bekannte Quellen zu einschlägiger Literatur wie z.b. Bücher, Artikel in wissenschaftlichen Zeitschriften und technische Berichte werden heutzutage durch Medien wie das World Wide Web und digitale Datenträger unterstützt. Durch den Einsatz spezieller Such- und Filterfunktionen ist es möglich, elekronische Literaturdatenbanken schneller und effizienter nach Informationen zu durchsuchen. Ein Beispiel einer elektronischen Literaturdatenbank für medizinische Zeitschriften und deren Artikel stellt Medline 1 dar. 1

19 3.1 Einführung der allgemeinen Methoden Brainstorming Brainstorming wurde 1953 von Alex F. Osborn in den USA entwickelt und ist eine Aktivität, mit dem Ziel, Ideen oder Lösungsmöglichkeiten zu einem vorgegebenen Thema zu finden. Ein grundlegender Aspekt des Brainstormings innerhalb einer Gruppe ist die Auffassung, dass gefundene Ideen untereinander ausgetauscht werden können und somit einen wesentlichen Anteil zur Lösungsfindung beitragen können. Während einer Brainstorming-Session sollen zwischenmenschliche Barrieren abgebaut und kreatives Verhalten gefördert werden. Brainstorming basiert auf Gruppenarbeit und verwendet zur Dokumentation der Ergebnisse ein Protokoll, das entweder entweder am Tisch zu Papier oder auf eine Tafel gebracht wird. Einerseits muss die Gruppe groß genug sein, um die erforderlichen gruppendynamischen Anreize zu schaffen, andererseits muss sie klein genug sein, um die Kommunikation von jedem mit jedem zu ermöglichen. [6] Dies wird durch den Einsatz bestimmter Regeln erzielt: Alle Teilnehmer sollten ihr Wissen einbringen, auch wenn es für das Problem nicht relevant erscheint, denn es kann Assoziationen bei anderen wecken. Einfälle der Teilnehmer dürfen nicht reglementiert werden. Problemorientierung geht vor Lösungsorientierung, denn frühzeitiges Einschießen auf eine Lösung erschwert das Auffinden von Alternativen. Geringer Konsens kann fördernd auf das Hervorbringen neuer, innovativer Ideen wirken. Die Ideenbewertung kommt nach der Sitzung, denn diese dient allein der Ideenfindung. In hierarchisch strukturierten Gruppen mit Abhängigkeitsverhältnissen darf der Vorgesetzte die von ihm vermutete oder favorisierte Lösung nicht äußern, denn die anderen schwenken sonst leicht darauf ein, anstatt innovativ und kreativ zu sein.

20 3.1 Einführung der allgemeinen Methoden 12 Quantität geht vor Qualität, denn es geht zunächst darum, Ideen zu produzieren. Jeder Versuch einer Kritik oder Stellungnahme während der Sitzung soll vermieden oder aufgeschoben werden. Es besteht kein individuelles Urheberrecht an Ideen, sondern ein kollektives, denn Kennzeichen des Brainstormings ist das Aufgreifen und Erweitern von Ideen. Brainstorming liefert nur unstruktiertes Material welches in einem weiteren Schritt strukturiert werden muss. In dieser Phase ist nun auch Kritik erlaubt und auch notwendig. Nach Zusammenfassen der entstandenen Ideen können diese sortiert werden. Die Ideen können z.b. in sofort realisierbar, später realisierbar, nach weiterer Bearbeitung realisierbar und nicht realisierbar sortiert werden. Diese Phase des Brainstormings liefert idealerweise eine Liste mit Vorschlägen wie ein Problem definitiv zu lösen ist Unified Modeling Language Die erste Version einer objekt-orientierten Beschreibungssprache wurde 1997 als Standard von der Object Management Group (OMG) akzeptiert und als Unified Modeling Language (UML) bezeichnet. Heutzutage ist UML eine der am weitest verbreiteten Beschreibungssprachen zur Modellierung von Objektsystemen und hat sich als De-facto- Standard hearausgebildet [1]. The OMG s Unified Modeling Language TM (UML R ) helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements. [7] Zur Beschreibung einzelner Aspekte eines Objektsystems, beinhaltet UML eine Vielzahl von grafischen Notationen. Dadurch ist es möglich, nahezu alle Applikationen zu modellieren, unabhängig von deren Programmiersprache oder deren zu Grunde liegendes Betriebssystem. UML 2.0 beinhaltet dreizehn verschiedene Diagrammtypen, welche wiederum in zwei Kategorien aufgeteilt werden können:

21 3.1 Einführung der allgemeinen Methoden Strukturdiagramme: illustrieren die statischen Aspekte eines Entwurfs, d.h. Klassen und Assoziationen, Objekte und Referenzen sowie die Zusammenarbeit aller Komponenten. Zu den Strukturdiagrammen zählen unter anderem das Klassendiagramm, das Komponentendiagramm und das Objektdiagramm. 2. Verhaltensdiagramme: beschreiben die einzelnen Elemente und deren Veränderung zur Laufzeit. Zu den Verhaltensdiagrammen zählen unter anderem das Anwendungsfalldiagramm (Use-Case-Diagramm), das Sequenzdiagramm, das Aktivitätsdiagramm und das Zustandsdiagramm. [8] In 2004 wurde die UML in der Version 2.0 verabschiedet und liegt mittlerweile in der Version 2.1 vor Web Ontology Language (OWL) Die Web Ontology Lanuage [9], kurz OWL, ist für den Einsatz von Anwendungen bestimmt, die den Inhalt der Informationen anstatt der Informationen selbst darstellt. OWL erleichtert eine bessere rechnergestützte Interpretation des Inhalts als vergleichsweise XML, RDF 1 und RDF-S 2 Dies wird durch zusätzliches Vokabular erreicht, das innerhalb der formalen Semantik zur Verfügung gestellt wird. OWL besitzt drei verschiedene und mächtige Untermengen: OWL Lite: unterstützt jene Benutzer, die hauptsächlich eine Klassifikationshierarchie und eine Begrenzung benötigen. OWL Lite besitzt im Gegensatz zu OWL DL eine niedrigere formale Komplexität und dient vor allem zum Erschaffen einfacher Ontologien. OWL DL: unterstützt jene Benutzer, die eine maximale Ausdruckskraft benötigen. OWL DL beinhaltet alle der in OWL befindlichen Sprachkonstrukte, jedoch können 1 RDF... Resource Description Framework. Ist eine formale Sprache zur Bereitstellung von Metadaten im World Wide Web 2 RDF-S... RDF-Schema. Ist eine einfache Sprache um Domänen-Ontologien zu spezifizieren. RDF-S erweiter das RDF um weitere Klassen.

22 4 Durchführung 14 diese nur eingeschränkt benutzt werden. Damit die Abbildbarkeit auf diese Logik gewährleistet bleibt, wurden diverse Einschränkungen eingeführt. Ein Beispiel dafür lautet, dass eine Klasse keine Instanz einer anderen Klasse sein darf. DL steht für description logic, welche zu einer entscheidbaren Untermenge der Prädikatenlogik erster Stufe äquivalent ist. OWL Full: besteht aus den selben Sprachkonstrukten wie OWL DL, verzichtet jedoch auf die dort vorhandenen Einschränkungen. Dadurch werden Ontologien unentscheidbar, können dafür aber prädikatenlogische Ausdrücke höheren Grades ermöglichen. Jede einzelne Subsprache ist eine Erweiterung seines semantisch einfacheren Vorgängers. [9] Dies wird mit folgender Auflistung verdeutlicht. Jede gültige OWL Lite Ontologie ist eine gültige OWL DL Ontologie. Jede gültige OWL DL Ontologie ist eine gültige OWL Full Ontologie. Jede gültige OWL Lite Aussage ist eine gültige OWL DL Aussage. Jede gültige OWL DL Aussage is eine gültige OWL Full Aussage. 4 Durchführung Die aus dem Kapitel3.1 eingeführten Methoden werden in diesem Kapitel eingesetzt, um relevante semantische Standards für den Austausch medizinischer Daten zu finden und Werkzeuge für eine mögliche Harmonisierung relevanter Standards zu beschreiben. Im nächsten Abschnitt erfolgt eine genaue Beschreibung, wie die Methoden aus Kapitel3.1 eingesetzt wurden, um die Interoperabilität zweier EHR (siehe Kapitel??) Standards, die sich aus dem selben RIM ableiten lassen, zu verdeutlichen.

23 4.1 Durchführung der Literaturanalyse Durchführung der Literaturanalyse Die Literaturanalyse und die Materialbeschaffung für diese Arbeit wurde durch das Heranziehen von einschlägigen Journals und themenspezifischen Zeitschriften durchgeführt. Die technischen Grundlagen für diese Arbeit wurden aus diversen Fachbüchern, Fachzeitschriften und Online-Datenquellen bezogen. Durch die Anwendung sehr spezifischer Standards, war es nicht immer möglich, die neuesten Ausgaben bzw. Releases einzelner Dokumente zu lesen, da diese meist nur als Draft-Versionen - und somit nicht vollständig - zur Verfügung standen. Quellen relevanter Standards: Google, pubmed, IEEE, Medline. 4.2 Erstellen und übersetzen der R-MIMs in OWL Das R-MIM (siehe Kapitel ) basierte Mappen zweier verschiedener EHR Standards wird in mehreren Schritten durchgeführt. Im ersten Schritt müssen bestimmte Regeln für das Ableiten der R-MIMs aus dem RIM generiert werden. Hierfür ist es notwending, die Klassen des RIMs zu finden, mit denen es möglich ist, einen Teil der Dokumentenstruktur der verschiedenen EHR Standards abzubilden. Der CEN pren (EHRcom) und der HL7-CDA R2 Standard, welche beide zur Abbildung medizinischer Daten aus einer EHR verwendet werden, werden aus dem RIM Model abgeleitet und die interoperablen Klassen beider Standards in einem R-MIM dargestellt. Eine vereinfachte Darstellung der HL7-RIM Klassen und den daraus abgeleiteten R-MIMs ist in Abbildung1 dargestellt. Im zweiten Schritt werden die gebildeten R- MIMs verwendet, um die Eigenschaften für das Archetyp-basierende Mapping der EHR-Instanzen zu finden. Dafür werden das RIM, die R-MIMs und die Archetypen in einer Ontologie-Sprache dargestellt. In diesem Fall wurde die OWL (siehe Kapitel 3.1.5) verwendet, um die gebildeten Modelle in einer Beschreibungssprache darzustellen. Damit die EHRcom R-MIM Klassen und die CDA R-MIM Klassen in eine OWL-

24 4.2 Erstellen und übersetzen der R-MIMs in OWL 16 (a) HL7 RIM Klassen (b) EHRcom R-MIM Klassen (c) CDA R-MIM Klassen Abbildung 1: In dieser Abbildung ist ein Auszug der HL7-RIM sowie die abgeleiteten EHRcom und HL7 R-MIM Klassen dargestellt. Für nähere Informationen siehe Text. Repräsentation umgewandelt werden, wurde [10] durchgeführt. Danach wird ein Mapping-Algorithmus verwendet, um bereits bestehende Archetypen auf die jeweilige OWL-Repräsentation anzuwenden und die im Archetypen vorhandenen Properties mit den definierten Properties des dazugehörigen R-MIMs abzubilden. Die jeweils gebildete OWL-Repräsentation der HL7-RIM Klassen, der EHRcom R-MIM Klassen und der CDA R-RMIM Klassen sind im Kapitel 7.1 dargestellt. Die gebildeten OWL-Repräsentationen der R-MIMs und der Mapping-Algorithmus können in weiterer Folge verwendet werden um EHR Instanzen in andere Standards überzuführen.

25 5 Ergebnisse 17 5 Ergebnisse 5.1 Ergebnisse zu Ziel 1 Ziel1 wurde folgendermaßen definiert: Ziel ist es, relevante semantische Standards für eine elektronische Gesundheitsakte zu finden. In Tabelle1 werden die internationalen semantischen Standards, sortiert nach deren Standardisierungsgremien, dargestellt. Standardisierungs-Gremien CEN (European Comittee for Standardization) Open EHR Foundation HL7 (Health Level Seven) IHE (Integrating the Healthcares Enterprises) Standards - pren Reference Model - pren Archetypes - pren Reference Archetypes and Term Lists - pren Security Requirements and Distribution Rules - pren Exchange Model - openehr - HL7 V3 - HL7 Reference Information Model - HL7 Clicnical Document Architecture - RID (Retrieve Information for Display) - XDS (Cross-enterprise Clinical Document Sharing) Tabelle 1: Darstellung der internationalen semantischen Standards für den Austausch, das Management und die Integration von Daten in EHR Strukturen. Nach Erarbeitung der Grundlagen aus Kapitel 2 war klar, welche relevanten semantischen Standards zur Verfügung stehen. Die wichtigsten semantischen Standards werden in den folgenden Abschnitten genauer vorgestellt.

26 5.1 Ergebnisse zu Ziel openehr Hintergrund und Einführung Die openehr Foundation wurde 1999 gegründet, um die Entwicklung von offenen Spezifikationen, Software- und Wissensresourcen für Gesundheitsinformationssysteme und insbesondere für die elektronische Gesundheitsakte (EHR) zu ermöglichen. Alle Spezifikationen, die aus openehr resultieren, werden veröffentlicht. Ein wichtiger Bestandteil von openehr bilden ihre Implementierungen, die als Open Source Software angeboten und veröffentlicht werden. Die openehr Spezifikationen sind streng genommen keine Standards, sondern beruhen vielmehr auf Basis anerkannter Standards, wie z.b. ISO, HL7 oder CEN. Das openehr Specification Project ist für das Entwickeln der Spezifikationen verantwortlich, auf denen die openehr rechnergestütze Gesundheitsplattform basiert. Die Beziehungen zwischen den einzelnen Bausteinen der rechnerunterstützten Plattform und den weiteren Spezifikationen werden in der folgenden Abbildung2 verdeutlicht. [11] Die in Abbildung2 dargestellten abstract specifications bestehen aus dem Bezugsmodell (RM), dem Service-Modell (SM) und dem Archetypen-Modell (AM). Im nächsten Abschnitt werden die drei Modelle der abstract specifications in ihrer Paketstruktur vorgestellt, wobei das Referenzmodell näher beschrieben wird openehr Paketstruktur Eines der wichtigsten Designziele von openehr ist ein zusammenhängendes, gleichbleibendes und mehrfach verwendbares System für den rechnerunterstützten Gesundheitsbereich zur Verfügung zu stellen. Dementsprechend stellt die Core-Komponente des RM die Bezeichner, Datentypen, Datenstrukturen und verschiedene Designmuster zur Verfügung. Diese Elemente können sowohl in den oberen Schichten des RM, als auch in den AM und SM Pakteten verwendet werden. Die folgende Abbildung3 veranschaulicht die Beziehungen zwischen den einzelnen Paketen. Abhängigkeiten bestehen nur von höheren zu den tieferen Paketen. [11]

27 5.1 Ergebnisse zu Ziel 1 19 Abbildung 2: Veranschaulichung der Struktur des openehr Spezification Project, übernommen von [12] openehr Reference Model (RM) Das openehr Reference Model[12], welches aus dem GEHR 1 Object Model (GOM) weiterentwickelt wurde, stellt zum Unterschied zum GOM eine Konformität zum EN Reference Model (Siehe Kapitel ) dar. In Abbildung4 wird der zentrale Part des openehr Reference Models mittels den Teilmodellen EHR und Composition dargestellt. Die in der EHR befindlichen Informationen werden durch das EHR Paket zu einer strukturierten Guppierung arrangiert und bei einer eingehenden Anfrage (Request) durch das EHR EXTRACT Paket weitergeleitet. 1 GEHR... Good European Health Record( ) ist ein EU-Projekt aus dem 3. Rahmenprogramm Advanced Informatics in Medicine (AIM) und bildete die Grundlage für die Weiterentwicklung zum openehr-konzept

28 5.1 Ergebnisse zu Ziel 1 20 Abbildung 3: Veranschaulichung der openehr Paket Struktur. Für nähere Informationen siehe Text. Übernommen von [12] Im folgenden werden die wichtigsten Paketstrukturen des Reference Models beschrieben. Das EHR Paket enthält die erforderlichen Strukturen zur Repräsentation einer EHR. In diesem Paket des RM werden die in der EHR gesammelten Informationen durch FOLDER gegliedert um eine bessere Navigation zu ermöglichen. Die Zuordnung der Informationen erfolgt zu folgenden Ordnern: Persönliche Daten: Name, Geburtsdatum, Adresse uvm. Persistente Daten: Diagnosen, Medikation, uvm. Ereignisse und Episoden Das COMPOSITION Paket definiert Strukturelemente zur persistenten Speicherung von Informationen. Zudem stellt das Paket die Instanziierung eines Archetypen und dessen Ausprägung zur Informationseinheit dar. Zur logischen Gruppierung werden

29 5.1 Ergebnisse zu Ziel 1 21 Abbildung 4: Veranschaulichung des openehr Reference Models mittels den Teilmodellen EHR und Composition. Für nähere Informationen siehe Text. Übernommen von [12] sogenannte Sections verwendet, die entweder weitere Sections, oder sogenannte Entries zur fachlichen Zuordnung enthalten können. Composition, Section und Entry werden auch als archetypeable bezeichnet, da sie die Wurzel eines Archetypen bilden können. Ein Beispiel hierzu wäre der Archetyp blood pressure measurement 1. Dieser ist vom Typ Observation und somit eine Unterklasse von Entry. Das DATA STRUCTURE Paket enthält Strukturen die zu Definition komplexer Datenstrukturen verwendet werden. Das Element HISTORY ermöglicht es Datenstrukturen 1 Unter stehen sämtliche Archetypen kostenlos zur Verfügung. Der Archetyp Blood preasure measurement besitzt folgende ArchID: openehr-ehr-observation.blood pressure.v1

30 5.1 Ergebnisse zu Ziel 1 22 mit Ereignissen zu verknüpfen und diese auf einer Zeitachse darzustellen. EHR EXTRACT wird verwendet um ein Teilsystem einer EHR zu isolieren und bei einer eingehenden Anfrage auf die EHR, Informationen repräsentativ aufzubereiten und zu versenden. [11] openehr Archetype Model (AM) Das openehr Archetype Model[13] Paket enthält die notwendigen Modelle, um die Semantik von Archetypen und Templates und deren Gebrauch innerhalb des openehr Standards zu beschreiben. Diese Modelle beinhalten die Archetype Definition Language( ) (ADL), die Archetyp-Templates die ein Profil des generischen Archeyp Modells definieren. Das openehr Archetyp Model wurde gänzlich von ENV übernommen und wir im Kapitel näher erläutert. [11] openehr Service-Model (SM) Das openehr Service Model beinhaltet Definitionen von Standard-Services im Gesundheitsinformationsbereich, die auf die Elektronische Gesundheitsakte ausgelegt sind. Ein umfassendes Kontingent an Services wird sich erst im Laufe der Zeit herausstellen und deshalb befindet sich dieses Model noch in der Entwicklung. Ein Beispiel eines solchen Standard-Services ist z.b. die Bereitstellung der EHR-Daten in einem Online-Repository, welches durch den Menschen via Browser bedient werden kann, oder durch rechnergestützte Anfragen durchsucht werden kann. [11] CEN Der 1999 eingeführte, auf die medizinische Versorgung beschränkte CEN ENV Health informatics EHCR communication Standard definierte eine komponenten-basierte EHR Referenzarchitektur, ohne die Container füllenden Fachkonzepte zu beschreiben. EN/ISO Health informatics Electronic Health Record communication, ergänzt die weiterentwickelte, zum HL7 RIM verträgliche Referenzarchitektur (Part1: Reference Model) um die im Rahmen des openehr-projektes entwickelte Konzeptrepräsentation

31 5.1 Ergebnisse zu Ziel 1 23 durch Archetypes (EN Part2: Archetype Interchange Specification). Die Terminologie wird im neuen Teil 3 (Part3: Reference Archetypes and Term Lists) um ein Set von Archetypes erweitert, die Unterschiede zu klinischen Anforderungen und Rahmenbedingungen reflektieren. Der datenschutzrelevante Teil 3 (ENV Part 3:Distribution Rules) wird als Teil 4 (EN Part4: Security Features) zu einer umfassenderen Sicht auf Datenschutz und Datensicherheit erweitert. Der letzte Teil der neuen Spezifikation (EN Part5: Exchange Models) beschreit durch Beispiele die Implementierung des Standards. Die Revision des CEN ENV liefert eine dem Architekturparadigma folgende Spezifikation für semantisch-interoperable EHR-Systeme, die die Kommunikation und Kooperation von EHR-Extrakten, aber auch ganzer EHR unterstützt. Die Referenzarchitektur des EN/ISO ermöglicht die strukturelle Komposition/Dekomposition sowie die Repräsentation von Konzepten der jeweiligen Komponentenmodelle durch plattformunabhängige Informationsmodelle. Da die Definition der Archetypen im Gegensatz zum strengen systemtheoretischen Ansatz der etablierten Standards weder strenge Paradigmen für die Definition der Komponenten noch Regeln für ihre Komposition/Dekomposition enthält, kann die semantische Komposition/Dekomposition nicht realisiert werden. [14] CEN pren , Reference Model Die Informationen in einer Gesundheitakte sind hierarchisch aufgebaut. Klinische Beobachtungen, Argumentationen und Absichten können eine einfache oder eine komplizierte Struktur haben. Eine Gesundheitsakte wird im Allgemeinen in verschiedene Rubriken unterteilt. Solche Rubriken können verschiedene Dokumente, wie z.b. ärztliche Anmerkungen, Arzbriefe und Befunde enthalten. Diese Dokumente werden üblicherweise in Akten eingeordnet, und ein Patient kann mehr als nur eine Akte innerhalb einer Gesundheitseinrichtung (z.b. Medizinisce Abteilung, Pflegestation, etc.) haben. [15] Das EHR Extract Reference Model muss diese hierarchische Struktur und deren Organisation wiedergeben können, sowie den ursprünglichen klinischen Kontext und dessen Bedeutung zuverlässig wieder herstellen können. Dies ist gerade dann von enormer Bedeutung, wenn Aufzeichnungen zwischen heterogenen klinischen Informationssystemen

32 5.1 Ergebnisse zu Ziel 1 24 transferiert werden. Das Informationsmodell enthält eine Gruppe von Kategorien und Attributen, die auch als Reference Model bezeichnet wird. Das Informationsmodell wird als eine Klasse von Diagrammen dargestellt, welche mittels der Unified Modelling Language (UML) modeliert sind. Zusammen mit der formalen Dokumentation wird jedes einzelne Konstrukt erläutert und alle relevanten Kardinalitäten, Datentypen und Bedingungen definiert.[15] Das Informationsmodell wird in folgende Klassenpakete aufgeteilt: Extract package: definiert die EHR EXTRACT Wurzelklasse, die alle EHR Daten enthält (); Demographics package: stellt eine minimal erforderliche Datenklasse bereit, welche die verschiedenen Personen, Einheiten und Organisation definiert, die in der Wurzelklasse referenziert sind; Access Control package: definiert die Darstellung der Zugangsregeln, auf welche Daten definierte Personen innerhalb der Wurzelklasse Zugang haben; Message package: ist ein Platzhalter für alle Attribute die benötigt werden damit die Wurzelklasse mit einem anfragenden Prozess (z.b. Nachricht) kommunizieren kann. [15]

33 Abbildung 5: In dieser Abbildung ist das CEN Reference Model mit dessen Hauptklassen und Attributen dargestellt. Für nähere Informationen siehe Text. Übernommen von [15]

34 5.1 Ergebnisse zu Ziel Extract package Dies ist die Wurzelklasse des Reference Models. Sie repräsentiert die virtuelle Elektronische Gesundheitsakte für eine Person bzw. eines Patienten. Die EHR EXTRACT Klasse enthält Attribute für die eindeutige Identifizierung und Zuordnung einer Person zu einer Gesundheitsakte. Weiters identifiziert diese Klasse den Provider (Informationsübermittler) der Gesundheitsakte und die Organisation, die sie erstellt hat. [15] Abbildung 6: EHR EXTRACT Klasse des pren Reference Models Die weiteren Klassen, welche mit der EHR EXTRACT Wurzelklasse assoziiert werden, bilden bei einer eingehenden Anfrage auf eine EHR die gesammelten Informationen zu einer Person bzw. Patienten aus desssen virtueller elektronischen Gesundheitsakte ab. Abbildung 7: EHR EXTRACT Klasse der pren RM und Assoziationen Die Klassen FOLDER, COMPOSITION, SECTION, ENTRY, CLUSTER und ELE- MENT werden auch als Record Components bezeichnet und sind jeweils Unterklassen der

35 5.1 Ergebnisse zu Ziel 1 27 abstrakten RECORD COMPONENT Klasse. Diese müssen einen eindeutigen Namen und eine Bezeichnung (Identifier) besitzen. Die Record Components werden wie folgt beshrieben: Die Klasse Folder: wird benötigt, um die highest-level Organisationen der EHR EXTRACT darzustellen. Die Klasse Composition: enthält jene Informationen der Klasse RE- CORD COMPONENTS, die während einer Sitzung bzw. eines Zugriffs eines Benutzers auf die EHR erfasst wurden. Die Klasse Section: wird dazu verwendet, um klinischen Rubriken hierarchisch darzustellen und die Eintragungen innerhalb einer COMPOSITION zu gruppieren und zu strukturieren. Dadurch entsteht für den Menschen eine bessere Lesbarkeit. Die Klasse Entry: enthält jene Informationen, die für eine einzelne Beobachtung bzw. mehrere aufeinander folgende Beobachtungen erhoben werden. Zudem werden einzelne klinische Aussagen, wie z.b. über die Geschichte des Patienten und durchgeführte Tätigkeiten in der Entry-Klasse aufbewahrt. Die Klasse Cluster: wird verwendet, Elemente innerhalb eines Eintrags zu vereinigen, um die Darstellung von komplizierten Datenstrukturen, wie z.b. Tabellen oder Listen zu ermöglichen. Die Klasse Element: stellt den Blattknoten innerhalb der EHR Hierarchie dar. Beispiele zu dieser Klasse sind z.b. der Grund für die Aufnahme, Körpergewicht, Puls uvm. Jede Instanz dieser Klasse besitzt einen einzelnen Datenwert, der einer der definierten Datentypen der CEN darstellt.

36 5.1 Ergebnisse zu Ziel pren , Archytype Model In der Spezifikation pren Archytype Model[13] sind die eigentlichen Baupläne der elektronische Patientenakte enthalten. Diese werden in Form von Archetypen definiert. Als Archetyp bezeichnet man eine bestimmte Darstellung eines klinischen Begriffs auf Basis des aus der Spezifikation pren bekannten Referenzmodells. Archetyp bedeutet Urform oder Musterbild und meint hier die Beschreibung des Aufbaus einer Informationseinheit. Ein Archetyp legt fest, wie Objekte des Referenzmodells zur Darstellung eines Begriffs im Computersystem miteinander kombiniert und welche Werte darin gespeichert werden dürfen. Ein Archetyp ist unabhängig von Terminologie und Sprache, da er den Begriff, das gedankliche Konzept, repräsentiert.... [16] Definition Der Hauptdefinitionsteil eines Archetypen besteht aus sich abwechselnden Schichten von Objekt-, Attribut- und Constraintknoten. Jede einzelne Schicht beinhaltet eine weitere Knotenebene. In diesem Abschnitt bezieht sich das Wort attribute auf mögliche Dateneigenschaften einer Klasse. Dabei ist es unabhängig davon, ob die betrachtete Dateneigenschaft als eine Beziehung zwischen den einzelnen Klassen (d.h. Assoziation, Aggregation oder Composition) angesehen wird, oder als Attribut (d.h. Wert) in einem Objektmodell verstanden wird. An den Blättern befinden sich Constraintknoten, die primitive Datentypen, wie z.b. STRING, INTEGER, etc. beinhalten. Weitere Knoten repräsentieren interne Referenzen zu anderen Knoten. Zudem bestehen Constraintreferenzknoten die sich auf textuelle Constraints im Contraintbindungsteil der Ontologie eines Archetypen beziehen und Archetypconstraintknoten, die Constraints an neu angelegten Archetypen repräsentieren. [13]

37 Abbildung 8: In dieser Abbildung ist das Archetyp Model Teil1 der pren Spezifikation mit den dazugehörigen Hauptklassen dargestellt. Für nähere Informationen siehe Text. Übernommen von [13]

38 Abbildung 9: In dieser Abbildung ist Teil2 der pren Spezifikation mit den Attributen der C PRIMITIV OBJECT Klasse dargestellt. Für nähere Informationen siehe Text. Übernommen von [13]

39 5.1 Ergebnisse zu Ziel Datentypen Abseits der bereits im UML Standard enthaltenen Semantik und dessen Datentypen, werden weitere Standard-Datentypen und Basistypen aus dem openehr Reference Model eingeführt. [16] Diese Datentypen lauten wie folgt: Date Time Date Time Duration Hash <T, K:Comparable>...eine Liste von Objekten eines jeden einzelnen Typs Intervall <T:Comparable>...Intervall von Instanzen eines geordneten Typs Diese oben genannten Typen werden wie in den meisten Implementierungstechnologien, wie z.b. XML oder Java, unsterstützt. Sie werden in der Archetyp Spezifikation jedoch nicht definiert, damit sie in den vorhandenen Implementationstechnologien problemlos gemappt und anderen Datentypen zugewiesen werden können. [13] Folgende openehr Datentypen wurden in diese Spezifikation übernommen: ARCHETYPE ID HIER OBJECT ID TERMINOLOGY ID CODE PHRASE DV CODED TEXT Abbildung dient zur Veranschaulichung der aus openehr entnommenen Datentypen.

40 5.1 Ergebnisse zu Ziel 1 32 Abbildung 10: In dieser Abbildung sind die openehr spezifische Datentypen abgebildet. Für nähere Informationen siehe Text.Übernommen von [13] Ontologie Es gibt keine sprachlichen Entitäten im Definitionsteil eines Archetypen, mit Ausnahme einer möglichen Begrenzung auf Texteinzelteile, die in regulären Ausdrücken bzw. Zeichenketten (Strings) definiert wurden. Alle sprachlichen Entitäten werden im Ontologie-Teil eines Archetypen so definiert, dass sie in andere Sprachen (z.b. XML) übersetzt werden können. [13] Es gibt vier Hauptteile in der Ontologie eines Archetypen: 1. die Ausdrucksdefinitionen 2. die Constraintdefinitionen 3. die Ausdrucksverbindungen 4. die Constraintverbindungen Die beiden ersten definieren die Bedeutungen der verschiedenen Bezeichnungen und die Begrenzungen der Texteinzelteile innerhalb eines Archetypen. Sie werden mit einer eindeutigen Bezeichnung versehen, welche im Definitionsteil des Archetypen beschrieben werden. Die beiden letzten Ontologie-Anteile beschreiben die Bedingungen zum Abbilden der internen Ausdrücke auf eine externe Terminologie.

41 5.1 Ergebnisse zu Ziel Spezialisierung Archetypen können spezialisiert werden. Ein Archetyp gilt als eine Spezialisierung eines anderen Archetypen, wenn er diesen als seinen Elternknoten enthält. Änderungen an der Definition eines spezialisierten Archetyps werden nur so gemacht, dass seine Begrenzungen in einem engeren Bereich liegen, als die seines Elternknotes. Alle generierten Daten, die über eine Spezialisierung erzielt wurden, sind folglich zu sich selbst und zu seinem Elternknoten komplementär. Der Begriff der Spezialisierung entspricht der Idee der Substitution bezogen auf Daten. Jeder Archetyp besitzt eine Spezialisierungstiefe. Archetypen mit keinem Elternteil haben Tiefe 0. Spezialisierte Archetypen fügen je eine Ebene zu ihrer Tiefe hinzu, für jeden Schritt der benötigt wird, um sie in der Hierarchie zu erreichen. [13] Archetype Definition Language (ADL) Was ist ADL? Neben der Möglichkeit, Archetypen durch das Archetyp Model darzustellen, gibt es mit der Archetype Definition Language (ADL) noch einen weiteren Ansatz. ADL ist eine formale Sprache die zum Spezifizieren der Archetypen dient. Dies ist durch eine abstrakte Syntax zur Constraintbeschreibung aller Domänenentitäten möglich, deren Daten durch ein Informationsmodell dargestellt sind. Für jeden Archetyp wird ein ADL- Konstrukt in Textform angegeben, das analog zu XML/DOM ebenfalls als hierarchische Objektstruktur interpretiert werden kann. [17] Das openehr Archetype Object Model beschreibt ein Objektmodel, welches äquivalent zur ADL Syntax ist. ADL verwendet zwei weitere Sprachen um die Constraints der Daten zu beschreiben, die Instanzen zu generischen Informationsmodellen wie z.b. UML darstellen. Diese zwei Sprachen heißen: 1. cadl - Constraint ADL 2. dadl - Data ADL Üblicherweise kommen sehr generische Informationsmodelle zum Einsatz, um die Daten

42 5.1 Ergebnisse zu Ziel 1 34 eines Systems zu beschreiben. Ein Beispiel hierzu wäre die Datenrepräsentation der logischen Konzepte PATIENT, ARZT und KRANKENHAUS, welche durch die Klassen Partei und Adresse dargestellt werden können. In so einem Fall, geben Archetypen die gültigen Instanzen von generischen Klassen vor und repräsentieren somit die gewünschten Domänenkonzepte. Auf diese Weise ist es möglich, zukunftsorientierte und sichere Informationssysteme zu bilden. Aus verhältnismäßig einfachen Informationsmodellen und Datenbankschemen können spezifisch modellierte Archetypen, die vom System vollkommen unabhängig sind, erstellt werden. ADL kann somit für das Erstellen von Archetypen sowie für fast jede Domäne verwendet werden, in welcher formale Objektmodelle existieren und Dateninstanzen beschrieben werden. ADL ist eine Spezifikationssprache, die sowohl von openehr verwendet wird, als auch Inhalt der Norm CEN ist. [17] Strukturaufbau der ADL Die Archetypen, die in ADL ausgedrückt werden, ähneln sehr stark Sprachepaketen verschiedener Programmiersprachen und haben eine definierte Syntax. ADL selbst ist eine relativ einfache Syntax, die zwei andere Syntaxen für das Ausdrücken der strukturierten Daten verwendet. Die cadl Syntax wird verwendet, um die Archetypdefinition auszudrücken, während die dadl Syntax verwendet wird, Daten auszudrücken, die in Sprach-, Beschreibungs- und Ontologieabschnitten eines ADL-Archetypen auftreten. [17] Die Struktur eines ADL-Archetypen wird in Abbildung verdeutlicht.

43 5.1 Ergebnisse zu Ziel 1 35 Abbildung 11: In dieser Abbildung ist der Strukturaufbau eines Archetyp dargestellt. Für nähere Informationen siehe Text. Übernommen von [13] Ein Archetyp wird mittels ADL bzw. auch implizit mittels des Archetyp Models in vier Abschnitten beschrieben: 1. Abschnitt: Identifikation 2. Abschnitt: Beschreibung 3. Abschnitt: Definition 4. Abschnitt: Ontologie Im Abschnitt Identifikation wird jeder Archetyp durch eine Beschreibung bzw. durch einen Identifikator eindeutig bestimmt. Zudem ist es möglich, dass sich ein Archetyp zur Identifikation von einem anderen Archetypen ableiten lässt. Im folgenden Beispiel stellt blood pressure die eindeutige Beschreibung des Archetypen dar. archetype (adl_version=1.2) openehr-observation.blood_pressure.v1

44 5.1 Ergebnisse zu Ziel 1 36 Das Concept-Statement ermöglicht es einem Archetypen eine Verbindung zu einem Begriff herzustellen. Das folgende Beispiel zeigt mit der lokalen Referenz at0000 auf einen Eintrag, der sich im Ontologie-Abschnitt des Archetypen befindet: concept [at0000] -- blood pressure Der Abschnitt Beschreibung enthält die Metadaten eines Archetypen. Er enthält Information zu Zweck, Anwendungsgebiet und Ersteller des Archetypen. Dieser Abschnitt wird mittels der Sprache dadl kodiert: description original_author=<"hans Schmidt"> description("de")=< purpose=<"blutdruckmessung"> [...] Der nächste Abschnitt in einem Archetypen formuliert die erlaubten Objektstrukturen, die in Form von Constraints angegeben werden. Hier wird festgelegt, welche Klassen des Referenzmodells für einen Archetypen instanziiert werden, wie diese hierarchisch gruppiert werden und welche Assoziationen erlaubt sind. Dabei ist darauf zu achten, dass für jede Instanziierung einer Referenzmodellklasse eigene Constraints (Einrschränkungsregel) angegeben werden müssen. Im Definitionsabschnitt kommt die Sprache cadl zum Einsatz. Das nächste Beispiel beschreibt den Ausdruck für den diastolischen Blutdruck: ELEMENT at00005 matches{ -- diastolic blood pressure value matches{ QUANTITY matches{ magnitude matches{ } property matches{"pressure"} units{"mm[hg]"} } } }

45 5.1 Ergebnisse zu Ziel 1 37 Das Beispiel zeigt, dass die Klasse ELEMENT aus dem Referenzmodell instanziiert werden muss, um eine Informationseinheit für den diastolischen Blutdruck zu erstellen. Weiters muss die Assoziation value auf eine weitere Instanz des Typs QUANTITY zeigen, für den Einschränkungen bzgl. der Attribute definiert sind. Im letzten Abschnitt, dem Ontologie-Abschnitt, wird dem Archetypen bzw. seiner Objektstruktur eine Semantik hinzugefügt. Hier können nun textuelle Beschreibungen des Archetypen als auch Beschreibungen für einzelne Informationseinheiten (term definition) hinterlegt werden und zusätzliche Verknüpfungen (term binding) zu einer bestehenden Termininologie hergestellt werden. Das folgende Beispiel zeigt einen Ontologie-Abschnitt eines Archetypen in dadl kodiert: term_definition("en")=< items("at0005")=< text=<"diastolic"> description=<"the systemic arterial blood pressure in diastolic phase"> > > term_binding("snomed-ct")=< items("at0005")=<[snomed-ct(2003):: ]> > Wie stehen Archetypen mit HL7 V3 in Verbindung? HL7 hat eine Interessengruppe (SIG - Special Interest Group) für Templates eingerichtet. Ein Template(siehe Kapitel ) ist für HL7 die ungefähre Übersetzung eines Archetypen. Zur Zeit unterscheidet HL7 nicht zwischen den Begriffen eines Archetypen und eines Templates wie es in openehr definiert ist. Für HL7 liegt der Hauptaugenschein auf einer Template Methode für RIM-basierte Objekte. Derzeit wird das HL7 Model Interchange Format (MIF) verwendet. Dies ist ein HL7 spezifischer Formalismus um HL7 Modelle darzustellen. Fakt ist, dass ADL-Archetypen(siehe Kapitel ) gegen jedes UML Model beschrieben

46 5.1 Ergebnisse zu Ziel 1 38 werden können. Zusätzlich ist es möglich, Archetypen direkt gegen das HL7v3 Reference Information Model (RIM) abzubilden Health Level 7 (HL7) Hintergrund und Einführung Health Level Seven (HL7) wurde 1987 gegründet und ist eine von der amerikanischen Normierungsbehörde ANSI und zwischenzeitlich auch von Normierungsbehörden anderer Länder anerkannte Non-for-Profit-Organisation, die Standards im Gesundheitswesen entwickelt. Diese Standards dienen dem Austausch, Management und zur Integration von Daten, die der Patientenversorgung dienen und das Management sowie der Evaluation von Gesundheitsdienstleistungen betreffen. Dieser weit verbreitete Standard wird ständig weiterentwickelt und befindet sich zum momentanen Stand in der Version 3. Nationale Benutzergruppen rund um die Welt adaptieren und verbreiten HL7 nicht nur im eigenen Land, sondern haben in den letzten Jahren die Internationalisierung von HL7 im Sinne eines weltweit nutzbaren Standards im Gesundheitswesen entscheidend mitbestimmt und vorangetrieben HL7 Reference Information Model (RIM) Das HL7 RIM [18] ist ein kritischer Bestandteil im Entwicklungprozess der Version 3. Es ist die Wurzel aller Informationsmodelle und Strukturen, die als Teil des V3 Entwicklungsprozesses entwickelt werden. Der HL7 V3 Standardentwicklungsprozess ist eine modellbasierte Methodik, in der ein Netzwerk aus zusammenhängenden Modellen entwickelt wird. Dieses Netzwerk stellt die statischen Apekte der Anforderungen, des Designs der HL7 Standards, sowie die zugrundeliegende Semantik und die Geschäftsprinzipien bildlich dar. Das RIM liefert eine statische Ansicht aller Informationen der Standards. Es beinhaltet Klassen und Zustands-Diagramme und wird von verschiedenen Modellen (Use-Case-Modelle, Daten-Typen-Modell, etc.) begleitet um eine komplette Darstellung aller Anforderungen der HL7 Standards zur Verfügung zu stellen. Weiters definiert der HL7 V3 Standardentwicklungsprozeß Richtlinien, welche die

47 5.1 Ergebnisse zu Ziel 1 39 Ableitung der Domänen-Informations-Modelle vom RIM und die Verfeinerung solcher Modelle in Spezifikationen des HL7 Standards regeln. Die Richtlinien erfordern, dass alle Informationsstrukturen in abgeleiteten Modellen zum RIM zurückverfolgbar sind. Hinzu kommt, dass ihre semantischen Geschäftsprinzipien nicht mit denen im RIM spezifierten widersprechen dürfen. Das RIM ist folglich die entscheidende Quelle für den gesamten Informationsgehalt des HL7 V3 Standards. Abbildung12 zeigt das HL7 Reference Information Model (RIM) mit dessen sechs Kernklasse. Abbildung 12: HL7-RIM Model und Kernklasse. Die Hauptklassen lauten Act, Role, Participation, Entity, RoleLink und ActRelationship. Für nähere Informationen siehe Text. Übernommen von [18]

48 5.1 Ergebnisse zu Ziel Von V2.x zu V3 Nachrichten V2.x Nachrichten besitzen eine variable Länge, ein einheitliches Format und bestehen aus Segmenten, die mit ASCII-Text gefüllt sind. Jedes Textsegment besitzt eine festgelegte Sequenz von Datenelementen (auch Felder gennant), die durch Trennzeichen von einander getrennt sind. Jedes Datenelement wird üblicherweise mit einer vertikal angeordneten Leiste (auch pipe gennant) von einander getrennt. Jedes Datenelement kann mehrere Komponenten beinhalten, die mit einem ˆ - Symbol von einander getrennt werden. Die folgende Beispiel-Nachricht (V2-Nachricht) dient einer besseren Anschauung: MSH ^~\& PATH GP ORU^R P 2.5^AUS AL NE AUS en<cr>pid KNEE123 Knees^Nobby^J^^Mr M 23 Shady Lane^LIGHTNING RIDGE^NSW^ <cr> OBR 1 PMS LFT^LIVER TEST^N2270<cr> OBX 1 NM ^S Albumin^LN 38 g/l F<cr> OBX 2 NM ^S Alkaline Phosphatase^LN 52 U/L F<cr> Version 3 repräsentiert einen neuen Ansatz von Version2.x indem eine neue Methodik zur Nachrichtengenerierung entwickelt wurde. Version 2.x besitzt keine spürbare Entwicklungsmethodik und dadurch wurden verschiedene Bestandteile des V2.x Standards in verschiedenen Formen neu entwickelt. Version 3 wird aus einem einzelnen Objektmodel, dem Reference Information Model (RIM) gebildet. Der aktuelle Entwurf der V3 Spezifikationen ist durch 96 Hierarchical Message Descriptors(siehe Kapitel ) (HMDs) definiert und wird durch individuelle Nachrichtentypen spezialisiert. Während sich Version2.x meist auf allgemeine Trigger, Struktur und Kommunikationsentwürfe beschränkte, ist Version 3 mehr auf spezifische Zusammenhänge, Terminologie, Modelle und konzeptionelle Definitionen und Beziehungen fokussiert. Im Gegensatz zu V2.x, die auf ASCII Textnachrichten ausgerichtet ist, ist V3 durch das Einsetzen von XML durch eine bessere Struktur gekennzeichnet. [19]

49 5.1 Ergebnisse zu Ziel HL7 Templates Ein HL7-Template [20] ist eine Datenstruktur, basierend auf dem Reference Information Model, welche den Dateninhalt ausdrückt, der in einem spezifischen klinischen oder administrativen Kontext benötigt wird. Sie sind vorgeschriebene Muster, bei denen mehrfache OBX 1. Segmente kombiniert werden können, um die ausgewählten, groben Beobachtungen zu beschreiben. Einige Beobachtungen können, wie das Messen des Blutdrucks, ziehmlich einfach sein. In diesem Beispiel wird ein Satz der gemachten Beobachtungen miteinbezogen (z.b.: systolisch, diastolisch, Position, Methode, usw..) Andere, durchdachtere Diagnostikverfahren können Hunderte der in Verbindung stehenden Information, einschließlich Anatomie, Lagebestimmung, Reihenfolgen von Maßen, usw. mit einbeziehen. Ein Template wird durch eine formale Definition in einer oder mehrerer für den Menschen lesbaren Sprachen und einer formalen Definition als statisches Modell dargellt. Zusätzlich wird ein Template durch eine oder mehrere implementationsabhängigen Darstellungen, die zur Kontextvalidierung verwendet werden, repräsentiert. Zu jedem Template gibt es einen Satz von Metadaten der mit dem Template verbunden ist, um den Zweck und die Anwendbarkeit des Templates zu beschreiben. Ein Template wird durch ein einzelnes XML Dokument dargestellt. Das Dokument enthält die XML Metadatan, eine Darstellung des Modells und optional eine beliebige Anzahl von Attachments, die die implementierungsspezifischen Darstellungen des Templates liefern bzw. zusätzliche unterstützende Informationen enthalten Clinical Document Architecture (CDA) Die HL7 Clinical Document Architecture (CDA) [21] ist ein XML Dokument-Markup Standard, der die Struktur und die Semantik von klinischen Dokumenten spezifiziert. XML ist eine flexible Weise, Standardinformationsformate zu generieren und das Format und die Daten bezüglich Austausch und Interkommunikation bereitzustellen. Ein CDA 1 OBX... Observation/Result Segment.In diesem Segment werden die Untersuchungsergebnisse abgelegt

50 5.1 Ergebnisse zu Ziel 1 42 Dokument ist ein definiertes und komplettes Informationsobjekt, welches Text, Bilder und andere multimediale Daten enthalten kann. Die Clinical Document Architecture wurde innerhalb der HL7-Gruppe entwickelt und stellt seit 1997 einen XML-basierten Dokumenten-Markup Standard zur strukturierten klinischen Dokumentation zur Verfügung. Der CDA Standard ist Teil der HL7 Version 3 Standards. Die erste Version konnte bereits im September 2000 als offizieller Standard verabschiedet werden (CDA Level One ANSI/HL7 CDA R ). Damit galt CDA R1 als erster offizieller XML-basierter Standard im Gesundheitswesen. The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. A clinical document is a documentation of clinical observations and services [...] [22]. CDA ist sehr ähnlich zu der Composition Klasse der CEN Spezifikation(siehe Kapitel) und der Transaction Klasse aus openehr(siehe Kapitel) Eigenschaften von CDA Im CDA Standard werden sechs Kerneigenschaften definiert, die ein Dokument nach CDA beschreiben. Diese Eigenschaften werden wie folgt beschrieben: Persistenz: ist die dauerhafte Existenz eines Dokuments innerhalb eines Systems. Dies bedeutet, dass ein CDA Dokument zu keiner Zeit aus einem System gelöscht werden darf. Ein CDA Dokument ist somit wie ein papierbasiertes Dokument in einer Gesundheitseinrichtung, zu Dokumentationszwecken unbedingt aufzubewahren. Verantwortung für die Abzeichnung des Dokuments: Eine Organisation bzw. all jene Personen, die für die Erstellung und Verwaltung des CDA Dokuments verantwortlich sind, haben dieses Dokument zu unterzeichnen. Signaturfähigkeit: Ein CDA Dokument ist durch Informationen bzw. durch gültige digitale Signaturen gekennzeichnet, damit dieses vor dem Gesetz Bestand hat.

51 5.1 Ergebnisse zu Ziel 1 43 Ganzheit des Dokuments: Der Inhalt eines Dokuments bezieht sich immer auf das Dokument als Ganzes. Dies bedeutet, dass Teilinformationen eines Dokuments, nicht ohne Bezug auf das Dokument verwendet werden. Kontext: Für das gesamte Dokument gilt die Kontextbewahrung. Dies bedeutet, dass z.b. für einen Entlassungsbrief, alle gesammelten Informationen über den Patienten und dessen vorangegangener Behandlung im Kontext der Entlassung stehen. Lesbarkeit: ist die für den Menschen lesbare Form von klinischen Informationen eines CDA Dokuments. Diese sogenannte Lesbarkeit ist dadurch gegeben, dass die klinischen Informationen im XML Dokument auf einem deterministischen Weg für den Menschen lesbar gemacht werden. Dies ist z.b. mit der Hilfe von Stylesheets und einem handelsüblichen Browser gegeben. Die Spezifikation unterscheidet drei aufeinander aufbauende Stufen (Level), die sich durch den Grad der Strukturierung des Dokumenteninhaltes unterscheiden. Generell besteht jedes CDA Dokument aus einem header und einem body. Die drei aufeinander aufbauenden Stufen werden wie folgt beschrieben: Level1 : Der CDA Header wird aus dem HL7 RIM abgeleitet und definiert die Semantik eines jeden Eintrags im Dokument. In Level 1 wird lediglich ein strukturierter Header definiert. Der Body, der den Inahlt des Dokuments wiedergibt, ist unstrukturiert und lässt die Eingabe eines beliebigen Textes zu. Dies bedeutet, dass Level1 nur durch einen Menschen lesbar ist. Level2 : Im Gegensatz zu Level1, ist der Body in Level2 in Abschnitte unterteilt und strukturiert, jedoch besteht weiterhin die Möglichkeit unstrukturierten Text zum Dokument hinzuzufügen. Der Header ist im Gegensatz zu Level1 mit verschiedene Dokumententypen erweiterbar, wie z.b. dem Arztbrief. Eine teilweise Lesbarkeit durch Maschinen ist in Level2 erstmals gegeben. Level3 : In diesem Level ist das Dokument völlig strukturiert. Es gibt keine Möglichkeit mehr, dem Dokument unstrukturierten Text hinzuzufügen. Das Dokument ist

52 5.1 Ergebnisse zu Ziel 1 44 komplett durch eine Maschine lesbar und die Semantik jeder einzelnen Entität wird durch einen eindeutigen Code in einem Codierungssystem (SNOMED, LOINC, etc.) dargestellt. [21] Unterschiede CDA Release1&2 CDA Release 2 ist eine Weiterentwicklung der CDA Release1. Release 2 wurde stark überarbeitet, um eine größere Anzahl von Dokumententypen zu unterstützen und um in sich komplettere Header Informationen zu beinhalten. Zusätzlich basiert CDA Realease 2 vollständig (Header und Body) auf das HL7 RIM und ist mit anderen Spezifikationen harmonisiert worden, damit die klinischen Informationen, die im CDA oder vergleichbaren HL7 V3 Nachrichteninhalt ausgedrückt werden, dargestellt werden können. Das CDA ist flexibel erweiterbar und wurde auch deshalb zur Release 2 weiterentwickelt, da die Struktur des Release1 Headers und Bodys deutliche Grenzen in Bezug auf Interoperabilität aufweiste. [21] Aufbau und Struktur eines CDA R2 Dokuments Ein CDA Dokument beginnt durch das Element <ClinicalDocument>. In diesem Bereich befindet sich der header und der body. Der header, der die Metadaten zur Authentisierung, zum Patienten und den involvierten Providern beinhaltet, liegt zwischen den Elementen <ClinicalDocument> und <structuredbody>. Der body beinhaltet den klinischen Befund und kann entweder ein unstrukturierter Blob, oder ein strukturierter Markup sein. Das folgende Beispeil zeigt einen strukturierten body, welcher ab dem <structuredbody> Element beginnt. Der body ist in verschiedene Dokumentenabschnitte (Sektionen) unterteilt. Ein Abschnitt beginnt durch das Element <section>. Jeder Abschnitt kann einen einzelnen Textblock und jede mögliche Anzahl von CDA entries und externe Referenzen beinhalten. Der CDA Textblock beginnt durch das Element <text> innerhalb des <section> Elements und muss den für den Menschen lesbaren Inhalt enthalten.

53 5.1 Ergebnisse zu Ziel 1 45 Innerhalb eines Dokumentabschnitts stellt der Textblock den übertragenen Inhalt dar, während CDA entries den strukturierten Inhalt darstellen, der für die weitere maschinelle Verarbeitung bereitgestellt wird. CDA entries kodieren für gewöhnlich den Inhalt, der im Textblock des gleichen Abschnitts vorhanden ist. Das Beispiel zeigt zwei <observation> CDA entries und einen <substanceadministraion> entry, der einen <supply> entry enthält, obgleich einige andere CDA entries definiert werden. CDA entries können auf externe Objekte referenzieren. CDA externe Referenzen treten immer innerhalb des Kontextes eines CDA entries auf. Sie beziehen sich auf einen Inhalt, der außerhalb dieses CDA Dokumentes - wie z.b. ein externes Bild, Verfahren oder eine andere Beobachtung - steht. [23] Die folgende Abbildung zeigt ein Basis CDA Dokument und dessen grundlegenden Elemente. Abbildung 13: Standard CDA Dokument. Das CDA Dokument besteht aus einem Header und einem Body. Der Body beinhaltet verschiedene Sections, in denen frei wählbarer Inhalt eingegeben werden kann. Für nähere Informationen siehe Text.

54 5.1 Ergebnisse zu Ziel HL7-CDA Hierarchical Description (HD) Eine HMD (Hierarchical Message Description) ist eine durch Seperatoren getrennte Repräsentation einer Sequenz von Elementen (z.b. Klassen, Attribute und Assoziationen), welche in einem R-MIM (siehe Kapitel ) dargestellt wird und ohne Referenz auf die verwendete Implementierungstechnologie (Java, XML, etc.) definiert wird. Die HMD definiert eine elementare Nachrichtenstruktur, die als common message type bezeichnet wird. Die zugrundeliegende Nachrichtenstruktur wird niemals versendet und hat daher keinen entsprechenden Auslöser (Trigger). Es bildet das Template(siehe Kapitel ) aus dem die entsprechenden und spezifischen Nachrichtentypen bezogen werden. Es steht eine Open-Source-Software 1 zur Verfügung, mit deren Hilfe man aus einer spezifischen und validierten HMD weitere HMDs erschaffen kann, oder ein fertiges XML-Schema erschaffen kann. Die CDA-HD ist die beschreibende Bezugsquelle für die CDA Konformitätsregeln aus denen ein CDA-Schema abgeleitet werden kann. Während eine CDA-Instanz gegen das CDA-Schema validiert werden muss, müssen zusätzlich die Konformitätsregeln eingehalten werden. [24] Die folgende Abbildung14 zeigt eine HMD als Excel Tabelle, in der verschiedene Klassen und deren Attribute erkennbar sind HL7-CDA Refined Message Information Model (R-MIM) Das CDA R-MIM [20] ist ein grafisches Hilfsmittel zum Bessern Verständnis der CDA Spezifikation. Da die CDA Hierarchical Description und daraus folgend auch das CDA- Schema aus dem R-MIM resultieren, dient das R-MIM als gute Ausgangsbasis zur Beschreibung des Standards. Das R-MIM ist eine Untermenge des D-MIM 1, das zum Ausdrücken des Inhalts einer Nachricht bzw. mehrerer Nachrichten sowie dessen Kommentaren verwendet wird. Der Inhalt eines R-MIM, der für eine spezifische Domäne verwendet wird, wird aus dem D-MIM abgeleitet. Das R-MIM beinhaltet Duplikate von ausgewählten Klassen und beschreibt diese mit Pseudonymen, spezifisch für die zu übermittelnde Nachricht(en). 1 RoseTreeModel 1 D-MIM... Domain Message Information Model. Methodologie zum Ableiten von Nachrichten

55 5.1 Ergebnisse zu Ziel 1 47 Abbildung 14: In dieser Abbildung ist ein Ausschnitt einer HMD dargestellt. Hierbei sind verschiedene Klassen und Attribute zu erkennen, welche in einem R-MIM dargestellt sind. Für nähere Informationen siehe Text. Übernommen von [18] Zusätzlich repräsentiert das R-MIM den Inhalt von einer oder mehereren abstrakten Nachrichtenstrukturen. Diese werden auch als Hierarchical Message Descriptions (HMDs) bezeichnet.

Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen

Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen Hans Demski GMDS2010 - Mannheim Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt Arbeitsgruppe

Mehr

Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen

Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen Hans Demski GMDS2010 - Mannheim Erhebung interoperabler medizinischer Daten basierend auf ISO/CEN 13606 Archetypen Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt Arbeitsgruppe

Mehr

Patientenübergreifende, multiple Verwendung von Gesundheitsdaten mit Hilfe von openehr-archetypen

Patientenübergreifende, multiple Verwendung von Gesundheitsdaten mit Hilfe von openehr-archetypen Institut für Medizinische Biometrie und Informatik: Medizinische Informatik Patientenübergreifende, multiple Verwendung von Gesundheitsdaten mit Hilfe von openehr-archetypen Christian Kohl Gliederung Einleitung

Mehr

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Identifier: http://www.kimforum.org/material/pdf/uebersetzung_singapore_20090213.pdf Title: Übersetzung des Singapore Framework für

Mehr

Standardisierte Schnittstelle zwischen rechnerunterstützten Dokumentations-, Scan-, Signatur- und Archivlösungen

Standardisierte Schnittstelle zwischen rechnerunterstützten Dokumentations-, Scan-, Signatur- und Archivlösungen Standardisierte Schnittstelle zwischen rechnerunterstützten Dokumentations-, Scan-, Signatur- und Archivlösungen Marco Blevins, CCESigG Inhalt: Ausgangssituation Ziele Vorgehen Signierung elektronischer

Mehr

Werkzeugbasierte Entwicklung von Benutzeroberflächen mit CDA-Templates und ART DECOR

Werkzeugbasierte Entwicklung von Benutzeroberflächen mit CDA-Templates und ART DECOR Werkzeugbasierte Entwicklung von Benutzeroberflächen mit CDA-Templates und ART DECOR Dipl.-Inform. Med. Markus Birkle Heidelberger Archivtage 2015, Heidelberg HL7 Clinical Document Architecture (CDA) für

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Anforderungen an eine Telematik-Rahmenarchitektur aus Sicht der Standardisierung

Anforderungen an eine Telematik-Rahmenarchitektur aus Sicht der Standardisierung ATG-Forum 2002 Telematik-Rahmenarchitektur Anforderungen an eine Telematik-Rahmenarchitektur aus Sicht der Standardisierung Erwin Bartels Institut für Luft- und Raumfahrtmedizin Deutsches Zentrum für Luft-

Mehr

Strukturierte Analyse von Entwicklungs-Frameworks für elektronische Akten im Gesundheitswesen

Strukturierte Analyse von Entwicklungs-Frameworks für elektronische Akten im Gesundheitswesen Strukturierte Analyse von Entwicklungs-Frameworks für elektronische Akten im Gesundheitswesen Christian Schäfer Martin Staemmler 06. September 2010 GMDS Jahrestagung 2010, Mannheim understanding reality

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

DER WEG ZU STRUKTURIERTEN GESUNDHEITSDATEN

DER WEG ZU STRUKTURIERTEN GESUNDHEITSDATEN DER WEG ZU STRUKTURIERTEN GESUNDHEITSDATEN DIE NÄCHSTE HERAUSFORDERUNG IN DER TELEMEDIZIN OPENEHR UND HL7 FHIR x-tention Informationstechnologie GmbH WACHSENDE MÖGLICHKEITEN FÜR TELEMEDIZIN DATA CAPTURE

Mehr

Eine Schnittstelle für Arztpraxisdaten mittels einer Ontologie auf Basis von HL7 Version 3

Eine Schnittstelle für Arztpraxisdaten mittels einer Ontologie auf Basis von HL7 Version 3 Eine Schnittstelle für Arztpraxisdaten mittels einer Ontologie auf Basis von HL7 Version 3 Jan Kunze, Thomas Riechert, Sören Auer Universität Leipzig Augustusplatz 10-11 04109 Leipzig jan-kunze@gmx.de,

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Ontologien und Ontologiesprachen

Ontologien und Ontologiesprachen Ontologien und Ontologiesprachen Semantische Datenintegration SoSe2005 Uni Bremen Yu Zhao Gliederung 1. Was ist Ontologie 2. Anwendungsgebiete 3. Ontologiesprachen 4. Entwicklung von Ontologien 5. Zusammenfassung

Mehr

SEMANTISCHE INTEROPERABILITÄT IM ELEKTRONISCHEN GESUNDHEITSDATENAUSTAUSCH MITTELS DUALER MODELLIERUNG - DER HL7 TEMPLATES ANSATZ

SEMANTISCHE INTEROPERABILITÄT IM ELEKTRONISCHEN GESUNDHEITSDATENAUSTAUSCH MITTELS DUALER MODELLIERUNG - DER HL7 TEMPLATES ANSATZ SEMANTISCHE INTEROPERABILITÄT IM ELEKTRONISCHEN GESUNDHEITSDATENAUSTAUSCH MITTELS DUALER MODELLIERUNG - DER HL7 TEMPLATES ANSATZ Karl Bointner 1, Georg Duftschmid 1 ABSTRACT HL7 Templates ermöglichen die

Mehr

Ressourcen-Beschreibung im Semantic Web

Ressourcen-Beschreibung im Semantic Web Ressourcen-Beschreibung im Semantic Web Cristina Vertan Inhaltsübersicht Wie sollen die Ressourcen für Semantic Web annotiert werden? Was ist und wie funktioniert RDF? Wie kodiert man RDF-Statements in

Mehr

Produktskizze. 28. November 2005 Projektgruppe Syspect

Produktskizze. 28. November 2005 Projektgruppe Syspect 28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der

Mehr

Werkzeugbasierte Entwicklung von Benutzeroberflächen mit CDA-Templates und ART DECOR

Werkzeugbasierte Entwicklung von Benutzeroberflächen mit CDA-Templates und ART DECOR Werkzeugbasierte Entwicklung von Benutzeroberflächen mit CDA-Templates und ART DECOR Dipl.-Inform. Med. Markus Birkle HL7/IHE Jahrestagung 2015, Kassel Praktische Herausforderungen bei der Implementierung

Mehr

Medical Data Models Ein offenes Repository Medizinscher Formulare

Medical Data Models Ein offenes Repository Medizinscher Formulare Ein offenes Repository Medizinscher Formulare auf Basis von CDISC ODM German CDISC User Group Leverkusen, 26. Februar 2013 Dr. Bernhard Breil 2 Inhalt Medizinische Dokumentation Probleme Forschungsfrage

Mehr

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 18. Dezember 2014 Rekapitulation Der Gang der Argumentation 1. Der Rohstoff:

Mehr

Medical Data Models Ein offenes Repository Medizinscher Formulare

Medical Data Models Ein offenes Repository Medizinscher Formulare Ein offenes Repository Medizinscher Formulare Metadatenmanagement in der patientenorientierten Forschung Berlin, 18. Dezember 2012 Dr. Bernhard Breil 2 Inhalt Medizinische Dokumentation Probleme Forschungsfrage

Mehr

Semantic Markup für die Dokumentenklassifizierung. Seminarvortrag von Mirko Pracht

Semantic Markup für die Dokumentenklassifizierung. Seminarvortrag von Mirko Pracht Semantic Markup für die Dokumentenklassifizierung Seminarvortrag von Mirko Pracht Ziel des Vortrags Aufbau digitaler Bibliotheken Verbesserung Informationssuche Semantic Markup Gliederung 1. Grundlagen

Mehr

Vorlesung Computerphilologie. Ontologien und Ontologie-Sprachen

Vorlesung Computerphilologie. Ontologien und Ontologie-Sprachen Wintersemester 2006 Institut für Germanistik I Vorlesung Computerphilologie Ontologien und Ontologie-Sprachen Wie kann man Inhalte (von Webseiten) erschließen? v.hahn Uni Hamburg 2005 1 Was bringen Ontologien

Mehr

Semantische Integration für translationale und personalisierte klinische Forschung: Unterschiedliche Lösungen und Vorgehensweisen

Semantische Integration für translationale und personalisierte klinische Forschung: Unterschiedliche Lösungen und Vorgehensweisen Semantische Integration für translationale und personalisierte klinische Forschung: Unterschiedliche Lösungen und Vorgehensweisen Wolfgang Kuchinke (HHU Düsseldorf) 15.5.2014 in Berlin BMBF Partnering

Mehr

... MathML XHTML RDF

... MathML XHTML RDF RDF in wissenschaftlichen Bibliotheken (LQI KUXQJLQ;0/ Die extensible Markup Language [XML] ist eine Metasprache für die Definition von Markup Sprachen. Sie unterscheidet sich durch ihre Fähigkeit, Markup

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Requirements Engineering I

Requirements Engineering I Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

RDF und RDF Schema. Einführung in die Problematik Von HTML über XML zu RDF

RDF und RDF Schema. Einführung in die Problematik Von HTML über XML zu RDF RDF und RDF Schema Einführung in die Problematik Von HTML über XML zu RDF Kirsten Albrecht Roland Illig Probleme des HTML-basierten

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Elektronische Gesundheitsakten im Zeichen der elektronischen Gesundheitskarte. Dr. Frank Warda, Köln

Elektronische Gesundheitsakten im Zeichen der elektronischen Gesundheitskarte. Dr. Frank Warda, Köln Elektronische Gesundheitsakten im Zeichen der elektronischen Gesundheitskarte Dr. Frank Warda, Köln Deutsches Institut für Medizinische Dokumentation und Information Definition 1 Eine elektronische Gesundheitskarte

Mehr

3. Ontologien und Wissensbasen

3. Ontologien und Wissensbasen Ontologien Ontologien stellen mittlerweile die Basis für viele innovative wissensbasierte Systeme dar: 3. Ontologien und Wissensbasen ecommerce/elearning Knowledge Management Informationsextraktion/Data-mining

Mehr

Standardisierungsansätze in Leitlinienmanagement und Entscheidungsunterstützung

Standardisierungsansätze in Leitlinienmanagement und Entscheidungsunterstützung Standardisierungsansätze in Leitlinienmanagement und Entscheidungsunterstützung Dr. Martin Sedlmayr Lehrstuhl für Medizinische Informatik Universität Erlangen Agenda Motivation Leitlinienmanagement Einzelbetrachtung

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

Mehr

HL7/Sciphox Spezifikationen in Kooperation mit VHitG und KBV für die deutsche ehealth - Plattform

HL7/Sciphox Spezifikationen in Kooperation mit VHitG und KBV für die deutsche ehealth - Plattform Praxis der Informationsverarbeitung in Krankenhaus und Versorgungsnetzen (KIS 2007) 21.-22. Juni 2007 im Heinrich-Pesch-Haus in Ludwigshafen HL7/Sciphox Spezifikationen in Kooperation mit VHitG und KBV

Mehr

Semantic Web Services

Semantic Web Services Semantic Web Services Daniel Fischer TU Chemnitz - WS 2011/12 1 Gliederung (1) Web Services (2) Semantic Web Services: Motivation (3) Ontologien (4) Technologien 1. WSDL 2. SA-WSDL 3. WSMF / WSMO 4. OWL-S

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

Rollen in GFO und HL7-RIM

Rollen in GFO und HL7-RIM n in GFO und HL7-RIM Frank Loebe Forschungsgruppe Ontologien in der Medizin (Onto-Med) Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE), Universität Leipzig frank.loebe@imise.uni-leipzig.de

Mehr

Beschreibungslogiken. Daniel Schradick 1schradi@informatik.uni-hamburg.de

Beschreibungslogiken. Daniel Schradick 1schradi@informatik.uni-hamburg.de Beschreibungslogiken Daniel Schradick 1schradi@informatik.uni-hamburg.de Was sind Beschreibungslogiken? Definition: Formalisms that represent knowledge of some problem domain (the world ) by first defining

Mehr

Entwicklung eines Electronic Resource Management Systems für Bibliotheken auf Basis von Linked Data Technologien

Entwicklung eines Electronic Resource Management Systems für Bibliotheken auf Basis von Linked Data Technologien Entwicklung eines Electronic Resource Management Systems für Bibliotheken auf Basis von Linked Data Technologien Lydia Unterdörfel, Björn Muschall Wissenschaftskommunikation im Semantischen Web (EFRE)

Mehr

Interoperabilität elektronischer Aktensysteme

Interoperabilität elektronischer Aktensysteme Interoperabilität elektronischer Aktensysteme Nürnberger Archivtage 2014 Dr. Ralf Brandner Anwendungsfälle Datenaustausch auf Basis von Aktensystemen Archivierung Konsil Befundung Fallbesprechung Überweisung

Mehr

Anwendung im Projekt epsos Diskussion Zusammenfassung und Ausblick

Anwendung im Projekt epsos Diskussion Zusammenfassung und Ausblick Definition von Value Sets für standardisierte semantische Systeme am Beispiel von IHE und HL7 S Thun, F Oemig, K Heitmann, C Gessner Dr. Sylvia Thun, DIMDI User Chair IHE Deutschland Vorstand HL7 Benutzergruppe

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

STANDARDISIERUNGSVORGABEN IM RAHMEN DER

STANDARDISIERUNGSVORGABEN IM RAHMEN DER STANDARDISIERUNGSVORGABEN IM RAHMEN DER ELEKTRONISCHEN GESUNDHEITSAKTE ELGA EIN ERFAHRUNGSBERICHT AUS ANWENDERSICHT HL7 JAHRESTAGUNG KASSEL DANIEL GALLER 26.10.2015 x-tention Informationstechnologie GmbH

Mehr

OWL Web Ontology Language

OWL Web Ontology Language OWL Web Ontology Language Hauptseminar Ontologien in Informatik und Linguistik SS 2007 Bianca Selzam 27.4.2007 Gliederung 1. Einleitung 2. Resource Description Framework (RDF) 3. Resource Description Framework

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

Mehr

Claudia Rappold Seminar Biomedizinische Informatik Hall, 02.12.2010

Claudia Rappold Seminar Biomedizinische Informatik Hall, 02.12.2010 Claudia Rappold Seminar Biomedizinische Informatik Hall, 02.12.2010 Motivation Definition Nutzen Voraussetzungen Status Quo in Österreich Länderüberblick Fazit Der Hausarzt ist auf Urlaub. Also geht die

Mehr

Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java

Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java von Christian Brand Kennnummer: 09376 November 2005 Abkürzungen Abkürzungen API - Application Programming Interface

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Datenmodelle im Kontext von Europeana. Stefanie Rühle (SUB Göttingen)

Datenmodelle im Kontext von Europeana. Stefanie Rühle (SUB Göttingen) Datenmodelle im Kontext von Europeana Stefanie Rühle (SUB Göttingen) Übersicht Datenmodelle RDF DCAM ORE SKOS FRBR CIDOC CRM Datenmodelle "Datenmodellierung bezeichnet Verfahren in der Informatik zur formalen

Mehr

Persönliche, einrichtungsübergreifende, elektronische Patientenakten (PEPA) Vision, Architektur und Herausforderungen an die digitale Archivierung

Persönliche, einrichtungsübergreifende, elektronische Patientenakten (PEPA) Vision, Architektur und Herausforderungen an die digitale Archivierung Persönliche, einrichtungsübergreifende, elektronische Patientenakten (PEPA) Vision, Architektur und Herausforderungen an die digitale Archivierung Archivtage Heidelberg, Dezember 2015 Dr. Oliver Heinze

Mehr

Standardisierung in der Sozialwirtschaft Wege zu einem besseren Miteinander von IT-Lösungen

Standardisierung in der Sozialwirtschaft Wege zu einem besseren Miteinander von IT-Lösungen Fachverband Informationstechnologie in Sozialwirtschaft und Sozialverwaltung FINSOZ e.v. Standardisierung in der Sozialwirtschaft Wege zu einem besseren Miteinander von IT-Lösungen Jörg Waste, Dr. Dietmar

Mehr

VALIDIEREN VON AUF ZWEIMODELL-ANSÄTZEN BASIERENDEN, VOLLSTRUKTURIERTEN EHR-DATEN AM BEISPIEL EN/ISO13606 UND HL7 CDA Rinner C 1, Duftschmid G 1

VALIDIEREN VON AUF ZWEIMODELL-ANSÄTZEN BASIERENDEN, VOLLSTRUKTURIERTEN EHR-DATEN AM BEISPIEL EN/ISO13606 UND HL7 CDA Rinner C 1, Duftschmid G 1 VALIDIEREN VON AUF ZWEIMODELL-ANSÄTZEN BASIERENDEN, VOLLSTRUKTURIERTEN EHR-DATEN AM BEISPIEL EN/ISO13606 UND HL7 CDA Rinner C 1, Duftschmid G 1 Kurzfassung In dieser Arbeit wird ein Ansatz zur Validierung

Mehr

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit EMF ist ein eigenständiges Eclipse-Projekt (Eclipse Modeling Framework Project) EMF ist ein Modellierungsframework und Tool

Mehr

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf Softwareentwicklungspraktikum Sommersemester 2007 Feinentwurf Auftraggeber Technische Universität Braunschweig

Mehr

Ministerium für Kultus, Jugend und Sport Baden-Württemberg

Ministerium für Kultus, Jugend und Sport Baden-Württemberg Anlage zu 45-6512-2420/31 Ministerium für Kultus, Jugend und Sport Baden-Württemberg Schulversuch 51-6624.20/100 (früher: /84) vom 26. August 2003 Lehrpläne für das berufliche Gymnasium der sechs- und

Mehr

Dokumenten-Modelle im CMS CoreMedia

Dokumenten-Modelle im CMS CoreMedia Dokumenten-Modelle im CMS CoreMedia Einleitung Das Content Management System CoreMedia ist ein innovatives Produkt der Hamburger Firma CoreMedia, das hauptsächlich im Unternehmensbereich und für komplexe

Mehr

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Server 3.5 Produktbeschreibung Uptime Services AG Inhaltsverzeichnis 1 Einleitung... 2 2

Mehr

Dokumentation Projekt Virtuelles Tagebuch

Dokumentation Projekt Virtuelles Tagebuch Priv.Doz. Dr. Michael Hahsler Institut für Informationswirtschaft Dokumentation Projekt (Matr. Nr. 9806106) - 1 - 1 Problembeschreibung Das Ziel dieses Projektes ist es, ein Tagebuch in elektronischer

Mehr

Medizinische Informationssysteme. MeCuM Modul V L 9 Klaus Adelhard

Medizinische Informationssysteme. MeCuM Modul V L 9 Klaus Adelhard Medizinische Informationssysteme im Krankenhaus MeCuM Modul V L 9 Klaus Adelhard Ziele Schneller und gezielter Zugriff auf Akten und einzelne Inhalte Gleichzeitige Nutzung durch mehrere Stellen. Vermeidung

Mehr

Vorlesung "Software-Engineering"

Vorlesung Software-Engineering Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

Mehr

Kapitel WT:VIII (Fortsetzung)

Kapitel WT:VIII (Fortsetzung) Kapitel WT:VIII (Fortsetzung) VIII. Semantic Web WWW heute Semantic Web Vision RDF: Einführung RDF: Konzepte RDF: XML-Serialisierung RDF: Anwendungen RDFS: Einführung RDFS: Konzepte Semantik im Web Semantik

Mehr

Entwicklung eines elektronischen Einwilligungsmanagementsystems für intersektorale Informationssysteme

Entwicklung eines elektronischen Einwilligungsmanagementsystems für intersektorale Informationssysteme Entwicklung eines elektronischen Einwilligungsmanagementsystems für intersektorale Informationssysteme Berlin, November 2010 Markus BIRKLE, Oliver HEINZE, Björn BERGH Zentrum für Informations- und Medizintechnik

Mehr

Interoperabilitätstandards damals und heute

Interoperabilitätstandards damals und heute Jahrestagung HL7 Österreich Interoperabilitätstandards damals und heute Prof. Dr. habil., FACMI, FACHI, FHL7, Interoperabilitäts-Herausforderung Interoperabilität beschreibt Motivation, Bereitschaft, Fähigkeit

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Stand der Entwicklung und Nutzererwartungen

Stand der Entwicklung und Nutzererwartungen Persönliche einrichtungsübergreifende elektronische Patientenakte (PEPA): Stand der Entwicklung und Nutzererwartungen Ines Vogel 1, Björn Bergh 2, Oliver Heinze 2, Stefan Noest 1, Joachim Szecsenyi 1,

Mehr

Die Nutzung des HL7 Standard Set zur Sicherung semantischer Interoperabilität. Bernd Blobel Kjeld Engel Peter Pharow

Die Nutzung des HL7 Standard Set zur Sicherung semantischer Interoperabilität. Bernd Blobel Kjeld Engel Peter Pharow Die Nutzung des HL7 Standard Set zur Sicherung semantischer Interoperabilität Bernd Blobel Kjeld Engel Peter Pharow Fraunhofer-Institut für Integrierte Schaltungen IIS Erlangen Projektgruppe Gesundheitstelematik

Mehr

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling 30. Juni 2006 - Technische Universität Kaiserslautern Paul R. Schilling ! " #$% & '( ( ) *+, - '. / 0 1 2("$ DATEN SIND ALLGEGENWÄRTIG Bill Inmon, father of data warehousing Unternehmen In einer vollkommenen

Mehr

Was sind Ontologie-Editoren?

Was sind Ontologie-Editoren? Was sind Ontologie-Editoren? Kurzeinführung Protégé Sonja von Mach und Jessica Otte Gliederung Ontologie Editoren- allgemein warum nutzen wofür nutzen Probleme Marktlage Einführung in die praktische Arbeit

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8 Prof. Dr. Wilhelm Schäfer Paderborn, 8. Dezember 2014 Christian Brenner Tristan Wittgen Besprechung der Aufgaben: 15. - 18. Dezember 2014 Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Semantic Web Technologies I! Lehrveranstaltung im WS10/11! Dr. Andreas Harth! Dr. Sebastian Rudolph!

Semantic Web Technologies I! Lehrveranstaltung im WS10/11! Dr. Andreas Harth! Dr. Sebastian Rudolph! Semantic Web Technologies I! Lehrveranstaltung im WS10/11! Dr. Andreas Harth! Dr. Sebastian Rudolph! www.semantic-web-grundlagen.de Ontology Engineering! Dr. Sebastian Rudolph! Semantic Web Architecture

Mehr

Führung und Moderation von Patientenakten

Führung und Moderation von Patientenakten Prof. Dr. Peter Haas FH Dortmund / (www.prof-haas.de) (2006) Prof. Dr. Peter Haas Seite 1 Regelungen im SGB V 68 Finanzierung einer persönlichen elektronischen Gesundheitsakte Zur Verbesserung der Qualität

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

Mehr

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses

Mehr

Automatisierte Generierung von Schematron-Regeln aus Archetypen zur Validierung standardisierter medizinischer Dokumente

Automatisierte Generierung von Schematron-Regeln aus Archetypen zur Validierung standardisierter medizinischer Dokumente Automatisierte Generierung von Schematron-Regeln aus Archetypen zur Validierung standardisierter medizinischer Dokumente Klaus Pfeiffer, Georg Duftschmid, Christoph Rinner Institut für medizinisches Informationsmanagement

Mehr

Semantic Web Technologies I

Semantic Web Technologies I Semantic Web Technologies I Lehrveranstaltung im WS11/12 Dr. Elena Simperl PD Dr. Sebastian Rudolph M. Sc. Anees ul Mehdi Ontology Engineering Dr. Elena Simperl XML und URIs Einführung in RDF RDF Schema

Mehr

Technische Dokumentation

Technische Dokumentation Technische Dokumentation der Ontologie Wärmedämmung des Projekts EcoNavi Erstellt für: Bremer Umweltberatung Hamburg, Juli 2005-1 - Inhaltsverzeichnis Einleitung... 2 Aufbau einer Ontologie... 3 Ontologieeditor

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung. Dr. Bernhard Wentz

Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung. Dr. Bernhard Wentz Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung Einleitung und Motivation Medizinische IT-Anwendungssysteme komplexe hoch funktionale Systeme Basisfunktionen

Mehr

Jens Kupferschmidt Universitätsrechenzentrum

Jens Kupferschmidt Universitätsrechenzentrum Einordnung der Metadaten im MyCoRe Projekt Connection to other databases Data presentations MyCoResearch over instances Classifications Metadate and search Derivate User and access rights GUI Workflow

Mehr

Einführung in die Theoretische Informatik

Einführung in die Theoretische Informatik Einführung in die Theoretische Informatik Woche 10 Harald Zankl Institut für Informatik @ UIBK Wintersemester 2014/2015 Zusammenfassung Zusammenfassung der letzten LV Satz Sei G = (V, Σ, R, S) eine kontextfreie

Mehr

Elektronische Patientenakten und Gesundheitstelematik

Elektronische Patientenakten und Gesundheitstelematik Elektronische Patientenakten und Gesundheitstelematik - kursorische Betrachtungen - Prof. Dr. Peter Haas FH Dortmund / Prof. Dr. Peter Haas Seite 1 Begriffsverwirrung allerorten Elektronische Krankenakte

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

Bericht BTI7311: Informatik Seminar Was sind Ontologien?

Bericht BTI7311: Informatik Seminar Was sind Ontologien? Bericht BTI7311: Informatik Seminar Was sind Ontologien? Inhaltsverzeichnis 1 Ontologien...3 1.1 Ontologien in der Philosophie...3 1.2 Ontologien in der Psychologie...3 1.3 Ontologien in der Informatik...3

Mehr

Innovator 11 classix. Erweiterter XMI-Export aus Innovator Business und Object classix. HowTo. www.mid.de

Innovator 11 classix. Erweiterter XMI-Export aus Innovator Business und Object classix. HowTo. www.mid.de Innovator 11 classix Erweiterter XMI-Export aus Innovator Business und Object classix HowTo www.mid.de Erweiterter XMI-Export aus Innovator Business und Object classix Inhaltsverzeichnis Zweck... 2 Modellinhalte

Mehr

Inhalt. Motivation Techniken des MDE. Fallbeispiele

Inhalt. Motivation Techniken des MDE. Fallbeispiele ISE-Seminar 2012 Inhalt Motivation Techniken des MDE Computer Aided Software Engineering (CASE) Domain-Specific-Languages (DSL) Model Driven Architecture (MDA) Fallbeispiele Motivation Automatische Codegenerierung

Mehr

Jump Project. Softwarelösungen für professionelles Projektmanagement

Jump Project. Softwarelösungen für professionelles Projektmanagement Jump Project Softwarelösungen für professionelles Projektmanagement Jump Project Office Übersichtliche Dokumentenstruktur und schneller Zugriff auf alle wichtigen Funktionen. Steuern Sie Ihre Projekte

Mehr