D I P L O M A R B E I T

Größe: px
Ab Seite anzeigen:

Download "D I P L O M A R B E I T"

Transkript

1 D I P L O M A R B E I T Semantische Interoperabilität im elektronischen Gesundheitsdatenaustausch mittels Dualer Modellierung: Der HL7 Template Ansatz Ausgeführt am Institut für Medizinische Informations- und Auswertesysteme der Medizinischen Universität Wien für die Technische Universität Wien Unter der Anleitung von Ao. Univ.-Prof. Dipl.-Ing. Dr. Georg Duftschmid durch Karl Bointner, Bakk.techn. Saarplatz 20/5/ Wien

2 Kurzfassung Durch die zunehmende Spezialisierung der modernen Medizin gewinnt die fachübergreifende Kooperation von Gesundheitsdienstleistern in der Behandlung gemeinsamer Patienten zunehmend an Bedeutung. Eine wesentliche Voraussetzung für die Effizienz einer derartigen integrierten Versorgung ist der elektronische Austausch von Gesundheitsdaten zwischen den beteiligten Akteuren. Um die übermittelten Daten empfängerseitig maschinell weiterverarbeiten zu können, muss der Datenaustausch auf semantisch interoperabler Basis erfolgen. Die Duale Modellierung ist eine in der Fachwelt viel zitierte Technik für einen semantisch interoperablen Gesundheitsdatenaustausch. Neben der bereits relativ ausgereiften Anwendung der Dualen Modellierung in Form des sogenannten Archetyp -Ansatzes arbeitet die amerikanische Standardisierungsorganisation HL7 seit einigen Jahren an einem ähnlichen Konzept, dem Template -Ansatz. Der Template-Ansatz wird in der Fachliteratur zwar regelmäßig genannt, wurde bisher hinsichtlich seiner Methodik, üblicherweise mit Verweis auf den unfertigen Zustand der Arbeiten, jedoch nur oberflächlich beschrieben. Ziel dieser Arbeit ist es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand der zugrunde liegenden Methodik zu beleuchten. Zu diesem Zweck wird nach einem Überblick über die Technik der Dualen Modellierung die kürzlich von HL7 publizierte Spezifikation des Template-Ansatzes dargestellt. Weiters werden drei im internationalen Gesundheitsdatenaustausch bereits praktisch erprobte Implementierungsleitfäden von auszutauschenden medizinischen Dokumenten, welche bisher ein ähnliches Ziel verfolgten wie künftig die HL7 Templates, auf Basis eines einheitlichen Kriterienkatalogs analysiert und der aktuellen Template- Methodik gegenüber gestellt. Die Arbeit schließt mit einem Vergleich des Template-Ansatzes mit dem bereits erwähnten Archetyp-Ansatz, wobei hierfür das HL7 Template Modell und das Archetyp Objekt Modell gegenübergestellt werden. i

3 Inhaltsverzeichnis KURZFASSUNG... I INHALTSVERZEICHNIS... II 1 EINLEITUNG THEORETISCHE GRUNDLAGEN INTEROPERABILITÄT Technische Interoperabilität Semantische Interoperabilität Prozess Interoperabilität DUALE MODELLIERUNG VON GESUNDHEITSINFORMATION DIE STANDARDISIERUNGSORGANISATION HEALTH LEVEL Das Reference Information Model Der Standard HL7 Version Clinical Document Architecture Release DAS HL7 TEMPLATE STAND DER FORSCHUNG ARCHITEKTUREN VON GESUNDHEITSINFORMATIONS-SYSTEMEN, DIE AUF MULTIPLEN MODELLEN BERUHEN IMPLEMENTIERUNGSASPEKTE VON ARCHETYPEN UND TEMPLATES METHODEN ERGEBNISSE ERGEBNISSE DER ANALYSEPLANUNG ERGEBNISSE DER INFORMATIONSBESCHAFFUNG ERGEBNISSE DER MODELLIERUNG UND DER VERIFIKATION Der Implementierungsleitfaden VHitG Arztbrief Der Leitfaden Continuity of Care Document (CCD) Der Electronic Medical Summary Clinical Document Architecture Implementation Guide GEGENÜBERSTELLUNG VON HL7 TEMPLATES UND CEN ARCHETYPEN DISKUSSION ZUSAMMENFASSUNG UND AUSBLICK ii

4 DANKSAGUNG ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS CODE-BEISPIEL-VERZEICHNIS LITERATURVERZEICHNIS ANHANG iii

5 1 EINLEITUNG 1 Einleitung Informationssysteme im Gesundheitswesen müssen heutzutage immer komplexere Anforderungen bewältigen, die durch eine höhere Qualität der Systeme und optimierte Technologien abgedeckt werden müssen. Die Umstellung von der traditionellen Papierdokumentation auf elektronische Dokumentationssysteme hat zur Folge, dass immer größere Datenmengen entstehen, welche entsprechend aufbereitet und gespeichert werden müssen. Diese Daten sind meist nur bestimmten Einrichtungen oder Instituten zugänglich, da im Bereich der medizinischen Informations- und Dokumentationssysteme proprietäre Formate zur Speicherung der Daten verwendet werden, die untereinander oftmals nicht kompatibel sind. Die Integration von einheitlichen Standards in medizinische Informationssysteme ist ein Ziel, das erreicht werden muss, um Patientendaten zwischen unterschiedlichen Gesundheitsdienstleistern austauschen zu können und für autorisierte Personen verfügbar zu machen. Electronic Health Records (EHRs) stellen die moderne Form von elektronischen Patientenakten dar, deren Integration in das Gesundheitssystem in den letzten Jahren ausgiebig diskutiert wurde. Ein EHR repräsentiert laut International Organization for Standardization (ISO 1 ) einen Behälter für Information, bezugnehmend auf den Gesundheitszustand eines Patienten, in computerverarbeitbarer Form [1, 2, 3]. In [4, 5] werden EHRs hierarchisch in fünf Stufen gegliedert: Automated Record: Enthält Patienteninformationen für administrative Zwecke und kann daher als Archivverwaltungssystem angesehen werden. Computerised Medical Record: Enthält alle patientenbezogenen Dokumente, jedoch meist nur in gescannter Form

6 1 EINLEITUNG Electronic Medical Record: Entspricht einer strukturierten medizinischen Dokumentation einer Einrichtung. Electronic Patient Record: Enthält die Summe aller Electronic Medical Records und entspricht daher einer einrichtungsübergreifenden medizinischen Gesamtdokumentation. Electronic Health Record: Entspricht einer lebensbegleitenden Gesundheitsakte eines Patienten (EHR), welche zusätzlich Eintragungen paramedizinischer Einrichtungen und vom Patienten selbst beinhaltet. In Österreich wurde im Jahr 2006 unter dem Titel ELGA 2 mit der Umsetzung eines EHR-Systems auf nationaler Ebene begonnen [6]. Die Arge-ELGA 3 hat diesbezüglich eine Machbarkeitsstudie [7] durchgeführt, die Detailplanung finalisiert und eine Studie zur Kosten/Nutzen-Analyse in Auftrag gegeben. Die Einführung von EHRs soll in Zukunft zahlreiche Vorteile mit sich bringen, wie z.b. eine Verringerung des finanziellen und organisatorischen Aufwands für Gesundheitsdienstleister medizinische Entscheidungsunterstützung Warnungen in Echtzeit, die medizinische Wechselwirkungen anzeigen Vermeidung von Mehrfacherhebungen medizinischer Daten Um den Anforderungen eines EHR-Systems gerecht werden zu können, müssen einheitliche Standards eingesetzt werden, durch die heterogene Informationssysteme miteinander kommunizieren können und ein sicherer Datenaustausch erfolgen kann. 2 Elektronische Gesundheitsakte 3 Arbeitsgemeinschaft Elektronische Gesundheitsakte, 2

7 1 EINLEITUNG In diesem Bereich haben sich vor allem die Standards von HL7 4, openehr 5, und CEN 6 etabliert, die teilweise ähnliche Ziele verfolgen und auf Interoperabilität (siehe Kapitel 2.1) setzen. Derzeit sind verschiedene Harmonisierungsbestrebungen im Gange, die die Stärken der verschiedenen Ansätze vereinen sollen. Interoperabilität ist ein wichtiger Grundsatz, der in Zukunft durch EHR- Systeme abgedeckt werden muss. Zur Aufbereitung der medizinischen Information in EHR-Systemen bietet sich ein relativ neues Konzept an, das Information und Wissen voneinander trennt die Duale Modellierung [2, 3, 8, 9]. In der Praxis kann die Duale Modellierung durch Archetypen umgesetzt werden, die dynamische Konzepte auf Wissensebene repräsentieren (siehe Kapitel 2.2). Neben dem von openehr entwickelten und in der Norm EN/ISO festgeschriebenen Archetypen-Konzept stellt der HL7 Template Ansatz eine weitere wichtige Anwendung der Dualen Modellierung von Daten des Gesundheitswesens dar. Das Konzept der Templates wird in der Literatur seit Jahren als konzeptueller Baustein des HL7 Version 3 Standards zitiert [10, 11, 12, 13, 14], eine detaillierte Erläuterung der Methodik fehlt dabei jedoch bisher, wobei üblicherweise auf die nicht abgeschlossene Entwicklung verwiesen wird. Ziel dieser Arbeit ist es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand des zugrunde liegenden Frameworks zu beleuchten. Zu diesem Zweck werden die Implementierungsleitfäden VHitG Arztbrief für das deutsche Gesundheitswesen, Continuity of Care Document (CCD) und Electronic Medical Summary (e-ms), welche spezifische Anwendungen des generischen CDA-Modells darstellen und auf HL7 Templates basieren, mittels eines einheitlichen Kriterienkatalogs

8 1 EINLEITUNG analysiert. Nach einer Darstellung des aktuellen Standes der Template- Framework-Spezifikation von HL7 werden die genannten Implementierungsleitfäden der Spezifikation gegenübergestellt und untersucht, inwieweit diese mit der Spezifikation kompatibel sind. Die Analyse des HL7 Template Ansatzes wird weiters ergänzt durch einen Vergleich mit dem Archetyp Ansatz der Norm EN/ISO

9 2 THEORETISCHE GRUNDLAGEN 2 Theoretische Grundlagen 2.1 Interoperabilität Unter Interoperabilität versteht man die Möglichkeit von Systemen oder (Software-)Produkten, miteinander kommunizieren zu können [1]. Im Besonderen bedeutet das, dass Daten zwischen zwei oder mehreren (Computer-)Systemen ausgetauscht werden können bzw. dass unterschiedliche Programme ihre Datenformate und Protokolle gemeinsam verwenden können. Der Begriff Interoperabilität hat sich in den letzten Jahren in vielen Bereichen der Technik und Industrie angesiedelt. Im medizinisch-technischen Kontext spielt die Interoperabilität eine immer größer werdende Rolle. Eine optimale Patientenversorgung erfordert, dass Krankenhaus-Informationssysteme problemlos miteinander kommunizieren und die ausgetauschten Daten und Informationen auch anwenden können. Das Institute of Electrical and Electronics Engineers (IEEE-USA 7 ) sieht die Interoperabilität als einen entscheidenden und kritischen Punkt bei der Implementierung von Informationstechnologie in bestehende Gesundheitssysteme [15]. Auch in den Bereichen Telekommunikation, Software und öffentliche Sicherheit wird Interoperabilität immer mehr in den Vordergrund gerückt. Im Web finden sich unzählige Definitionen von Interoperabilität. Die HL7 EHR Interoperability Work Group hat den Begriff hierarchisch strukturiert und in 3 Bereiche eingeteilt [16]: Technische Interoperabilität Semantische Interoperabilität Prozess Interoperabilität In den folgenden Kapiteln sollen diese drei Begriffe näher erläutert werden

10 2 THEORETISCHE GRUNDLAGEN Technische Interoperabilität Wenn im technischen Kontext von Interoperabilität gesprochen wird, ist oft die verbreitete Form der technischen Interoperabilität gemeint, die in der Literatur auch unter dem Begriff Funktionale Interoperabilität bekannt ist. Diese Form repräsentiert die niedrigste Stufe der Hierarchie und bezieht sich hauptsächlich auf die Hardware bzw. auf Hardware-bezogene Aspekte. Technische Interoperabilität bedeutet, dass zwei oder mehrere Systeme die Fähigkeit besitzen, Daten auszutauschen, die einem Nutzen zugeführt werden können und menschenlesbar sein müssen. Das Verstehen der Bedeutung der Information und die erfolgreiche Verarbeitung beim empfangenden System kann durch technische Interoperabilität nicht abgedeckt werden. Sie ist jedoch eine Notwendigkeit, um Daten und Information erfolgreich von System zu System transferieren zu können und dadurch deren räumliche Trennung zu überwinden Semantische Interoperabilität Diese zweite Stufe der Interoperabilität bedeutet, dass die empfangenen Daten auch maschinell sinnvoll genutzt und verarbeitet werden können. Bezogen auf Computersysteme heißt semantische Interoperabilität also, dass die Information vom empfangenden System richtig interpretiert wird und daraus ein sinnvolles Ergebnis generiert werden kann. Um eine effektive und sichere Patientenversorgung garantieren zu können, wird diese Stufe in Zukunft anzustreben sein. Semantische Interoperabilität wird in erster Linie durch die Anwendung von Klassifikationssystemen (z.b. ICD 8 ) und Nomenklaturen (z.b. SNOMED CT 9 [17]) erzielt. Dadurch können computerverwertbare Informationen bereitgestellt werden und mit Hilfe von Archetypen (siehe Kapitel 2.2) und Templates (siehe Kapitel 2.4) Strukturvorgaben erzielt werden, die direkt vom System verarbeitet werden können. 8 International Classification of Diseases 9 Systemized Nomenclature of Medicine -- Clinical Terms 6

11 2 THEORETISCHE GRUNDLAGEN Die ISO definiert vier Voraussetzungen zur Realisierung von semantischer Interoperabilität [1], wobei die ersten beiden auch für technische Interoperabilität erforderlich sind: a) Ein standardisiertes EHR Referenzmodell, das Sender und Empfänger der Information gemeinsam verwenden. b) Ein standardisiertes Service-Schnittstellen-Modell, um die Interoperabilität zwischen dem EHR Service und anderen Diensten (z.b. Terminologie und Sicherheitsdienst in einem klinischen Informationssystem) zu gewährleisten. c) Eine Menge an standardisierten domänenspezifischen Konzept- Modellen (z.b. Templates, siehe Kapitel 2.4). d) Standardisierte Terminologien (zur Unterstützung der Templates) Prozess Interoperabilität Diese dritte Stufe der Interoperabilität beschäftigt sich mit Arbeitsprozessen und deren Ablauf. Sie setzt voraus, dass die Daten erfolgreich übermittelt wurden (technische Interoperabilität) und diese vom System auch erfasst und verstanden wurden (semantische Interoperabilität). Sie wurde definiert, um Sicherheit und Qualität speziell im Gesundheitswesen zu garantieren. Dieser Ansatz enthält Methoden, die zur erfolgreichen Integration von Computersystemen in bestimmten Arbeitssituationen herangezogen werden können. Folgende Ziele werden damit verfolgt [16]: Eine explizite Nutzerrollen-Spezifikation Ein benutzerfreundliches Mensch-Maschine-Interface Datenrepräsentation und Datenfluss unterstützen die Arbeitssituation Ein ausgereiftes Arbeitsdesign Effektivität im jeweiligen Einsatz 7

12 2 THEORETISCHE GRUNDLAGEN Bezugnehmend auf das Gesundheitswesen koordiniert die Prozess Interoperabilität die Arbeitsprozesse insofern, als dass die übermittelte Information in einer zeit-, ablauf- und sequenzorientierten Weise erfolgen kann und somit die Patientenversorgung effizient und sicher durchgeführt werden kann. 2.2 Duale Modellierung von Gesundheitsinformation Informationssysteme werden heutzutage in verschiedensten Bereichen eingesetzt, stellen Information und Wissen bereit und bieten Mechanismen an, die eine effiziente und zielorientierte Nutzung der Daten ermöglichen. Finanzielle Aspekte, kürzere Entwicklungszeit und eine einfachere Implementierung sind einige der Motive aufgrund derer viele Informationssysteme auf so genannten singulären Modellen (Single-Level Approach) [8, 9] aufbauen. Dieser Ansatz bedeutet, dass Information und Wissen auf eine Ebene gestellt werden und die Modelle hard-coded in Software und Datenbank integriert werden. Diese direkte Implementierung hat zur Folge, dass umfangreiche und komplexe Systeme große Klassenmodelle und Datenbanken produzieren und dadurch Änderungen und Erweiterungen schwer durchzuführen sind und eine Stabilität des Informationssystems nicht garantiert werden kann. Gesundheitsinformationssysteme stellen einige Ansprüche, die durch Systeme, die auf single-level-modellen basieren, nicht oder nur teilweise abgedeckt werden können. Dynamische Systemkomponenten und das Streben nach semantischer Interoperabilität verlangen einen flexibleren Ansatz [18]. Der Dual Model Approach der Ansatz der Dualen Modellierung soll den Erfordernissen moderner Gesundheitsinformationssysteme gerecht werden und wurde von Thomas Beale vorgestellt [8, 9]. Der Ansatz geht davon aus, dass Information und Wissen semantisch voneinander getrennt werden. Die Idee einer dual-level Methodologie wurde später vom Europäischen Normungsinstitut in dessen 8

13 2 THEORETISCHE GRUNDLAGEN Standards übernommen. Die Ebenen der dualen Modellierung sind folgendermaßen definiert: Informationsebene: Repräsentiert den generischen Teil und wird in der Praxis durch ein Referenzmodell (siehe Kapitel 2.3.1) dargestellt. Information enthält Aussagen über einen bestimmten Sachverhalt oder eine bestimmte Entität und bezieht sich nur auf eine bestimmte Person. Wissensebene: Repräsentiert den dynamischen Teil und wird in der Praxis durch Archetypen [8] repräsentiert. Wissen beinhaltet Aussagen, die allen Entitäten einer Klasse entsprechen. Wissen kann z.b. aus einer medizinischen Datenbank abgerufen werden und ist auf alle Personen anwendbar. Der Begriff Archetyp wurde definiert, um Modelle auf Basis der Wissensebene zu beschreiben. Archetypen sind Strukturen, die Einschränkungen auf Instanzen eines Referenzmodells definieren und verfolgen laut [9] folgende Ziele: Den Nutzern einer Domäne soll die Formulierung ihrer eigenen Konzepte ermöglicht werden. Informationssysteme sollen Benutzereingaben während der Erstellung und Modifizierung von Information leiten und validieren können und gewährleisten, dass alle Instanzen der Information den Erfordernissen der Domäne entsprechen. Interoperabilität soll auf Wissensebene gewährleistet werden. Es soll eine eindeutige Basis geschaffen werden, um komplexe Daten effizient abfragen zu können. In Abbildung 1 werden die Ebenen der dualen Modellierung grafisch dargestellt und in Beziehung gesetzt. 9

14 2 THEORETISCHE GRUNDLAGEN Informationsebene Wissensebene Referenzmodell Archetypobjektmodell Einschränkungen Instanz Instanz Einschränkungen Information Archetyp Abbildung 1: Archetyp-Modell Meta-Architektur, übernommen aus [9] Auf Informationsebene wird ein Referenzmodell definiert, das Struktur und Semantik der Information darstellt. Die Beziehung zwischen Referenzmodell und Informations-Objekt kann mit der üblichen objektorientierten Klassen- Objekt-Beziehung verglichen werden, wobei Information eine Instanz des Referenzmodells darstellt. Auf Wissensebene werden Archetypen definiert, die Struktur und Semantik der Information einschränken. Archetypen haben ein eigenes formales Modell (siehe Abbildung 1 rechts oben) bzw. eine eigene Sprache die Archetype Definition Language (ADL) [19, 20]. 10

15 2 THEORETISCHE GRUNDLAGEN 2.3 Die Standardisierungsorganisation Health Level 7 Die Organisation Health Level 7 (HL7) wurde 1987 gegründet und hat ihren Hauptsitz in Ann Arbor (Michigan, USA). Das Unternehmen wurde vom American National Standards Institute (ANSI) als Standards Developing Organization (SDO) akkreditiert und hat die Mission Standards für das Gesundheitswesen zu entwickeln, um die Gesundheitsversorgung zu verbessern, deren Abläufe zu optimieren und den Transfer von Wissen zu steigern. Viele von HL7 entwickelte Standards werden im Gesundheitswesen intensiv genutzt. Level 7 bezieht sich auf das von der ISO zertifizierte Kommunikationsmodell für Open Systems Integration (OSI) [21, 22]. Dieses Modell ist in sieben Ebenen gegliedert, wobei die ersten vier Stufen zusammengefasst die Kommunikationsebene repräsentieren. Von der fünften bis zur siebenten Stufe spricht man von der Funktionalitätsebene. Level 7 repräsentiert die oberste Ebene der Integration, nämlich die Applikationsebene. Durch die Gründung zahlreicher Benutzergruppen, die sich über den gesamten Erdball verstreuen (unter anderem auch in Österreich 10 und Deutschland 11 ), wurde der Ansatz zu einem international einsetzbaren und anerkannten Standard. Mittlerweile werden HL7 Standards in vielen Ländern eingesetzt und nehmen in manchen sogar den Rang einer offiziellen Norm ein Das Reference Information Model Das Reference Information Model (RIM) [23] wurde von HL7 entwickelt und als Draft-Version erstmals im Jänner 1997 veröffentlicht. Das offizielle Release 1 wurde im Jahr 2003 durch die ANSI anerkannt und auch durch die ISO unter der Referenz ISO/HL :2006 übernommen. Es ist ein

16 2 THEORETISCHE GRUNDLAGEN statisches Modell das aus sechs Hauptklassen besteht, die den Kern des Modells darstellen sollen. Abbildung 2: Die 6 Core-Klassen des HL7 RIM, übernommen aus [23] Act: Diese Klasse repräsentiert Handlungen, die ausgeführt werden und folglich auch dokumentiert werden müssen (z.b. eine Behandlung oder Untersuchung). Entity: Eine Entität repräsentiert physische Dinge und Personen, die für eine Handlung von Relevanz sind (z.b. Person, Röntgen-Gerät). Role: Eine Rolle wird von einer Entität verkörpert. Eine Entität kann jedoch mehrere Rollen haben (z.b. Dokumentenverfasser, behandelnder Arzt). Participation: Eine Beteiligung stellt eine Beziehung zwischen Handlungen und Rollen her. Dabei ist eine bestimmte Rolle an einer bestimmten Handlung beteiligt (z.b. ein bestimmter Arzt führt eine Behandlung durch). ActRelationship: Diese Klasse repräsentiert Beziehungen zwischen verschiedenen Handlungen (z.b. eine Diagnose folgt aus einer Beobachtung). RoleLink: Auch zwischen Rollen können Beziehungen und Abhängigkeiten bestehen (z.b. Hierarchie in einem Krankenhaus). Diese Klassen dienen als Bausteine und somit als Grundlage für alle Informationsmodelle und Strukturen, die im Rahmen des HL7 Version 3 12

17 2 THEORETISCHE GRUNDLAGEN Entwicklungsprozesses (siehe Kapitel 2.3.2) erstellt werden. Diese Bausteine werden in verschiedenen HL7-Schulungen mit Lego Steinen verglichen. Diese Metapher soll RIM-Einsteigern das Prinzip näher bringen, nämlich die Möglichkeit aus verschiedenen Bausteinen unterschiedliche Modelle und Strukturen erstellen zu können. Abgesehen von den sechs Hauptklassen besteht das RIM noch aus einigen Subklassen (siehe Abbildung 3). Das statische Modell wurde mittels der Unified Modeling Language (UML 12 ) [24] erstellt, das durch einige HL7- spezifische Erweiterungen ergänzt wurde. Abbildung 3: HL7 Reference Information Model, übernommen aus [23] Neben den in Abbildung 3 dargestellten Klassen wurde von HL7 die Superklasse 13 InfrastructureRoot erstellt, deren Attribute spezifische Einschränkungen auf Klassen anwenden können und speziell im Kontext des Informationsaustauschs Anwendung finden Eine Superklasse vererbt ihre Attribute an die Subklassen des RIM 13

18 2 THEORETISCHE GRUNDLAGEN InfrastructureRoot.nullFlavor: Dieser Wert zeigt an, dass die betreffende Information nicht vorhanden ist. Er spezifiziert, warum die Information nicht existiert oder in diesem speziellen Fall nicht angewendet werden kann. InfrastructureRoot.realmCode: Dieses Attribut erzwingt bereichsspezifische Einschränkungen. InfrastructureRoot.typeId: Erzwingt Einschränkungen, die in einem HL7-spezifischen Message Type (siehe Kapitel ) definiert sind. Ein Beispiel dazu findet sich in Kapitel InfrastructureRoot.templateId: Gibt an, dass definierte Einschränkungen (Templates) auf die Instanz angewendet werden. Die oben genannten Attribute können aufgrund des Vererbungsprinzips in Instanzen des RIM eingesetzt werden (siehe Kapitel 2.3.3). In [25] wird das RIM als inkohärenter Standard beschrieben, der trotz seines über zehn-jährigen Bestehens Probleme bei der Implementierung, Usability und Dokumentation aufweist. Der angesprochenen Doppeldeutigkeit des RIM könne nur mit der Generierung zweier separater Modelle abgeholfen werden: eine Referenz-Ontologie 14 des Gesundheitsbereichs und ein Modell für die Gesundheitsinformation. In der Praxis hat sich das RIM jedoch etabliert. Die immer wieder laut gewordene Kritik beruht laut [26] auf Missverständnissen und unterschiedlichen Sichtweisen der Anwender Das Domain Message Information Model Um eine spezielle Domäne des Gesundheitswesens darstellen zu können, hat HL7 das Domain Message Information Model (D-MIM) entwickelt. Es wird vom RIM abgeleitet und kann mittels der in Kapitel erwähnten Bausteine beliebig zusammengestellt und an verschiedenste Bedürfnisse 14 Eine Ontologie ist eine (meist hierarchische) Struktur, durch die ein Bereich der Realität modelliert werden kann. 14

19 2 THEORETISCHE GRUNDLAGEN angepasst werden. Dabei kommen die so genannten class clones ins Spiel, welche Kopien von RIM-Klassen darstellen und für eine bestimmte Domäne im Gesundheitswesen eingesetzt werden können. Ein D-MIM besteht aus jenen Klon-Klassen, Attributen und Beziehungen, die zur Konstruktion jeglicher domänenspezifischer Nachrichten benötigt werden. Wie auch das RIM, könnte auch ein D-MIM mittels UML grafisch dargestellt werden. Um jedoch die semantischen Verbindungen zwischen den verschiedenen Klassen und Attributen, sowie deren Einschränkungen besser darstellen zu können, hat HL7 eine eigene Notation entwickelt. Ein D-MIM stellt also ein Modell dar, das Einschränkungen auf das RIM anwendet und weiters eine Basis für alle spezifischeren Modelle, genannt R- MIM (siehe Kapitel ) Das Refined Message Information Model Das Refined Message Information Model (R-MIM) leitet seinen Inhalt vom zugehörigen D-MIM ab und beschreibt jene Klassen, Attribute und Beziehungen, die zur Erstellung von HL7-Nachrichten benötigt werden. Es wird grafisch wie auch das D-MIM durch die HL7 Notation repräsentiert und schränkt das zugehörige D-MIM in der Weise ein, dass ein weitaus spezifischerer Bereich zum Zweck der Erstellung einer Nachricht dargestellt werden kann. Um eine Nachricht aus einem R-MIM generieren zu können bedarf es zwei weiterer Strukturen: Hierarchical Message Description (HMD) Message Type (MT) Eine HMD spezifiziert, wie Nachrichten im HL7-Kontext auszusehen haben und beschreibt Kardinalität, Optionalität, Gruppierung und Sequenz einer Nachricht. Die Abfolge dieser Elemente wird in tabellarischer Form dargestellt (z.b. als MS-Excel-Dokument), ohne sich auf die verwendeten 15

20 2 THEORETISCHE GRUNDLAGEN Implementierungstechnologien (z.b. XML 15 ) zu beziehen. Die Spezifikation enthält weiters so genannte Message Types, die die Regeln zur Erstellung von Nachrichten beschreiben Der Standard HL7 Version 3 Im Jahr 1994 begann die Version 3 Arbeitsgruppe mit der Entwicklung eines neuen Standards und veröffentlichte 1997 das HL7 Version 3 Message Development Framework (MDF) [27] als neue Methodologie. Durch die stetige Weiterentwicklung des MDF wurde ein umfassendes HL7 Development Framework (HDF) [28] gebildet, das nun den Grundstock für Architekturentwicklungen und Nachrichtenstandards darstellen soll [29]. Basierend auf dem RIM wurde ein Paket von modell- und objektorientierten Kommunikationsstandards definiert, welche für die Entwicklung von Nachrichtenspezifikationen eingesetzt werden. Es wurden vier Modelle spezifiziert, die zur Entwicklung von Nachrichtenspezifikationen durchlaufen werden (siehe Abbildung 4). Use Case Model: Das Use Case Model stellt die erste Struktur dar, die im Entwicklungsprozess generiert werden muss und beschreibt den Informationsfluss zwischen den Applikationen. Information Model: Das Information Model muss dessen Inhalt zur Erstellung einer HL7-Nachricht vom Reference Information Model ableiten, was den meist kritischsten Punkt in der Entwicklung darstellt. Interaction Model: Das Interaction Model definiert Trigger Events, Interaktionen und Applikationsrollen, welche das Verhalten von Systemen, die HL7-Nachrichten nutzen, angeben. Message Design Model: Das Message Design Model wird aus Klassen, Attributen und Beziehungen des RIM zusammengestellt und beschreibt somit die Anforderungen an eine Nachricht für eine

21 2 THEORETISCHE GRUNDLAGEN beliebige Interaktion. Das daraus entstehende Message Information Model (MIM, siehe die Kapitel und ) dient als Grundlage für ein message object diagram, aus welchem die Hierarchical Message Descriptions generiert werden. Die Modelle auf denen HL7 Version 3 basiert, wie auch die erwähnte Methodologie, machen Version 3 zu einem mächtigen und flexiblen Standard im medizinischen Sektor. Abbildung 4: Message Development Modelle, übernommen aus [27] 17

22 2 THEORETISCHE GRUNDLAGEN Clinical Document Architecture Release 2 Die Clinical Document Architecture (CDA) ist ein von der ANSI akkreditierter Standard, der die Struktur und Semantik eines klinischen Dokuments zum Zweck der Übermittlung vorgibt [30]. Seit dem Release 2 ist der maschinen-verwertbare Teil der CDA nun vollständig vom RIM abgeleitet. Die CDA wird grafisch durch ein R-MIM (siehe Kapitel ) dargestellt, wobei sich die farbliche Codierung aus den RIM-Klassen (siehe Abbildung 2) ableitet. CDA-Dokumente wurden entwickelt, um eine einfachere und effektivere Kommunikation zwischen Informationssystemen zu gewährleisten, sie können jedoch auch zur Archivierung klinischer Dokumente eingesetzt werden und dadurch deren Persistenz garantieren. Die CDA weist folgende Charakteristika auf: Persistenz: Ein klinisches Dokument bleibt über eine Zeitspanne, die durch lokale oder gesetzliche Anforderungen definiert wird, unverändert. Zuständigkeit: Ein klinisches Dokument wird durch die für die Pflege zuständige Organisation betreut. Möglichkeit der Authentifizierung: Ein klinisches Dokument ist eine Ansammlung von Informationen, dessen Urheberschaft und Integrität sichergestellt werden muss. Kontext: Ein klinisches Dokument erstellt einen Kontext zu seinen Inhalten. Gesamtheit: Die Authentifizierung eines klinischen Dokuments bezieht sich auf die Gesamtheit und nicht nur auf Teile des Dokuments. Menschenlesbarkeit: Ein klinisches Dokument ist menschenlesbar. 18

23 2 THEORETISCHE GRUNDLAGEN Die CDA verfolgt einige Ziele, die jedoch in der Spezifikation nur sehr vage definiert sind. Zusammenfassend sollen hier die wichtigsten Punkte angeführt werden: Die CDA legt ihr Hauptaugenmerk auf die Patientenversorgung Kosteneffektive Implementierungen sollen mit einer hohen System- Bandbreite ermöglicht werden Der Austausch von menschenlesbaren Dokumenten zwischen Benutzergruppen (auch zwischen jenen mit unterschiedlichen Erfahrungsstufen) soll unterstützt werden Die Langlebigkeit aller kodierten Informationen betreffend der CDA- Architektur soll gefördert werden Die Weiterverarbeitung der CDA-Daten soll einer großen Auswahl an Applikationen ermöglicht werden CDA-Dokumente sollen mit einer großen Anzahl von Applikationen zur Dokumentenerstellung kompatibel sein Generell kann man sagen, dass mit Hilfe der CDA in Zukunft eine Textstrukturierung angestrebt wird und somit eine hohe semantische Interoperabilität gewährleistet werden kann. Um jedoch zu garantieren, dass der Empfänger des Dokuments die mitgelieferte Information auch ohne Zuhilfenahme von spezieller Software lesen und interpretieren kann, ist es notwendig, dass die vom Verfasser erstellten Inhalte menschenlesbar also narrativ übermittelt werden. Die zusätzliche Möglichkeit der Maschinenlesbarkeit stellt zwar einen für die Zukunft wichtigen Aspekt für die medizinische Dokumentation dar, wird aber in den Spezifikationen nicht zwingend vorgeschrieben, sondern nur als optionale Möglichkeit gehandhabt. Die CDA ist ein XML-Dokument, das die oben genannten Charakteristika aufweisen muss. Ein CDA-Dokument muss mit einem einfachen Editor ohne Zuhilfenahme spezieller Software gelesen werden können. Mit zusätzlichen 19

24 2 THEORETISCHE GRUNDLAGEN XML-Stylesheets [31] kann der Quelltext jedoch auch in einer gewünschten Formatierung anzeigbar gemacht werden. Die CDA besteht aus einem Header und einem Body, die zwingend aus narrativem Text (unstrukturiert) und optional aus maschinenverwertbaren (strukturierten) Daten bestehen. Zusätzlich können dem Dokument noch Multimedia-Dateien, wie z.b. Audiodateien und Bilder beigefügt werden. Aufgrund der Wichtigkeit der CDA für diese Arbeit werden in den nächsten Kapiteln die Klassen und Attribute von Header und Body näher betrachtet. Die Root-Klasse eines CDA-Dokuments ClinicalDocument stellt den Einstiegspunkt in das Objektmodell (R-MIM, siehe Abbildung 5) der CDA dar und enthält zahlreiche Attribute, deren Bedeutung in Kapitel erläutert werden soll. Das Attribut typeid der Superklasse InfrastructureRoot muss innerhalb der ClinicalDocument-Klasse vorkommen und folgendermaßen aussehen: <typeid root= extension= POCD_HD /> Code-Beispiel 1: Das XML-Fragment "typeid", übernommen aus [30] Die ebenfalls aus der Klasse InfrastructureRoot stammende templateid kann in allen Klassen eines CDA-Dokuments vorkommen und deutet somit darauf hin, dass zusätzliche Einschränkungen auf die Klassen angewendet werden. 20

25 2 THEORETISCHE GRUNDLAGEN CDA R2 Header Der Header identifiziert und klassifiziert das Dokument durch die Metadaten und ermöglicht dadurch die Dokumentenverwaltung und den Austausch von CDA-Dokumenten innerhalb von Institutionen und über Institutionsgrenzen hinaus Header Attribute In diesem Kapitel soll eine Übersicht der Attribute der Root-Klasse ClinicalDocument erstellt und ihre Bedeutung kurz erläutert werden. ClinicalDocument.id: Identifiziert das Dokument durch einen eindeutigen Identifier. ClinicalDocument.code: Beschreibt die Art des Dokuments (z.b. Entlassungsbericht). o CE Coded With Equivalents bedeutet, dass der Dokumenttyp kodiert vorliegen muss und eine Ausprägung des Datentyps Concept Descriptor sein muss, welcher ein Konzept mit einem Code beschreibt. o CWE Coded With Extensibility gibt die Strenge der Kodierung an und bedeutet, dass auch ein Code verwendet werden darf, der nicht in den Vocabularies von HL7 beschrieben ist (z.b. LOINC 16 ). o CNE Coded non-extensible schreibt vor, dass nur Codes aus den Vocabularies verwendet werden dürfen. CWE und CNE leiten sich aus dem Datentyp Coded Value (CV) ab, der kodierte Daten zulässt. ClinicalDocument.title: Repräsentiert den Dokumententitel. 16 Logical Observation Identifiers Names and Codes (LOINC) Ein Begriffssystem zur Verschlüsselung von Laborwerten und klinischen Untersuchungen, 21

26 2 THEORETISCHE GRUNDLAGEN ClinicalDocument.effectiveTime: Bezeichnet den Zeitpunkt der Erstellung des Dokuments. ClinicalDocument.confidentialityCode: Beschreibt die Vertraulichkeit des Dokuments, die Normal (N), Restricted (R) oder Very Restricted (V) sein kann. ClinicalDocument.languageCode: Spezifiziert die Sprache des Dokuments mit Hilfe eines von HL7 definierten Kodierungssystems. ClinicalDocument.setId: Ein Identifier, der über alle Dokumentrevisionen gebraucht wird. ClinicalDocument.versionNumber: Eine Zahl, welche die Version des Dokuments angibt Header Beteiligte Seit der Veröffentlichung des Release 2 der CDA, das durch die Entwicklung des RIM maßgeblich beeinflusst wurde, können im Header weitaus mehr beteiligte Personen und Organisationen unterschieden werden, als das noch im Release 1 der Fall war [10]. Eine beteiligte Person kann in einem CDA- Dokument mehrere Rollen gleichzeitig besetzen. In den folgenden Punkten soll die Bedeutung der wichtigsten Klassen beschrieben werden, die über eine Beteiligung (Participation) mit der Root- Klasse ClinicalDocument in Beziehung stehen. authenticator: Eine Person, welche die Richtigkeit eines Dokuments bescheinigt, die jedoch nicht das Recht einer legalen Beglaubigung hat. author: Verfasser des Dokuments (z.b. eine Person, eine Maschine bzw. ein System). custodian: Jedes CDA Dokument wird durch genau eine Organisation verwaltet. 22

27 2 THEORETISCHE GRUNDLAGEN dataenterer: Eine Person, die Daten in das Ursprungssystem eingibt. encounterparticipant: Repräsentiert einen Kliniker, der an einer Interaktion zwischen dem Patient und dem Gesundheitsdienstleister (z.b. ein Arztbesuch) beteiligt ist. informant: Eine Person, die relevante Informationen zur Verfügung stellt (z.b. ein Elternteil eines Kindes). informationrecipient: Der Empfänger des Dokuments. legalauthenticator: Eine beteiligte Person, die das Dokument legal bescheinigt hat. participant: Alle Beteiligten (Personen und Organisationen), die nicht schon explizit durch andere Klassen abgedeckt werden. performer: Repräsentiert Kliniker, die ein ServiceEvent (siehe Kapitel ) ausführen. recordtarget: Repräsentiert das EHR, welchem das CDA-Dokument zugeordnet wird und nimmt Bezug auf den Patienten, der die medizinische Leistung in Anspruch nimmt. responsibleparty: Stellt eine Person oder Organisation dar, die die Verantwortung über die ausgeführte Interaktion (encounter) hat Header Beziehungen In Abbildung 6 sind jene Klassen abgebildet, die über eine Beziehung mit der Root-Klasse ClincialDocument in Verbindung stehen. Ihre Bedeutung soll in den folgenden Punkten erläutert werden: ParentDocument: Ein anderes Dokument, das die Quelle eines überarbeiteten Dokuments oder eines Dokumentenanhangs darstellt. ServiceEvent: Repräsentiert die eigentliche Handlung, die dokumentiert werden soll (wie z.b. eine Darmspiegelung). 23

28 2 THEORETISCHE GRUNDLAGEN Order: Beinhaltet Anweisungen, die im Laufe einer klinischen Interaktion erfüllt werden müssen (z.b. die Anforderung eines Röntgen). Consent: Beschreibt Genehmigungen, die mit dem CDA-Dokument einhergehen. EncompassingEncounter: Diese Klasse beschreibt die klinische Interaktion, innerhalb der die Dokumentation stattgefunden hat. 24

29 2 THEORETISCHE GRUNDLAGEN Abbildung 5: CDA R2 Header mit Beteiligten, übernommen aus [30] 25

30 2 THEORETISCHE GRUNDLAGEN Abbildung 6: CDA R2 Header Beziehungen, übernommen aus [30] 26

31 2 THEORETISCHE GRUNDLAGEN CDA R2 Body Der Body enthält den klinischen Befund und kann entweder aus unstrukturiertem Text (repräsentiert durch die Klasse NonXMLBody) oder aus strukturiertem Markup (repräsentiert durch die Klasse StructuredBody) bestehen. Jedes CDA-Dokument besteht aus genau einem Body, welcher über die Beziehung component mit der Root-Klasse in Verbindung steht (siehe Abbildung 7). Beim Eintritt in den Body gelangt man in den so genannten BodyChoice, der die Auswahl zwischen strukturiertem XML-Code und unstrukturiertem Blob 17 ermöglicht Section Jeder Body enthält mindestens eine Section-Klasse, welche ähnlich wie die Klasse ClinicalDocument aus verschiedenen Attributen aufgebaut ist: Section.id: Ein eindeutiger Identifikator einer Section Section.code: Spezifiziert die Art der Section Section.title: Der menschenlesbare Titel der Section Section.text: Repräsentiert den Narratviblock der Section, welcher vom Empfänger des Dokuments gerendert werden muss Section.confidentialityCode: Die Vertraulichkeit der Section (siehe Kapitel ). Ein hier angegebener Wert überschreibt für den Kontext der aktuellen Section den gleichnamigen Wert, der in der Klasse StructuredBody angegeben wurde. Section.languageCode: Die gewählte Sprache für Inhalt und Attribute Wie auch im Header kann es in einer Section verschiedene Beteiligte geben, die entweder eine exakte Kopie der jeweiligen Klasse im Header darstellen, 17 Blob steht für Binary Large Object und bezeichnet große binäre Objekte, die in einer Datenbank unstrukturiert vorliegen 27

32 2 THEORETISCHE GRUNDLAGEN oder durch einen neuen Wert überschrieben werden können. Diesen Kontext findet man in einigen Attributen der CDA (z.b. confidentiality und language). Im Header definierte Werte können bis in verschachtelte Klassen des Bodys propagiert werden, falls sie nicht durch neue Werte überschrieben wurden. Die Beteiligten author und informant können analog zu den gleichnamigen Beteiligten des Headers gesehen werden. Der Beteiligte subject repräsentiert jene Person, auf die sich die in der Section beschriebene Handlung bezieht. Einer Section können über die Beziehung component beliebig viele Sections folgen, wobei der Kontext in die untergeordneten Sections propagiert wird clinicalstatement Über die Beziehung entry gelangt man zu einer weiteren ChoiceBox clinicalstatement (siehe Abbildung 8). Durch die so genannten entries (oder auch entry-acts) können narrative Inhalte der Sections durch kodierte, computerverwertbare Inhalte dargestellt werden. Anders als bei bodychoice und Section ist ein entry nicht zwingender Bestandteil eines CDA- Dokuments, da hier eine 0 *-Kardinalität besteht. Die in einem clinicalstatement erlaubten Klassen stellen Ableitungen von RIM-Klassen dar und sollen in den folgenden Punkten kurz beschrieben werden: Observation: Repräsentiert klinische Beobachtungen. RegionOfInterst: Der Bereich, der in einem Bild von Interesse ist. ObservationMedia: Repräsentiert Multimedia-Inhalte, die Teil des bescheinigten Inhalts eines CDA-Dokuments sind (im Gegensatz zur Referenz ExternalObservation). SubstanceAdministration: Wird für die Darstellung der Medikation genutzt und kann auch Events repräsentieren, die mit der Medikation in Verbindung stehen (z.b. Medikationsgeschichte oder der geplante Ablauf der Medikation). 28

33 2 THEORETISCHE GRUNDLAGEN Supply: Die Weitergabe eines Produkts oder Materials von einer Entität zur nächsten. Procedure: Repräsentiert Prozeduren, deren Folge die Änderung des physischen Zustands des betreffenden subjects ist. Encounter: Durch diese Klasse werden weitere Interaktionen zwischen Patient und Kliniker repräsentiert (zusätzlich zu den Interaktionen, die durch die Klasse EncompassingEncounter im Header beschrieben werden, siehe Kapitel ). Organizer: Kann verwendet werden, um beliebige Gruppierung von CDA-entries zu erstellen, welche einen gemeinsamen Kontext haben (Weitere Organizer können durch die Beziehung component realisiert werden). Act: Wenn die Gesundheitsdienstleistung keiner spezielleren Klasse zugeordnet werden kann wird auf die allgemeine Klasse Act zurück gegriffen. Der folgende XML-Code repräsentiert eine einfache Observation, in der die Körpertemperatur dokumentiert wurde. Diese ist in eine Section Vital- Signs eingebettet. 29

34 2 THEORETISCHE GRUNDLAGEN <section> <code code="8716-3" codesystem=" " codesystemname="loinc"/> <title>vital Signs</title> <text>temperature is 36.9 C</text> <entry> <observation classcode="obs" moodcode="evn"> <code code=" " codesystem=" " codesystemname="snomed CT" displayname="body temperature"/> <statuscode code="completed"/> <effectivetime value=" "/> <value xsi:type="pq" value="36.9" unit="cel"/> </observation> </entry> </section> Code-Beispiel 2: Observation innerhalb einer section, übernommen aus [10] In diesem Beispiel werden einige typische Attribute einer Observation ersichtlich, wie z.b. Observation.code und Observation.value. Der moodcode EVN (Event) sagt aus, dass es sich um ein Ereignis handelt und dass die Observation somit stattgefunden hat. Die clinicalstatements sind mit zahlreichen Beteiligten verknüpft, die wie auch in den Sections entweder vom Header in den Body propagieren oder durch neue Werte überschrieben werden. Die wichtigsten Beteiligten decken sich mit den Klassen in Kapitel Über die Beziehung reference können über die CDA-entries noch externe Objekte (wie z.b. Bilder oder ältere Befunde) referenziert werden. 30

35 2 THEORETISCHE GRUNDLAGEN Abbildung 7: CDA R2 Section, übernommen aus [30] 31

36 2 THEORETISCHE GRUNDLAGEN Abbildung 8: CDA R2 Body entries, übernommen aus [30] 32

37 2 THEORETISCHE GRUNDLAGEN 2.4 Das HL7 Template Bestehende Gesundheitsinformationsmodelle sind in der Lage einen Ausschnitt der realen Welt darzustellen. Wie wir bereits in Kapitel gesehen haben, kann mittels ausgewählter RIM-Klassen ein klinisches Dokument erstellt werden, das einem klassischen Papier-Dokument entspricht. Diese Strukturen sind oftmals relativ allgemein gehalten und können daher nur schwer für speziellere medizinische Anwendungen (wie z.b. einen Laborbefund) herangezogen werden [32]. Das HL7 Template beinhaltet eine Menge von Bedingungen, durch die es ermöglicht wird, bestehende Modelle einzuschränken und zu verfeinern. Dadurch kann ein weitaus spezifischerer Bereich einer im HL7-Kontext meist klinischen Anwendung dargestellt werden. Ein Template wird ebenso wie die CDA durch ein XML-Dokument repräsentiert und enthält idealerweise noch zusätzliche Metadaten, die den Zweck und die Anwendung des Templates beschreiben. Optional können dem Template noch Anhänge beigefügt werden, wie z.b. eine grafische Repräsentation des Template-Modells. Das Template-Konzept von HL7 beruht auf der in Kapitel 2.2 behandelten Dualen Modellierung, in der Informations- und Wissensebene voneinander getrennt werden. Im HL7-Kontext wird die Informationsebene durch das RIM (siehe Kapitel 2.3.1) und die Wissensebene durch Templates repräsentiert. Die Organisation HL7 hat eine Gruppe ins Leben gerufen, die sich mit der Ausarbeitung von Vorgaben zur Erstellung von Templates beschäftigt. Diese Vorgaben wurden in einer Spezifikation zusammengefasst, die in Zukunft zur Erstellung von HL7 Templates herangezogen werden soll und im Folgenden erläutert wird. Die HL7 Template Spezifikation Diese Spezifikation [33] wurde als Draft Standard for Trial Use (DSTU) veröffentlicht, trägt den offiziellen Titel Specification and Use of Reusable Constraint Templates und beinhaltet allgemeine Vorgaben zur Erstellung 33

38 2 THEORETISCHE GRUNDLAGEN von HL7 Templates. Die aktuelle near final version wird nach erfolgreicher Absolvierung eines Balloting-Verfahrens wie auch andere Entwicklungen von HL7 als offizieller Standard durch die ANSI akkreditiert werden. Die Definition von HL7 besagt, dass ein Template folgendermaßen repräsentiert wird: durch eine formale Definition in einer oder mehrerer menschenlesbaren Sprachen oder Notationen (optional) durch ein Static Model (optional) durch eine oder mehrere implementierungsspezifische Repräsentationen, die zur Validierung von Instanzen in einem speziellen Kontext genutzt werden können Der Begriff Static Model wird im HL7 Kontext einerseits für das RIM verwendet und andererseits für alle Modelle, die Einschränkungen auf das RIM repräsentieren. Weiters werden auch Klassenmodelle und Schemata als Static Models bezeichnet. Im Kontext der Template Spezifikation wird der Begriff zur Beschreibung mehrerer Konzepte verwendet. Einerseits steht das Static Model für das Template selbst, welches eine Instanz des HL7 Template Modells (siehe Anhang) repräsentiert und die Einschränkungen der Klassen, Attribute und Assoziationen in einer maschinen-verwertbaren Sprache enthält. Weiters steht das Static Model für das HL7 Template Modell zur Erstellung von Templates und alle Modelle, die Einschränkungen auf das RIM anwenden, wie z.b. das Constrained Information Model (CIM) in Abbildung 10. In Abbildung 9 wird ein Modell eines Templates dargestellt, das einen Ausschnitt des in der Medizin verwendeten Barthel-Index (BI) darstellt, welcher zur Bewertung des funktionellen Status eines Patienten verwendet wird. Wird das Modell publiziert, wird dem Template ein template identifier (templateid) zugeordnet (z.b : REPC_RM000103), der aus einem OID (Object Identifier) und einem model identifier 34

39 2 THEORETISCHE GRUNDLAGEN zusammengesetzt wird. Ein OID ist eine weltweit eindeutige Nummer, die einen Knoten in einem hierarchisch zugewiesenen Namensraum repräsentiert. Knoten können an Institutionen weitergegeben werden, die zur eigenen Verwendung verwaltet werden und zur eindeutigen Identifikation Objekten zugeordnet werden können. Ein Template schränkt immer ein zugehöriges allgemeineres Modell ein. Im Fall des Barthel-Index wurde das CIM aus Abbildung 10 näher spezifiziert. Das Beispiel-CIM ist ein sehr generisch gehaltenes Modell, das auf dem clinical statement pattern basiert (siehe Kapitel ). Es besteht aus einer Klasse Observation, welche components enthalten kann, die wiederum Observations darstellen. Abbildung 9: Modell des "Barthel-Index", übernommen aus [33] 35

40 2 THEORETISCHE GRUNDLAGEN Abbildung 10: Constraint Information Modell, übernommen aus [33] Ein Template wird als einfaches XML-Dokument gespeichert, welches zusätzlich noch eine Repräsentation durch ein statisches Modell und Metadaten beinhalten kann. Die Liste der Metadaten wurde gemeinsam mit dem Europäischen Normungsinstitut (CEN) erstellt, um in Zukunft die Möglichkeit zu wahren, HL7 Templates und CEN Archetypen in gemeinsamen Registern speichern und verwalten zu können. Metadaten beschreiben das Template und ermöglichen eine einfachere Wiederfindung und Wiederverwendung (Reuse) derselben. Einige zwingende Attribute der Metadaten sollen in den folgenden Punkten angeführt werden: id: ermöglicht eine eindeutige, jedoch nicht-semantische Identifikation name: der Name des Templates in Freitext intention: der Zweck des Templates in Freitext beschrieben derivationmodelid: die eindeutige Id des Modells, das durch das Template eingeschränkt wird 36

41 2 THEORETISCHE GRUNDLAGEN referencemodelid: die eindeutige Id des Referenzmodells, von welchem das Template abgeleitet wird (im HL7-Kontext immer das RIM) publicationstatus: kann Draft, Not For Use, For Production Use, Withdrawn oder Superseded sein Der XML-Code eines Templates basiert auf einem UML-Diagramm, das in Kapitel 5.4 näher beschrieben wird. Templates stellen eine formale Definition eines medizinischen Konzepts dar. Ein Beispiel für die Anwendung eines klinischen Templates ist ein Laborbericht, in dem Templates seine spezifische Form bestimmen können wie z.b. ein Complete Blood Count (CBC), der Auskunft über die Zellen im Blut gibt. HL7 Templates können entweder flach oder tief strukturiert werden. Tiefe Templates enthalten alle nötigen Klassen, Attribute und Assoziationen, die zur Beschreibung einer bestimmten Anwendung vonnöten sind. Ein einfaches Beispiel für ein tiefes Template findet sich in Abbildung 9. Flache Templates basieren auf der Idee, bestehende Komponenten wieder zu verwenden. Als wiederverwendbare Komponenten kommen dabei so genannte Common Message Element Types (CMETs) zum Einsatz, auf die vom flachen Template aus verwiesen wird (siehe Abbildung 11). Vorteile von tiefen Templates: Sie sind vollständig und daher einfacher zu verstehen Die Verarbeitung kann einfacher und schneller erfolgen Vorteil von flachen Templates: Die Wiederverwendung wird gewährleistet In der Praxis wird man sich häufig für eine Kombination der beiden Konzepte entscheiden. 37

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

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

Mehr

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

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

erezept und Dokumenten-Kommunikation

erezept und Dokumenten-Kommunikation erezept und Dokumenten-Kommunikation...mit der Clinical Document Architecture Dr. med. Kai U. Heitmann Heitmann Consulting & Services (NL) Universität zu Köln (DE) Stellvertretender Vorsitzender HL7-Benutzergruppe

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

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

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

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

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

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

Mehr

GI-Technologien zur Umsetzung der EU-Wasserrahmenrichtlinie (WRRL): Wissensbasen. Teil 1: Einführung: Wissensbasis und Ontologie.

GI-Technologien zur Umsetzung der EU-Wasserrahmenrichtlinie (WRRL): Wissensbasen. Teil 1: Einführung: Wissensbasis und Ontologie. GI-Technologien zur Umsetzung der EU-Wasserrahmenrichtlinie (WRRL): Wissensbasen Teil 1: Einführung: Wissensbasis und Ontologie Was ist eine Wissensbasis? Unterschied zur Datenbank: Datenbank: strukturiert

Mehr

Stellungnahme. E-Government-Standards Seite 1 von 6. Dokument:...eCH-0108. Version:...1.0 ech-kategorie:...standard. Datum der Eingabe:...04.05.

Stellungnahme. E-Government-Standards Seite 1 von 6. Dokument:...eCH-0108. Version:...1.0 ech-kategorie:...standard. Datum der Eingabe:...04.05. E-Government-Standards Seite 1 von 6 Stellungnahme Dokument:...eCH-0108 Version:...1.0 ech-kategorie:...standard Datum der Eingabe:...04.05.2010 Koordinaten Vernehmlassungsteilnehmer/In: Organisation:

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Medical Data Models Ein offenes Repository Medizinscher Formulare

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

Mehr

Barrierefreie Webseiten erstellen mit TYPO3

Barrierefreie Webseiten erstellen mit TYPO3 Barrierefreie Webseiten erstellen mit TYPO3 Alternativtexte Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für Bilder. In der Liste der HTML 4-Attribute

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,

Mehr

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

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

Mehr

Ü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

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Bausteine für zukünftige HL7- Hausstandards. Kraska D, Wentz B, Prokosch HU Medizinisches IK-Zentrum; Universitätsklinikum Erlangen

Bausteine für zukünftige HL7- Hausstandards. Kraska D, Wentz B, Prokosch HU Medizinisches IK-Zentrum; Universitätsklinikum Erlangen Bausteine für zukünftige HL7- Hausstandards Kraska D, Wentz B, Prokosch HU Medizinisches IK-Zentrum; Universitätsklinikum Erlangen Einleitung Health Level entwickelt seit 1988 Nachrichtenstandards für

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

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

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

Mehr

«Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen

«Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen 18 «Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen teilnimmt und teilhat.» 3Das Konzept der Funktionalen

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

Software-Validierung im Testsystem

Software-Validierung im Testsystem Software-Validierung im Testsystem Version 1.3 Einleitung Produktionsabläufe sind in einem Fertigungsbetrieb ohne IT unvorstellbar geworden. Um eine hundertprozentige Verfügbarkeit des Systems zu gewährleisten

Mehr

Die itsystems Publishing-Lösung

Die itsystems Publishing-Lösung Die itsystems Publishing-Lösung www.itsystems.ch 1/6 Inhaltsverzeichnis 1 Publishing-Portal Funktionsübersicht... 3 1.1 Umfang des itsystems Portal... 3 1.2 Portal-Lösungsübersicht... 4 www.itsystems.ch

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf

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

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

Sehr geehrte Faktor-IPS Anwender,

Sehr geehrte Faktor-IPS Anwender, März 2014 Faktor-IPS 3.11 Das neue Release Faktor-IPS 3.11 steht Ihnen zum Download zur Verfügung. Wir informieren Sie über die neusten Feautres. Lesen Sie mehr Sehr geehrte Faktor-IPS Anwender, Auf faktorzehn.org

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

Adami CRM - Outlook Replikation User Dokumentation

Adami CRM - Outlook Replikation User Dokumentation Adami CRM - Outlook Replikation User Dokumentation Die neue Eigenschaft der Adami CRM Applikation macht den Information Austausch mit Microsoft Outlook auf vier Ebenen möglich: Kontakte, Aufgaben, Termine

Mehr

Bundeskanzlei BK Programm GEVER Bund. als Basis für GEVER. 29. November 2012

Bundeskanzlei BK Programm GEVER Bund. als Basis für GEVER. 29. November 2012 Bundeskanzlei BK Programm GEVER Bund Geschäftsprozesse als Basis für GEVER 29. November 2012 Zielsetzung der Präsentation Sie erhalten einen Überblick über den Stand der Entwicklung von GEVER als Geschäftsverwaltungssystem

Mehr

Benutzerhandbuch für die Verwendung des viavac HL7 Forcast Webservices (VAC-CDSS)

Benutzerhandbuch für die Verwendung des viavac HL7 Forcast Webservices (VAC-CDSS) Benutzerhandbuch für die Verwendung des viavac HL7 Forcast Webservices (VAC-CDSS) Inhaltsverzeichnis Zweck des Dokuments... 2 Verwendung des Dokuments... 2 Referenzierte Dokumente... 2 Übersicht...3 Allgemeine

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

Erstellung eines Verfahrensverzeichnisses aus QSEC

Erstellung eines Verfahrensverzeichnisses aus QSEC Erstellung eines Verfahrensverzeichnisses aus QSEC Im QSEC-Reporting-Modul steht ab der Version 4.2 ein neuer Bericht zur Verfügung. Es besteht nun die Möglichkeit, einen BDSG-konformen Datenschutzbericht

Mehr

Der HL7 basierte Standard für einen elektronischen Pflegebericht. Ursula Hübner Daniel Flemming Carsten Giehoff

Der HL7 basierte Standard für einen elektronischen Pflegebericht. Ursula Hübner Daniel Flemming Carsten Giehoff Der HL7 basierte Standard für einen elektronischen Pflegebericht Ursula Hübner Daniel Flemming Carsten Giehoff Einleitung: Ausgangslage Steigende Zahl an pflegebedürftigen Menschen Zunehmende Vernetzung

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

Medical Data Models Ein offenes Repository Medizinscher Formulare

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

Mehr

TYPO3 Super Admin Handbuch

TYPO3 Super Admin Handbuch TYPO3 Super Admin Handbuch Erweiterung News Für das System der Maria Hilf Gruppe Version 02 09.03.10 Erstellt durch: NCC Design Florian Kesselring Zeltnerstraße 9 90443 Nürnberg 1 Inhaltsverzeichnis Inhalt

Mehr

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos in Verbindung mit der Webshopanbindung wurde speziell auf die Shop-Software shop to date von DATA BECKER abgestimmt. Mit

Mehr

Dok.-Nr.: Seite 1 von 6

Dok.-Nr.: Seite 1 von 6 Logo Apotheke Planung, Durchführung und Dokumentation von QM-Audits Standardarbeitsanweisung (SOP) Standort des Originals: Dok.-Nr.: Seite 1 von 6 Nummer der vorliegenden Verfaßt durch Freigabe durch Apothekenleitung

Mehr

Professionelle Seminare im Bereich MS-Office

Professionelle Seminare im Bereich MS-Office Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion

Mehr

Techniken der Projektentwicklungen

Techniken der Projektentwicklungen Von der Analyse zum Entwurf 5. Termin Vom Use Case zum Domänenmodell Bis zum nächsten Mal Vom Use Case zum Domänenmodell Vom Use Case zum Domänenmodell Was ist ein Domänenmodell? Graphische Beschreibung

Mehr

GPP Projekte gemeinsam zum Erfolg führen

GPP Projekte gemeinsam zum Erfolg führen GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.

Mehr

.. für Ihre Business-Lösung

.. für Ihre Business-Lösung .. für Ihre Business-Lösung Ist Ihre Informatik fit für die Zukunft? Flexibilität Das wirtschaftliche Umfeld ist stärker den je im Umbruch (z.b. Stichwort: Globalisierung). Daraus resultierenden Anforderungen,

Mehr

Sonstige Marktregeln Gas

Sonstige Marktregeln Gas Sonstige Marktregeln Gas Kapitel 7 Elektronischer Austausch von Netzabrechnungsdaten Marktregeln Gas 2013 Version 1.0 Dokument-Historie Version Release Veröffentlichung Inkrafttreten Anmerkungen 1 0 20.09.2013

Mehr

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem

Mehr

Energetische Klassen von Gebäuden

Energetische Klassen von Gebäuden Energetische Klassen von Gebäuden Grundsätzlich gibt es Neubauten und Bestandsgebäude. Diese Definition ist immer aktuell. Aber auch ein heutiger Neubau ist in drei (oder vielleicht erst zehn?) Jahren

Mehr

Arbeiten mit UMLed und Delphi

Arbeiten mit UMLed und Delphi Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf

Mehr

Grundzüge der Programmierung. Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN

Grundzüge der Programmierung. Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN Grundzüge der Programmierung Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN Inhalt dieser Einheit JAVA ist objektorientiert! Grundbegriffe der objektorientierten Programmierung:

Mehr

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten Das große x -4 Alles über das Wer kann beantragen? Generell kann jeder beantragen! Eltern (Mütter UND Väter), die schon während ihrer Elternzeit wieder in Teilzeit arbeiten möchten. Eltern, die während

Mehr

Nach der Anmeldung im Backend Bereich landen Sie im Kontrollzentrum, welches so aussieht:

Nach der Anmeldung im Backend Bereich landen Sie im Kontrollzentrum, welches so aussieht: Beiträge erstellen in Joomla Nach der Anmeldung im Backend Bereich landen Sie im Kontrollzentrum, welches so aussieht: Abbildung 1 - Kontrollzentrum Von hier aus kann man zu verschiedene Einstellungen

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

P030 The Open Group Architecture Framework (TO-GAF) als Unternehmensarchitektur Methode für die Bundesverwaltung

P030 The Open Group Architecture Framework (TO-GAF) als Unternehmensarchitektur Methode für die Bundesverwaltung Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB P030 The Open Group Architecture Framework (TO-GAF) als Unternehmensarchitektur Methode für die Bundesverwaltung Klassifizierung:

Mehr

Hilfe Bearbeitung von Rahmenleistungsverzeichnissen

Hilfe Bearbeitung von Rahmenleistungsverzeichnissen Hilfe Bearbeitung von Rahmenleistungsverzeichnissen Allgemeine Hinweise Inhaltsverzeichnis 1 Allgemeine Hinweise... 3 1.1 Grundlagen...3 1.2 Erstellen und Bearbeiten eines Rahmen-Leistungsverzeichnisses...

Mehr

Stellen Sie bitte den Cursor in die Spalte B2 und rufen die Funktion Sverweis auf. Es öffnet sich folgendes Dialogfenster

Stellen Sie bitte den Cursor in die Spalte B2 und rufen die Funktion Sverweis auf. Es öffnet sich folgendes Dialogfenster Es gibt in Excel unter anderem die so genannten Suchfunktionen / Matrixfunktionen Damit können Sie Werte innerhalb eines bestimmten Bereichs suchen. Als Beispiel möchte ich die Funktion Sverweis zeigen.

Mehr

(1) Mit dem Administrator Modul werden die Datenbank, Gruppen, Benutzer, Projekte und sonstige Aufgaben verwaltet.

(1) Mit dem Administrator Modul werden die Datenbank, Gruppen, Benutzer, Projekte und sonstige Aufgaben verwaltet. 1 TimeTrack! TimeTrack! Ist ein Softwareprodukt von The Project Group, welches der Erfassung von Ist- Aufwänden von Projekten dient. Voraussetzung hierfür ist allerdings, dass das Projekt vorher mit Microsoft

Mehr

Infrastruktur: Vertrauen herstellen, Zertifikate finden

Infrastruktur: Vertrauen herstellen, Zertifikate finden TeleTrusT Bundesverband IT-Sicherheit e.v. Infrastruktur: Vertrauen herstellen, Zertifikate finden Allgemeines zur TeleTrusT EBCA Seit 2001 Zusammenschluss einzelner, gleichberechtigter n zu -Verbund einfacher,

Mehr

D i e n s t e D r i t t e r a u f We b s i t e s

D i e n s t e D r i t t e r a u f We b s i t e s M erkblatt D i e n s t e D r i t t e r a u f We b s i t e s 1 Einleitung Öffentliche Organe integrieren oftmals im Internet angebotene Dienste und Anwendungen in ihre eigenen Websites. Beispiele: Eine

Mehr

CNAME-Record Verknüpfung einer Subdomain mit einer anderen Subdomain. Ein Alias für einen Domainnamen.

CNAME-Record Verknüpfung einer Subdomain mit einer anderen Subdomain. Ein Alias für einen Domainnamen. Seite 1 von 5 Nameserver Fragen zu den Nameservereinstellungen df FAQ Technische FAQ Nameserver Welche Nameserver-Records stehen zur Verfügung? Bei domainfactory können folgende Nameservereinträge erstellt

Mehr

How to do? Projekte - Zeiterfassung

How to do? Projekte - Zeiterfassung How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...

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

Standard XPersonenstand - Version 1.4.3 - Verbindliche Handlungsanweisungen

Standard XPersonenstand - Version 1.4.3 - Verbindliche Handlungsanweisungen Standard XPersonenstand - Version 1.4.3 - Verbindliche Handlungsanweisungen Stand: 19. September 2013 1 Mit diesem Dokument werden verbindliche Handlungsanweisungen für die Implementierung des Standards

Mehr

News & RSS. Einleitung: Nachrichten er-(veröffentlichen) und bereitstellen Nachrichten erstellen und bereitstellen

News & RSS. Einleitung: Nachrichten er-(veröffentlichen) und bereitstellen Nachrichten erstellen und bereitstellen News & RSS Nachrichten er-(veröffentlichen) und bereitstellen Nachrichten erstellen und bereitstellen Einleitung: Sie wollen Ihre Nutzer immer mit den neuesten Informationen versorgen bzw. auf dem laufendem

Mehr

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte

Mehr

Skript Pilotphase em@w für Arbeitsgelegenheiten

Skript Pilotphase em@w für Arbeitsgelegenheiten Die Pilotphase erstreckte sich über sechs Meilensteine im Zeitraum August 2011 bis zur EMAW- Folgeversion 2.06 im August 2013. Zunächst einmal musste ein grundsätzliches Verständnis für das Verfahren geschaffen

Mehr

C++11 C++14 Kapitel Doppelseite Übungen Musterlösungen Anhang

C++11 C++14 Kapitel Doppelseite Übungen Musterlösungen Anhang Einleitung Dieses Buch wendet sich an jeden Leser, der die Programmiersprache C++ neu lernen oder vertiefen möchte, egal ob Anfänger oder fortgeschrittener C++-Programmierer. C++ ist eine weitgehend plattformunabhängige

Mehr

DOKUMENTATION PASY. Patientendaten verwalten

DOKUMENTATION PASY. Patientendaten verwalten DOKUMENTATION PASY Patientendaten verwalten PASY ist ein Programm zur einfachen und zuverlässigen Verwaltung von Patientendaten. Sämtliche elektronisch gespeicherten Dokumente sind sofort verfügbar. Neue

Mehr

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

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

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

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

Mehr

Wo sind meine Anforderungen?

Wo sind meine Anforderungen? Whitepaper Telekommunikation Wo sind meine Anforderungen? Eine effektive Lösung auf Basis von Confluence und JIRA 2011 SYRACOM AG 1 Einleitung Erfahrene Projektmitarbeiter sehen sich oftmals im Projektalltag

Mehr

1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage:

1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage: Zählen und Zahlbereiche Übungsblatt 1 1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage: Für alle m, n N gilt m + n = n + m. in den Satz umschreiben:

Mehr

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv Roboter programmieren mit NXC für Lego Mindstorms NXT 1. Auflage Roboter programmieren mit NXC für Lego Mindstorms NXT schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv Verlag

Mehr

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla BlaBla Diese Kennzeichnungen sind nur Erläuterungen und nicht Bestandteil des Diagramms Quelle: P.Grässle, H.Baumann, P.Baumann, UML projektorientiert, Galileo Verlag, 2003 21 Primäre Begriffe Kapselung

Mehr

Key Management für ETCS

Key Management für ETCS Key Management für ETCS Betrieblich-technische Kundenveranstaltung 2014 DB Netz AG, Informationssysteme Kundeninteraktion/Vertrieb (I.NVT 65) 16.05.2014 1 DB Netz AG Niels Neuberg, Stefan Seither I.NVT

Mehr

Wir entwickeln Medical-IT-Lösungen für die Aufgaben von heute und die Anforderungen von morgen!

Wir entwickeln Medical-IT-Lösungen für die Aufgaben von heute und die Anforderungen von morgen! Wir entwickeln Medical-IT-Lösungen für die Aufgaben von heute und die Anforderungen von morgen! Mission Die MEDNOVO Medical Software Solutions GmbH verbindet die Informationstechnologie und Medizintechnik

Mehr

Einleitung: Frontend Backend

Einleitung: Frontend Backend Die Internetseite des LSW Deutschland e.v. hat ein neues Gesicht bekommen. Ab dem 01.01.2012 ist sie in Form eines Content Management Systems (CMS) im Netz. Einleitung: Die Grundlage für die Neuprogrammierung

Mehr

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken.

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken. In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access Die Grundlagen der Datenbanken kurspc15 Inhaltsverzeichnis Access... Fehler! Textmarke nicht

Mehr

Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH

Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH Amt für Informatik Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH Anleitung vom 12. September 2009 Version: 1.0 Ersteller: Ressort Sicherheit Zielgruppe: Benutzer von SSLVPN.TG.CH Kurzbeschreib:

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr

Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.

Vermeiden Sie es sich bei einer deutlich erfahreneren Person dranzuhängen, Sie sind persönlich verantwortlich für Ihren Lernerfolg. 1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich

Mehr

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Informationssysteme Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Definitionen: Informationen Informationssysteme

Mehr

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Tutorial: Wie erfasse ich einen Termin? In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Neben den allgemeinen Angaben zu einem

Mehr

Novell Client. Anleitung. zur Verfügung gestellt durch: ZID Dezentrale Systeme. Februar 2015. ZID Dezentrale Systeme

Novell Client. Anleitung. zur Verfügung gestellt durch: ZID Dezentrale Systeme. Februar 2015. ZID Dezentrale Systeme Novell Client Anleitung zur Verfügung gestellt durch: ZID Dezentrale Systeme Februar 2015 Seite 2 von 8 Mit der Einführung von Windows 7 hat sich die Novell-Anmeldung sehr stark verändert. Der Novell Client

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf

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

Mehr

Standard Inhaltsverzeichnis für Testvorschrift

Standard Inhaltsverzeichnis für Testvorschrift Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2

Mehr

CGM JESAJANET Zuweiserportal 3.1.0 Einrichtung des Konfigurationsassistenten und der Benachrichtigungen

CGM JESAJANET Zuweiserportal 3.1.0 Einrichtung des Konfigurationsassistenten und der Benachrichtigungen CGM JESAJANET Zuweiserportal 3.1.0 Einrichtung des Konfigurationsassistenten und der Benachrichtigungen CGM JESAJANET Zuweiserportal 3.1 - Einrichtung Konfigurationsassistent und der Benachrichtigungen

Mehr

Anforderungen an die HIS

Anforderungen an die HIS Anforderungen an die HIS Zusammengefasst aus den auf IBM Software basierenden Identity Management Projekten in NRW Michael Uebel uebel@de.ibm.com Anforderung 1 IBM Software Group / Tivoli Ein Feld zum

Mehr

Content Management System mit INTREXX 2002.

Content Management System mit INTREXX 2002. Content Management System mit INTREXX 2002. Welche Vorteile hat ein CM-System mit INTREXX? Sie haben bereits INTREXX im Einsatz? Dann liegt es auf der Hand, dass Sie ein CM-System zur Pflege Ihrer Webseite,

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Mengen Mittlere

Mehr

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität

Mehr