Ehscda:CDA-CH-EMED-PRE

From eHealth Suisse
Jump to: navigation, search





Impressum

Autoren Hans Muster (eHealthFirma);x2;...

Identifikation dieses Dokuments
Abkürzung: aName
OID: anOid)

Zweck und Positionierung
Gleichstellung von Mann und Frau

Zusammenfassung

Emed-pre:Zusammenfassung


Einleitung

Emed-pre:AusgangslageMotivation

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Das vorliegende Dokument beschreibt den Inhalt von „CDA-CH-EMED-PRE“ und definiert damit ein einheitliches Austauschformat für den Informationsaustausch im Gesundheitswesen Schweiz. Es enthält den Text wie er vom Projektteam erarbeitet wurde und beinhaltet die normative Spezifikation basierend auf HL7 CDA. Dieses Austauschformat ist nach einer breiten Anhörung als nationaler Standard durch eHealth Suisse zur Verwendung empfohlen.


Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Das vorliegende Austauschformat richtet sich an Behandelnde, Hersteller und Lieferanten von Software und Systemen sowie alle weiteren Gesundheitsfachpersonen, welche sich mit vorliegendem Thema befassen.

ICT-Fachleute finden im Kapitel #Spezifikation (normativ) die normative Spezifikation und im Kapitel #Validierung, Technologien und Tools Verweise auf Dokumente zu Technologien und Tools zur Validierung sowie weitere Hilfsunterlagen (sogenannte „Supporting Documents“). Eine Beschreibung der Anwendungsfälle findet sich in Kapitel #Anwendungsfälle.


Ziele und Abgrenzungen

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Eine sinnvolle Umsetzung elektronischer Meldungen bedingt Interoperabilität der beteiligten Systeme. Die "HL7 EHR Interoperability Work Group" hat Interoperabilität unterteilt in folgende Stufen[Anmerkung 1] :

  • Technische Interoperabilität
  • Semantische Interoperabilität
  • Prozessinteroperabilität

Technisch interoperabel sind Systeme, die miteinander Daten austauschen können. Semantische Interoperabilität bedeutet, dass die Information vom empfangenen System richtig interpretiert werden kann. Die Prozessinteroperabilität befasst sich mit der Integration der Systeme in den Arbeitsablauf.

Das vorliegende Austauschformat beinhaltet die Spezifikationen für die semantische Interoperabilität von Systemen im Zusammenhang mit "CDA-CH-EMED-PRE".

Die technische Interoperabilität ist eine Voraussetzung dafür, dass die semantische Interoperabilität zum Tragen kommt. Sie beinhaltet unter anderem den Transportmechanismus von Meldungen. Dieses Austauschformat macht zum Transportmechanismus keine Vorgaben.

Kapitel #Anwendungsfälle zeigt relevante Anwendungsfälle und gibt Hinweise für eine geeignete Implementation. Den Hinweisen liegen Überlegungen zur Prozessinteroperabilität zugrunde. Vorgaben und eine vertiefte Behandlung der Prozessinteroperabilität sind jedoch nicht Gegenstand dieses Dokuments.

Emed-pre:Ziele Emed-pre:Abgrenzungen

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die Anwendungsfälle rund um "CDA-CH-EMED-PRE" lassen sich nach den Empfehlungen der Strategie eHealth Schweiz umsetzen. Die elektronischen Informationen dazu sollen im elektronischen Patientendossier zugänglich sein und den Beteiligten eine elektronische Verarbeitung ermöglichen.
Das vorliegende Austauschformat basiert auf Integrationsprofilen der IHE und der HL7 Clinical Document Architecture (CDA). Siehe auch Kapitel #Bezug zu anderen Standards und Leitfäden.

Emed-pre:Verantwortlichkeiten


Formelle Grundlagen

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Im vorliegenden Dokument werden folgende verkürzte Darstellungen und visuelle Orientierungshilfen eingesetzt.

Notation Bedeutung Beispiel
XXXX alphanumerischer Platzhalter
[N/A] Not applicable (nicht anwendbar)
[XXXX] Angabe von referenzierten Dokumenten [VHitG Arzt-brief]
<XXXX> CDA Regelbezeichnung gemäss deutschem [VHitG Arztbrief] <TURS>
<CH-XXXX> Bezeichnung von zusätzlichen, schweizerischen CDA Regeln <CH-TZON>
[xx] Sprachdefinitionen:

de = Deutsch
fr = Französisch
it = Italienisch
en = Englisch

[de]
[XX] Optionalität (siehe auch Kapitel „7.1.3 Optionalität“ auf Seite 32):

M = Mandatory / Zwingend
NP = Not permitted / Nicht erlaubt
R = Required / Erforderlich
R2 = Required if known / Erforderlich, wenn bekannt
O = Optional / Erlaubt / Freiwillig
C = Conditional / Bedingt erforderlich

[O]
[X..X] Kardinalitäten:

0..1 = höchstens einmal
0..* = mehrfach ohne Mindestangabe
1..1 = genau einmal
1..* = einmal oder mehrfach

[1..*]

[Tabelle 1] Notationen in diesem Dokument


Emed-pre:BezugStandards

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

IHE (Integrating the Healthcare Enterprise) ist eine internationale Initiative zur Verbesserung des elektronischen Datenaustausches zwischen IT-Systemen im Gesundheitswesen. IHE erarbeitet sogenannte Integrationsprofile, welche definieren, wie bestehende Standards (z. B. HL7, DICOM) in Arbeitsabläufen anzuwenden sind, damit Informationssysteme unterschiedlicher Hersteller interoperabel und ohne Verlust von Informationen miteinander kommunizieren können. IHE wurde im Jahr 1998 in den USA ins Leben gerufen; Europa und Asien folgten kurz darauf. 2010 wurde IHE Suisse gegründet.

Dokumente, welche basierend auf IHE Inhaltsprofilen (Content Profiles) erstellt werden, können in der IHE Cross-enterprise document sharing Architektur (XDS.b) abgelegt, gemäss IHE Cross-Enterprise Document Reliable Interchange (XDR) an einen Empfänger gesendet oder wie von IHE Cross-Enterprise Document Media Interchange (XDM) vorgegeben auf ein Medium geschrieben und von dort wieder gelesen werden. Das IHE Integrationsprofil XDS.b ist im Übrigen die Basis für das verteilte elektronische Patientendossier (EPD) in der Schweiz.

Die, im vorliegenden Austauschformat referenzierten IHE Inhaltsprofile referenzieren auf HL7 CDA R2 als Basisstandard für Dokumenteninhalte.


Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

HL7 steht für "Health Level Seven" und bezeichnet einen internationalen Standard zum elektronischen Austausch von Daten im Gesundheitswesen. Die Zahl „7“ bezieht sich auf die siebte Schicht des OSI Modells und drückt damit aus, dass HL7 primär die Kommunikation auf der applikatorischen Ebene standardisiert. HL7 hat seinen Ursprung 1987 in den USA. Mittlerweile ist es eine kommerzielle Organisation (HL7.org), die HL7 heute in den Versionen 2.x, 3.0 und FHIR anbietet. Gleichzeitig ist HL7.org die Dachorganisation aller HL7 Benutzer und koordiniert deren Aktivitäten auch auf internationaler Ebene. HL7-Affiliates existieren inzwischen in über 30 Ländern, darunter auch in der Schweiz.

Das vorliegende Austauschformat baut auf HL7 Version 3 auf. Version 3 ist XML-basiert und fusst auf einem umfangreichen Objektmodell, dem Reference Information Model (RIM). Dieses Modell bildet die Grundlage für Standards wie die Clinical Document Architecture (CDA) und damit auch für dieses Austauschformat.


Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die HL7 Clinical Document Architecture ist ein offizieller ANSI und HL7 Standard mit gültiger Fassung R2 aus dem Jahr 2005. Die HL7 CDA R2 ist eine von mehr als 30 verschiedenen Domänen der HL7 V3 Standards-Familie, welche objektorientiert entworfen worden und im sogenannten HL7 Reference Information Model (RIM) dokumentiert ist.


Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Zusätzlich und nicht direkt in oben dargestellter Referenzpyramide integrierbar nimmt das vorliegende Dokument Bezug auf bereits bestehende Empfehlungen von „eHealth Suisse“ (eHealth Koordinationsorgan Bund/Kantone):
Standards & Architektur:

  • Empfehlungen I (Ausgabe 2009)[1]
  • Empfehlungen II (Ausgabe 2010)[2]
  • Empfehlungen III (Ausgabe 2011)[3]
  • Empfehlungen IV (Ausgabe 2013)[4]
  • Empfehlungen V (Ausgabe 2014)[5]
  • OID Konzept (Ausgabe 2011)[6]

Semantik & Metadaten:

  • Empfehlungen I (Ausgabe 2013)[7]

Insbesondere „Empfehlung 9: Orientierung an HL7 CDA als Dokumentenformat“.

Das vorliegende Austauschformat ist konform zu den oben genannten Empfehlungen von „eHealth Suisse“ und damit zur eHealth Strategie und Architektur in der Schweiz. Durch die Wahl von IHE und HL7 als technologische Basis sind entsprechend erstellte Dokumente zudem auch grenzüberschreitend interoperabel.



Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Diese Version des Dokuments ist in Deutsch und Französisch verfügbar.


Begriffsdefinitionen

Emed-pre:Begriffsdefinitionen


Anwendungsfälle

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die hier skizzierten Anwendungsfälle (UC = Use Case) beziehen sich auf Beispiele, wie sie heute bei den verschiedenen Akteuren im Schweizer Gesundheitswesen vorkommen, die mit dem vorliegenden Thema zu tun haben. Einige Anwendungsfälle werden erst möglich, wenn durch Import/Export-Mechanismen alle relevanten Informationen interoperabel fliessen können.

Ziel ist einerseits die Bereitstellung von Informationen zum Gesundheitszustand des Patienten in einer menschlich lesbaren Form für die am Behandlungspfad beteiligten Personen. Andererseits sollen durch die elektronische Verarbeitung der Informationen Prozesse in den ICT-Systemen optimiert werden können.
Nachfolgend beschriebene Anwendungsfälle verdeutlichen diese Zusammenhänge im vorliegenden Kontext.

Emed-pre:AnwendungsfaelleEinfuehrung Emed-pre:AnwendungsfaelleStoryboard

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die vorstehend beschriebenen Anwendungsfälle erfordern eine Kommunikation zwischen den Applikationen bei Sender und Empfänger. Bei der Implementierung ist zwischen medizinischem bzw. fachlichem Inhalt (Content) und eigentlichem Transport dieser Inhalte (Communication) zu unterscheiden.

Ehscda trsp mech.png

Ehscda trsp mech.png

[Abbildung 1] Communication vs. Content

Das vorliegende Dokument spezifiziert den Inhalt (Content). Die Spezifikation des Transportweges ist nicht Teil dieses Dokumentes.

Empfehlung zum Transportmechanismus

Der Inhalt (Content), der mit vorliegendem Dokument spezifiziert wird, soll mit sogenannten Metadaten (Angaben zum Typ, Inhalt, Autor, Empfänger, Patient, etc.) angereichert werden und als Paket (Dokument plus Metadaten) über einen sicheren Kanal übertragen werden. Dazu eignen sich folgende Transaktionen aus dem IHE IT Infrastructure Technical Framework:

  • Cross-Enterprise Document Media Interchange (XDM)
    • Distribute Document Set on Media [ITI-32]
  • Cross-Enterprise Document Reliable Interchange (XDR)
    • Provide and Register Document Set-b [ITI-41]
  • Cross-Enterprise Document Sharing (XDS.b)
    • Provide and Register Document Set-b [ITI-41]
    • Registry Stored Query [ITI-18]
    • Retrieve Document Set [ITI-43]

Diese Transaktionen sind auch Rahmen des elektronischen Patientendossiers (EPD) anwendbar.


Spezifikation (normativ)

Emed-pre:SpezifikationIntro

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Ein Dokument, welches anhand dieser Spezifikation erstellt wird, ist ein HL7 CDA Dokument und damit ein definiertes und komplettes Informationsobjekt, das Texte, Bilder und andere multimediale Objekte enthalten kann. CDA Dokumente dokumentieren den Gesundheitszustand eines Patienten zu einem bestimmten Zeitpunkt. Sie enthalten administrative (Header) und medizinische (Body) Daten und sind mittels eXtensible Markup Language (XML) kodiert.

Die normative Spezifikation definiert das Dokument „CDA-CH-EMED-PRE“ als HL7 CDA Vorlage, welche helvetische Präzisierungen für den CDA Header festlegt. Damit produzierte Dokumente sind vollständig kompatibel zum internationalen HL7 CDA R2 Standard (Normative Edition 2005) und somit international interoperabel.

Die normative Spezifikation bezweckt, dass Systeme für das Handling von Informationen im CDA Header durch die Softwarehersteller unabhängig von Sender und Empfänger implementiert werden können.

Die vorliegende Spezifikation wurde in ART-DECOR modelliert und daraus können auch Schematron-Regeln generiert werden, welche eine automatisierte und harmonisierte Validierung der CDA-Dokumente erlauben.

Schlüsselwörter

Die normative Spezifikation verwendet folgende, jeweils in Grossbuchstaben geschriebene Schlüsselwörter zu Angabe von Verbindlichkeiten. Siehe auch [ELGA Allgemein], Kap. 4.1 resp. RFC 2119.

MUSS (engl. MUST) bedeutet eine verpflichtend einzuhaltende Vorschrift. Entspricht der Optionalität [R] und [M].

NICHT ERLAUBT (engl. NOT PERMITTED) formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht der Optionalität [NP].

SOLL oder EMPFOHLEN (engl. SHOULD) steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht der Optionalität Required [R]. Wenn kein Wert angegeben werden kann, MUSS nullFlavor angegeben werden.

KANN oder OPTIONAL (engl. MAY, OPTIONAL). Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Optionalität [O].

Optionalität

Nachfolgende Tabelle legt die Verwendung von zwingenden, empfohlenen und optionalen Elementen und den dazu gehörenden Kardinalitäten inkl. Verwendung von nullFlavor normativ fest. Die nachfolgende Definition wurde aus IHE Technical Frameworks General Introduction, Appendix E: Standards Profiling and Documentation Conventions, Revision 1.0, July 1, 2014, "Table E.4.2.2.1-1: Data Element Optionality Constraints" übernommen und mit dem Element [NP] ergänzt.

Optionalitäten Mögliche Kardinalitäten Verwendung von nullFlavor Beschreibung
[M] 1..1

1..*

NICHT ERLAUBT Das Element MUSS mit einem korrekten "echten" Wert angegeben werden.

nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.

[NP] 0..0 NICHT ERLAUBT Element ist NICHT ERLAUBT.
[R] 1..1

1..*

KANN verwendet werden Das Element MUSS in der Instanz vorhanden sein. Wenn nicht bekannt, ist die Verwendung von nullFlavor vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
[O] 0..1

0..*

KANN verwendet werden Das Element ist OPTIONAL. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird.
[C] [N/A] [N/A] KONDITIONALES Optionalität. Die Optionalität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen. Die konkreten Abhängigkeiten sind jeweils angegeben.

[Tabelle 2] Notationen in diesem Dokument

nullFlavor

Wenn ein Wert nicht bekannt ist, kann dort wo es gemäss obenstehender Tabelle erlaubt ist, mit den nullFlavor-Codes in #HL7 NullFlavor der Grund für die fehlende Angabe präzisiert werden. Wird ein nullFlavor eingesetzt, DÜRFEN mit Ausnahme von xsi:type KEINE weiteren Attribute angegeben werden.

Emed-pre:HierarchieSpezifikationen Emed-pre:AkteureTransaktionen


TODO Document Level Template


CDA Header

TODO Header Level Templates


CDA Body

TODO Body Level Templates TODO Entry Level Templates


Codes und Wertebereiche

Sonderfälle

OID IVR und eCH bereinigen und implementieren!


Id2.16.756.5.30.1.127.11.10Effective Date2017‑06‑12 14:27:43
StatusKyellow.png DraftVersion Label
NameSonderfaellebeifehlendenangabenDisplay NameSpecial case missing Information (nullFlavor)
Source Code System
2.16.840.1.113883.5.1008 - Null Flavor
Level/ TypeCodeCode System

0‑L
ASKU
asked but unknown
Null Flavor
0‑L
MSK
masked
Null Flavor
0‑L
NA
not applicable
Null Flavor
0‑L
NASK
not asked
Null Flavor
0‑L
NAV
temporarily unavailable
Null Flavor
0‑L
OTH
other
Null Flavor
0‑L
UNK
unknown
Null Flavor
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.


Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Dieser Themenbereich wurde zwecks Wiederverwendbarkeit in verschiedenen Austauschformaten basierend auf CDA-CH in ein eigenständiges Dokument ausgelagert. Es wird auf das Whitepaper CDA-CH - Validierung, Technologien und Tools verwiesen.
Ausserdem enthält auch die Spezifikation CDA-CH-II (2011) ein Schematron Tutorial und Informationen zu Best Practices.
Hinweis: Obschon CDA-CH-II (2011) mit der Genehmigung von CDA-CH V2 (2017) ausser Kraft gesetzt wird, bleiben dort rein informativ lesenswert:

  • Kapitel "8 Schematron Tutorial"
  • Kapitel "9 Schematron Best Practices"

Anmerkungen

  1. HL7 Interoperability Work Group. Coming To Terms - Scoping Interoperability for Health Care. 2007; Siehe auch: http://www.hln.com/assets/pdf/Coming-to-Terms-February-2007.pdf

Referenzierte Dokumente

  1. eHealth Suisse - Empfehlungen I "Standards und Architektur", verabschiedet am 19. März 2009, http://goo.gl/EjZ2G,
  2. eHealth Suisse - Empfehlungen II "Standards und Architektur", verabschiedet am 21. Oktober 2010, http://goo.gl/2KloM
  3. eHealth Suisse - Empfehlungen III "Standards und Architektur", verabschiedet am 27. Oktober 2011, http://goo.gl/hMevI
  4. eHealth Suisse - Empfehlungen IV "Standards und Architektur", verabschiedet am 17. Januar 2013, http://goo.gl/0OBQD
  5. eHealth Suisse - Empfehlungen V "Standards und Architektur", verabschiedet am 28. August 2014, http://goo.gl/wRzD0v
  6. eHealth Schweiz - OID-Konzept für das Schweizerische Gesundheitswesen, 24. März 2010, http://goo.gl/x534f
  7. eHealth Suisse - Empfehlungen I "Semantik und Metadaten", verabschiedet am 17. Januar 2013, http://goo.gl/S6nnz

Abkürzungen und Glossar

Abbildungen

  1. Communication vs. Content

Tabellen

  1. Notationen in diesem Dokument
  2. Notationen in diesem Dokument