Template  CDA-CH v2.0 - structuredBody

This document template is used as the primary base for CDA-CH exchange formats. It only specifies the usage of CDA header templates. It requires a structured CDA body, but does not define any CDA body rules. For CDA body rules, see the derived exchange formats.

Conformity rules that are not further modelled in ART-DECOR:

• XML encoding
  UTF-8 encoding is required. All CDA-CH V2 documents MUST start with this line:
  <?xml version="1.0" encoding="UTF-8"?>

• Phone numbers
  Phone numbers MUST be declared in the international format.
  Dots (.) MUST be used as separators for grouping of number blocks.
  The minus sign (-) MUST be used as a separator between public and internal telephone numbers. Purpose: Some telephone exchanges - especially in the US, allow direct dial-up of an internal telephone number after the actual connection has been established over the public telephone network.
  Examples:
  <telecom value="tel:+41.33.123.45.67"/>
  <telecom value="tel:+1.987.654.3210-999"/>

• Target patient
  The HL7 CDA R2 (2005) standard allows multiple patients.
  In order to ensure that the information in a CDA document is unambiguously assigned to one and only patient, a CDA-CH V2 based document MUST contain exactly one patient.
  Special cases: In exceptional cases (e.g., new-born twins, both having jaundice), multiple documents MUST be created (all of the same content, but each with a unique patient).
  
  
• Patient identifiers
  Multiple ids (patient identification number) MAY be declared.
  If multiple ids are known, it is highly recommended to declare all known ids. Especially in cases where the CDA document instance is kind of an answer to a preceding order (independent of its data format), all ids specified by the ordering system SHALL be declared in the CDA document instance. This allows the receiver to assign its internal patient identification.
  The patient identification number MUST be grouped with the OID of its assigning system. The patient identification number MUST be unique within the system identified by the OID.
  The declared OID MUST be found in one of the public OID registries, such as oid.refdata.ch (preferred), oid-info.com, hl7.org/oid, www.dimdi.de/static/de/klassi/oid/, gesundheit.gv.at/OID_Frontend/ etc.
  OIDs that can't be found in a public OID registry are NOT ALLOWED.
  
  
• Pseudonymizing
  In special cases, the demographic data of the patient are not allowed to be transmitted or they have to be pseudonymized.
  While HL7 CDA or its derivatives like CDA-CH or Swiss exchange formats nevertheless require these elements in the XML structure, the affected values MUST be replaced by a nullFlavor of type "MSK" (masked), in order to support the required data format structure and simultaneously to shield the real data.
  
  

The functionCode MUST be taken from the Swiss EPR Value-Set for author roles. See FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3: Metadata, Section 2.1.

If the desired functionCode is not available in the Swiss EPR Value-Set for author roles, nullFlavor='NAV' MUST be used. In this case, the originalText element MUST contain the description of the role.

Translations to other vocabularies are allowed.

• The main recipient of the document is indicated by typeCode 'PRCP' (primary recipient).
  Note: Since it makes no sense to create a CDA document without doing it for someone, in Switzerland at least one recipient MUST be declared. If the document is created for the user's own needs, the user itself or its organization will be the primary recipient.
  
  
• Other recipients (copy to; Cc) are indicated with typeCode, TRC '(secondary recipient).

Relationship to another CDA-CH V2 based document that is replaced by the current one.

Notes: For correction of wrong information, a new document that replaces the earlier document MUST be created. The new document corrects previously incorrect information. This also applies to the case where information in the CDA header has been corrected (e.g., if the original document has been issued to the wrong patient). While processing the new document at the recipient, all values from the previous document MUST be interpreted as deprecated (deleted/marked as deleted/deprecated) and all values in the new document MUST be marked as valid:

• Values that were only contained in the previous document have to be treated as deleted.
• Values that are present in both documents are overwritten with the contents of the new document.
• Values that are only contained in the new document are to be added.