CDAR2_IG_ORTHO_ATTACH_R1_D1_2018SEP

 

 

HL7-International-Logo_2_x2

 

 

 

HL7 CDA® R2 Implementation Guide:

Orthodontic Attachment,

Release 1 – US Realm

 

August 2018

 

 

HL7 STU Ballot

 

 

 

Sponsored by:
Attachments Work Group

Structured Documents Work Group

 

 

 

 

 

 

 

Copyright © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

Use of this material is governed by HL7's IP Compliance Policy .

Primary Editor

Russell Ott
Deloitte Consulting LLP
rott@deloitte.com

Co-Chair

Durwin Day

Health Care Service Corporation

dayd@bcbsil.com

Co-Chair:

Craig Gabron

cgabron@sc.rr.com

Co-Chair

Christol Green

Anthem, Inc.

christol.green@anthem.com

Co-Editor

Mimi Boussouf

Deloitte Consulting LLP

mboussouf@deloitte.com

Co-Editor

Christopher Brancato
Deloitte Consulting LLP
cbrancato@deloitte.com

Co-Editor

Carla Evans DDS DMSc

Boston University

caevans@bu.edu

Co-Editor

Jeffrey A. Ford DMD

Lt Col, United States Air Force

jeffrey.a.ford28.mil@mail.mil

Co-Editor

Brett Marquard
WaveOne Associates
brett@waveoneassociates.com

Co-Editor

Jean Narcisi

American Dental Association

narcisij@ada.org

Co-Editor

Nancy Orvis

Defense Health Agency

nancy.j.orvis.civ@mail.mil

 

 

Current Work Group includes those who participated in the Attachments Workgroup Orthodontic Attachment IG project:  Jeff Ford, Nancy Orvis, Chris Brancato, Jean Narcisi, Mimi Boussouf, Carla Evans, Antonio Magni, Chris Hills, Jean Lose, Brett Marquard, Rod Dubois

 

 

 

Acknowledgments

This guide was developed and produced through the efforts of Health Level Seven (HL7).

The editors appreciate the support and sponsorship of the HL7 Attachments Working Group, the HL7 Structured Documents Working Group (SDWG), and all volunteers and staff associated with the creation of this document. This guide would not have been possible without the support of the Defense Health Agency and the American Dental Association.

This material contains content from SNOMED CT® ( http://www.ihtsdo.org/snomed-ct/ ). SNOMED CT is a registered trademark of the International Health Terminology Standard Development Organization (IHTSDO).

This material contains content from SNODENT® ( http://www.ada.org/snodent ). SNODENT is a registered trademark of the American Dental Association (ADA). Licensing information is available at http://www.ada.org/8466.aspx .

This material contains content from LOINC® ( http://loinc.org ). The LOINC table, LOINC codes, LOINC panels and forms file, LOINC linguistic variants file, LOINC/RSNA Radiology Playbook, and LOINC/IEEE Medical Device Code Mapping Table are copyright © 1995-2016, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license at http://loinc.org/terms-of-use .

Table of Contents

1 Introduction .................................................................

1.1 Purpose .................................................................

1.2 Audience ................................................................

1.3 Organization of the Guide .....................................................

2 Background on Orthodontic Exams and Attachments ......................................

2.1 Background: Orthodontic Attachments .............................................

2.2 Background: Orthodontic Exams .................................................

2.3 Sample Orthodontic Exam User Story .............................................

3 Using This Implementation Guide ...................................................

3.1 Conformance Conventions Used in This Guide .......................................

3.1.1 Templates and Conformance Statements ........................................

3.1.2 Open and Closed Templates ................................................

3.1.3 Conformance Verbs (Keywords) .............................................

3.1.4 Cardinality ...........................................................

3.1.5 Optional and Required with Cardinality ........................................

3.1.6 Containment Relationships

3.1.7 Vocabulary Conformance .................................................

3.1.8 Data Types ...........................................................

3.1.9 Document-Level Templates "Properties" Heading ..................................

3.2 XML Conventions Used in This Guide .............................................

3.2.1 XPath Notation ........................................................

3.2.2 XML Examples and Sample Documents ........................................

4 References ..................................................................

5 document ...................................................................

5.1 Orthodontic Claim Attachment Document ...........................................

5.2 US Realm Header (V3) .......................................................

5.2.1 Properties ............................................................

6 section .....................................................................

6.1 Orthodontic Observations Section ................................................

6.2 Orthodontic Salzmann Malocclusion Severity Assessment Section ..........................

7 entry ......................................................................

7.1 Airway Problems Impacting Orthodontic Treatment Activity ..............................

7.2 Craniofacial Anomaly Observation ...............................................

7.3 Dental Abnormality Impacting Orthodontic Treatment Observation ..........................

7.4 Dental Closed-Spaced Teeth Count Observation ......................................

7.5 Dental Crossbite Teeth Count Observation ..........................................

7.6 Dental Crowded Teeth Count Observation ..........................................

7.7 Dental Crowding Observation ..................................................

7.8 Dental Missing Teeth Count Observation ...........................................

7.9 Dental Openbite Observation ...................................................

7.10 Dental Openbite Teeth Count Observation ......................................

7.11 Dental Open-Spaced Teeth Count Observation ...................................

7.12 Dental Overbite Observation ...............................................

7.13 Dental Overbite Teeth Count Observation ......................................

7.14 Dental Overjet Observation ................................................

7.15 Dental Overjet Teeth Count Observation .......................................

7.16 Dental Posterior Inter-Arch Deviation Observation ................................

7.17 Dental Rotated Teeth Count Observation .......................................

7.18 Dental Spacing Observation ................................................

7.19 Dentition Stage Observation ...............................................

7.20 Labiolingual Deviation Observation ..........................................

7.21 Orthodontic Asymmetry of Lower Face Activity ..................................

7.22 Orthodontic Benefits Requested Observation ....................................

7.23 Orthodontic Condylar Abnormality Activity .....................................

7.24 Orthodontic Diagnostic Feature Observation .....................................

7.25 Orthodontic Habits Activity ................................................

7.26 Orthodontic Medical Conditions Activity .......................................

7.27 Orthodontic Narrative Activity ..............................................

7.28 Orthodontic Precondition Observation .........................................

7.29 Orthodontic Severe Traumatic Deviations Activity .................................

7.30 Orthognathic Surgery Possibility Activity .......................................

7.31 Salzmann Index Observation ...............................................

8 US Realm Header Supporting Templates ..............................................

8.1 US Realm Address (AD.US.FIELDED) ............................................

8.2 US Realm Date and Time (DTM.US.FIELDED) ......................................

8.3 US Realm Patient Name (PTN.US.FIELDED) ........................................

8.4 US Realm Person Name (PN.US.FIELDED) .........................................

9 Template Ids in This Guide .......................................................

10 Value Sets In This Guide .........................................................

11 Code Systems in This Guide ......................................................

Table of Figures

Figure 1: Examples of Conditions Recorded in Orthodontic Exams .......................................

Figure 2: Constraint Conformance Including "such that it" Syntax Example .................................

Figure 3: Constraints Format – only one allowed ...................................................

Figure 4: Constraints Format – only one like this allowed .............................................

Figure 5: Binding to a Single Code ............................................................

Figure 6: XML Expression of a Single-Code Binding ................................................

Figure 7: Translation Code Example ...........................................................

Figure 8: XML Document Example ...........................................................

Figure 9: XPath Expression Example ..........................................................

Figure 10: ClinicalDocument Example .........................................................

Figure 11: Orthodontic Claims Attachment Document Service Event Sample ................................

Figure 12: US Realm Header (V3) Example ......................................................

Figure 13: recordTarget Example .............................................................

Figure 14: author Example .................................................................

Figure 15: dateEnterer Example ..............................................................

Figure 16: Assigned Health Care Provider informant Example ..........................................

Figure 17: Personal Relation informant Example ...................................................

Figure 18: custodian Example ...............................................................

Figure 19: informationRecipient Example .......................................................

Figure 20: Digital signature Example ..........................................................

Figure 21: legalAuthenticator Example .........................................................

Figure 22: authenticator Example .............................................................

Figure 23: Supporting Person participant Example ..................................................

Figure 24: inFulfillmentOf Example ...........................................................

Figure 25: performer Example ...............................................................

Figure 26: documentationOf Example ..........................................................

Figure 27: authorization Example .............................................................

Figure 28: Orthodontic Observations Section Sample ................................................

Figure 29: Orthodontic Salzmann Malocclusion Severity Assessment Section Sample ..........................

Figure 30: Airway Problems Impacting Orthodontic Treatment Activity Sample ..............................

Figure 31: Craniofacial Anomalies Observation Sample ..............................................

Figure 32: Dental Abnormalities Impacting Orthodontic Treatment Observation Sample .........................

Figure 33: Dental Closed-Spaced Teeth Count Observation Sample ......................................

Figure 34: Dental Crossbite Teeth Count Observation ...............................................

Figure 35: Dental Crowded Teeth Count Observation Sample ..........................................

Figure 36: Dental Crowding Observation Sample ..................................................

Figure 37: Dental Missing Teeth Count Observation Sample ...........................................

Figure 38: Dental Openbite Observation Sample ...................................................

Figure 39: Dental Openbite Teeth Count Observation Sample ..........................................

Figure 40: Dental Open-Spaced Teeth Count Observation Sample .......................................

Figure 41: Dental Overbite Observation Sample ...................................................

Figure 42: Dental Overbite Teeth Count Observation Sample ...........................................

Figure 43: Dental Overjet Observation Sample ....................................................

Figure 44: Dental Overjet Teeth Count Observation .................................................

Figure 45: Dental Posterior Inter-Arch Deviation Observation ..........................................

Figure 46: Dental Rotated Teeth Count Observation Sample ...........................................

Figure 47: Dental Spacing Observation Sample ....................................................

Figure 48: Dentition Stage Observation Sample ...................................................

Figure 49: Labiolingual Deviation Observation Sample ..............................................

Figure 50: Orthodontic Asymmetry of Lower Face Activity Sample ......................................

Figure 51: Orthodontic Benefits Requested Observation Sample .........................................

Figure 52: Orthodontic Diagnostic Features Observation ..............................................

Figure 53: Orthodontic Habits Activity .........................................................

Figure 54: Orthodontic Medical Conditions Activity Sample ...........................................

Figure 55: Orthodontic Narrative Activity Sample ..................................................

Figure 56: Orthodontic Precondition Observation Sample .............................................

Figure 57: Orthodontic Severe Traumatic Deviations Activity Sample .....................................

Figure 58: Orthognathic Surgery Possibility Activity Sample ...........................................

Figure 59: Salzmann Index Observation Sample ...................................................

Figure 60: US Realm Address Example .........................................................

Figure 61: US Realm Date and Time Example ....................................................

Figure 62: US Realm Patient Name Example .....................................................

Table of Tables

Table 1: Contexts Table Example—Allergy Concern Act (V2) ..........................................

Table 2: Constraints Overview Example—Allergy Concern Act (V2) .....................................

Table 3: Example Value Set Table (Referral Types) .................................................

Table 4: Orthodontic Claim Attachment Document Contexts ...........................................

Table 5: Orthodontic Claim Attachment Document Constraints Overview ..................................

Table 6: US Realm Header (V3) Contexts .......................................................

Table 7: US Realm Header (V3) Constraints Overview ...............................................

Table 8: Race ..........................................................................

Table 9: HL7 BasicConfidentialityKind .........................................................

Table 10: Language ......................................................................

Table 11: Telecom Use (US Realm Header) ......................................................

Table 12: Administrative Gender (HL7 V3) ......................................................

Table 13: Marital Status ...................................................................

Table 14: Religious Affiliation ...............................................................

Table 15: Race Category Excluding Nulls .......................................................

Table 16: Ethnicity ......................................................................

Table 17: Personal And Legal Relationship Role Type ...............................................

Table 18: Country .......................................................................

Table 19: LanguageAbilityMode .............................................................

Table 20: LanguageAbilityProficiency .........................................................

Table 21: Detailed Ethnicity ................................................................

Table 22: Healthcare Provider Taxonomy (HIPAA) .................................................

Table 23: INDRoleclassCodes ...............................................................

Table 24: x_ServiceEventPerformer ...........................................................

Table 25: ParticipationFunction ..............................................................

Table 26: Orthodontic Observations Section Contexts ...............................................

Table 27: Orthodontic Observations Section Constraints Overview .......................................

Table 28: Orthodontic Salzmann Malocclusion Severity Assessment Section Contexts ..........................

Table 29: Orthodontic Salzmann Malocclusion Severity Assessment Section Constraints Overview .................

Table 30: Airway Problems Impacting Orthodontic Treatment Activity Contexts ..............................

Table 31: Airway Problems Impacting Orthodontic Treatment Activity Constraints Overview .....................

Table 32: Craniofacial Anomaly Observation Contexts ...............................................

Table 33: Craniofacial Anomaly Observation Constraints Overview ......................................

Table 34: Craniofacial Anomaly ..............................................................

Table 35: Dental Abnormality Impacting Orthodontic Treatment Observation  Contexts .........................

Table 36: Dental Abnormality Impacting Orthodontic Treatment Observation  Constraints Overview ................

Table 37: Dental Abnormality Impacting Orthodontic Treatment ........................................

Table 38: Dental Universal Numbering System ....................................................

Table 39: Dental Closed-Spaced Teeth Count Observation Contexts ......................................

Table 40: Dental Closed-Spaced Teeth Count Observation Constraints Overview .............................

Table 41: Oral Cavity Area .................................................................

Table 42: Dental Crossbite Teeth Count Observation Contexts ..........................................

Table 43: Dental Crossbite Teeth Count Observation Constraints Overview .................................

Table 44: Dental Crowded Teeth Count Observation Contexts ..........................................

Table 45: Dental Crowded Teeth Count Observation Constraints Overview .................................

Table 46: Dental Crowding Observation Contexts ..................................................

Table 47: Dental Crowding Observation Constraints Overview .........................................

Table 48: Dental Missing Teeth Count Observation Contexts ...........................................

Table 49: Dental Missing Teeth Count Observation Constraints Overview ..................................

Table 50: Dental Openbite Observation Contexts ...................................................

Table 51: Dental Openbite Observation Constraints Overview ..........................................

Table 52: Dental Openbite Teeth Count Observation Contexts ..........................................

Table 53: Dental Openbite Teeth Count Observation Constraints Overview .................................

Table 54: Dental Open-Spaced Teeth Count Observation Contexts .......................................

Table 55: Dental Open-Spaced Teeth Count Observation Constraints Overview ..............................

Table 56: Dental Overbite Observation Contexts ...................................................

Table 57: Dental Overbite Observation Constraints Overview ..........................................

Table 58: Dental Overbite Teeth Count Observation Contexts ..........................................

Table 59: Dental Overbite Teeth Count Observation Constraints Overview ..................................

Table 60: Dental Overjet Observation Contexts ....................................................

Table 61: Dental Overjet Observation Constraints Overview ...........................................

Table 62: Dental Overjet Teeth Count Observation Contexts ...........................................

Table 63: Dental Overjet Teeth Count Observation Constraints Overview ..................................

Table 64: Dental Posterior Inter-Arch Deviation Observation Contexts ....................................

Table 65: Dental Posterior Inter-Arch Deviation Observation Constraints Overview ............................

Table 66: Dental Posterior Inter-Arch Deviation Type ...............................................

Table 67: Salzmann Index Inter-Arch Deviation Maxillary Tooth ........................................

Table 68: Dental Rotated Teeth Count Observation Contexts ...........................................

Table 69: Dental Rotated Teeth Count Observation Constraints Overview ..................................

Table 70: Dental Spacing Observation Contexts ...................................................

Table 71: Dental Spacing Observation Constraints Overview ...........................................

Table 72: Jaw Type ......................................................................

Table 73: Dentition Stage Observation Contexts ...................................................

Table 74: Dentition Stage Observation Constraints Overview ...........................................

Table 75: Dentition State ..................................................................

Table 76: Labiolingual Deviation Observation Contexts ..............................................

Table 77: Labiolingual Deviation Observation Constraints Overview .....................................

Table 78: Orthodontic Asymmetry of Lower Face Activity Contexts ......................................

Table 79: Orthodontic Asymmetry of Lower Face Activity Constraints Overview .............................

Table 80: Orthodontic Benefits Requested Observation Contexts ........................................

Table 81: Orthodontic Benefits Requested Observation Constraints Overview ................................

Table 82: Orthodontic Condylar Abnormality Activity Contexts .........................................

Table 83: Orthodontic Condylar Abnormality Activity Constraints Overview ................................

Table 84: Orthodontic Diagnostic Feature Observation Contexts ........................................

Table 85: Orthodontic Diagnostic Feature Observation Constraints Overview ................................

Table 86: Orthodontic Diagnostic Feature .......................................................

Table 87: Orthodontic Habits Activity Contexts ...................................................

Table 88: Orthodontic Habits Activity Constraints Overview ...........................................

Table 89: Orthodontic Medical Conditions Activity Contexts ...........................................

Table 90: Orthodontic Medical Conditions Activity Constraints Overview ..................................

Table 91: Orthodontic Narrative Activity Contexts .................................................

Table 92: Orthodontic Narrative Activity Constraints Overview .........................................

Table 93: Orthodontic Precondition Observation Contexts .............................................

Table 94: Orthodontic Precondition Observation Constraints Overview ....................................

Table 95: Orthodontic Treatment Precondition ....................................................

Table 96: Orthodontic Severe Traumatic Deviations Activity Contexts ....................................

Table 97: Orthodontic Severe Traumatic Deviations Activity Constraints Overview ............................

Table 98: Orthognathic Surgery Possibility Activity Contexts ..........................................

Table 99: Orthognathic Surgery Possibility Activity Constraints Overview ..................................

Table 100: Salzmann Index Observation Contexts ..................................................

Table 101: Salzmann Index Observation Constraints Overview .........................................

Table 102: US Realm Address (AD.US.FIELDED) Contexts ...........................................

Table 103: US Realm Address (AD.US.FIELDED) Constraints Overview ..................................

Table 104: PostalAddressUse ...............................................................

Table 105: StateValueSet ..................................................................

Table 106: PostalCode ....................................................................

Table 107: US Realm Date and Time (DTM.US.FIELDED) Contexts .....................................

Table 108: US Realm Date and Time (DTM.US.FIELDED) Constraints Overview ............................

Table 109: US Realm Patient Name (PTN.US.FIELDED) Contexts ......................................

Table 110: US Realm Patient Name (PTN.US.FIELDED) Constraints Overview ..............................

Table 111: EntityNameUse .................................................................

Table 112: EntityPersonNamePartQualifier ......................................................

Table 113: US Realm Person Name (PN.US.FIELDED) Contexts ........................................

Table 114: US Realm Person Name (PN.US.FIELDED) Constraints Overview ...............................

Table 115: Template List ..................................................................

Table 116: Template Containments ............................................................

Table 117: Value Sets ....................................................................

Table 118: Code Systems ..................................................................

1          Introduction

1.1         Purpose

The purpose of this implementation guide is to provide a HL7 CDA-based set of templates defining a standardized document that can be used to convey supporting clinical documentation from a dental provider to a payer (e.g., insurance company) to substantiate a claim for orthodontic care.

This publication provides the data model, defined data items and their corresponding code and value sets, if available, specific to a orthodontic attachment for the following applications.

  • Those codes that identify the attachment or attachment components used in transactions such as those defined by the ASC X12N 277 Health Care Claim Request for Additional Information and the ASC X12N 275 Additional Information to Support a Health Care Claim or Encounter implementation guides.
  • Those codes used in HL7 Clinical Document Architecture (CDA) documents designed for inclusion in the BIN segment of the 275 transaction set as described in the HL7 Additional Information Specification Implementation Guide.

 

The document leverages several observations that are already in use today. This was done to provide consistency to the doctrine of repurpose and reuse found within the CDA.

This document is heavily based on the American National Standard/American Dental Association (ANS/ADA) Specification Number 1079; Standard Content of Electronic Attachments for Dental Claims, 2015.

All proprietary documents, guides, guidance, standards, codes and values contained herein remain the property of their respective Standards Designating Organization. HL7 does not make any claim to ownership herein.

Where possible, it has been designed to align with design patterns present in the Release 2.1 version of the Consolidated CDA Temfplates for Clinical Notes.

This guide, in conjunction with the HL7 CDA Release 2 (CDA R2) standard, is to be used for implementing Orthodontic Attachment CDA documents.

1.2         Audience

The audience for this implementation guide includes architects and developers of dental health information technology and dental payer systems in the US Realm. Business analysts and policy managers can also benefit from a basic understanding of the use of orthodontic attachments to support both claim substantiation, as well as secondary use for dental care coordination.

1.3              Organization of the Guide

This document provides background on the use of Orthodontic Attachments, and detailed documentation of how to use the included CDA templates and supporting terminologies to construct CDA-based Orthodontic Attachments.

 

 

2                    Background on Orthodontic Exams and Attachments

2.1              Background: Orthodontic Attachments

 

The Orthodontic attachment is used to convey information about orthodontic related services.   This includes the business use of claims attachments, prior authorization and pre-determinations.   It may also be used for other clinical data exchange functions as needed. The items defined for electronic supporting documentation were developed by the Standards Committee on Dental Informatics of the American Dental Association (ADA).   Many of the items described in the attachments are based on an analysis of paper forms that have been used by dentists and payers in the past. Each possible attachment item, however, has been reviewed for appropriateness in an electronic format.   This standard does not include diagnostic quality scanned images, or digital images in DICOM or other image file types to represent radiographs or pictures of patient conditions. These are included in a separate attachment if needed.

 

Currently the industry is capturing and sending orthodontic exam information which is transferred to electronic systems in the form of unstructured data.   The authors respectfully believe that by creating new document types to support these data, claims processing speed will be increased and the overall delivery and payment of care will be made more interoperable through the use of standardized document types fit for this purpose.  

 

The orthodontic claim attachment may be originated in two ways:   solicited – where the payer requires information after a claim for payment was received and processed, and unsolicited – where the orthodontic claim attachment is sent when the provider is sending and electronic claim for payment without a request from the payer.  

 

2.2              Background: Orthodontic Exams

 

The Orthodontic Exam is a series of physical observations and measurements starting with an interview with the patient (and parent as appropriate) to gather information concerning history and reasons for treatment, including patient (and or parent) complaints and psychosocial needs. The clinical exam follows to evaluate overall and oral health, jaw function, facial form, dental occlusion, and growth status parameters. Other observations include the functional status (habits, functional shifts of the mandible, temporomandibular joint dysfunction), and any deviations from normal standards.   Third, diagnostic records are made and analyzed for dentofacial esthetics and alignment of the jaws and dentition in all three planes of space (transverse, antero-posterior, and vertical). Included in this exam is the evaluation for the presence of pathology, such as, caries, periodontal disease, 1 and hard/soft tissue abnormalities of the head / neck regions.   The patient’s oral hygiene status is recorded at the exam and every subsequent visit thereafter.

 

The exam data and information are gathered into a diagnostic database for the patient and used to formulate a problem list / diagnosis.   This listing (or diagnosis) is used to formulate a treatment plan stating: “the timing of treatment, complexity of the treatment required, predictability of success with given treatment approach, and the patient’s (and parents when appropriate) goals and desires.” [1] Patients (and parents when appropriate) are informed of the diagnosis and treatment plan option(s).   The provider reviews treatment options and therapeutic limitations (effectiveness based on evidence) with the patient and a treatment option is chosen. These options are usually determined for the dentition phase the patient is in:   primary, mixed, or permanent. For example, options can include (but are not limited to): non-extraction or extraction of teeth (primary and/or permanent) and orthodontic alignment of teeth growth modification appliances, or orthognathic surgery.

(Timing of treatment is related to function, growth status, psychosocial status.)

 

See Figure 1 : Examples of Conditions Recorded in Orthodontic Exams below for examples of the type of conditions recorded in the course of Orthodontic Exams.

Figure 1 : Examples of Conditions Recorded in Orthodontic Exams

 

 

 


 

2.3              Sample Orthodontic Exam User Story

 

Susan Smith is an eleven-year-old girl referred to an orthodontic provider, Dr. Smiles, by her dentist for evaluation of her large overjet and deep impinging overbite.   Her mother has brought her in today for what Susan says in her own words, “my buck teeth are really bothering me.” She expresses being teased in school and her mother states Susan’s grades and self-esteem appear to be lowering.  

Susan is in the 5th grade and lives with her mother, father and one younger brother (Johnny, age 6) at 12345 Pinetree Ln, Fairfax, VA 22022.   Other demographic information is collected along with payer information from insurance and any out-of-pocket costs are discussed.

 

Mrs. Smith provides a medical history for Susan which includes a list of medications and allergies (environmental, medications, and food).   The referring dentist provided a panoramic radiograph dated last month. Dr. Smiles orders a lateral-cephalometric radiograph and reviews this information and directs her staff to enter dictated information into Susan’s dental record system while she performs a comprehensive orthodontic examination.  

 

The exam begins with a an evaluation of the growth patterns of the face and jaw relations followed by a gross examination of the mouth.   Notes are made about the general health of the hard and soft tissue structures (including all teeth) of the oral cavity. Radiographs are reviewed and commented on.   Dr. Smiles performs a Periodontal Screening and Recording (PSR) and expresses Susan’s oral hygiene is excellent. Dr. Smiles also evaluates Susan’s speech, muscles of facial expression, temporomandibular joint function and occurrence of oral habits.

 

During the evaluation, Dr. Smiles compiles the problem list/diagnosis.   Susan has a retrognathic (mandible) jaw causing a convex facial profile.   Dr. Smiles notes that the upper and lower dentitions display 4mm and 5mm of anterior crowding respectfully with a tapered maxillary arch form.   There is 10mm’s of overjet and the dentition is in complete molar and canine bilateral class II relationships. The midlines are coincident but the posterior is constricted on both sides.   Dr. Smiles notes that there will be a bilateral dental posterior cross-bite when the jaws are corrected to class I. The overbite is 10mm (100%) and is causing tissue damage to the incisive papilla.   Dr. Smiles notes that the deep Curve of Spee and mandibular supraeruption of the lower incisors is adding to the vertical problems.

 

Dr. Smiles observes that Susan is in zone for optimal growth modification treatment and discusses options with Mrs. Smith for non-extraction, class II appliance treatment with expansion of the upper arch.   Susan also understands and is excited to start treatment right away if possible.

 

Mrs. Smith and Susan agree to further diagnostic records and Dr. Smiles’ staff proceed to make extra and intraoral photographs along with alginate impressions of the upper and lower dentition with occlusal record (centric relation).   In some cases, digital scanning by use of Cone Beam Computed Tomography or digital intraoral scanning is used. This completes the initial records. Dr. Smiles’ staff re-schedules Susan for an appointment to discuss the final diagnosis and all treatment plan options after Dr. Smiles reviews all information gathered.  

3          Using This Implementation Guide

The authors of this guide recommend implementers of this standard reference the invaluable content in Section 4: “Using this Implementation Guide” of Volume 1 of HL7 CDA R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2.1.

In the interest of providing a single reference for implementers, the most important content from that section has been reprinted in this section with minor modifications to reflect this publication.

 

3.1         Conformance Conventions Used in This Guide

3.1.1         Templates and Conformance Statements [2]

Conformance statements within this implementation guide are presented as constraints from Trifolia Workbench, a template repository. An algorithm converts constraints recorded in Trifolia to a printable presentation. Each constraint is uniquely identified by an identifier at or near the end of the constraint (e.g., CONF:86-7345). The digits in the conformance number before the hyphen identify which implementation guide the template belongs to and the number after the hyphen is unique to the owning implementation guide. Together, these two numbers uniquely identify each constraint. These identifiers are persistent but not sequential. Conformance numbers in this guide associated with a conformance statement that is carried forward from a previous version of this guide will carry the same conformance number from the previous version. This is true even if the previous conformance statement has been edited. If a conformance statement is entirely new it will have a new conformance number.

Bracketed information following each template title indicates the template type (section, observation, act, procedure, etc.), the object identifier (OID) or uniform resource name (URN) , and whether the template is open or closed . The identifier OID is the templateId/@root value ; all templateIds have an @root value. Versioned templates also have an @extension value, which is a date identifying the version of this template; such templates are identified by URN and the HL7 version ( urn:hl7ii ). The URN identifier includes both the @root and @extension value for the templateId (for example, identifier urn:hl7ii:2.16.840.1.113883.10.20.5.5.41:2014-06-09 ).

Each section and entry template in this guide includes a context table. The "Contained By" column indicates which templates use this template, and if the template is optional or required in the containing template. The "Contains" column indicates any templates that the template uses.

Table 1 : Contexts Table Example— Allergy Concern Act (V2)

Contained By:

Contains:

Allergies and Intolerances Section (entries optional) (V2) (optional)

Allergies and Intolerances Section (entries required) (V2) (required)

Allergy - Intolerance Observation (V2)

Author Participation

 

Each entry template also includes a constraints overview table to summarize the constraints in the template.

Table 2 : Constraints Overview Example —Allergy Concern Act (V2)

XPath

Card.

Verb

Data Type

CONF#

Value

act (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.4.30:2014-06-09)

@classCode

1..1

SHALL

 

1098-7469

2.16.840.1.113883.5.6 (HL7ActClass) = ACT

@moodCode

1..1

SHALL

 

1098-7470

2.16.840.1.113883.5.1001 (ActMood) = EVN

templateId

1..1

SHALL

 

1098-7471

 

@root

1..1

SHALL

 

1098-10489

2.16.840.1.113883.10.20.22.4.30

@extension

1..1

SHALL

 

1098-32543

2014-06-09

...

 

 

 

 

 

 

The expression “such that it” at the end of one conformance statement links that conformance statement to the following subordinate conformance statement to further constrain the first conformance statement. To understand the full effect of this conformance construct, the two conformances must be considered as a single compound requirement. The subordinate conformance statement functions as a subordinate clause (like a "where" clause), which is being applied on the first conformance statement.

The following example shows a compound conformance statement made up of two conformance statements joined by a "such that it" clause. The effect of this syntax can be interpreted as a "where" clause. Thus...

  1. SHALL contain exactly one [1..1] templateId (CONF:81-7899) such that it
    1. SHALL contain exactly one [1..1] @root = "2.16.840.1.113883.10.20.22.4.31" (CONF:81-10487).

...is understood as:

This template SHALL contain exactly one [1..1] templateId where it contains exactly one [1..1] @root = "2.16.840.1.113883.10.20.22.4.31" .

This means that you must have a template id with @root = "2.16.840.1.113883.10.20.22.4.31", but you can also have other template ids with different valued attributes.

The following figure shows a typical template’s set of constraints presented in this guide. The next chapters describe specific aspects of conformance statements—open vs. closed templates, conformance verbs, cardinality, vocabulary conformance, containment relationships, and null flavors.


Figure 2 : Constraint Conformance Including "such that it" Syntax Example

3.1.2         Open and Closed Templates [3]

In open templates, all of the features of the CDA R2 base specification are allowed except as constrained by the templates. By contrast, a closed template specifies everything that is allowed and nothing further may be included.

Open templates allow HL7 implementers to develop additional structured content not constrained within this guide. HL7 encourages implementers to bring their use cases forward as candidate requirements to be formalized in a subsequent version of the standard to maximize the use of shared semantics.

3.1.3         Conformance Verbs (Keywords) [4]

The keywords shall , should , may , need not , should not , and shall not in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. [5]

  • shall : an absolute requirement
  • shall not : an absolute prohibition against inclusion
  • should/should not : best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
  • may/need not : truly optional; can be included or omitted as the author decides with no implications

The keyword " shall" allows the use of nullFlavor unless the requirement is on an attribute or the use of nullFlavor is explicitly precluded.

When conformance statements are nested (or have subordinate clauses) the conformance statements are to be read and interpreted in hierarchical order. These hierarchical clauses can be interpreted as "if then, else" clauses. Thus...

  1. This structuredBody SHOULD contain zero or one [0..1] component (CONF:1098-29066) such that it
    1. SHALL contain exactly one [1..1] Plan of Treatment Section (V2) (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.2.10:2014-06-09) (CONF:1098-29067).

...is understood as:

  1. It is recommended ( SHOULD ) that the structureBody contains a component.
    1. If the component exists, then it must contain a Plan of Treatment Section (V2),
    2. else the component does not exist, and the conformance statement about the Plan of Treatment Section (V2) should be skipped.

In the case where the higher level conformance statement is a SHALL, there is no conditional clause. Thus...

  1. This structuredBody SHALL contain exactly one [1..1] component (CONF:1098-29086) such that it
    1. SHALL contain exactly one [1..1] Problem Section (entries required) (V2) (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.2.5.1:2014-06-09) (CONF:1098-29087).

...means that the structuredBody is always required to have a component.

3.1.4         Cardinality [6]

The cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within a document instance. The cardinality indicators are interpreted with the following format “m…n” where m represents the least and n the most:

  • 0..1 zero or one
  • 1..1 exactly one
  • 1..* at least one
  • 0..* zero or more
  • 1..n at least one and not more than n

When a constraint has subordinate clauses, the scope of the cardinality of the parent constraint must be clear. In the next figure, the constraint says exactly one participant is to be present. The subordinate constraint specifies some additional characteristics of that participant.

Figure 3 : Constraints Format – only one allowed

1. SHALL contain exactly one [1..1] participant (CONF:2777).

     a. This participant SHALL contain exactly one [1..1] @typeCode ="LOC"
       ( CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType )
       (CONF:2230) .

In the next figure, the constraint says only one participant “like this” is to be present. Other participant elements are not precluded by this constraint.

Figure 4 : Constraints Format – only one like this allowed

1. SHALL contain exactly one [1..1] participant (CONF:2777) such that it

     a.  SHALL contain exactly one [1..1] @typeCode ="LOC" ( CodeSystem:

        2.16.840.1.113883.5.90 HL7ParticipationType) (CONF:2230).

3.1.5         Optional and Required with Cardinality [7]

The terms optional and required describe the lower bound of cardinality as follows:

Optional means that the number of allowable occurrences of an element may be 0; the cardinality will be expressed as [0..1] or [0..*] or similar. In these cases, the element may not be present in the instance. Conformances formulated with MAY or SHOULD are both considered "optional" conformances.

Required means that the number of allowable occurrences of an element must be at least 1; the cardinality will be expressed as [m..n], where m >=1 and n >=1 (for example, [1..1] or [1..*]). In these cases, the element must be present in the instance. Conformance statements formulated with SHALL are required conformances.

3.1.6         Containment Relationships [8]

Containment constraints between a section and its entries allow indirect containment in this guide. This means that where a section asserts containment of an entry, that entry either can be a direct child or a further descendent of that section.

For example, in the following constraint:

1.        SHALL contain at least one [1..*] entry ( CONF:8647) such that it

a.         SHALL contain exactly one [1..1] Advance Directive Observation

(templateId:2.16.840.1.113883.10.20.22.4.48) (CONF:8801).

The Advance Directive Observation can be a direct child of the section (i.e., section/entry/AdvanceDirectiveObservation ) or a further descendent of that section (i.e., section/entry/…/AdvanceDirectiveObservation ). Either of these are conformant.

All other constraints are direct and do not allow an indirect containment relationship, for example:

1.        SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.10.20.22.2.21 " ( CONF:7928 ).
 

The templateId must be a direct child of the section (i.e., section/templateId).

3.1.7         Vocabulary Conformance [9]

The templates in this document use terms from several code systems. These vocabularies are defined in various supporting specifications and may be maintained by other bodies, as is the case for the LOINC ® and SNOMED CT ® vocabularies.

Note that value set identifiers (e.g., ValueSet 2.16.840.1.113883.1.11.78 Observation Interpretation (HL7) DYNAMIC ) used in the binding definitions of template conformance statements do not appear in the XML instance of a CDA document. The definition of the template must be referenced to determine or validate the vocabulary conformance requirements of the template.

Value set bindings adhere to HL7 Vocabulary Working Group best practices, and include both an indication of stability and of coding strength for the binding. Value set bindings can be STATIC , meaning that they bind to a specified version of a value set, or DYNAMIC , meaning that they bind to the most current version of the value set. If a STATIC binding is specified, a date SHALL be included to indicate the value set version. If a DYNAMIC binding is specified, the value set authority and link to the base definition of the value set SHALL be included, if available, so implementers can access the current version of the value set. When a vocabulary binding binds to a single code, the stability of the binding is implicitly STATIC .

Figure 5 : Binding to a Single Code

2. SHALL contain exactly one [1..1] code (CONF:15403).

    a) This code SHALL contain exactly one [1..1] @ code = "11450-4" Problem List 

       (CONF:15408) .

    b) This code SHALL contain exactly one [1..1] @ codeSystem = "2.16.840.1.113883.6.1"  

       (CodeSystem: LOINC 2.16.840.1.113883.6.1 STATIC ) (CONF: 31141).

The notation conveys the actual code ( 11450-4 ), the code’s displayName (Problem List), the OID of the codeSystem from which the code is drawn (2.16.840.1.113883.6.1), and the codeSystemName (LOINC).

HL7 Data Types Release 1 requires the codeSystem attribute unless the underlying data type is “Coded Simple” or “CS”, in which case it is prohibited. The displayName and the codeSystemName are optional, but recommended, in all cases.

The above example would be properly expressed as follows.

Figure 6 : XML Expression of a Single-Code Binding

<code code= " 11450-4 " codeSystem= " 2.16.840.1.113883.6.1 " />

 

<!-- or -->

 

<code code= " 11450-4 " codeSystem= " 2.16.840.1.113883.6.1 "

      displayName= " Problem List "

      codeSystemName=”LOINC”/>

A full discussion of the representation of vocabulary is outside the scope of this document; for more information, see the HL7 V3 Normative Edition 2010 [10] sections on Abstract Data Types and XML Data Types R1.

There is a discrepancy between the HL7 R1 Data Types and this guide in the implementation of translation code versus the original code. The R1 data type requires the original code in the root. The convention agreed upon for this implementation guide specifies a code from the required value set be used in the element and other codes not included in the value set are to be represented in a translation for the element. This discrepancy is resolved in HL7 Data Types R2.

In the next example, the conformant code is SNOMED-CT code 206525008.

Figure 7 : Translation Code Example

<code code='206525008’

      displayName='neonatal necrotizing enterocolitis'
      codeSystem='2.16.840.1.113883.6.96'

      codeSystemName='SNOMED CT'>

   <translation code='NEC-1'

      displayName='necrotizing enterocolitis'

      codeSystem='2.16.840.1.113883.19'/>

</code>

Value set tables are present below a template, or are referenced if they occur elsewhere in the specification, when there are value set bindings in the template. The value set table provides the value set identifier, a description, and a link to the source of the value set when possible. Ellipses in the last row indicate the value set members shown are examples and the true source must be accessed to see all members.

If a value set binding has a DYNAMIC stability, implementers creating a CDA document must go to the location in the URL to check for the most current version of the value set expansion.

Table 3 : Example Value Set Table (Referral Types)

Value Set: Referral Types 2.16.840.1.113883.11.20.9.56

A value set of SNOMED-CT codes descending from "3457005" patient referral (procedure).

Value Set Source: http://vtsl.vetmed.vt.edu/TerminologyMgt/RF2Browser/ISA.cfm?SCT_ConceptID=3457005

Code

Code System

Code System OID

Print Name

44383000

SNOMED CT

2.16.840.1.113883.6.96

Patient referral for consultation

391034007

SNOMED CT

2.16.840.1.113883.6.96

Refer for falls assessment (procedure)

86395003

SNOMED CT

2.16.840.1.113883.6.96

Patient referral for family planning (procedure)

306106002

SNOMED CT

2.16.840.1.113883.6.96

Referral to intensive care service (procedure)

306140002

SNOMED CT

2.16.840.1.113883.6.96

Referral to clinical oncology service (procedure)

396150002

SNOMED CT

2.16.840.1.113883.6.96

Referral for substance abuse (procedure)

...

3.1.8         Data Types [11]

All data types used in a CDA document are described in the CDA R2 normative edition. [12] All attributes of a data type are allowed unless explicitly prohibited by this specification.

3.1.9         Document-Level Templates "Properties" Heading [13]

In Volume 2 of this implementation guide, each document-level template has a "Properties" heading for ease of navigation. The Properties heading is an organizational construct, underneath which relevant CDA act-relationships and roles are called out as headings in the document.

3.2              XML Conventions Used in This Guide

3.2.1         XPath Notation [14]

Instead of the traditional dotted notation used by HL7 to represent RIM classes, this document uses XML Path Language (XPath) notation [15] 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. This notation provides a mechanism that will be familiar to developers for identifying parts of an XML document.

XPath statements appear in this document in a monospace font.

XPath syntax selects nodes from an XML document using a path containing the context of the node(s). The path is constructed from node names and attribute names (prefixed by a ‘@’) and catenated with a ‘/’ symbol.

Figure 8 : XML Document Example

<author>

  <assignedAuthor>

  ...

    <code codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'

          code='17561000' displayName='Cardiologist' />

  ...

  </assignedAuthor>

</author>

In the above example, the code attribute of the code could be selected with the XPath expression in the next figure.

Figure 9 : XPath Expression Example

author/assignedAuthor/code/@code

3.2.2         XML Examples and Sample Documents [16]

Extensible Mark-up Language (XML) examples appear in figures in this document in this monospace font . XML elements ( code, assignedAuthor, etc.) and attribute names ( SNOMED CT, 17561000 , etc.) also appear in this monospace font . Portions of the XML content may be omitted from the content for brevity, marked by an ellipsis (...) as shown in the example below.

Figure 10 : ClinicalDocument Example

<ClinicalDocument xmls=”urn:hl7-org:v3”>

  ...

</ClinicalDocument>

 

4                    References

5                    document

5.1              Orthodontic Claim Attachment Document

[ClinicalDocument: identifier urn:hl7ii:2.16.840.1.113883.10.20.39.1.1:2018-08-01 (open)]

Table 4 : Orthodontic Claim Attachment Document Contexts

 

Document for providing supporting clinical information to substantiate a claim to a payer related to orthodontic care.

Table 5 : Orthodontic Claim Attachment Document Constraints Overview

XPath

Card.

Verb

Data Type

CONF#

Value

ClinicalDocument (identifier: urn:hl7ii:2.16.840.1.113883.10.20.39.1.1:2018-08-01)

templateId

1..1

SHALL

 

4376-365

 

@root

1..1

SHALL

 

4376-375

2.16.840.1.113883.10.20.39.1.1

@extension

1..1

SHALL

 

4376-548

2018-08-01

code

1..1

SHALL

 

4376-366

 

@code

1..1

SHALL

 

4376-376

urn:oid:2.16.840.1.113883.6.1 (LOINC) = TBD LOINC

@codeSystem

1..1

SHALL

 

4376-433

urn:oid:2.16.840.1.113883.6.1 (LOINC) = 2.16.840.1.113883.6.1

participant

0..*

SHOULD

 

4376-383

 

@typeCode

1..1

SHALL

 

4376-386

urn:oid:2.16.840.1.113883.5.90 (HL7ParticipationType) = CALLBCK

associatedEntity

1..1

SHALL

 

4376-384

 

@classCode

1..1

SHALL

 

4376-387

urn:oid:2.16.840.1.113883.5.110 (HL7RoleClass) = ASSIGNED

addr

0..*

SHOULD

 

4376-389

 

telecom

1..*

SHALL

 

4376-390

 

associatedPerson

1..1

SHALL

 

4376-385

 

name

1..*

SHALL

 

4376-391

 

scopingOrganization

0..1

MAY

 

4376-392

 

documentationOf

1..1

SHALL

 

4376-393

 

serviceEvent

1..1

SHALL

 

4376-394

 

@classCode

1..1

SHALL

 

4376-397

urn:oid:2.16.840.1.113883.5.6 (HL7ActClass) = ACT

id

1..*

SHALL

 

4376-395

 

code

1..1

SHALL

 

4376-396

urn:oid:2.16.840.1.113883.6.13 (CDT)

component

1..1

SHALL

 

4376-371

 

structuredBody

1..1

SHALL

 

4376-372

 

component

1..1

SHALL

 

4376-374

 

section

1..1

SHALL

 

4376-382

Orthodontic Observations Section (identifier: urn:hl7ii:2.16.840.1.113883.10.20.39.2.1:2018-08-01

component

0..1

MAY

 

4376-549

 

section

1..1

SHALL

 

4376-550

Orthodontic Salzmann Malocclusion Severity Assessment Section (identifier: urn:hl7ii:2.16.840.1.113883.10.20.39.2.2:2018-08-01

 

  1. Conforms to US Realm Header (V3) template (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2015-08-01) .
  2. SHALL contain exactly one [1..1] templateId (CONF:4376-365) such that it
    1. SHALL contain exactly one [1..1] @root = "2.16.840.1.113883.10.20.39.1.1" (CONF:4376-375) .
    2. SHALL contain exactly one [1..1] @extension = "2018-08-01" (CONF:4376-548) .
  3. SHALL contain exactly one [1..1] code (CONF:4376-366) such that it
    1. SHALL contain exactly one [1..1] @code = "TBD LOINC" Orthodontic Claims Attachment (CodeSystem: LOINC urn:oid:2.16.840.1.113883.6.1 ) (CONF:4376-376) .
    2. SHALL contain exactly one [1..1] @codeSystem = "2.16.840.1.113883.6.1" (CodeSystem: LOINC urn:oid:2.16.840.1.113883.6.1 ) (CONF:4376-433) .
  4. SHOULD contain zero or more [0..*] participant (CONF:4376-383) such that it

The CALLBCK participant is intended to contain contact information that a recipient of the Orthodontic Attachment Document could use to obtain further information related to the attachment.

  1. SHALL contain exactly one [1..1] @typeCode = "CALLBCK" (CodeSystem: HL7ParticipationType urn:oid:2.16.840.1.113883.5.90 ) (CONF:4376-386) .
  2. SHALL contain exactly one [1..1] associatedEntity (CONF:4376-384) .
    1. This associatedEntity SHALL contain exactly one [1..1] @classCode = "ASSIGNED" (CodeSystem: HL7RoleClass urn:oid:2.16.840.1.113883.5.110 ) (CONF:4376-387) .
    2. This associatedEntity SHOULD contain zero or more [0..*] addr (CONF:4376-389) .
    3. This associatedEntity SHALL contain at least one [1..*] telecom (CONF:4376-390) .
    4. This associatedEntity SHALL contain exactly one [1..1] associatedPerson (CONF:4376-385) such that it
      1. SHALL contain at least one [1..*] name (CONF:4376-391) .
    5. This associatedEntity MAY contain zero or one [0..1] scopingOrganization (CONF:4376-392) .

An orthodontic claim attachment should be associated with a particular patient visit - the details of that visit are documented within the documentationOf structure.

  1. SHALL contain exactly one [1..1] documentationOf (CONF:4376-393) such that it
    1. SHALL contain exactly one [1..1] serviceEvent (CONF:4376-394) such that it
      1. SHALL contain exactly one [1..1] @classCode = "ACT" (CodeSystem: HL7ActClass urn:oid:2.16.840.1.113883.5.6 ) (CONF:4376-397) .

The ID should be the "attachment re-association ID" described in section 3.6.1 of the Supplement to Consolidated CDA for Attachments - http://www.hl7.org/implement/standards/product_brief.cfm?product_id=305 .

  1. SHALL contain at least one [1..*] id (CONF:4376-395) .
  2. SHALL contain exactly one [1..1] code , which SHALL be selected from CodeSystem CDT (urn:oid:2.16.840.1.113883.6.13) DYNAMIC (CONF:4376-396) .
  1. SHALL contain exactly one [1..1] component (CONF:4376-371) such that it
    1. SHALL contain exactly one [1..1] structuredBody (CONF:4376-372) .
      1. This structuredBody SHALL contain exactly one [1..1] component (CONF:4376-374) such that it
        1. SHALL contain exactly one [1..1]  Orthodontic Observations Section (identifier: urn:hl7ii:2.16.840.1.113883.10.20.39.2.1:2018-08-01) (CONF:4376-382) .
      2. This structuredBody MAY contain zero or one [0..1] component (CONF:4376-549) such that it
        1. SHALL contain exactly one [1..1]  Orthodontic Salzmann Malocclusion Severity Assessment Section (identifier: urn:hl7ii:2.16.840.1.113883.10.20.39.2.2:2018-08-01) (CONF:4376-550) .

Figure 11 : Orthodontic Claims Attachment Document Service Event Sample

<serviceEvent classCode="ACT">

    <!-- This ID should be the "Attachment Re-association ID" used to correlate this Attachment to a claim -->

    <id root="9aaccc19-7083-495b-9547-ac7f00a15da1"/>

    <code code="D8090" displayName="Comprehensive orthodontic treatment of the adult dentition" codeSystem="2.16.840.1.113883.6.13" codeSystemName="Code on Dental Procedures and Nomenclature"/>

    <!-- The effectiveTime reflects the provision of care summarized in the document. -->

    <effectiveTime>

        <low value="20180401"/>

        <high value="20180601"/>

        <!-- The high value represents when the summarized provision of care being ended. -->

    </effectiveTime>

    <performer typeCode="PRF">

        <functionCode code="PCP" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction" displayName="Primary Care Provider">

            <originalText>Primary Care Provider</originalText>

        </functionCode>

        <assignedEntity>

            <!-- The ID below represents an individual NPI -->

            <id extension="5555555555" root="2.16.840.1.113883.4.6"/>

            <code code="1223S0112X" displayName="Oral & Maxillofacial Surgery" codeSystem="2.16.840.1.113883.6.101" codeSystemName="Healthcare Provider Taxonomy (HIPAA)"/>

            <addr use="WP">

                <streetAddressLine>12345 Main Street</streetAddressLine>

                <city>Fairfax</city>

                <state>VA</state>

                <postalCode>22031</postalCode>

                <country>US</country>

            </addr>

            <telecom use="WP" value="tel:+1(555)555-0002"/>

            <assignedPerson>

                <name>

                    <given>Otto</given>

                    <family>Orthodontist</family>

                    <suffix qualifier="AC">DMD</suffix>

                </name>

            </assignedPerson>

            <representedOrganization>

                <!-- The ID below represents an NPI for an organization -->

                <id extension="123456789" root="2.16.840.1.113883.4.6"/>

                <name>Fairfax Orthodontic Care</name>

                <telecom use="WP" value="tel:+1(555)555-0002"/>

                <addr use="WP">

                    <streetAddressLine>12345 Main Street</streetAddressLine>

                    <city>Fairfax</city>

                    <state>VA</state>

                    <postalCode>22031</postalCode>

                    <country>US</country>

                </addr>

            </representedOrganization>

        </assignedEntity>

    </performer>

</serviceEvent>

 

5.2              US Realm Header (V3)

[ClinicalDocument: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2015-08-01 (open)]

Table 6 : US Realm Header (V3) Contexts

 

This template defines constraints that represent common administrative and demographic concepts for US Realm CDA documents. Further specification, such as ClinicalDocument/code, are provided in document templates that conform to this template.

Table 7 : US Realm Header (V3) Constraints Overview

XPath

Card.

Verb

Data Type

CONF#

Value

ClinicalDocument (identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2015-08-01)

realmCode

1..1

SHALL

 

1198-16791

US

typeId

1..1

SHALL

 

1198-5361

 

@root

1..1

SHALL

 

1198-5250

2.16.840.1.113883.1.3

@extension

1..1

SHALL

 

1198-5251

POCD_HD000040

templateId

1..1

SHALL

 

1198-5252

 

@root

1..1

SHALL

 

1198-10036

2.16.840.1.113883.10.20.22.1.1

@extension

1..1

SHALL

 

1198-32503

2015-08-01

id

1..1

SHALL

 

1198-5363

 

code

1..1

SHALL

 

1198-5253

 

title

1..1

SHALL

 

1198-5254

 

effectiveTime

1..1

SHALL

 

1198-5256

US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4

confidentialityCode

1..1

SHALL

 

1198-5259

urn:oid:2.16.840.1.113883.1.11.16926 (HL7 BasicConfidentialityKind)

languageCode

1..1

SHALL

 

1198-5372

urn:oid:2.16.840.1.113883.1.11.11526 (Language)

setId

0..1

MAY

 

1198-5261

 

versionNumber

0..1

MAY

 

1198-5264

 

recordTarget

1..*

SHALL

 

1198-5266

 

patientRole

1..1

SHALL

 

1198-5267

 

id

1..*

SHALL

 

1198-5268

 

addr

1..*

SHALL

 

1198-5271

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

telecom

1..*

SHALL

 

1198-5280

 

@use

0..1

SHOULD

 

1198-5375

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

patient

1..1

SHALL

 

1198-5283

 

name

1..*

SHALL

 

1198-5284

US Realm Patient Name (PTN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1

administrativeGenderCode

1..1

SHALL

 

1198-6394

urn:oid:2.16.840.1.113883.1.11.1 (Administrative Gender (HL7 V3))

birthTime

1..1

SHALL

 

1198-5298

 

maritalStatusCode

0..1

SHOULD

 

1198-5303

urn:oid:2.16.840.1.113883.1.11.12212 (Marital Status)

religiousAffiliationCode

0..1

MAY

 

1198-5317

urn:oid:2.16.840.1.113883.1.11.19185 (Religious Affiliation)

raceCode

1..1

SHALL

 

1198-5322

urn:oid:2.16.840.1.113883.3.2074.1.1.3 (Race Category Excluding Nulls)

sdtc:raceCode

0..*

MAY

 

1198-7263

urn:oid:2.16.840.1.113883.1.11.14914 (Race)

ethnicGroupCode

1..1

SHALL

 

1198-5323

urn:oid:2.16.840.1.114222.4.11.837 (Ethnicity)

sdtc:ethnicGroupCode

0..*

MAY

 

1198-32901

urn:oid:2.16.840.1.114222.4.11.877 (Detailed Ethnicity)

guardian

0..*

MAY

 

1198-5325

 

code

0..1

SHOULD

 

1198-5326

urn:oid:2.16.840.1.113883.11.20.12.1 (Personal And Legal Relationship Role Type)

addr

0..*

SHOULD

 

1198-5359

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

telecom

0..*

SHOULD

 

1198-5382

 

@use

0..1

SHOULD

 

1198-7993

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

guardianPerson

1..1

SHALL

 

1198-5385

 

name

1..*

SHALL

 

1198-5386

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

birthplace

0..1

MAY

 

1198-5395

 

place

1..1

SHALL

 

1198-5396

 

addr

1..1

SHALL

 

1198-5397

 

country

0..1

SHOULD

 

1198-5404

urn:oid:2.16.840.1.113883.3.88.12.80.63 (Country)

languageCommunication

0..*

SHOULD

 

1198-5406

 

languageCode

1..1

SHALL

 

1198-5407

urn:oid:2.16.840.1.113883.1.11.11526 (Language)

modeCode

0..1

MAY

 

1198-5409

urn:oid:2.16.840.1.113883.1.11.12249 (LanguageAbilityMode)

proficiencyLevelCode

0..1

SHOULD

 

1198-9965

urn:oid:2.16.840.1.113883.1.11.12199 (LanguageAbilityProficiency)

preferenceInd

0..1

SHOULD

 

1198-5414

 

providerOrganization

0..1

MAY

 

1198-5416

 

id

1..*

SHALL

 

1198-5417

 

@root

0..1

SHOULD

 

1198-16820

2.16.840.1.113883.4.6

name

1..*

SHALL

 

1198-5419

 

telecom

1..*

SHALL

 

1198-5420

 

@use

0..1

SHOULD

 

1198-7994

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

addr

1..*

SHALL

 

1198-5422

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

author

1..*

SHALL

 

1198-5444

 

time

1..1

SHALL

 

1198-5445

US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4

assignedAuthor

1..1

SHALL

 

1198-5448

 

id

1..*

SHALL

 

1198-5449

 

id

0..1

SHOULD

 

1198-32882

 

@nullFlavor

0..1

MAY

 

1198-32883

urn:oid:2.16.840.1.113883.5.1008 (HL7NullFlavor) = UNK

@root

1..1

SHALL

 

1198-32884

2.16.840.1.113883.4.6

@extension

0..1

SHOULD

 

1198-32885

 

code

0..1

SHOULD

 

1198-16787

 

@code

1..1

SHALL

 

1198-16788

urn:oid:2.16.840.1.114222.4.11.1066 (Healthcare Provider Taxonomy (HIPAA))

addr

1..*

SHALL

 

1198-5452

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

telecom

1..*

SHALL

 

1198-5428

 

@use

0..1

SHOULD

 

1198-7995

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

assignedPerson

0..1

SHOULD

 

1198-5430

 

name

1..*

SHALL

 

1198-16789

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

assignedAuthoringDevice

0..1

SHOULD

 

1198-16783

 

manufacturerModelName

1..1

SHALL

 

1198-16784

 

softwareName

1..1

SHALL

 

1198-16785

 

dataEnterer

0..1

MAY

 

1198-5441

 

assignedEntity

1..1

SHALL

 

1198-5442

 

id

1..*

SHALL

 

1198-5443

 

@root

0..1

SHOULD

 

1198-16821

2.16.840.1.113883.4.6

code

0..1

MAY

 

1198-32173

urn:oid:2.16.840.1.114222.4.11.1066 (Healthcare Provider Taxonomy (HIPAA))

addr

1..*

SHALL

 

1198-5460

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

telecom

1..*

SHALL

 

1198-5466

 

@use

0..1

SHOULD

 

1198-7996

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

assignedPerson

1..1

SHALL

 

1198-5469

 

name

1..*

SHALL

 

1198-5470

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

informant

0..*

MAY

 

1198-8001

 

assignedEntity

1..1

SHALL

 

1198-8002

 

id

1..*

SHALL

 

1198-9945

 

code

0..1

MAY

 

1198-32174

urn:oid:2.16.840.1.114222.4.11.1066 (Healthcare Provider Taxonomy (HIPAA))

addr

1..*

SHALL

 

1198-8220

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

assignedPerson

1..1

SHALL

 

1198-8221

 

name

1..*

SHALL

 

1198-8222

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

informant

0..*

MAY

 

1198-31355

 

relatedEntity

1..1

SHALL

 

1198-31356

 

custodian

1..1

SHALL

 

1198-5519

 

assignedCustodian

1..1

SHALL

 

1198-5520

 

representedCustodianOrganization

1..1

SHALL

 

1198-5521

 

id

1..*

SHALL

 

1198-5522

 

@root

0..1

SHOULD

 

1198-16822

2.16.840.1.113883.4.6

name

1..1

SHALL

 

1198-5524

 

telecom

1..1

SHALL

 

1198-5525

 

@use

0..1

SHOULD

 

1198-7998

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

addr

1..1

SHALL

 

1198-5559

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

informationRecipient

0..*

MAY

 

1198-5565

 

intendedRecipient

1..1

SHALL

 

1198-5566

 

id

0..*

MAY

 

1198-32399

 

informationRecipient

0..1

MAY

 

1198-5567

 

name

1..*

SHALL

 

1198-5568

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

receivedOrganization

0..1

MAY

 

1198-5577

 

name

1..1

SHALL

 

1198-5578

 

legalAuthenticator

0..1

SHOULD

 

1198-5579

 

time

1..1

SHALL

 

1198-5580

US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4

signatureCode

1..1

SHALL

 

1198-5583

 

@code

1..1

SHALL

 

1198-5584

urn:oid:2.16.840.1.113883.5.89 (HL7ParticipationSignature) = S

sdtc:signatureText

0..1

MAY

 

1198-30810

 

assignedEntity

1..1

SHALL

 

1198-5585

 

id

1..*

SHALL

 

1198-5586

 

@root

0..1

MAY

 

1198-16823

2.16.840.1.113883.4.6

code

0..1

MAY

 

1198-17000

urn:oid:2.16.840.1.114222.4.11.1066 (Healthcare Provider Taxonomy (HIPAA))

addr

1..*

SHALL

 

1198-5589

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

telecom

1..*

SHALL

 

1198-5595

 

@use

0..1

SHOULD

 

1198-7999

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

assignedPerson

1..1

SHALL

 

1198-5597

 

name

1..*

SHALL

 

1198-5598

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

authenticator

0..*

MAY

 

1198-5607

 

time

1..1

SHALL

 

1198-5608

US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4

signatureCode

1..1

SHALL

 

1198-5610

 

@code

1..1

SHALL

 

1198-5611

urn:oid:2.16.840.1.113883.5.89 (HL7ParticipationSignature) = S

sdtc:signatureText

0..1

MAY

 

1198-30811

 

assignedEntity

1..1

SHALL

 

1198-5612

 

id

1..*

SHALL

 

1198-5613

 

@root

0..1

SHOULD

 

1198-16824

2.16.840.1.113883.4.6

code

0..1

MAY

 

1198-16825

 

@code

0..1

MAY

 

1198-16826

urn:oid:2.16.840.1.114222.4.11.1066 (Healthcare Provider Taxonomy (HIPAA))

addr

1..*

SHALL

 

1198-5616

US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2

telecom

1..*

SHALL

 

1198-5622

 

@use

0..1

SHOULD

 

1198-8000

urn:oid:2.16.840.1.113883.11.20.9.20 (Telecom Use (US Realm Header))

assignedPerson

1..1

SHALL

 

1198-5624

 

name

1..*

SHALL

 

1198-5625

US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1

participant

0..*

MAY

 

1198-10003

 

time

0..1

MAY

 

1198-10004

 

inFulfillmentOf

0..*

MAY

 

1198-9952

 

order

1..1

SHALL

 

1198-9953

 

id

1..*

SHALL

 

1198-9954

 

documentationOf

0..*

MAY

 

1198-14835

 

serviceEvent

1..1

SHALL

 

1198-14836

 

effectiveTime

1..1

SHALL

 

1198-14837

 

low

1..1

SHALL

 

1198-14838

 

performer

0..*

SHOULD

 

1198-14839

 

@typeCode

1..1

SHALL

 

1198-14840

urn:oid:2.16.840.1.113883.1.11.19601 (x_ServiceEventPerformer)

functionCode

0..1

MAY

 

1198-16818

 

@code

0..1

SHOULD

 

1198-32889

urn:oid:2.16.840.1.113883.1.11.10267 (ParticipationFunction)

assignedEntity

1..1

SHALL

 

1198-14841

 

id

1..*

SHALL

 

1198-14846

 

@root

0..1

SHOULD

 

1198-14847

2.16.840.1.113883.4.6

code

0..1

SHOULD

 

1198-14842

urn:oid:2.16.840.1.114222.4.11.1066 (Healthcare Provider Taxonomy (HIPAA))

authorization

0..*

MAY

 

1198-16792

 

consent

1..1

SHALL

 

1198-16793

 

id

0..*

MAY

 

1198-16794

 

code

0..1

MAY

 

1198-16795

 

statusCode

1..1

SHALL

 

1198-16797

 

@code

1..1

SHALL

 

1198-16798

urn:oid:2.16.840.1.113883.5.6 (HL7ActClass) = completed

componentOf

0..1

MAY

 

1198-9955

 

encompassingEncounter

1..1

SHALL

 

1198-9956

 

id

1..*

SHALL

 

1198-9959

 

effectiveTime

1..1

SHALL

 

1198-9958

 

 

5.2.1         Properties

5.2.1.1     realmCode

  1. SHALL contain exactly one [1..1] realmCode = "US" (CONF:1198-16791) .
  2. SHALL contain exactly one [1..1] typeId (CONF:1198-5361) .
    1. This typeId SHALL contain exactly one [1..1] @root = "2.16.840.1.113883.1.3" (CONF:1198-5250) .
    2. This typeId SHALL contain exactly one [1..1] @extension = "POCD_HD000040" (CONF:1198-5251) .
  3. SHALL contain exactly one [1..1] templateId (CONF:1198-5252) such that it
    1. SHALL contain exactly one [1..1] @root = "2.16.840.1.113883.10.20.22.1.1" (CONF:1198-10036) .
    2. SHALL contain exactly one [1..1] @extension = "2015-08-01" (CONF:1198-32503) .
  4. SHALL contain exactly one [1..1] id (CONF:1198-5363) .
    1. This id SHALL be a globally unique identifier for the document (CONF:1198-9991).
  5. SHALL contain exactly one [1..1] code (CONF:1198-5253) .
    1. This code SHALL specify the particular kind of document (e.g., History and Physical, Discharge Summary, Progress Note) (CONF:1198-9992).
    2. This code SHALL be drawn from the LOINC document type ontology (LOINC codes where SCALE = DOC) (CONF:1198-32948).
  6. SHALL contain exactly one [1..1] title (CONF:1198-5254) .
    Note: The title can either be a locally defined name or the displayName corresponding to clinicalDocument/code
  7. SHALL contain exactly one [1..1]  US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:1198-5256) .
  8. SHALL contain exactly one [1..1] confidentialityCode , which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC (CONF:1198-5259) .
  9. SHALL contain exactly one [1..1] languageCode , which SHALL be selected from ValueSet Language urn:oid:2.16.840.1.113883.1.11.11526 DYNAMIC (CONF:1198-5372) .
  10. MAY contain zero or one [0..1] setId (CONF:1198-5261) .
    1. If  setId is present versionNumber SHALL be present (CONF:1198-6380).
  11. MAY contain zero or one [0..1] versionNumber (CONF:1198-5264) .
    1. If versionNumber is present setId SHALL be present (CONF:1198-6387).
      1. recordTarget

The recordTarget records the administrative and demographic data of the patient whose health information is described by the clinical document; each recordTarget must contain at least one patientRole element

  1. SHALL contain at least one [1..*] recordTarget (CONF:1198-5266) .
    1. Such recordTargets SHALL contain exactly one [1..1] patientRole (CONF:1198-5267) .
      1. This patientRole SHALL contain at least one [1..*] id (CONF:1198-5268) .
      2. This patientRole SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5271) .
      3. This patientRole SHALL contain at least one [1..*] telecom (CONF:1198-5280) .
        1. Such telecoms SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-5375) .
      4. This patientRole SHALL contain exactly one [1..1] patient (CONF:1198-5283) .
        1. This patient SHALL contain at least one [1..*]  US Realm Patient Name (PTN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1) (CONF:1198-5284) .
        2. This patient SHALL contain exactly one [1..1] administrativeGenderCode , which SHALL be selected from ValueSet Administrative Gender (HL7 V3) urn:oid:2.16.840.1.113883.1.11.1 DYNAMIC (CONF:1198-6394) .
        3. This patient SHALL contain exactly one [1..1] birthTime (CONF:1198-5298) .
          1. SHALL be precise to year (CONF:1198-5299).
          2. SHOULD be precise to day (CONF:1198-5300).

For cases where information about newborn's time of birth needs to be captured.

  1. MAY be precise to the minute (CONF:1198-32418).
  1. This patient SHOULD contain zero or one [0..1] maritalStatusCode , which SHALL be selected from ValueSet Marital Status urn:oid:2.16.840.1.113883.1.11.12212 DYNAMIC (CONF:1198-5303) .
  2. This patient MAY contain zero or one [0..1] religiousAffiliationCode , which SHALL be selected from ValueSet Religious Affiliation urn:oid:2.16.840.1.113883.1.11.19185 DYNAMIC (CONF:1198-5317) .
  3. This patient SHALL contain exactly one [1..1] raceCode , which SHALL be selected from ValueSet Race Category Excluding Nulls urn:oid:2.16.840.1.113883.3.2074.1.1.3 DYNAMIC (CONF:1198-5322) .
  4. This patient MAY contain zero or more [0..*] sdtc:raceCode , which SHALL be selected from ValueSet Race urn:oid:2.16.840.1.113883.1.11.14914 DYNAMIC (CONF:1198-7263) .
    Note: The sdtc:raceCode is only used to record additional values when the patient has indicated multiple races or additional race detail beyond the five categories required for Meaningful Use Stage 2. The prefix sdtc: SHALL be bound to the namespace “urn:hl7-org:sdtc”. The use of the namespace provides a necessary extension to CDA R2 for the use of the additional raceCode elements.
    1. If sdtc:raceCode is present, then the patient SHALL contain [[]1..1[]] raceCode (CONF:1198-31347).
  5. This patient SHALL contain exactly one [1..1] ethnicGroupCode , which SHALL be selected from ValueSet Ethnicity urn:oid:2.16.840.1.114222.4.11.837 DYNAMIC (CONF:1198-5323) .
  6. This patient MAY contain zero or more [0..*] sdtc:ethnicGroupCode , which SHALL be selected from ValueSet Detailed Ethnicity urn:oid:2.16.840.1.114222.4.11.877 DYNAMIC (CONF:1198-32901) .
  7. This patient MAY contain zero or more [0..*] guardian (CONF:1198-5325) .
    1. The guardian, if present, SHOULD contain zero or one [0..1] code , which SHALL be selected from ValueSet Personal And Legal Relationship Role Type urn:oid:2.16.840.1.113883.11.20.12.1 DYNAMIC (CONF:1198-5326) .
    2. The guardian, if present, SHOULD contain zero or more [0..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5359) .
    3. The guardian, if present, SHOULD contain zero or more [0..*] telecom (CONF:1198-5382) .
      1. The telecom, if present, SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-7993) .
    4. The guardian, if present, SHALL contain exactly one [1..1] guardianPerson (CONF:1198-5385) .
      1. This guardianPerson SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-5386) .
  8. This patient MAY contain zero or one [0..1] birthplace (CONF:1198-5395) .
    1. The birthplace, if present, SHALL contain exactly one [1..1] place (CONF:1198-5396) .
      1. This place SHALL contain exactly one [1..1] addr (CONF:1198-5397) .
        1. This addr SHOULD contain zero or one [0..1] country , which SHALL be selected from ValueSet Country urn:oid:2.16.840.1.113883.3.88.12.80.63 DYNAMIC (CONF:1198-5404) .
        2. If country is US, this addr SHALL contain exactly one [[]1..1[]] state, which SHALL be selected from ValueSet StateValueSet 2.16.840.1.113883.3.88.12.80.1 DYNAMIC (CONF:1198-5402).
          Note: A nullFlavor of ' UNK' may be used if the state is unknown.
        3. If country is US, this addr MAY contain zero or one [[]0..1] postalCode, which SHALL be selected from ValueSet PostalCode urn:oid:2.16.840.1.113883.3.88.12.80.2 DYNAMIC (CONF:1198-5403).
  9. This patient SHOULD contain zero or more [0..*] languageCommunication (CONF:1198-5406) .
    1. The languageCommunication, if present, SHALL contain exactly one [1..1] languageCode , which SHALL be selected from ValueSet Language urn:oid:2.16.840.1.113883.1.11.11526 DYNAMIC (CONF:1198-5407) .
    2. The languageCommunication, if present, MAY contain zero or one [0..1] modeCode , which SHALL be selected from ValueSet LanguageAbilityMode urn:oid:2.16.840.1.113883.1.11.12249 DYNAMIC (CONF:1198-5409) .
    3. The languageCommunication, if present, SHOULD contain zero or one [0..1] proficiencyLevelCode , which SHALL be selected from ValueSet LanguageAbilityProficiency urn:oid:2.16.840.1.113883.1.11.12199 DYNAMIC (CONF:1198-9965) .
    4. The languageCommunication, if present, SHOULD contain zero or one [0..1] preferenceInd (CONF:1198-5414) .
  1. This patientRole MAY contain zero or one [0..1] providerOrganization (CONF:1198-5416) .
    1. The providerOrganization, if present, SHALL contain at least one [1..*] id (CONF:1198-5417) .
      1. Such ids SHOULD contain zero or one [0..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-16820) .
    2. The providerOrganization, if present, SHALL contain at least one [1..*] name (CONF:1198-5419) .
    3. The providerOrganization, if present, SHALL contain at least one [1..*] telecom (CONF:1198-5420) .
      1. Such telecoms SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-7994) .
    4. The providerOrganization, if present, SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5422) .
    1. author

The author element represents the creator of the clinical document.  The author may be a device or a person.

  1. SHALL contain at least one [1..*] author (CONF:1198-5444) .
    1. Such authors SHALL contain exactly one [1..1]  US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:1198-5445) .
    2. Such authors SHALL contain exactly one [1..1] assignedAuthor (CONF:1198-5448) .
      1. This assignedAuthor SHALL contain at least one [1..*] id (CONF:1198-5449) .

If this assignedAuthor is an assignedPerson

  1. This assignedAuthor SHOULD contain zero or one [0..1] id (CONF:1198-32882) such that it

If id with @root="2.16.840.1.113883.4.6" National Provider Identifier is unknown then

  1. MAY contain zero or one [0..1] @nullFlavor = "UNK" Unknown (CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008 ) (CONF:1198-32883) .
  2. SHALL contain exactly one [1..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-32884) .
  3. SHOULD contain zero or one [0..1] @extension (CONF:1198-32885) .

Only if this assignedAuthor is an assignedPerson should the assignedAuthor contain a code.

  1. This assignedAuthor SHOULD contain zero or one [0..1] code (CONF:1198-16787) .
    1. The code, if present, SHALL contain exactly one [1..1] @code , which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-16788) .
  2. This assignedAuthor SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5452) .
  3. This assignedAuthor SHALL contain at least one [1..*] telecom (CONF:1198-5428) .
    1. Such telecoms SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-7995) .
  4. This assignedAuthor SHOULD contain zero or one [0..1] assignedPerson (CONF:1198-5430) .
    1. The assignedPerson, if present, SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-16789) .
  5. This assignedAuthor SHOULD contain zero or one [0..1] assignedAuthoringDevice (CONF:1198-16783) .
    1. The assignedAuthoringDevice, if present, SHALL contain exactly one [1..1] manufacturerModelName (CONF:1198-16784) .
    2. The assignedAuthoringDevice, if present, SHALL contain exactly one [1..1] softwareName (CONF:1198-16785) .
  6. There SHALL be exactly one assignedAuthor/assignedPerson or exactly one assignedAuthor/assignedAuthoringDevice (CONF:1198-16790).
    1. dataEnterer

The dataEnterer element represents the person who transferred the content, written or dictated, into the clinical document. To clarify, an author provides the content found within the header or body of a document, subject to their own interpretation; a dataEnterer adds an author's information to the electronic system.

  1. MAY contain zero or one [0..1] dataEnterer (CONF:1198-5441) .
    1. The dataEnterer, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:1198-5442) .
      1. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-5443) .
        1. Such ids SHOULD contain zero or one [0..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-16821) .
      2. This assignedEntity MAY contain zero or one [0..1] code , which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-32173) .
      3. This assignedEntity SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5460) .
      4. This assignedEntity SHALL contain at least one [1..*] telecom (CONF:1198-5466) .
        1. Such telecoms SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-7996) .
      5. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-5469) .
        1. This assignedPerson SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-5470) .
        1. informant

The informant element describes an information source for any content within the clinical document. This informant is constrained for use when the source of information is an assigned health care provider for the patient.

  1. MAY contain zero or more [0..*] informant (CONF:1198-8001) such that it
    1. SHALL contain exactly one [1..1] assignedEntity (CONF:1198-8002) .
      1. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-9945) .
        1. If assignedEntity/id is a provider then this id, SHOULD include zero or one [[]0..1[]] id where id/@root ="2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-9946).
      2. This assignedEntity MAY contain zero or one [0..1] code , which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-32174) .
      3. This assignedEntity SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-8220) .
      4. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-8221) .
        1. This assignedPerson SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-8222) .
        1. informant

The informant element describes an information source (who is not a provider) for any content within the clinical document. This informant would be used when the source of information has a personal relationship with the patient or is the patient.

  1. MAY contain zero or more [0..*] informant (CONF:1198-31355) such that it
    1. SHALL contain exactly one [1..1] relatedEntity (CONF:1198-31356) .
      1. custodian

The custodian element represents the organization that is in charge of maintaining and is entrusted with the care of the document.
There is only one custodian per CDA document. Allowing that a CDA document may not represent the original form of the authenticated document, the custodian represents the steward of the original source document. The custodian may be the document originator, a health information exchange, or other responsible party.

  1. SHALL contain exactly one [1..1] custodian (CONF:1198-5519) .
    1. This custodian SHALL contain exactly one [1..1] assignedCustodian (CONF:1198-5520) .
      1. This assignedCustodian SHALL contain exactly one [1..1] representedCustodianOrganization (CONF:1198-5521) .
        1. This representedCustodianOrganization SHALL contain at least one [1..*] id (CONF:1198-5522) .
          1. Such ids SHOULD contain zero or one [0..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-16822) .
        2. This representedCustodianOrganization SHALL contain exactly one [1..1] name (CONF:1198-5524) .
        3. This representedCustodianOrganization SHALL contain exactly one [1..1] telecom (CONF:1198-5525) .
          1. This telecom SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-7998) .
        4. This representedCustodianOrganization SHALL contain exactly one [1..1]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5559) .
        1. informationRecipient

The informationRecipient element records the intended recipient of the information at the time the document was created. In cases where the intended recipient of the document is the patient's health chart, set the receivedOrganization to the scoping organization for that chart.

  1. MAY contain zero or more [0..*] informationRecipient (CONF:1198-5565) .
    1. The informationRecipient, if present, SHALL contain exactly one [1..1] intendedRecipient (CONF:1198-5566) .
      1. This intendedRecipient MAY contain zero or more [0..*] id (CONF:1198-32399) .
      2. This intendedRecipient MAY contain zero or one [0..1] informationRecipient (CONF:1198-5567) .
        1. The informationRecipient, if present, SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-5568) .
      3. This intendedRecipient MAY contain zero or one [0..1] receivedOrganization (CONF:1198-5577) .
        1. The receivedOrganization, if present, SHALL contain exactly one [1..1] name (CONF:1198-5578) .
        1. legalAuthenticator

The legalAuthenticator identifies the single person legally responsible for the document and must be present if the document has been legally authenticated. A clinical document that does not contain this element has not been legally authenticated.
The act of legal authentication requires a certain privilege be granted to the legal authenticator depending upon local policy. Based on local practice, clinical documents may be released before legal authentication.
All clinical documents have the potential for legal authentication, given the appropriate credentials.
Local policies MAY choose to delegate the function of legal authentication to a device or system that generates the clinical document. In these cases, the legal authenticator is a person accepting responsibility for the document, not the generating device or system.
Note that the legal authenticator, if present, must be a person.

  1. SHOULD contain zero or one [0..1] legalAuthenticator (CONF:1198-5579) .
    1. The legalAuthenticator, if present, SHALL contain exactly one [1..1]  US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:1198-5580) .
    2. The legalAuthenticator, if present, SHALL contain exactly one [1..1] signatureCode (CONF:1198-5583) .
      1. This signatureCode SHALL contain exactly one [1..1] @code = "S" (CodeSystem: HL7ParticipationSignature urn:oid:2.16.840.1.113883.5.89 STATIC ) (CONF:1198-5584) .
        1. sdtc:signatureText

The sdtc:signatureText extension provides a location in CDA for a textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode. Details of what goes in the field are described in the HL7 CDA Digital Signature Standard balloted in Fall 2013.

  1. The legalAuthenticator, if present, MAY contain zero or one [0..1] sdtc:signatureText (CONF:1198-30810) .
    Note: The signature can be represented either inline or by reference according to the ED data type. Typical cases for CDA are:
    1) Electronic signature: this attribute can represent virtually any electronic signature scheme.
    2) Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
     
  2. The legalAuthenticator, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:1198-5585) .
    1. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-5586) .
      1. Such ids MAY contain zero or one [0..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-16823) .
    2. This assignedEntity MAY contain zero or one [0..1] code , which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-17000) .
    3. This assignedEntity SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5589) .
    4. This assignedEntity SHALL contain at least one [1..*] telecom (CONF:1198-5595) .
      1. Such telecoms SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-7999) .
    5. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-5597) .
      1. This assignedPerson SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-5598) .
      1. authenticator

The authenticator identifies a participant or participants who attest to the accuracy of the information in the document.

  1. MAY contain zero or more [0..*] authenticator (CONF:1198-5607) such that it
    1. SHALL contain exactly one [1..1]  US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:1198-5608) .
    2. SHALL contain exactly one [1..1] signatureCode (CONF:1198-5610) .
      1. This signatureCode SHALL contain exactly one [1..1] @code = "S" (CodeSystem: HL7ParticipationSignature urn:oid:2.16.840.1.113883.5.89 STATIC ) (CONF:1198-5611) .

The sdtc:signatureText extension provides a location in CDA for a textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode. Details of what goes in the field are described in the HL7 CDA Digital Signature Standard balloted in Fall of 2013.

  1. MAY contain zero or one [0..1] sdtc:signatureText (CONF:1198-30811) .
    Note: The signature can be represented either inline or by reference according to the ED data type. Typical cases for CDA are:
    1) Electronic signature: this attribute can represent virtually any electronic signature scheme.
    2) Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
     
  2. SHALL contain exactly one [1..1] assignedEntity (CONF:1198-5612) .
    1. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-5613) .
      1. Such ids SHOULD contain zero or one [0..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-16824) .
    2. This assignedEntity MAY contain zero or one [0..1] code (CONF:1198-16825) .
      1. The code, if present, MAY contain zero or one [0..1] @code , which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 STATIC (CONF:1198-16826) .
    3. This assignedEntity SHALL contain at least one [1..*]  US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:1198-5616) .
    4. This assignedEntity SHALL contain at least one [1..*] telecom (CONF:1198-5622) .
      1. Such telecoms SHOULD contain zero or one [0..1] @use , which SHALL be selected from ValueSet Telecom Use (US Realm Header) urn:oid:2.16.840.1.113883.11.20.9.20 DYNAMIC (CONF:1198-8000) .
    5. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:1198-5624) .
      1. This assignedPerson SHALL contain at least one [1..*]  US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-5625) .
      1. participant

The participant element identifies supporting entities, including parents, relatives, caregivers, insurance policyholders, guarantors, and others related in some way to the patient.
A supporting person or organization is an individual or an organization with a relationship to the patient. A supporting person who is playing multiple roles would be recorded in multiple participants (e.g., emergency contact and next-of-kin).

  1. MAY contain zero or more [0..*] participant (CONF:1198-10003) such that it
    1. MAY contain zero or one [0..1] time (CONF:1198-10004) .
    2. SHALL contain associatedEntity/associatedPerson AND/OR associatedEntity/scopingOrganization (CONF:1198-10006).
    3. When participant/@typeCode is IND , associatedEntity/@classCode SHOULD be selected from ValueSet 2.16.840.1.113883.11.20.9.33 INDRoleclassCodes STATIC 2011-09-30 (CONF:1198-10007).
      1. inFulfillmentOf

The inFulfillmentOf element represents orders that are fulfilled by this document such as a radiologists’ report of an x-ray.

  1. MAY contain zero or more [0..*] inFulfillmentOf (CONF:1198-9952) .
    1. The inFulfillmentOf, if present, SHALL contain exactly one [1..1] order (CONF:1198-9953) .
      1. This order SHALL contain at least one [1..*] id (CONF:1198-9954) .
        1. documentationOf
  2. MAY contain zero or more [0..*] documentationOf (CONF:1198-14835) .

A serviceEvent represents the main act being documented, such as a colonoscopy or a cardiac stress study. In a provision of healthcare serviceEvent, the care providers, PCP, or other longitudinal providers, are recorded within the serviceEvent. If the document is about a single encounter, the providers associated can be recorded in the componentOf/encompassingEncounter template.

  1. The documentationOf, if present, SHALL contain exactly one [1..1] serviceEvent (CONF:1198-14836) .
    1. This serviceEvent SHALL contain exactly one [1..1] effectiveTime (CONF:1198-14837) .
      1. This effectiveTime SHALL contain exactly one [1..1] low (CONF:1198-14838) .
      1. performer

The performer participant represents clinicians who actually and principally carry out the serviceEvent. In a transfer of care this represents the healthcare providers involved in the current or pertinent historical care of the patient. Preferably, the patient’s key healthcare care team members would be listed, particularly their primary physician and any active consulting physicians, therapists, and counselors.

  1. This serviceEvent SHOULD contain zero or more [0..*] performer (CONF:1198-14839) .
    1. The performer, if present, SHALL contain exactly one [1..1] @typeCode , which SHALL be selected from ValueSet x_ServiceEventPerformer urn:oid:2.16.840.1.113883.1.11.19601 STATIC (CONF:1198-14840) .
    2. The performer, if present, MAY contain zero or one [0..1] functionCode (CONF:1198-16818) .
      1. The functionCode, if present, SHOULD contain zero or one [0..1] @code , which SHOULD be selected from ValueSet ParticipationFunction urn:oid:2.16.840.1.113883.1.11.10267 STATIC (CONF:1198-32889) .
    3. The performer, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:1198-14841) .
      1. This assignedEntity SHALL contain at least one [1..*] id (CONF:1198-14846) .
        1. Such ids SHOULD contain zero or one [0..1] @root = "2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-14847) .
      2. This assignedEntity SHOULD contain zero or one [0..1] code , which SHOULD be selected from ValueSet Healthcare Provider Taxonomy (HIPAA) urn:oid:2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:1198-14842) .
    1. authorization

The authorization element represents information about the patient’s consent.
The type of consent is conveyed in consent/code. Consents in the header have been finalized (consent/statusCode must equal Completed) and should be on file. This specification does not address how 'Privacy Consent' is represented, but does not preclude the inclusion of ‘Privacy Consent’.
The authorization consent is used for referring to consents that are documented elsewhere in the EHR or medical record for a health condition and/or treatment that is described in the CDA document.

  1. MAY contain zero or more [0..*] authorization (CONF:1198-16792) such that it
    1. SHALL contain exactly one [1..1] consent (CONF:1198-16793) .
      1. This consent MAY contain zero or more [0..*] id (CONF:1198-16794) .
      2. This consent MAY contain zero or one [0..1] code (CONF:1198-16795) .
        Note: The type of consent (e.g., a consent to perform the related serviceEvent) is conveyed in consent/code.
      3. This consent SHALL contain exactly one [1..1] statusCode (CONF:1198-16797) .
        1. This statusCode SHALL contain exactly one [1..1] @code = "completed" Completed (CodeSystem: HL7ActClass urn:oid:2.16.840.1.113883.5.6 ) (CONF:1198-16798) .
        1. componentOf

The encompassing encounter represents the setting of the clinical encounter during which the document act(s) or ServiceEvent(s) occurred. In order to represent providers associated with a specific encounter, they are recorded within the encompassingEncounter as participants. In a CCD, the encompassingEncounter may be used when documenting a specific encounter and its participants. All relevant encounters in a CCD may be listed in the encounters section.

  1. MAY contain zero or one [0..1] componentOf (CONF:1198-9955) .
    1. The componentOf, if present, SHALL contain exactly one [1..1] encompassingEncounter (CONF:1198-9956) .
      1. This encompassingEncounter SHALL contain at least one [1..*] id (CONF:1198-9959) .
      2. This encompassingEncounter SHALL contain exactly one [1..1] effectiveTime (CONF:1198-9958) .

Table 8 : Race

Value Set: Race urn:oid:2.16.840.1.113883.1.11.14914

Concepts in the race value set include the 5 minimum categories for race specified by OMB  along with a more detailed set of race categories used by the Bureau of Census.

Value Set Source: https://vsac.nlm.nih.gov/

Code

Code System

Code System OID

Print Name

1002-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

American Indian or Alaska Native

2028-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Asian

2054-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Black or African American

2076-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Native Hawaiian or Other Pacific Islander

2106-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

White

1006-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Abenaki

1579-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Absentee Shawnee

1490-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Acoma

2126-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Afghanistani

1740-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Ahtna

1654-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Ak-Chin

1993-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Akhiok

1897-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Akiachak

1898-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Akiak

2007-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Akutan

1187-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alabama Coushatta

1194-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alabama Creek

1195-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alabama Quassarte

1899-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alakanuk

1383-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alamo Navajo

1744-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alanvik

1737-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alaska Indian

1735-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alaska Native

1739-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alaskan Athabascan

1741-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alatna

1900-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aleknagik

1966-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aleut

2008-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aleut Corporation

2009-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aleutian

2010-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aleutian Islander

1742-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alexander

1008-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Algonquian

1743-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Allakaket

1671-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Allen Canyon

1688-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alpine

1392-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alsea

1968-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Alutiiq Aleut

1845-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Ambler

1004-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

American Indian

1846-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Anaktuvuk

1847-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Anaktuvuk Pass

1901-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Andreafsky

1814-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Angoon

1902-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aniak

1745-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Anvik

1010-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Apache

2129-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arab

1021-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arapaho

1746-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arctic

1849-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arctic Slope Corporation

1848-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arctic Slope Inupiat

1026-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arikara

1491-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Arizona Tewa

2109-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Armenian

1366-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Aroostook

2029-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Asian Indian

1028-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Assiniboine

1030-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Assiniboine Sioux

2119-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Assyrian

2011-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Atka

1903-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Atmautluak

1850-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Atqasuk

1265-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Atsina

1234-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Attacapa

1046-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Augustine

1124-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bad River

2067-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bahamian

2030-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bangladeshi

1033-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bannock

2068-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Barbadian

1712-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Barrio Libre

1851-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Barrow

1587-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Battle Mountain

1125-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bay Mills Chippewa

1747-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Beaver

2012-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Belkofski

1852-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bering Straits Inupiat

1904-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bethel

2031-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bhutanese

1567-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Big Cypress

1905-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bill Moore's Slough

1235-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Biloxi

1748-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Birch Creek

1417-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bishop

2056-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Black

1035-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Blackfeet

1610-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Blackfoot Sioux

1126-2

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bois Forte

2061-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Botswanan

1853-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Brevig Mission

1418-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bridgeport

1568-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Brighton

1972-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bristol Bay Aleut

1906-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Bristol Bay Yupik

1037-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Brotherton

1611-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Brule Sioux

1854-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Buckland

2032-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Burmese

1419-1

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Burns Paiute

1039-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Burt Lake Band

1127-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Burt Lake Chippewa

1412-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Burt Lake Ottawa

1047-0

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Cabazon

1041-3

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Caddo

1054-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Cahto

1044-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Cahuilla

1053-8

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

California Tribes

1907-5

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Calista Yupik

2033-9

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Cambodian

1223-7

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Campo

1068-6

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238

Canadian and Latin American Indian

1069-4

Race & Ethnicity - CDC

urn:oid:2.16.840.1.113883.6.238