CDA für die elektronische Fallakte
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden CDA für die elektronische Fallakte (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
March 2012
Jörg Caumanns
| Version: | 0.9 |
| Datum: | March 2012 |
| Status: | xxx |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
As part of the »eCR in a Box« specification, the eFA-Verein defined an interface for encoding eCR management operations within HL7v2 CDA documents. Due to the modular approach of this work a strong separation among eCR-specifc settings and general definions can be done. In December 2011 it was decided by eFA Verein and the German Interoperability Forum to extract the generic definitions from the eCR specification and to provide it as input for stan-dardization efforts of the national boards working in this field. During this process the Interoperability Forum will be responsible for organizing a commenting and approval process on be-half of HL7 Germany and IHE Germany.
Inhaltsverzeichnis
About electronic Case Records
The Electronic Case Record (eCR) is an initiative launched by the stationary sector - i.e. Ger-many’s hospitals and clinics - in 2006. Since 2009 it is operated by the Electronic CaseRecord Association (»Verein Elektronische Fall¬akte«), which is an interest group of major German hospitals, hospital chains, healthcare associations, and regional healthcare networks. Electronic case records provide a structured and integrated viewpoint of medical data that can be associated with an individual patient. A case begins with an initial diagnosis and integrates as many instances of billing or treatment as required. A physician oversees the eCR, with the various attending physicians having responsibility for the contents and their completeness. The decentralized handling and maintenance of case records is based on the metaphor of a supply network as a community of interest composed of autonomous actors working on a spe-cific task. Since it is generally preferred that the place, where medical data and administrative information (e.g. user accounts) is stored, remains constant, the case record can be imple-mented in existing networks very simply, facilitating the initiation of co-operation at the regional level.
eCR in a Box is an innovative deployment concept that introduces a plug&play capsule for eCR services. This capsule (»eCR Plugs«) decouples document sources from eCR services and allows for managing case records - including their scoping and permissions - on the ab-straction level of medical documents. By hiding most of the security services and privacy en-hancing technologies between rather simple client- and provider-side interfaces, eCR can be operated like a black box (»eCR Box«) that adds intelligent document sharing services to re-gional healthcare networks while being almost invisible to its users.
All eCR technical specifications and operation guidelines are open to the public at http://www.fallakte.de.
About eCR CDA Content Modules
This document provides a specification of Content Modules which normalize the use of German healthcare identifiers within medical documents. A Content Module is a template on a specific HL7v2 CDA entity such as a document, a section or an entry. The templates defined in this specification describe how an entity is to be used by document based services within the German healthcare system. E. g. the Patient Role Content Module consists of a template that defines how the new German Electronic Health Card is to be used for patient identification within medical documents.
Each template is identified by an OID. By assigning this OID as a <templateId> to a CDA en-tity, implementations of this entity are forced to comply with the template . An entity can be assigned multiple <templateId>s to denote compliance with multiple Content Modules. Content Modules can be profiles on already existing Content Modules by defining further constraints on that Content Module. Most of the Content Modules defined in this specification are profiles on Content Modules already defined in the IHE Patient Care and Coordination domain (IHE PCC).
All Content Modules templates defined in this specification are assigned an OID under the root 1.2.276.0.76.3.1.81.81.6.
The kind of entity which is profiled by the template is signaled by the following scheme:
| OID | Entity | Description |
|---|---|---|
| {root}.1 | Document | Document Content Module templates define constraints and conventions that MUST be followed by a document in order to be usable for the defined purpose. This specification does not include Document Content Modules as the respective eCR templates are closely bound to the eCR information model and therefore SHOULD NOT be reused for other puropses. Never-theless, specifications such as the »VHitG Arztbrief« fall into this category and SHOULD be referencable by a template identifier that fits into a general schema. |
| {root}.2 | Header Element | Header Content Modules define constraints and conventions for coding document participants and roles such as patients, care team members and guardians. |
| {root}.3 | Section | The purpose and content of medical document is encoded within different CDA document sections, e.g. diagnosis, consents and contracts, or visit references. Section Content Modules define how these sections MUST be used in order to be processable in an interoperable manner. Most of the defined sections allow for a CDA Level 2 encoding as well as for a Level 3 encoding. |
| {root}.4 | Entry | Acts and observations within a CDA Level 3 section are encoded as entries. Entry Content Modules define constraints on existing IHE PCC Entry Con-tent Modules in order to allow for an automatted processing of the respec-tive information. |
Related Documents
In addition, the following specifications are of particular relevance for the implementation, deployment, and operation of the Content Modules as specified in this document:
- HL7 CDA specification
- IHE PCC Technical Framework Vol. 1 and 2
Syntactical Conventions
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be inter-preted in accordance with [RFC2119].
All Content Modules specified in this document are defined by open templates; classes that are not constrained MAY be provided to the user’s own conventions.
The following example shows the conventions used in this document:
<element1> <templateId id='...'/> <templateId id='...'/> <element2> <element3 value='fixed'/><element4 value='...'/><element5> <element6 value='.....'/> </element5></element2> </element1>
- <element1>
- If an element is constraint by one or more templates, the respective OIDs are listed within <templateId> elements after the element.
- <element2>
- Elements shown in normal font weight MUST be present but are not profiled by this specification. Further attributes or sub-elements MAY be added to such elements as long as this does not conflict with the CDA schema and – if defined – other templates that are registered for the element.
- <element3>
- If a value is given for an attribute, this value is considered as fixed and MUST NOT be omitted or changed.
- <element4>
- Elements in red color are profiled by this specification. They MUST be used as defined in the text underneath the template.
- <element5>
- Elements that are optional for the base template but that MUST NOT be used within the German healthcare system are stroked out.
Header Content Modules
Patient Role Header Content Module
- CDA Content Module Specification: Patient Role Header Content Module
Assigned Human Entity Content Module
- CDA Content Module Specification: Assigned Human Entity Content Module
Assigned Organizational Entity Content Module
- CDA Content Module Specification: Assigned Organizational Entity Content Module
Custodian Organization Header Content Module
- CDA Content Module Specification: Custodian Organization Header Content Module
eCR Participating Healthcare Providers Content Module
- CDA Content Module Specification: eCR Participating Healthcare Providers Content Module
Section Content Modules
Consents and Contracts Section (1.2.276.0.76.3.1.81.81.6.3.1)
Entry Content Modules
Consent Directive Observation (1.2.276.0.76.3.1.81.81.6.4.1) Document Reference (1.2.276.0.76.3.1.81.81.6.4.4)
Codesystems
eCR Consent Authorization Code (1.2.276.0.76.3.1.81.81.5.1) eCR Participant Function Code (1.2.276.0.76.3.1.81.81.5.2) eCR Assigned Entity Code (1.2.276.0.76.3.1.81.81.5.3) eCR Encompassing Organizational Act (1.2.276.0.76.3.1.81.81.5.4)
German Profile: Instance Identifiers
Healthcare Professional Instance Identifiers Healthcare Professional Organization Instance Identifiers
