Implementation Guide for CDA Release 2.0
Patient Generated Health Data (PGHD) Document
(InternationalUniversal Realm)
And
(US Realm)
Draft version: September October 2012
Primary Editor: / Virinder BatraIntuit Health
/ Co-Chair/Co-editor: / Robert H. Dolin, MD
Lantana Consulting Group
Primary Editor: / Lisa Nelson
Life Over Time Solutions / Co-Chair: / Calvin Beebe
Mayo Clinic
Co-Editor: / Jessi Formoe
Intuit Health
/ Co-Chair: / Rob Hausam
Hausam Consulting
Co-Editor: / Leslie Kelly Hall
Healthwise
/ Co-Chair: / Austin Kreisler
SAIC Consultant to CDC/NHSN
Co-Editor: / Shawn Meyers
Healthwise
/ Co-Chair: / Brett Marquard
Lantana Consulting Group
Co-Editor: / Brian Scheller
Healthwise
/ Co-Editor: / Kevin Harbauer
Healthwise
Co-Editor: / Gordon Raup
Datuit LLC
/ Co-Editor: / David Tao
Siemens
Co-Editor: / Elaine Ayres
National Institutes of Health
/ Co-Editor: / Catherine Welsh
St Judes Research Hospital
Co-Editor: / Allen Traylor
Child Health& Development Interactive System (CHADIS)
/ Co-Editor: / Chris Schultz
Child Health& Development Interactive System (CHADIS)
Co-Editor: / Stephen Chu
National E-Health Transition Authority (NEHTA) Australia
/ Co-Editor: / Vin Sekar
National E-Health Transition Authority (NEHTA) Australia
Co-Editor: / Emma Jones
Allscripts
Virinder Batra, Intuit Health
Lisa Nelson, Life Over Time Solutions
Elaine Ayres, Academy of Nutrition and Dietetics, National Institutes of Health
Catherine Welsh, St. Jude Children's Research Hospital
Bob Dolin, Lantana Consulting
Emma Jones, Allscripts
Shawn Meyers, Healthwise
Brian Scheller, Healthwise
Chris Schultz, Child Health & Development Interactive System (Chadis)
Gordon Raup, Datuit
David Tao, Siemens Healthcare
Jessi Formoe, Intuit Health
Leslie Kelly Hall, Healthwise
Kevin Harbauer,Healthwise
Allen Traylor, Child Health & Development Interactive System (Chadis)
Table of Contents
Open Issues 6
1 Introduction 7
1.1 Audience 7
1.2 Purpose 7
1.3 Scope 7
1.4 Approach 7
1.5 Organization of This Guide 7
1.10 Content of the Package 8
2 General Universal Realm Patient Authored Note Header Template 9
2.1 Document Type Codes 9
2.2 Patient Authored Document Header 9
2.2.1 RecordTarget 11
2.2.2 Author 22
2.2.3 DataEnterer 24
2.2.4 Informant 25
2.2.5 Custodian 26
2.2.6 InformationRecipient 28
2.2.7 LegalAuthenticator 28
2.2.8 Authenticator 30
2.2.9 Participant (Support) 31
2.2.10 InFulfillmentOf 33
2.2.11 DocumentationOf/serviceEvent 33
2.2.12 Authorization/consent 35
2.2.13 ComponentOf 36
2.3 US Realm Address (AD.US.FIELDED) 36
2.4 US Realm Date and Time (DT.US.FIELDED) 37
2.5 US Realm Date and Time (DTM.US.FIELDED) 38
2.6 US Realm Patient Name (PTN.US.FIELDED) 38
2.7 US Realm Person Name (PN.US.FIELDED) 40
2.8 Rendering Header Information for Human Presentation 40
3 General US Realm Patient Authored Note Header Template 42
3.1 Document Type Codes 42
3.2 Patient Authored Document Header 42
3.2.1 RecordTarget 44
3.2.2 Author 55
3.2.3 DataEnterer 57
3.2.4 Informant 58
3.2.5 Custodian 59
3.2.6 InformationRecipient 61
3.2.7 LegalAuthenticator 61
3.2.8 Authenticator 63
3.2.9 Participant (Support) 64
3.2.10 InFulfillmentOf 66
3.2.11 DocumentationOf/serviceEvent 66
3.2.12 Authorization/consent 68
3.2.13 ComponentOf 69
3.3 US Realm Address (AD.US.FIELDED) 69
3.4 US Realm Date and Time (DT.US.FIELDED) 70
3.5 US Realm Date and Time (DTM.US.FIELDED) 71
3.6 US Realm Patient Name (PTN.US.FIELDED) 71
3.7 US Realm Person Name (PN.US.FIELDED) 73
3.8 Rendering Header Information for Human Presentation 73
Open Issues 5
1 Introduction 6
1.1 Audience 6
1.2 Purpose 6
1.3 Scope 6
1.4 Approach 6
1.5 Organization of This Guide 6
1.10 Content of the Package 7
2 General Header Template 8
2.1 Document Type Codes 8
2.2 Patient Authored Document Header 8
2.2.1 RecordTarget 10
2.2.2 Author 20
2.2.3 DataEnterer 21
2.2.4 Informant 23
2.2.5 Custodian 24
2.2.6 InformationRecipient 25
2.2.7 LegalAuthenticator 26
2.2.8 Authenticator 28
2.2.9 Participant (Support) 29
2.2.10 InFulfillmentOf 31
2.2.11 DocumentationOf/serviceEvent 31
2.2.12 Authorization/consent 33
2.2.13 ComponentOf 34
2.3 US Realm Address (AD.US.FIELDED) 34
2.4 US Realm Date and Time (DT.US.FIELDED) 35
2.5 US Realm Date and Time (DTM.US.FIELDED) 36
2.6 US Realm Patient Name (PTN.US.FIELDED) 36
2.7 US Realm Person Name (PN.US.FIELDED) 38
2.8 Rendering Header Information for Human Presentation 38
Table of Figures
Figure 1: US Realm header example 21
Figure 2: effectiveTime with time zone example 21
Figure 3: recordTarget example 29
Figure 4: Person author example 32
Figure 5: Device author example 32
Figure 6: dataEnterer example 34
Figure 7: Informant with assignedEntity example 35
Figure 8: Custodian example 36
Figure 9: informationRecipient example 37
Figure 10: legalAuthenticator example 39
Figure 11: Authenticator example 40
Figure 12: Participant example for a supporting person 42
Figure 13: DocumentationOf example 44
Figure 14: Procedure note consent example 45
Table of Tables
Table 1: Content of the Package 9
Table 2: Basic Confidentiality Kind Value Set 11
Table 3: Language Value Set (excerpt) 11
Table 4: Telecom Use (US Realm Header) Value Set 16
Table 5: Administrative Gender (HL7) Value Set 16
Table 6: Marital Status Value Set 16
Table 7: Religious Affiliation Value Set (excerpt) 17
Table 8: Race Value Set (excerpt) 17
Table 9: Ethnicity Value Set 17
Table 10: Personal Relationship Role Type Value Set (excerpt) 18
Table 11: State Value Set (excerpt) 18
Table 12: Postal Code Value Set (excerpt) 18
Table 13: Country Value Set (excerpt) 19
Table 14: Language Ability Value Set 19
Table 15: Language Ability Proficiency Value Set 19
Table 16: IND Role classCode Value Set 32
Table 17: PostalAddressUse Value Set 37
Table 18: EntityNameUse Value Set 39
Table 19: EntityPersonNamePartQualifier Value Set 39
Open Issues
How should we handle the need to generalize the pattern of document to make it appropriate for the International Realm, while at the same time retaining the US Realm specifications so that we remain consistent with the foundational specifications established by the Consolidated CDA project?
Example1: In section 2.2 the clinicalDocument/effectiveTime contains a US-specific requirement.
Example 2: In section 2.2.1, the RecordTarget contains US-specific requirements for the patient name, address and telecom A request has been made to Regenstreif through Rob Hausam to add the following description to the existing LOINC code 51855-5. This request is pending.
REQUESTED - DEFINITION/DESCRIPTION for 51855-5Source: HL7 Structured Documents Working Group
A Patient Authored Note is generated by a patient or a patient agent acting in a non-clinical role to provide clinically relevant information to support planned or unplanned health care services.
This document gives healthcare providers, and others involved in a person’s care, information which the patient considers essential input during care delivery and coordination. This document enables patients and their agents to contribute to the continuity of care.
Because a Patient Authored Note is generated by a person acting as a non-clinician, this document may not be a complete medical summary and should be considered in context with other information routinely collected by clinicians during care delivery and coordination.
This general class of patient authored notes includes information that is interoperable with data defined for clinician-generated documents. Other more specific classes of patient authored notes may include more tightly defined content.
This document may be generated from a patient-, clinician-, or payer-controlled source system.
Intention to Build a Hierarchy of codes for Patient Authored Notes
It is envisioned that the 51855-5 code will be the most general class of Patient Authored Note documents, and that additional more specific types of Patient Authored Notes will be created in the future.
A request has been initiated through Rob Hausam to have the code “SELF” added to the PersonalRelationshipRoleType value set.
It should be noted that mechanisms to encode and manage consent are inadequate for addressing expected consent management requirements. This represents current standard practices, and it is outside the scope of this project to address more robust consent mechanisms.
If the NUCC Health Care Provider Taxonomy (CodeSystem: 2.16.840.1.113883.6.101) does not have codes for allied health professions, then an additional value set will need to be added to expand any constraints referencing the NUCC Provider Taxonomy to include this additional taxonomy of allied health professions.
Erratta currently reported against the Consolidated CDA General Header need to be identified and the adopted resolutions need to be applied.
Example snippets need to be updated.
A sample Patient Authored Note document using the US Realm Header should be generated.
1 Introduction
1.1 Audience
The audiences for this implementation guide are the architects and developers of healthcare information technology (HIT) systems in the US Realm that exchange patient clinical data and seek to use data standards that are consistent with Universal or US Realm guidance. This includes those exchanges that comply to the Health Information Technology for Economic and Clinical Health (HITECH) provisions of the American Recovery And Reinvestment Act of 2009, the Final Rules for Stage 1 Meaningful Use, and the 45 CFR Part 170 – Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule.[1]
Business analysts and policy managers can also benefit from a basic understanding of the use of Clinical Document Architecture (CDA) templates across multiple implementation use cases.
1.2 Purpose
The integration of patient generated data (PGHD) into the HIT is an important change to the HIT ecosystem. Although patients have long been the source of information recorded in the EHR, this information has been gathered orally or in paper forms, and transcribed by the provider in a way that is assessed, interpreted and summarized, and the original patient information may not be retained. Digital integration of PGHD provides the opportunity for patients to author data in a way that is consumable within the EHR.
Based upon recent testimony received by the HITSC and HITPC PGHD hearing, the successful inclusion of PGHD incorporates the following characteristics; information is material to the patient’s experience of their own condition, meaningful to the provider, contextually relevant, consumable by the EHR in a familiar way and correctly attributed to the patient or designee. The ONC HITSC and HITPC have further directed that standards already directed in MU should be reused, repurposed and harmonized.
The purpose of this implementation guide is to develop a standard way within the current framework of structured documents in the evolving health information ecosystem to capture, record and make interoperable, patient generated information. The goal is to enable patients to participate and collaborate electronically with care team members.
Suggested person: Leslie
1.3 Scope
Suggested person: Virinder
This document is scoped by the content of the eight Health Story Guides, CCD, and additional constraints from IHE and HITSP. New conformance rules were not introduced unless an ambiguity or conflict existed among the standards.
All CDA templates required for Final Rules for Stage 1 Meaningful Use[2] are included in this guide. All CDA templates required for Health Story compliance to the section level are included, as well, of course, as the Health Story reuse of Stage 1 Meaningful Use templates.
This guide fully specifies a compliant CDA R2 document for each document type.
Additional optional CDA elements, not included here, can be included and the result will be compliant with the documents in this standard.
This implementation guide is intended to provide implementation guidance on the header elements for documents authored by patients or representatives of patients acting on behalf of the patient. It is modeled on the C-CDA header with the intent of being adopted as an alternative for the header used for clinician authored documents. It is expected that the C-CDA document library will be expanded over time to include patient & non-clinician generated C-CDA documents, and the C-CDA headers defined in this implementation will be used to guide the definition of these patient generated documents.
The following will be ‘in scope’ for this implementation guide
· Guidance and best practices for definition of the CDA header elements for the Patient authored documents
· Guidance on the universal realm and US realm header elements
· Guidance on use of the patient authored headers (universal realm & US realm) ina general Patient Authored Note documents
A set of ‘patient’ Use Cases to inform the best practices defined in this implementation guide
The following will not be in scope for this implementation guide
· Definition of new patient generated C-CDA document types. Even though the vision is for a new set of non-clinician generated consolidated document types, the new document types are NOT in scope for this implementation guide.
·
Implementers of this general Patient Authored Note document should consider utilizing section and entry templates defined in the Consolidated CDA Implementation Guide to maximize data interoperability. For example, a Patient Authored Note which included the same sections as a Continuity of Care Document would be a highly interoperable document because EHR systems that already exchange CCD documents would be well positioned to consume the patient generated content.
1.4 Approach
Suggested person: LisaThe Patient Authored Note header defines how to implement elements of the CDA header for documents that are generated by the patient or a person acting as a non-clinician and on behalf of the patient.
Like the General Header defined for Consolidated CDA documents authored by clinicians, the Patient Authored Note Header is general and can be used with classes of documents where the information is authored by the patient or a person acting as a non-clinician as the patient’s agent. The Patient Authored Note Header may be further constrained to fit narrower use cases requiring tighter constraints.
A universal realm implementation is defined to provide the most general implementation guidance. Additionally, US realm specific guidance is provided as an alternative to the current General Header defined for clinician-generated notes defined in the Consolidated CDA IG.
Going forward, the clinician and non-clinician header templates will be maintained in a syncronized manner to ensure continued alignment over time. Based upon these considerations, this document will use Consolidated CDA structures with minimal changes to reflect the inclusion of the patient as an author (and related roles). It is expected that templates created to be used in Patient Authored Note documents will also be consistent with the Consolidated CDA structure.
1.5 Organization of This Guide
This guide includes a single template defining the header constraints for a patient authored document. It is envisioned that the document-, section- and entry-level templates associated with any type of patient generated document will be defined within the consolidated CDA template library.are: