IG:CDA für die elektronische Fallakte

CDA für die elektronische Fallakte

CDA für die elektronische Fallakte

Implementierungsleitfaden

vorgelegt von:
March 2012
Jörg Caumanns

Draft

Version:	0.9
Datum:	March 2012
Status:	xxx
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2011-2012: HL7 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 standardization 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 behalf 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. Germany’s hospitals and clinics - in 2006. Since 2009 it is operated by the Electronic CaseRecord Association (»Verein Elektronische Fallakte«), 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 specific 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 implemented 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 abstraction level of medical documents. By hiding most of the security services and privacy enhancing 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 regional 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 entity, 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. Nevertheless, 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 Content Modules in order to allow for an automatted processing of the respective information.

Related Documents

In addition, the following specifications and guidelines are of particular relevance for the implementation, deployment, and operation of eCR CDA Content Modules:

• HL7 CDA Release 2
• CDA for Common Document Types History and Physical Notes (DSTU)
• IHE PCC Technical Framework Vol. 1 and 2
• Boone, Keith: The CDA Book. Springer, 2011.

Syntactical Conventions

The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted 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

Header Content Modules define CDA templates on basic CDA elements that may occur in a CDA header or within sections (e.g. <patientRole> and <assignedAuthor>).

Patient Role Header Content Module

The Patient Role Header Content Module defines constraints that apply to the identification of the patient who is subject to a documented healthcare event.

• CDA Content Module Specification: Patient Role Header Content Module

Assigned Human Entity Content Module

The Assigned Human Entity content module defines the recording of human entities. It can be used with the document header or within document body entries for the instantiation of <assignedEntity> and <assignedAuthor> elements.

• CDA Content Module Specification: Assigned Human Entity Content Module

Assigned Organizational Entity Content Module

The Assigned Organizational Entity content module defines the recording of organizations as assigned actors. It can be used with the document header or within document body entries for the instantiation of <assignedEntity> elements.

• CDA Content Module Specification: Assigned Organizational Entity Content Module

eCR Participating Healthcare Providers Content Module

The Participating Healthcare Providers content module records the persons and organizations that are nominated by the patient as participants in a care event that is documentend by the CDA document. The content module follows the IHE 5-Domain-Modell (see IHE White Paper on “Access Control”) and separates between the static structural role a user has within a certain medical facility (subject domain) and his/her functional role within the current context (context domain). Permissions are solely bound to functional roles. This allows for a coarse grainded assignment of roles and a fine grained enforcement of permissions. This specification defines how the assignment of functional roles to persons/organizations can be encoded within a CDA document. By this a document can describe its context in terms of the authorized user. This allows the receiver – and further processors – of this document to enforce access restrictions even outside the document’s original context. With the eCR this feature is used to define the participants who are acting within the patient’s treatment context and their respective functional roles as defined for eCR use cases.

• CDA Content Module Specification: eCR Participating Healthcare Providers Content Module

Section Content Modules

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.

Consents and Contracts Section

The Consents and Contracts section provides an overview about

• the consents given by the patient
• contracts among the care providers
• contracts between the care team and health insurance companies (e.g. for participation with a managed care program)

The CDA Level 3 coded Consent and Contracts section can as well manage digital consents or scanned documents as references to paper forms.

• CDA Section Content Module Specification: Consents and Contracts Section

Entry Content Modules

Consent Directive Observation

A Consent Directive Observation is a specialization of the IHE PCC simple observation content module for registering relevant consents and contracts with a care episode or an electronic record.

• CDA Content Module Specification: Consent Directive Observation (1.2.276.0.76.3.1.81.81.6.4.1)

Document Reference

A Document Reference Entry refers to a single information object (e.g. within an eCR or another type of health record). With eCR-in-a-Box, Document Reference entries are used for registering documents with an eCR instance.

• CDA Content Module Specification: Document Reference (1.2.276.0.76.3.1.81.81.6.4.4)

Codesystems

eCR Consent Authorization Codes

eCR Consent Authorization Codes encode the kinds of authorization granted by a patient consent (e.g. right to process restricted data).

• Codesystem: eCR Consent Authorization Code (1.2.276.0.76.3.1.81.81.5.1)

eCR Participant Function Code

eCR Participant Function Codes encode the role of a healthcare provider within the context of an eCR (e.g. case manager). A healthcare professional may be assigned to multiple roles.

• Codesystem: eCR Participant Function Code (1.2.276.0.76.3.1.81.81.5.2)

eCR Assigned Entity Code

eCR Assigned Entity Code encode the kind of an eCR-in-a-box system actor (e.g. eCR Box).

• Codesystem: eCR Assigned Entity Code (1.2.276.0.76.3.1.81.81.5.3)

eCR Encompassing Organizational Act

eCR Encompassing Organizational Acts encode the kind of an eCR container object. This is always a "case record" on the top level. 2nd level containers may be inpatient visits, administrative acts, etc.

• Codesystem: eCR Encompassing Organizational Act ((1.2.276.0.76.3.1.81.81.5.4)

German Profile: Instance Identifiers

The German healthcare system defines different codesystems that can be used for identifying human and organizational entities. The following tables define which of these code systems MUST be used for what purpose within the scope of CDA documents.

• Healthcare Professional Instance Identifiers
• Healthcare Professional Organization Instance Identifiers