CDA für die elektronische Fallakte

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
Zeile 43: Zeile 43:
  
 
The kind of entity which is profiled by the template is signaled by the following scheme:
 
The kind of entity which is profiled by the template is signaled by the following scheme:
 +
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!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.
 +
|}

Version vom 10. März 2012, 16:56 Uhr


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.

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.