Implementation Guide Levels 1,2 and 3 History & Physical (US Realm)

IMPL_CDAR2_IG_HPRPT_R1_D1_2007MAY

Implementation Guide Levels 1,2 and 3 – History & Physical (US realm)

Based on HL7 CDA Release 2.0

Co-Chair/Co-Editor: / Liora Alschuler
Alschuler Associates, LLC

Co-Chair/Co-Editor: / Calvin Beebe
Mayo Clinic

Co-Chair/Co-Editor: / Robert H. Dolin, MD
Kaiser Permanente

Co-Chair/Co-Editor: / Keith W. Boone
GE Healthcare

Co-Editor: / Crystal Kallem
AHIMA

Co-Editor: / Laura Bryan
AHDI

Co-Editor: / Harry Rhodes
AHIMA

Co-Editor: / Rick Geimer
Alschuler Associates, LLC

Co-Editor: / Kate Hamilton
Alschuler Associates, LLC

Co-Editor: / Juggy Jugganathan
MedQuist

Current Working Group: /

DRAFT
March 15, 2007

Known issues, 3/21/07

examples/figures
sections w/ highlight
Table 4 summarizing section codes: update, add cross-walk to CRS, CCD

Table of Contents

1History & Physical Reports

1Introduction

1.1Purpose

1.2Audience

1.3Approach

1.4Conventions Used in this Guide

1.4.1Explanatory Statements

1.4.2Conformance Requirements

1.4.3XPath Notation

1.4.4Key Words

1.4.5XML Samples

1.4.6Content of the Ballot Package

1.5Scope

1.5.1Future Work

2CDA Header – General Constraints

2.1ClinicalDocument

2.1.1General Constraints

2.1.2Rendering Information from the CDA Header for Human Presentation

2.1.3ClinicalDocument/realmCode

2.1.4ClinicalDocument/typeId

2.1.5ClinicalDocument/id

2.1.6ClinicalDocument/code

2.1.7ClinicalDocument/title

2.1.8ClinicalDocument/effectiveTime

2.1.9ClinicalDocument/confidentialityCode

2.1.10ClinicalDocument/languageCode

2.1.11ClinicalDocument/setId and ClinicalDocument/versionNumber

2.1.12ClinicalDocument/copyTime

3CDA Header – History and Physical Specific Constraints

3.1.1ClinicalDocument/templateId

3.1.2ClinicalDocument/code

3.2Participants

3.2.1recordTarget

3.2.2author

3.2.3dataEnterer

3.2.4informant

3.2.5custodian

3.2.6informationRecipient

3.2.7legalAuthenticator

3.2.8authenticator

3.2.9participant

3.2.10documentationOf

3.2.11inFulfillmentOf

3.2.12authorization

3.2.13componentOf

4Body

4.1LOINC Section Type Codes

4.1.1Claims Attachments

4.2Required Sections

4.2.1Reason for Visit/Chief Complaint 29299-5/10154-3/46239-0

4.2.2History of Present Illness 10164-2

4.2.3Past Medical History 11348-0

4.2.4Medications 10160-0

4.2.5Allergies X-AARA

4.2.6Social History 29762-2

4.2.7Family History 10157-6

4.2.8Review of Systems 10187-3

4.2.9Physical Examination 22029-3/8716-3/10210-3/11384-5

4.2.10Diagnostic Findings 30954-2

4.2.11Assessment and Plan X-AAPLN/X-ASSMT/X-PLAN

4.3Optional Sections

4.3.1Payers

4.3.2Problems

4.3.3Past Surgical History 10167-5

4.3.4Immunization 11369-6

5References [Harry]

Appendix A —Validation

Introduction

Vocabulary

Extending the Vocabulary Tables for Local Use

Administrative Contact Role Type

Administrative Gender

Ethnicity

LOINC

Marital Status

Null Flavor

Participation Function

Personal Relationship Role Type

Race

SNOMED CT

Appendix B —Sample Level 1 Conforming CDA Header

Appendix C —Sample Level 2 Conforming Structured Body

Appendix D —External Constraints

1CCD Constraints

2CRS Constraints

Appendix E —History and Physical Template IDs

Figures

Figure 1 Use of the templateId element to indicate use of this guide.

Figure 2 ClinicalDocument Example

Figure 3 Various Uses of nullFlavor

Figure 4 Restricted URL grammar for telephone communications

Figure 5 Unknown Telephone number example.

Figure 6 ClinicalDocument/realmCode Example

Figure 7 ClinicalDocument/typeId Example

Figure 10 ClinicalDocument/id Example

Figure 15 ClinicalDocument/title Example

Figure 16 CinicalDocument/effectiveTime Example

Figure 17 CinicalDocument/confidentialityCode Example

Figure 18 ClinicalDocument/languageCode Example with language only

Figure 19 ClinicalDocument/languageCode Example with language and country.

Figure 20 ClinicalDocument/setId and ClinicalDocument/versionNumber Example

Figure 8 ClinicalDocument/templateId Example conforming to Level 1 only

Figure 9 ClinicalDocument/templateId Example conforming to Level 1 and Level 2

Figure 11 ClinicalDocument/code Example

Figure 12 Use of a translation to include local equivalents for document type

Figure 13 Use of Precoordinated of Document Type Codes in the CDA

Figure 14 Precoordination of Document Type Codes in the CDA

Figure 21 recordTarget Example

Figure 22 author Example

Figure 24 dataEnterer Example

Figure 25 informant Example for healthcare providers in assigned roles.

Figure 26 informant Example for a related person.

Figure 27 informant Example for an unrelated person.

Figure 28 informant Example for healthcare providers not in assigned roles.

Figure 29 custodian Example

Figure 30 informationRecipient Example

Figure 31 legalAuthenticator Example

Figure 32 authenticator Example

Figure 33 participant Example for a Supporting Person

Figure 38 componentOf example

Figure 39 Sample nonXMLBody element with content.

Figure 40 Sample nonXMLBody element with a reference.

Figure 41 Reason for Visit/Chief Complaint Example

Figure 42 History of Present Illness Example

Figure 43 Past Medical History Example

Figure 44 Medications Example

Figure 45 Allergies Example

Figure 46 Social History Example

Figure 47 Family History Example

Figure 48 Review of Systems Example

Figure 49 Procedure Rendering

Figure 50 voc.xml Structure

Tables

Table 1 Contents of the Ballot Package

Table 2 LOINC Document Type Codes

Table 3 Participant Assignment

Table 4 LOINC Section Type Codes

Table 5 Administrative Gender

Table 6 Ethnicity

Table 7 LOINC Document Type Codes

Table 8 Marital Status

Table 9 Null Flavor

Table 10 Participating Function Codes

Table 11 Personal Relationship Role Type

1History & Physical Reports

1Introduction

1.1Purpose

The purpose of this document is to describe constraints on the CDA Header and Body elements for History & Physical documents. A History and Physical Examination (H&P) is a two-part medical report which documents the current and past condition of the patient. It contains both subjective and objective information and forms the basis of most treatment plans. The first half of the report includes subjective information, typically supplied by the patient or their caregiver, about the current medical problem or the reason for the patient encounter. This information is followed by a description of any past or ongoing medical issues including current medications and allergies. Information is also obtained about the patient's lifestyle, habits, and diseases among family members. The second half of the report contains objective information obtained by physically examining the patient and gathering diagnostic information in the form of laboratory tests, imaging or other diagnostic procedures. The report ends with the physician's assessment of the patient's situation and the intended plan to address those issues. An H&P is required upon hospital admission as well as before any operative procedure. An initial evaluation in an ambulatory setting is often documented in the form of an H&P.

1.2Audience

The audience for this document is software developers and consultants responsible for implementation of Electronic Health Record (EHR) systems, Electronic Medical Record (EMR) systems, Personal Health Record (PHR) systems, dictation/transcription systems, document management applications and local, regional and national health information exchange networks who wish to create and / or process CDA documents created according to this specification.

1.3Approach

The approach taken in the development of this specification was to review existing draft and final specifications or implementation guides for similar artifacts in the US, specifically:

Harry, these links were updated per Keith on 3-20, 5:30 by Laura, delete this comment after you acknowledge

ASTM’s Standard Specifications for Healthcare Document Formats (E2184.02)(headings and subheadings used in medical and associated with specific report types)
ASTM/HL7 Continuity of Care Document (CCD)
Clinical LOINC document and section codes
HL7 ASIG CDA R2 Attachment for Clinical Notes
HL7 Care Record Summary (CRS)
IHE profiles, including the content profiles within Patient Care Coordination
MHS/DoD-VA-IM-IT Demo Project Discharge Summary & SOAP HL7 CDA R2 Implementation Guides
Sample CDA documents developed for local provider institutions (Mayo Clinic, University of Pittsburgh Medical Center, New York Presbyterian and others)
Non-CDA sample documents supplied by participating providers and vendors

[xxxReferences for above] [Harry]

These last were taken and marked up according to this IG as a test on the design and to provide a sample document to accompany this IG.

In addition [statistical analysis, SME experience (clinical, transcription and technical), test against sample documents, review with SDTC]. ...and on that basis, constrain the CDA Header and Body elements. [Liora]

1.4Conventions Used in this Guide

This guide is a conformance profile, as described in the Refinement and Localization section of the HL7 Version 3 standards. The base standard for this guide is the HL7 Clinical Document Architecture, Release 2.0. As defined in that document, this guide is both an annotation profile and a localization profile.

1.4.1Explanatory Statements

As an annotation profile, portions of this guide summarize or explain the base standard.

Explanatory statements will appear in this style.

1.4.2Conformance Requirements

Conformance requirements for this Implementation Guide are of two types: those that are collected within a published template of CDA/V3 conformance statements and those that are not associated with a published template. Where not associated with a published template, they are numbered sequentially and listed within the body of the Guide as follows:

CONF-HP-1: This is an example conformance requirement original to this Guide.

Where conformance requirements are associated with a template, they are included through assertion of a Template Identifier and listed in Appendix D using the original numbering from the source Guide:

In the body of the Guide:

CONF-HP-2:All constraints from this section are from CCD. See Appendix D for CCD conformance requirements.This section SHALL include theCCD template identifier for the immunizations section is 2.16.840.1.113883.10.20.1.6.

In Appendix D:

CONF-HP-1:CCD CONF-378: The immunizations section SHALL contain Section / code.

CONF-HP-2:CCD CONF-379: The value for “Section / code” SHALL be “11369-6” “History of immunizations” 2.16.840.1.113883.6.1 LOINC STATIC.

CONF-HP-3:CCD CONF-380: The immunizations section SHALL contain Section / title.

CONF-HP-4:CCD CONF-381: Section / title SHOULD be valued with a case-insensitive language-insensitive text string containing “immunization”.

1.4.3XPath Notation

Instead of the traditional dotted notation used by HL7 to represent RIM classes, this guide uses XPath notation in conformance statements and elsewhere to identify the XML elements and attributes within the CDA document instance to which various constraints are applied. The implicit context of these expressions is the root of the document. The purpose of using this notation is to provide a mechanism which will be familiar to developers for identifying parts of an XML document.

1.4.4Key Words

The key words "shall", "shall not", "should", "should not", "may", and "need not" in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.

1.4.5XML Samples

XML Samples appear in various figures in this document in a fixed font. Portions of the XML content may be elided from the content for brevity. These are marked by a vertical ellipses, as shown in the example below.

</ClinicalDocument>

Within the narrative, XML element and attribute names in the text will appear in this font. Literal attribute values will appear in this font.

XPath expressions are used in the narrative and conformance requirements to identify elements. These were chosen because they are familiar to many XML implementers.

1.4.6Content of the Ballot Package

The ballot package contains the following files:

Filename / Description
cda4cdt_HandP.pdf / This guide
HandP.schema.sch / The Schematron schema found in Appendix A.
HandP.schema.xsl / An XSLT stylesheet that performs the same Schematron processing as the Schematron schema.
HandP.sample.xml / The sample CDA document found in Appendix B and C.
HandP.voc.xml / A vocabulary data file used by both the Schematron schema and the display stylesheet.
CCD.xsl / A stylesheet for displaying the content of the sample document in HTML.

Table 1 Contents of the Ballot Package

1.4.6.1Sample XML

A sample document is provided which conforms to the level 1 and level 2 constraints of this guide. Unlike some previous Implementation Guides, this sample document is an actual sample of a patient’s History & Physical note, with the name changed for privacy of the patient. It was provided by a project participant and used as a test of the IG design. Because it is drawn from actual practice, rather than composed to illustrate the Guide, it covers all requirements and some of the options described here. It is the source of some, not all, of the examples provided in this guide.

[NOTE: may add level 3 markup to sample; if so, indicate here]

1.5Scope

This specification defines additional constraints on CDA Header and Body elements used in a History & Physical document in the US realm, and provides examples of conforming fragments in the body of the document and an example of a conforming XML instance as an appendix.

This Guide specifies three levels of conformance requirements. Level 1 requirements specify constraints upon the CDA Header and the content of the document. Level 2 requirements specify constraints at the section level of the structuredBody of the ClinicalDocument element of the CDA document. Level 3 requirements specify constraints at the entry level within a section.

At this time, all Level 3 requirements are drawn directly from the HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD). Future work may add Level 3 constraints beyond those specified for CCD.

Additional realms and/or internationalization of this document may be considered in future HL7 informative documents. The specification of workflows, messages, or procedures used to negotiate the transfer of care or referral is outside the scope of this specification.

CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to the Level 1, Level 2 or Level 3 constraints specified in this implementation guide.

<templateId extension='IMPL_CDAR2_LEVEL1' root='CDA4CDT-OID-H-AND-P-OID/>

</ClinicalDocument>

Figure 1 Use of the templateId element to indicate use of this guide.

Within this guide, the required and optional content within the body are identified. This guide describes the information content of each section, but this cannot be verified by software.

1.5.1Future Work

Future work includes the definition of increasing refined (granular) machine-verifiable processing structures including mapping all requirements for processing the components of Evaluation and Management service level.

This work will be performed in conjunction other HL7 technical committees and in cooperation with professional societies and other SDOs. There are many parallel efforts to create CDA Implementation Guides. Future work will address libraries of templates, including those defined and reused here, and refinement of the document type hierarchy.

Future editions of this Implementation Guide may constrain the History & Physical according to clinical setting and/or specialty.

Additional work may harmonize this specification with History & Physical implementations outside the US.

2CDA Header – General Constraints

2.1ClinicalDocument

The namespace for CDA Release 2.0 is urn:hl7-org:v3. Appropriate namespace declarations shall be used in the XML instance of the Clinical Document. In the examples in this specification, all elements are shown un-prefixed, assuming that the default namespace is declared to be urn:hl7-org:v3. This guide does not require use of any specific namespace prefix. Instances should not include the xsi:schemaLocation[1]element.

The root of a History & Physicalshall be a ClinicalDocument element from the urn:hl7-org:v3 namespace.

CONF-HP-5:A document conforming to the general constraints in this guide SHALLindicate so by including the following template id in the header of the document:

<title>Good Health Clinic History & Physical</title>

<versionNumber value='1'/>
:

</ClinicalDocument>

Figure 2ClinicalDocument Example

2.1.1General Constraints

Within the clinical document header[2], the following general guidelines have been applied:

To support communication between the receiver of the document and the patient or any other person or organization mentioned within it, the elements representing them shall provide a name. All persons should, and the patient, assigned healthcare providers and other persons or organizations associated with the healthcare of the patient shall supply addr and telecom elements. Although the dataEnterer represents an assigned person, they are not (usually) an assigned healthcare provider, and are therefore not included by this constraint.

CONF-HP-6:All patient, guardianPerson, assignedPerson, maintainingPerson, relatedPerson, intendedRecipient/informationRecipient, associatedPerson, and relatedSubject/subject elements shall have a name.

CONF-HP-7:All patientRole, assignedAuthor, assignedEntity[not(parent::dataEnterer)] and associatedEntity elements shall have an addr and telecom element.

CONF-HP-8:All guardian, dataEnterer/assignedEntity, relatedEntity, intendedRecipient, relatedSubject and participantRole elements should have an addr and telecom element.

CONF-HP-9:All guardianOrganization, providerOrganization, wholeOrganization, representedOrganization, representedCustodianOrganization, recievedOrganization, scopingOrganization and serviceProviderOrganization elements shall have name, addr and telecom elements.

When name, addr or telecom information is unknown and where these elements are required to be present, the fact that the information is unknown shall be represented using an appropriate value for the nullFlavor attribute on the element. Legal values according to this specification come from the HL7 NullFlavor vocabulary. Use of nullFlavor is shown below in Figure 3.

</assignedPerson>

</assignedEntity>

Figure 3 Various Uses of nullFlavor

Events occurring at a single point in time which are represented in the in the Clinical Document header will in general be precise to the day. An exception is made for the patient birth time (which may only be approximately known). These point in time events are the time of creation of the document, or the starting time of a participation by an author, data enterer, authenticator or legal authenticator, or the starting and ending time of an encounter. Other times or intervals in time represented in the Clinical Document header shall be precise at least to the year, should be precise to the day, and may omit time zone.