Implementation Guide

Consolidated Clinical Documentation Architecture (C-CDA) Documents for

Clinical Data Repository (CDR)
______________________________________________
Revised: October, 2016 Version 1.7
Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Table of Contents

1. DOCUMENT CHANGE HISTORY .............................................................................................................. 2

2. INTRODUCTION .................................................................................................................................... 2
3. C-CDA DOCUMENT VALIDATION ........................................................................................................... 4
4. PATIENT IDENTIFICATION FOR C-CDA DATA SUBMISSION ...................................................................... 4
5. PATIENT MATCHING AT THE CDR .......................................................................................................... 5
6. C-CDA DATA SUBMISSION OPTIONS AND ERROR MESSAGE HANDLING ................................................. 7
7. CORRECTION OF C-CDA DATA SUBMISSIONS ......................................................................................... 8
8. C-CDA CONFIDENTIALITY CODES ........................................................................................................... 9
9. C-CDA DOCUMENT RENDERING AND PARSING IN THE CDR.................................................................. 10
10. IHE DATA SUBMISSION PROTOCOLS SUPPORTED BY THE ONEHEALTHPORT HIE .................................. 16

1. DOCUMENT CHANGE HISTORY

DOCUMENT NAME: OHP-HIE Implementation Guide – C-CDA Documents

Version Issue Date Modified By Comments/Reason
1.0 February, 2016 Rhonda May First draft of Implementation Guide for C-CDA Documents
1.1 February 17, 2016 Rhonda May Clarification of data confidentiality requirements, update
web link, correct typographical errors, add mapping table,
add error handling section, add section for C-CDA correction.
1.2 February 22, 2016 Rhonda May Updated Mapping Table
1.3 March 21, 2016 Rhonda May Added information about mapping table information
available on the OHP HIE website
1.4 April 2016 Rhonda May Update name element sequence information
1.5 May 2016 Rhonda May Add specific reference to the version of HL7 C-CDA
implementation guide being used for C-CDA processing at
the HIE.
Update name element sequence information with reference
to the implementation guide
1.6 August 2016 Rhonda May Document enhancements, add/update specificity on data
requirements and constraints, add supported XDS.b ITI
protocols
1.7 October 2016 Rhonda May, Kelly Revised C-CDA requirements and data submission methods.
Llewellyn and Sue Added information on Direct messaging.
Merk

2. INTRODUCTION

2.1. Overview
OneHealthPort offers Clinical Data Repository (CDR) services to organizations that are interested in collecting
clinical information for a specific or “sponsored” population of patients. Current organizations sponsoring lives
(Sponsors) and the patient lives being sponsored in the CDR are listed below. The CDR aggregates clinical data

Implementation Guide – C-CDA Documents Page - 2 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

providing a patient-centric, longitudinal medical record inclusive of clinical records supplied by all contributing
providers.

Clinical Data Repository Sponsors

• Washington State Health Care Authority - Apple Health Program (Medicaid population)
• Physicians of Southwest Washington - Managed Medicare risk contracts

2.2. Scope
This implementation guide, unique to the OneHealthPort CDR, provides information for:
• C-CDA validation testing for format conformance with national standards
• Identifying patient lives for C-CDA data submissions
• Patient matching with the CDR
• C-CDA data submission options
• C-CDA confidentiality coding

The implementation guide is intended to augment the HL7 national standard implementation guide
specifically for the operationalization of C-CDA document exchange on the OneHealthPort HIE as well as the
IHE protocols for document sharing. OneHealthPort is using the HL7 CDA R2 Implementation Guide:
Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2.1 which is
available on the HL7 website.

2.3. General Assumptions

• Organizations participating in the sponsored CDR initiatives are contracted with the OneHealthPort HIE.
• The OneHealthPort HIE provides the supporting technical infrastructure for C-CDA data submissions to the
CDR.
• HIE participating organizations will successfully “pre-validate” C-CDA documents with validation testing
tools provided or accepted by OneHealthPort, prior to submission to the HIE. (See section 3 below.)
• Organizations and vendors will develop and manage processes for identifying patients for C-CDA data
submissions, error message handling and automation of submissions.
• Confidentiality of clinical information sent in C-CDA documents is the responsibility of the submitting
organization, using the HL7 Basic Confidentiality Kind value set where N = Normal, R = Restricted, and V =
Very Restricted.

2.4. Terms and Acronyms

Term or Acronym Description or Additional Detail

CCD Continuity of Care Document
C-CDA Consolidated Clinical Data Architecture – a framework for electronic exchange of clinical
documents
CDR Clinical Data Repository – an OHP service providing a hosted database of specifically
defined patient lives that are sponsored by organizations such as the State of Washington
Health Care Authority (HCA). Data is segmented by sponsoring organization.
EHR Electronic Health Record
HIE Health Information Exchange
HL7 Health Level 7 – a healthcare standards setting organization having a defined set of
international standards for transfer of clinical and administrative data between software
applications used by various healthcare practitioners.
IHE Integrating the Healthcare Enterprise - a non-profit organization based in the US state of
Illinois. It sponsors an initiative by the healthcare industry to improve the way computer
systems share information.
Implementation Guide – C-CDA Documents Page - 3 -
Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

ITI-41 The IHE XDS.b standard message wrapper (ITI-41) for providing and registering documents
in a repository
NIST National Institute of Standards and Technology
PDQ Patient Demographic Query
XDS.b IHE Cross Enterprise Document Sharing interoperability profile

3. C-CDA DOCUMENT VALIDATION

3.1. Overview
OneHealthPort HIE participating organizations exchanging C-CDA documents are required to perform validation
testing to confirm messages conform to the National Institute of Standards and Technology (NIST) HL7 CDA_R2
standard. In addition to meeting formatting requirements all C-CDA xml files must be UTF-8 encoded for
processing by the CDR.

3.2. C-CDA Document Validation Testing Options

OneHealthPort offers two options for validation testing:

• Secure Environment Validation Testing – OneHealthPort sponsors an instance of the HL7 CDA_R2 (with no
extensions) testing harness on the OneHealthPort HIE Application portal website that is available to HIE
contracted organizations. Testers must obtain a OneHealthPort Single Sign-On account from their
organization’s SSO Administrator to access the secure testing harness. The validation tool can be accessed at
this link: https://apps.onehealthport.com/OHPHIEApps . C-CDA files tested on the OneHealthPort validation
tool are done so in a secure environment allowing use of actual patient files. Any data content and results
from the testing harness are completely deleted after each file is tested.
• National Institute of Standards and Technology (NIST) - OneHealthPort is also accepting NIST validation of
C-CDAs using the CDA_R2 with no extensions and with SDTC extensions. Organizations validating using the
NIST validation tool should forward a screen shot of their successful validation results to the OneHealthPort
HIE. The NIST validation tool can be accessed from this link: http://cda-validation.nist.gov/cda-
validation/validation.html Note: Because the NIST is a public website, only test data files should be used
with this validation testing harness.

Organizations testing C-CDA xml files using the validation testing tool receive an immediate response regarding
the validity of the file structure. If the test result is invalid, errors in the construct of the file will be displayed.
All errors must be cleared in order to obtain a “valid” test result. Note: The testing tool also provides warning
messages that may improve the file content but are not critical structure errors.

4. PATIENT IDENTIFICATION FOR C-CDA DATA SUBMISSION

4.1. Overview
The OneHealthPort CDR accepts clinical data submissions for sponsored patient lives and does not accept C-CDA
data submissions for patients not specified by a data Sponsor. Therefore, organizations participating in sponsored
CDR initiatives will need to work with their EHR vendor to identify or flag patients for C-CDA data submissions
based on identification information provided by the data Sponsor and send data only for those patients.

4.2. Sponsored Patient Identification Information

Data Sponsor patient identification information is posted on the OneHealthPort CDR website. Current Sponsor
patient identification is set by health plan products. Organizations contracted with and caring for patients
covered under the health plan products on the list must submit C-CDAs for these patients after an encounter.

Implementation Guide – C-CDA Documents Page - 4 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

5. PATIENT MATCHING AT THE CDR

5.1. Overview
C-CDAs submitted to the CDR are matched on the global patient identifier from the CDR, the Sponsor’s patient
identifier at the CDR or with patient demographic information submitted in the C-CDA. If a C-CDA is not an exact
match with a known patient in the CDR, or if there is a match with more than one patient, the message is
rejected and returned with a no patient match error.

5.2. Patient Matching Process

The patient matching processes supported by the CDR have varying degrees of “matching success”.

5.2.1. CDR Patient Global Identifier

Use of the patient CDR global identifier is the best method to ensure that C-CDAs submitted to the CDR
match against a known patient. The patient global identifier is assigned by the master person index in
the CDR after receiving patient eligibility from the Sponsor. To use this identifier:
• Organization EHR systems would first need to query the CDR using a patient demographic query
(PDQ) to obtain the global patient identifier.
• The global patient identifier and the CDR object identifier (OID) are returned in the response.
• These identifiers can then be included in the C-CDA patient role section of the message header
prior to submission to the CDR. Details for placement of the global patient identifier and
Sponsor OID are presented below.

5.2.2. CDR Sponsor Patient Identifier

Use of the Sponsor patient identifier is the next best method to ensure that C-CDAs submitted to the
CDR match against a known patient. The Sponsor patient identifier is assigned by the Sponsor and
reported in an eligibility feed sent to the CDR. To use this identifier:
• The Sponsor patient identifier and the CDR Sponsor object identifier (OID) must be known by
the submitting organization.
• These identifiers can then be included in the C-CDA patient role section of the message header
prior to submission to the CDR. Details for placement of the Sponsor patient identifier and
Sponsor OID are presented below.
Implementation Guide – C-CDA Documents Page - 5 -
Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

5.2.3. Patient Demographic Matching

C-CDAs may also be submitted without the CDR or Sponsor identifiers. When a C-CDA is received
without these identifiers, the CDR will launch a PDQ to find a patient match.
• If an exact match is found, the patient global identifier and CDR OID will be inserted into the C-
CDA and processed by the CDR.
• If an exact match is not found, or if multiple matches are found, then the CDR will send back an
error to the submitting organization and the organization will need to investigate the reason for
no patient match.

5.3. Using the PDQ

Organizations that do not have known patient identifiers are encouraged to use the PDQ before submission of C-
CDAs to the CDR. PDQs sent to the CDR from the EHR system are sent back exact patient match information for
insertion into the C-CDA (and storage in the EHR if set up to do so). In the event there are multiple matches, the
CDR will return a list of possible matches, with the patient global identifiers, to select from allowing the
organization to identify the correct patient and use of the appropriate identifiers.

5.4. Patient Demographic Information Used for Patient Matching

Patient matching at the CDR will be made on specific demographic fields contained in the C-CDA. Organizations
are encouraged to verify that patient demographic information collected and stored in the EHR at the time a
patient presents for care is accurate and matches the Sponsors eligibility information. The demographic fields in
the C-CDA used for patient matching are listed below.
• First Name (required)
• Last Name (required)
• Date of Birth (required)
• Address information (optional)
• Social Security Number (optional)
• Sponsor’s patient identifier (optional)
• CDR global patient identifier (optional)

Implementation Guide – C-CDA Documents Page - 6 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

6. C-CDA DATA SUBMISSION OPTIONS AND ERROR MESSAGE HANDLING

6.1. Overview
OneHealthPort supports four different C-CDA data submission pathways to the CDR. The options below can be
used to support the submission of validated C-CDA messages using existing functionality available in electronic
health record (EHR) systems. Organizations can work with their vendors to use the option that best supports their
system data submissions capabilities and operational processes.

6.2. Submission Timing

C-CDA submissions are required following a patient encounter. Organizations are encouraged to submit C-CDAs
within a reasonable time period following the patient visit, when the C-CDA is deemed complete in the EHR and
ready for submission.

6.3. ITI-41 XDS.b Using Certificate-Based Exchange

Organizations will be required to provide certificates to establish secure connectivity to the OneHealthPort HIE as
well as a URL that will be available for the HIE to send message disposition notifications (MDNs) and error
processing messages from the CDR back to the organization. Certificate requirements and endpoint URLs are
provided below.

6.3.1. Certificate Requirements

Certificate-based connectivity to the HIE uses the open internet to allow maximum bandwidth for
message exchange. Certificates are used to sign and encrypt the messages using full Public Key
Infrastructure (PKI) sent via a secured channel (https). Organizations choosing to connect to the
OneHealthPort HIE using this method are required to provide the certificates to the OneHealthPort HIE.
Self-signed certificates or certificates from a third-party certificate authority are accepted for use in the
user accepted testing (UAT or test) environment. The production environment requires separate
certificates than the UAT environment and does not accept self-signed certificates.

Certificate Specifications
• UAT (test) environment certificate is separate from PROD environment certificate
• UAT can be a self-signed certificate, PROD must be from a commercial certificate authority or
exported from an Axway Activator assigned to your organization (see below)
• 2048-bit SSL Secure Sockets Layer with TLS Encryption
• 256 bit encryption
• SHA-2
• Standard or Basic SSL certificate for a single Domain name (Wildcard or multi-domain is not
required unless that is your organization’s standard)
• Validity option: 1-3 years
• Preferred format - A digital certificate will be required for secure exchange of data. This may be
in the form of either a DER encoded binary X.509 (.cer) or Cryptographic Message Syntax
Standard PKCS #7 (.p7b, .p7c). If a .p7b/.p7c file is going to be used please export the entire
certificate chain for use during the connectivity process
• Provide full certificate chain from a third-party certificate authority

6.3.2. Certificate-based Connectivity Endpoints

Coming soon…

6.4. Direct Message

Implementation Guide – C-CDA Documents Page - 7 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Organizations choosing this data submission option will be required to send the C-CDA in a validated xml format
to the CDR’s Direct Mail address.

6.4.1. General Assumptions for Direct Message C-CDA Submissions

• Contracted organizations submitting clinical documents via Direct messaging will submit properly
formatted and fully formed .xml files meeting the C-CDA validation requirements.
• Direct messages with attached PDF documents will not be processed by the CDR. Attachments must
be in an .xml format.
• The OneHealthPort Direct mail address will be available and recognized by Direct-Trust certified
HISPs.
• Direct messages received from submitters not contracted with the OneHealthPort HIE will error and
no data will update in the CDR. An error message will be returned to the sending direct address.

6.4.2. CDR Direct Message Addresses

CDR Direct Mail addresses are listed below.
• CDR Test Environment – [email protected]
• CDR Production Environment – available after testing in UAT

6.5. C-CDA xml File Submission Using AS2 Connectivity

Organizations already connected to and exchanging data through the OneHealthPort HIE currently use an AS2
connectivity software tool provided by the HIE or support the AS2 connectivity to the HIE using their own tool
suite. If C-CDA xml files can be exported from the EHR system, organizations can use existing connectivity and
message delivery management tools to support delivery of the C-CDA files to the CDR.

6.6. ITI-41 XDS.b File Submission Using AS2 Connectivity

Organizations already connected to and exchanging data through the OneHealthPort HIE currently use an AS2
connectivity software tool provided by the HIE or support the AS2 connectivity to the HIE using their own tool
suite. If the EHR system is set up to export a C-CDA using the ITI-41 XDS.b protocol and the organization
prefers not to set up another connectivity using certificate-based exchange, the organization may use the
existing AS2 connectivity, provided a fully compliant and complete ITI-41 XDS.b document can be exported
from the EHR and transferred to the AS2 connectivity tool for submission.

7. CORRECTION OF C-CDA DATA SUBMISSIONS

7.1. Overview
Organizations may need to periodically update, append or replace previously submitted C-CDAs.

7.2. C-CDA Submission Correction and Updates

The HL7 C-CDA standard provides for correction and updates through relatedDocument functionality.
Organizations sending appended or replacement C-CDA documents must include an additional section in the C-
CDA message header. The location in the header for the relatedDocument information is after the
documentationOf section, and is shown below:

relatedDocument 0..* MAY 1098-29893

@typeCode 1..1 SHALL 1098-31889 2.16.840.1.113883.11.20.9.62
(Related Document (append/replace))
parentDocument 1..1 SHALL 1098-29894
Source: CDAR2_IG_CCDA_CLINNOTES_R2_D1_2014NOV_V2_ Templates_and_Supporting_Material

Implementation Guide – C-CDA Documents Page - 8 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Organizations submitting replacement or appended C-CDAs must have already done a registry stored-query (ITI-
18) to obtain the unique document identifier in the CDR. That identifier must be used as the parentDocument
element. An example of the relatedDocument section is show below:

<relatedDocument typeCode="RPLC">
<parentDocument>
<id root="aefe4f6a-d6e1-46ef-8c40-790998f7bee6" />
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName=“SUMMARIZATION OF EPISODE NOTE"/>

8. C-CDA CONFIDENTIALITY CODES

8.1. Overview
Data confidentiality codes assigned to clinical documents drive all access control to individual patient records in
the Clinical Data Repository. It is the responsibility of the submitting organization to code the content in the C-
CDA based upon the type of content in an encounter, or the patient request for data to be treated with
sensitivity.

8.2. Data Confidentiality Codes

Currently, the entire C-CDA has only one confidentiality code that should be based on the most confidential
element in the document. In the future, confidentiality coding will be accepted at the element level. Further
information regarding the HL7 standard discussing confidentiality code assignment can be found by an internet
search using the confidentiality code system object identifier 2.16.840.1.113883.5.25. The HL7 link is as follows:
http://www.hl7.org/documentcenter/public_temp_2873DC00-1C23-BA17-
0C63F6C676FED8DB/standards/vocabulary/vocabulary_tables/infrastructure/vocabulary/vs_Confidentiality.html

Electronic Health Record (EHR) systems must provide the means for the practitioner to identify the correct
confidentiality code for information included in the C-CDA. “Normal” (N) may be the system default for data
confidentiality. The EHR system must provide functionality to adjust the confidentiality code to match the
information in the record.

The State of Washington Health Care Authority has developed a reference guide for Confidentiality code
assignment based on ICD-10 and CPT-4 Codes associated with the record. This guide can assist vendors and
practices with examples for how to classify data.

Currently the C-CDA accommodates the HL7 Basic Confidentiality Kind. In the future the standard may add a
“sensitivity” classification providing more discreet definition of particular data/information in a record. A table of
the confidentiality codes and their definition is shown below:

Code Description Definition

N Normal Privacy metadata indicating that the information is typical, non-stigmatizing health
information, which presents typical risk of harm if disclosed without authorization.

Includes what HIPAA identifies as the minimum necessary protected health information
(PHI) given a covered purpose of use (treatment, payment, or operations). Includes
typical, non-stigmatizing health information disclosed in an application for health,
workers compensation, disability, or life insurance.
R Restricted Privacy metadata indicating highly sensitive, potentially stigmatizing information, which
presents a high risk to the information subject if disclosed without authorization. May
be preempted by jurisdictional law, e.g., for public health reporting or emergency

Implementation Guide – C-CDA Documents Page - 9 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

treatment.

Includes information that is additionally protected such as sensitive conditions mental

health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and
reproductive health; or sensitive demographic information such as a patient's standing as
an employee or a celebrity. May be used to indicate proprietary or classified information
that is not related to an individual, secret ingredient in a therapeutic substance, or the
name of a manufacturer.
V Very Privacy metadata indicating that the information is extremely sensitive and likely
Restricted stigmatizing health information that presents a very high risk if disclosed without
authorization. This information must be kept in the highest confidence.

Includes information about a victim of abuse, patient requested information sensitivity,

and taboo subjects relating to health status that must be discussed with the patient by an
attending provider before sharing with the patient. May also include information held
under legal lock or attorney-client privilege
Source: http://hl7.org/fhir/v3/Confidentiality/index.html

9. C-CDA DOCUMENT RENDERING AND PARSING IN THE CDR

9.1. Overview
When a document successfully uploads in the CDR, the entire document will render. Currently, the components
of the CDR that will parse with discrete data, if all appropriate coding is included in the submitted document, are
as follows:

1. Documents – a listing of all the documents in the system for a given patient
2. Medications
3. Vital Signs
4. Immunizations
5. Encounters (coming in a future release)
6. Problems
7. Allergies
8. Procedures
9. Lab Values

Sample screen shots of a rendered document:

Implementation Guide – C-CDA Documents Page - 10 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Implementation Guide – C-CDA Documents Page - 11 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Implementation Guide – C-CDA Documents Page - 12 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Implementation Guide – C-CDA Documents Page - 13 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Implementation Guide – C-CDA Documents Page - 14 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

Sample screen shot of parsed data:

Implementation Guide – C-CDA Documents Page - 15 -

Document Name OneHealthPort-HIE Implementation Guide – C-CDA Documents for CDR

10. IHE DATA SUBMISSION PROTOCOLS SUPPORTED BY THE ONEHEALTHPORT HIE

10.1. Overview
The OneHealthPort HIE supports several IHE protocols that can be leveraged and used for supporting information
exchange activity with the CDR.

10.2. Supported Submission Protocols

• ITI-41 Provide and Register Document Set

• ITI-47 PDQv3 Patient Demographic Query – Query (PRPA_IN201305UV02)and Response
(PRPA_IN201306UV02) for patient identifiers from the CDR
• ITI-18 Registry Stored Query for documents stored in the CDR (coming soon)
• ITI-55 Cross Gateway Query for patient identifiers] (coming soon)
• ITI-38 Cross Gateway Query for patient specific document identifiers stored in the CDR] (coming soon)
• ITI-39 Cross Gateway Query for specific CDR documents (coming soon)

Implementation Guide – C-CDA Documents Page - 16 -