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.

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

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

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

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

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

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

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

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

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

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

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

Elektronische Patientenakten

Elektronische Patientenakten Zentrum für Telematik im Gesundheitswesen GmbH Elektronische Patientenakten Stefan Kühn, Dipl.-Wirt.-Inf. (FH), Projektleiter Ein Projekt des Ministeriums für Arbeit, Gesundheit und Soziales des Landes

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

Eine Ontologie für Kommunikationsstandards (CSO) zur Etablierung semantischer Interoperabilität

Eine Ontologie für Kommunikationsstandards (CSO) zur Etablierung semantischer Interoperabilität Eine Ontologie für Kommunikationsstandards (CSO) zur Etablierung semantischer Interoperabilität Frank Oemig, Bernd Blobel GMDS 2010, Mannheim 5.-9. September 2010 Einleitung Wissen über Kommunikationsstandards

Mehr

Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen

Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen C Ohr, M Krasser, Dr. R Brandner Mannheim, 06.09.2010 Agenda Kommunikationsstandards im Gesundheitswesen Notwendigkeit

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

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

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

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

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

Seminarvortrag Ontologien im Software Engineering. Markus Luczak

Seminarvortrag Ontologien im Software Engineering. Markus Luczak Seminarvortrag Ontologien im Software Engineering Markus Luczak Übersicht Einleitung Anwendungsgebiete von Ontologien im SE Ontologien im SE State-of-the-Art Zusammenfassung Fazit und Fragestellungen Seminar

Mehr

DICOM Adapter IDeal HL7 PVS. Leistungsbeschreibung. Version 1.0

DICOM Adapter IDeal HL7 PVS. Leistungsbeschreibung. Version 1.0 DICOM Adapter IDeal KIS HL7 Cloverleaf DICOM Modalität Worklist Leistungsbeschreibung Version 1.0 PVS Dachauer Str. 11, D-80335 München Tel.: +49-(0)89-599 88 76-0 Fax: +49-(0)89-599 88 76-11 Info@Health-Comm.de

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

CEN pren 13606 konformer Export von medizinischen Daten aus einem Entity-Attribute-Value basierten Informationssystem

CEN pren 13606 konformer Export von medizinischen Daten aus einem Entity-Attribute-Value basierten Informationssystem CEN pren 13606 konformer Export von medizinischen Daten aus einem Entity-Attribute-Value basierten Informationssystem C. Rinner, G. Duftschmid, T. Wrba Institut für Medizinische Informations- und Auswertesysteme

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

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

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

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN Mathias Slawik, WI (M), 3. FS Aktuelle Themen der Wirtschaftsinformatik, HTW Berlin, WS 10/11 Gliederung 2 Methode

Mehr

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim Software- Der Strategien und ist der zum Definieren der Architektur, der Komponenten, der Schnittstellen und anderer Charakteristika (Datenstrukturen, Algorithmen etc.) eines Systems oder einer Komponente

Mehr

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

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

Björn Schreiweis, Oliver Heinze, Björn Bergh, Universitätsklinikum Heidelberg IHE Deutschland e.v. www.ihe-d.de

Björn Schreiweis, Oliver Heinze, Björn Bergh, Universitätsklinikum Heidelberg IHE Deutschland e.v. www.ihe-d.de IHE-basierte Aktensysteme - Architekturansätze Björn Schreiweis, Oliver Heinze, Björn Bergh, Universitätsklinikum Heidelberg Agenda 1. Hintergrund / Motivation 2. Rechtliche Grundlagen 3. IHE Was ist das?

Mehr

Jubiläumsabo März / April 2012 Jubiläumsausgabe #1-12 Deutschland Euro 12,00 ISSN: 1864-8398 www.dokmagazin.de

Jubiläumsabo März / April 2012 Jubiläumsausgabe #1-12 Deutschland Euro 12,00 ISSN: 1864-8398 www.dokmagazin.de Nur jetzt! Jubiläumsabo März / April 2012 Jubiläumsausgabe #1-12 Deutschland Euro 12,00 ISSN: 1864-8398 www.dokmagazin.de Enterprise Search Strategien für Erfolg Dokumentenmanagement mit SharePoint: Neue

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

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

Informationen für die Presse conhit 2014

Informationen für die Presse conhit 2014 Informationen für die Presse conhit 2014 Beliebige Daten ganz einfach integrieren ETIAM fast bestehende Lösungen in neuer Integrationsplattform zusammen ETIAM und Vidyo erweitern Kommunikation medizinischer

Mehr

Nationale und internationale Ansätze zur Erstellung von qualitativ hochwertigen Archetypen

Nationale und internationale Ansätze zur Erstellung von qualitativ hochwertigen Archetypen Nationale und internationale Ansätze zur Erstellung von qualitativ hochwertigen Archetypen Dr. Sebastian Garde Workshop Semantische Interoperabilität medizinischer Daten durch den Einsatz Archetyp-basierter

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

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

Health Level Seven (HL7)

Health Level Seven (HL7) FuE-Bereich IuK-Systeme im Gesundheitswesen IG Health Level Seven (HL7) Sascha Koch IG HL7 = Health Level Seven Health: Kommunikationsstandard speziell für das Gesundheitswesen Primäres Einsatzgebiet:

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

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

1 Status des Dokuments... 3. 3 Datenmodell... 3 3.1 Person... 3. 5 Zuständigkeit und Mutationswesen... 8. 6 Sicherheitsüberlegungen...

1 Status des Dokuments... 3. 3 Datenmodell... 3 3.1 Person... 3. 5 Zuständigkeit und Mutationswesen... 8. 6 Sicherheitsüberlegungen... E-Government-Standards Seite 1 von 10 ech-0046 Datenstandard Kontakt Name Standard-Nummer Kategorie Reifegrad Datenstandard Kontakt ech-0046 Standard Definiert Version 2.0 Status Genehmigt Genehmigt am

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

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen 3. Spezielle ER-Modelle und Tabellenableitung Spezialfälle von ER-Modellen Grundlage, was sind Relationen Transformation von ER-Diagrammen in Relationen 56 Lesebeispiel Access (Realisierungmodell!) 57

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN)

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN) Geschäftsprozessmanagement: in»business Process Modelling Notation«(BPMN) Eugen Labun Fachhochschule Gießen-Friedberg Fachbereich MNI Institut für Softwarearchitektur Serviceorientierte Architekturen bei

Mehr

Schreier G, Hayn D, Ammenwerth E, editors.tagungsband der ehealth2010. 6.-7.Mai 2010; Wien. OCG; 2010.

Schreier G, Hayn D, Ammenwerth E, editors.tagungsband der ehealth2010. 6.-7.Mai 2010; Wien. OCG; 2010. GENERISCHER EXPORT VON ARCHETYP- KONFORMEN OPENEHR EHR-EXTRAKTEN AUS EINEM GESUNDHEITSINFORMATIONSSYSTEM Dietrich R 1, Holzer K 1, Chaloupka J 1, Rinner C 1, Duftschmid G 1 Kurzfassung Im Gesundheitsinformationssystem

Mehr

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

Mehr

DSHL7: Eine Domain Specific Language für HL7v3 in Scala

DSHL7: Eine Domain Specific Language für HL7v3 in Scala DISL Seven DSHL7: Eine Domain Specific Language für HL7v3 in Scala Markus Gumbel, Ahmet Gül Institut für Medizinische Informatik Überblick Motivation: Warum eine DSL für HL7v3? Ansätze für eine DSL Beispiel:

Mehr

Automatisierungsarchitekturen für das Smart Grid Am Beispiel der OPC UA und der IEC 61970. Dr.-Ing. Mathias Uslar, Sebastian Rohjans

Automatisierungsarchitekturen für das Smart Grid Am Beispiel der OPC UA und der IEC 61970. Dr.-Ing. Mathias Uslar, Sebastian Rohjans Automatisierungsarchitekturen für das Smart Grid Am Beispiel der OPC UA und der IEC 61970 Dr.-Ing. Mathias Uslar, Sebastian Rohjans 2 OPC Foundation Vision: OPC-Technologien sollen überall dort zur Interoperabilitäts-Basis

Mehr

XML-basierte Standards für den Datenaustausch in der Logistikkette

XML-basierte Standards für den Datenaustausch in der Logistikkette XML und Electronic Data Interchange (EDI) EDIFACT-XML ein kleines Beispiel - Strukturierung von Daten Datensatz 347,M50,L Datensatz mit Pseudocode-ML strukturiert 347

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Klausur Software Engineering für WI (EuI)

Klausur Software Engineering für WI (EuI) Autor: Prof. Dr. Bernhard Humm, FB Informatik, FH Darmstadt Datum: 14. Februar 2006 Klausur Software Engineering für WI (EuI) Ihr Name: Ihre Matrikelnummer Erreichte Punkte (von insgesamt 57 Punkten):

Mehr

XML Grundlagen Sommersemester 2013

XML Grundlagen Sommersemester 2013 XML Grundlagen Sommersemester 2013 Die Lehrveranstaltung wird studienbegleitend durch eine Hausarbeit und eine Präsentation mit Diskussion geprüft. Die Themen der folgenden Liste werden im Rahmen der Lehrveranstaltung

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

XML in der betrieblichen Praxis

XML in der betrieblichen Praxis Klaus Turowski, Klement J. Fellner (Hrsg.) XML in der betrieblichen Praxis Standards, Möglichkeiten, Praxisbeispiele Ги dpunkt.verlag Inhaltsverzeichnis 1 XML/EDI-Standardisierung: Ein Überblick 1 1.1

Mehr

Das Common Information Model (CIM) Dr.-Ing. Mathias Uslar

Das Common Information Model (CIM) Dr.-Ing. Mathias Uslar Das Common Information Model (CIM) Dr.-Ing. Mathias Uslar Vision: Smart Grid 2 Wirtschaftlicher Impact: OFFIS und das IT Quartier 101 National Institute for Standards and Technology (USA): The term Smart

Mehr

Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Modellgetriebene Softwareentwicklung bei der IBYKUS AG Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 4: Domänenspezifische Sprachen Dr. Steffen Skatulla IBYKUS AG 1 Inhalt Teil 4: Domänenspezifische Sprachen Nutzung vorhandener Sprachen

Mehr

XMI & Java. von Stefan Ocke so3@inf.tu-dresden.de 5.Juli 2001

XMI & Java. von Stefan Ocke so3@inf.tu-dresden.de 5.Juli 2001 XMI & Java von Stefan Ocke so3@inf.tu-dresden.de 5.Juli 2001 1. XMI XML Metadata Interchange - Ziele und Historie - Metamodellarchitektur der OMG und MOF - XMI Dokumente und XMI DTD Ziele und Historie

Mehr

Die Orientierungshilfe Schritte auf dem Weg zu einem praktikablen Datenschutz

Die Orientierungshilfe Schritte auf dem Weg zu einem praktikablen Datenschutz Die Orientierungshilfe Schritte auf dem Weg zu einem praktikablen Datenschutz Bundesverband Gesundheits-IT e. V. Jan Neuhaus, Tieto Deutschland GmbH für AG Datenschutz IT-Trends, Düsseldorf, 21.9.2011

Mehr

TUDOOR - Ein Java Adapter für Telelogic DOORS

TUDOOR - Ein Java Adapter für Telelogic DOORS TUDOOR - Ein Java Adapter für Telelogic DOORS Jae-Won Choi, Anna Trögel, Ingo Stürmer Model Engineering Solutions GmbH Abstract: Im Bereich des Requirements Engineering hat sich DOORS der Firma Telelogic

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

Entwicklung eines korrekten Übersetzers

Entwicklung eines korrekten Übersetzers Entwicklung eines korrekten Übersetzers für eine funktionale Programmiersprache im Theorembeweiser Coq Thomas Strathmann 14.01.2011 Gliederung 1 Einleitung

Mehr

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

Institut für Unternehmensinformatik Konzeption eines Service Repository zur Beschreibung von Services in der Cloud

Institut für Unternehmensinformatik Konzeption eines Service Repository zur Beschreibung von Services in der Cloud Institut für Unternehmensinformatik Konzeption eines Service Repository zur Beschreibung von Services in der Cloud Commit Clusterworkshop Datenmanagement Thomas Specht Mannheim, 22.10.2012 Hochschule Mannheim

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

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Predictive Modeling Markup Language. Thomas Morandell

Predictive Modeling Markup Language. Thomas Morandell Predictive Modeling Markup Language Thomas Morandell Index Einführung PMML als Standard für den Austausch von Data Mining Ergebnissen/Prozessen Allgemeine Struktur eines PMML Dokuments Beispiel von PMML

Mehr

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10. AustroFeedr Pushing the Realtime Web Projektplan erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.2010 gefördert durch die Internet Privatstiftung Austria (IPA) 1 Projektbeschreibung

Mehr

Ein generativer Ansatz zur semantischen Beschreibung von Geschäftsdokumenten

Ein generativer Ansatz zur semantischen Beschreibung von Geschäftsdokumenten Ein generativer Ansatz zur semantischen Beschreibung von Geschäftsdokumenten Matthias Ferdinand 6ferdina@informatik.uni-hamburg.de Universität Hamburg, Fachbereich Informatik Verteilte Systeme und Informationssysteme

Mehr

7. Analyse-Phase: Datenmodellierung Software Engineering

7. Analyse-Phase: Datenmodellierung Software Engineering 7. Analyse-Phase: Datenmodellierung Software Engineering Hochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm Hochschule Darmstadt, 20. November 2006 Einordnung in den Kontext

Mehr

Elektronische Fallakte v2.0. EFAv2.0 für regionale Versorgungsnetze

Elektronische Fallakte v2.0. EFAv2.0 für regionale Versorgungsnetze Elektronische Fallakte v2.0 EFAv2.0 für regionale Versorgungsnetze Was ist EFA? Die elektronische Fallakte ist eine Lösung für den Austausch medizinischer Daten in regionalen Versorgungsnetzen Weitergabe

Mehr

Mehr Informationen zum Titel

Mehr Informationen zum Titel Mehr Informationen zum Titel 14 Kapitel 2 im Überblick 2.1 Die -Spezifikation Die -Spezifikation besteht aus insgesamt sieben Teilen (Parts). Part 1: Overview [IEC13a]: Dieser Teil der Spezifikation gibt

Mehr

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Dieses Dokument wurde verfasst von Dr. Jürgen Pitschke, BCS-Dr. Jürgen Pitschke, www.enterprise-design.eu Diese Unterlagen können frei für nicht-kommerzielle

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Situativer Widerspruch für ELGA in HL7 V2.x: Spezifizierung des CON-Segments

Situativer Widerspruch für ELGA in HL7 V2.x: Spezifizierung des CON-Segments 1 2 Situativer Widerspruch für ELGA in HL7 V2.x: Spezifizierung des CON-Segments 3 4 5 6 Version: Standard des Technischen Komitees der HL7 Austria - Version 1.0 Datum: 13.04.2015 Dokument OID: 2.16.840.1.113883.2.16.1.2.1.20150413.3

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

LDAP. Lightweight Directory. Desanka Bogicevic 1121621 Michael Wenig 1220567 Rupert Eisl 1220225

LDAP. Lightweight Directory. Desanka Bogicevic 1121621 Michael Wenig 1220567 Rupert Eisl 1220225 LDAP Lightweight Directory Access Protokoll Desanka Bogicevic 1121621 Michael Wenig 1220567 Rupert Eisl 1220225 LDAP Was ist LDAP? Was sind Verzeichnisdienste? Was ist ein Verzeichnis? Geschichte http://directory.apache.org/apacheds/basic-ug/1.2-some-background.html

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Design by Contract zur semantischen Beschreibung von Web Services

Design by Contract zur semantischen Beschreibung von Web Services Design by Contract zur semantischen Beschreibung von Web Services Gregor Engels 1, Marc Lohmann 1, Stefan Sauer 2 1 Institut für Informatik, 2 Software Quality Lab (s-lab) Universität Paderborn, 33095

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Analyse und Entwurf objektorientierter Systeme

Analyse und Entwurf objektorientierter Systeme Analyse und Entwurf objektorientierter Systeme Teil 3 Modellbildung in der Analysephase 3.1 Statische und dynamische Notationselemente Modul WI111: Objektorientierte Programmierung Fachrichtung Wirtschaftsinformatik

Mehr

SemTalk Services Stand: Februar 2015

SemTalk Services Stand: Februar 2015 SemTalk Services Stand: Was sind SemTalk Services? Navigation, Suche, Kommentierung, Reporting und andere Funktionalitäten über eine große Menge von Prozessen, Objekten und Dokumenten in veröffentlichten

Mehr

Abschlussarbeiten 2010 in der Medizininformatik

Abschlussarbeiten 2010 in der Medizininformatik Abschlussarbeiten 2010 in der Medizininformatik Ansprechpartner: Prof. Dr. Eberhard Beck eberhard.beck@fh-brandenburg.de FACHHOCHSCHULE BRANDENBURG FACHBEREICH INFORMATIK UND MEDIEN Konzeption und prototypische

Mehr

Computer & Medizin. Wo unterstützt der Computer Patienten und Ärzte? Und wo nicht? Daten, Information und Wissen (hier Diagnose & Therapie)

Computer & Medizin. Wo unterstützt der Computer Patienten und Ärzte? Und wo nicht? Daten, Information und Wissen (hier Diagnose & Therapie) Andere Herangehensweise um sich der MI zu nähern: Wo unterstützt der Computer Patienten und Ärzte? Und wo nicht? Wichtige Begriffe dazu sind, und Wissen (hier Diagnose & Therapie) Client Arzt Patient Patient

Mehr