Implementation Guide for CDA Release 2

CDAR2_IG_CONSENTDIR_R1_N1_2013MAY

HL7 Implementation Guide for CDA® Release 2: Privacy Consent Directives, Release 1

May 2013

HL7 Normative Ballot

Sponsored by: Community Based Collaborative Care Work Group

Additional Sponsor: Security Work Group

Copyright © 2013 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.

http://www.hl7.org/legal/ippolicy.cfm?ref=nav

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | Contents | 4

Contents

Acknowledgments............................................................................................................................ 6Revision History.............................................................................................................................. 8DSTU Issues................................................................................................................................... 10

List of Figures................................................................................................................................12

Chapter 1: INTRODUCTION...............................................................................14Overview............................................................................................................................................................. 15Glossary...............................................................................................................................................................15Approach............................................................................................................................................................. 16Scope................................................................................................................................................................... 17Audience..............................................................................................................................................................19Organization of This Guide................................................................................................................................19

Templates.................................................................................................................................................19Vocabulary and Value Sets..................................................................................................................... 19

Use of Templates................................................................................................................................................ 19Originator Responsibilities..................................................................................................................... 19Recipient Responsibilities.......................................................................................................................19

Conventions Used in This Guide....................................................................................................................... 19Conformance Requirements....................................................................................................................20Keywords.................................................................................................................................................21XML Examples.......................................................................................................................................21

Security Considerations...................................................................................................................................... 21

Chapter 2: DOCUMENT TEMPLATES............................................................. 24Privacy Consent Directive Document................................................................................................................ 25Privacy Consent Header Constraints..................................................................................................................34

Chapter 3: SECTION TEMPLATES................................................................... 48Privacy Consent Details Section........................................................................................................................ 49Signatures Section...............................................................................................................................................50

Chapter 4: CLINICAL STATEMENT TEMPLATES........................................52Computable Policy..............................................................................................................................................53Confidentiality Act..............................................................................................................................................53Consent Action....................................................................................................................................................54Consent Directive Definition..............................................................................................................................55Information Definition........................................................................................................................................ 55Obligation Policy Observation........................................................................................................................... 56Refrain Policy Observation................................................................................................................................ 57Related Problem..................................................................................................................................................58Scanned Privacy Consent................................................................................................................................... 60Security Observation...........................................................................................................................................60Signature Image Observation............................................................................................................................. 61

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | Contents | 5

Chapter 5: OTHER CLASSES............................................................................. 64Consent Action Obligation Security Observation Relationship.........................................................................65Consent Directive Entry..................................................................................................................................... 65IIHI Receiving Provider..................................................................................................................................... 67Information Criteria References......................................................................................................................... 67Information Definition Set Reference................................................................................................................ 68Policy Precondition.............................................................................................................................................69Policy Precondition Criterion............................................................................................................................. 69Privacy Consent Header Author.........................................................................................................................70Privacy Consent Header Documentation Of Service Event...............................................................................70Signature Image Entry........................................................................................................................................71

Chapter 6: VALUE SETS...................................................................................... 72Act Consent Type............................................................................................................................................... 73Act Policy Type.................................................................................................................................................. 73Obligation Policy................................................................................................................................................ 73Purpose Of Use...................................................................................................................................................73Refrain Policy..................................................................................................................................................... 74Security Observation Type................................................................................................................................. 74x Basic Confidentiality Kind..............................................................................................................................74

REFERENCES.............................................................................................................................. 76

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | Acknowledgments | 6

HL7 IG for CDA R2Missing Product Series (Draft Standard for TrialUse) in BookMap (bookmap/bookmeta/prodinfo/series)

Implementation Guide for CDARelease 2 ( Universal Realm )

Page 6March 2013

© 2013 Health Level Seven International. All rights reserved.. All rights reserved

Acknowledgments

This ballot was produced and developed through the efforts of the Substance Abuse and Mental Health ServicesAdministration (SAMHSA) and the Department of Veterans Affairs (VA) with modeling support provided byEversolve, LLC. The co-editors appreciate the support and sponsorship of the HL7 Structured Documents WorkGroup (SDWG). Finally, we acknowledge the foundational work by HL7 Version 3, the Reference InformationModel (RIM), and the HL7 domain committees, especially Patient Care, and the work done on Clinical DocumentArchitecture (CDA) itself. We also acknowledge the IHE BPPC specification as the precursor to this specificationand HITSP TP 30 Manage Consent Directives Transaction Package. All these efforts were critical ingredients to thedevelopment of this ballot; the degree to which this ballot reflects these efforts will foster interoperability across thespectrum of health care.

SNOMED CT is a registered trademark of the International Health Terminology Standard DevelopmentOrganisation (IHTSDO). LOINC is a registered United States trademark of Regenstrief Institute, Inc.

This document contains an example of healthcare standards and specifications publication generated from UMLmodels, using the OHT Model Driven Health Tools (MDHT). Some portions of this document may not be publiclyavailable but are included for demonstration purposes only; therefore this version of the document is to be treated asCONFIDENTIAL by the project participants.

This demonstration document contains information from the following sources:©2010 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is notaltered in any fashion and ANSI’s copyright is clearly noted.

SNOMED CT® is the registered trademark of the International Health Terminology Standard DevelopmentOrganization (IHTSDO).

This material contains content from LOINC® (http://loinc.org). The LOINC table, LOINC codes, and LOINC panelsand forms file are copyright © 1995-2010, Regenstrief Institute, Inc. and the Logical Observation Identifiers Namesand Codes (LOINC) Committee and available at no cost under the license at http://loinc.org/terms-of-use.

Certain materials contained in this Interoperability Specification are reproduced from Health Level Seven (HL7) HL7Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), HL7 Implementation Guide for CDARelease 2: History and Physical (H&P) Notes, HL7 Implementation Guide for CDA Release 2: Consult Notes, orHL7 Implementation Guide for CDA Release 2: Operative Notes with permission of Health Level Seven, Inc. Nopart of the material may be copied or reproduced in any form outside of the Interoperability Specification documents,including an electronic retrieval system, or made available on the Internet without the prior written permission ofHealth Level Seven, Inc. Copies of standards included in this Interoperability Specification may be purchased fromthe Health Level Seven, Inc. Material drawn from these standards is credited where used.

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | Revision History | 8



Page 8March 2013


Revision History

Rev Date By Whom Changes

1.0 DSTU September 15th, 2010 Serafina Versaggi May 2010 Ballotreconciliationcompleted.

Draft Standard forTrial Use Release

2.0 Normative March 17th, 2013 Ioana Singureanu First NormativeBallot includingrevised requirements.

Normative Release

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | DSTU Issues | 10



Page 10March 2013


DSTU Issues

This implementation guide contains new capabilities identified by early adopters during the trial period of the DSTUapproved in May 2010.

Issue Description Responsible Party Resolution Status

Missing ObligationPolicy Vocabulary

This version of theIG includes supportfor specifying anobligation policyconsistent with theData Segmentationfor Privacy IG.

CBCC Work Group The existingtemplate was revisedand vocabularyconstraints wereadded to a SecurityObservationTemplate.

Closed

Missing RefrainPolicy

This version ofthe IG includessupport for specifyingan refrain policyconsistent with theData Segmentationfor Privacy IG.

CBCC Work Group A new templateand vocabularyconstraints wereadded. The newtemplate is basedon a newly createdSecurity ObservationTemplate.

Closed

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | List of Figures | 12

List of Figures

Figure 1: Privacy Consent Directive Header rendered – example................................................. 15

Figure 2: Specification derivation and relationship to other standards.......................................... 16

Figure 3: Security Domain Analysis: Privacy Consent Structure.................................................. 18

Figure 4: Template name and "conforms to" appearance...............................................................20

Figure 5: Template-based conformance statements example......................................................... 20

Figure 6: CCD conformance statements example.......................................................................... 21

Figure 7: ClinicalDocument example............................................................................................. 21

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | INTRODUCTION | 14



Page 14March 2013


Chapter

1INTRODUCTION

Topics:

• Overview• Glossary• Approach• Scope• Audience• Organization of This Guide• Use of Templates• Conventions Used in This Guide• Security Considerations

The Privacy Consent Directive Implementation Guide applies to privacyconsent directives intended to protect health information maintained inelectronic health records (EHRs), personal health records (PHRs), HealthInformation Exchange systems (HIEs) and other forms of electroniccollection and maintenance of health information.

This specification provides a mechanism to record a client’s healthinformation privacy consent(s) and to exchange those privacy consentdirectives with entities that are custodians of the client's health recordsincluding Individually Identifiable Health Information (IIHI).

The scope of this project is to specify a Privacy Consent Directive in a formatthat may be used to sign the privacy consent as well as to allow informationsystems and specific rule engines to decode the assertions contained therein.

This implementation guide is a conformance profile, as described in theRefinement and Localization section of the HL7 Version 3 standards. Thebase standard for this implementation guide is the HL7 Clinical DocumentArchitecture, Release 2.0.

This implementation guide is both an annotation profile and a localizationprofile. CDA R2 is not fully described in this guide, so implementers mustbe familiar with the requirements of the base specification. As an annotationprofile, portions of this guide summarize or explain the base standard;therefore, some requirements stated here originate not in this DSTU but in thebase specification.

Requirements that do not add further constraints to the base standard and thatcan be validated through CDA R2 XML Schema Description and conformto the CDA R2 General Header constraints do not have correspondingconformance statements in this DSTU.




Page 15March 2013


OverviewThis implementation guide is generated from UML models developed in the Open Health Tools (OHT) Model-DrivenHealth Tools (MDHT) project. The data specifications have been formalized into computational models expressed inUML. These models are used by automated tooling to generate validation tools and Java libraries for implementers.This publication is generated by the tool from UML models as well.

Figure 1: Privacy Consent Directive Header rendered – example

Glossary1. Client: A client is a person who may receive or has received healthcare services in the past. Patient is a role

played by a client in the context of a health care encounter.2. Privacy Consent or Consent: Within the scope of this document, Consent refers to any client instructions that

declare their preferences with respect to health care privacy policies.




Page 16March 2013


3. Individually Identifiable Health Information (IIHI): For the purpose of this document, IIHI refers to healthdata that is transmitted by or maintained in electronic media or any other form or medium that can be uniquelyassociated with an individual. The use of this term is without respect to any jurisdiction.

4. Privacy Consent Directive: A client’s instructions regarding consent to collect, use and/or disclose IIHI.5. Consenter: The person who consents to the collection, use or disclosure of a client’s IIHI. The consenter may be

the client or a Substitute Decision Maker (SDM).

ApproachThis specification provides a CDA R2 representation of the Privacy Consent Directive structure described in the HL7 Version 3 Domain Analysis Model: Security, Release 1 - containing the Harmonized Security and Privacyrequirements analysis. This specification includes new requirements introduced by early adopters during the trialperiod since September 2010.

Existing specifications and terminology standards were leveraged to create this Implementation Guide resulting in abackwards-compatible document specification described graphically below:

Figure 2: Specification derivation and relationship to other standards

The following specifications were used to create this implementation guide:

• Clinical LOINC® document and section codes• Health Information Technology Standards Panel (HITSP) Constructs, Transaction Package (TP30) - Manage

Consent Directives• HL7 Clinical Document Architecture, Release 2 Normative Edition 2005,• Integrating the Healthcare Enterprise (IHE) Profiles, including the content profiles within Cross-Enterprise

Sharing Document (XDS) Sharing Scanned Documents Integration Profile (XDS-SD) and Basic Patient PrivacyConsents (BPPC) that is based on it

• HL7 Version 3 Domain Analysis Model: Security, Release 1- contains the Harmonized Security and PrivacyDomain Analysis Model that specifies the contents of a Privacy Consent Directive document. The full DomainAnalysis Model publication is available for review and comment on the HL7 DSTU page .

http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=74






Page 17March 2013


• Sample privacy consent authorization forms provided by the state and federal agencies (e.g., SAMHSA,SSA,VHA, Sate of New York, State of California, British Columbia

ScopeThe scope of this Implementation Guide applies to privacy consent directives intended to protect health informationmaintained in electronic health records (EHR-S), personal health records (PHR-S), Health Information Exchangesystems (HIEs) and other forms of electronic collection and maintenance of health information. This specificationis used to specify a Privacy Consent Directive in a format that may be used to sign the privacy consent as well as toallow information systems and specific rule engines to decode the assertions contained therein.

This Privacy Consent Directive Implementation Guide provides a mechanism to record a client’s health informationprivacy consent(s) and to exchange those privacy consent directives with entities that are custodians of the client'shealth records including Individually Identifiable Health Information (IIHI).

This DSTU implementation guide for Privacy Consent Directives is the second such implementation guide intendedto exchange health information privacy preferences for clients as privacy consent authorizations. The currentspecification, BPPC allows only for binary acknowledgement of an externally identified and defined policy of nospecific format and does not provide the ability to encode policy in a computable format.

The BPPC standard does not support stakeholders for a computable representation of client privacy consents and thisspecification, based on requirements documented in the Composite Security and Privacy Domain Analysis Model(CPCD DAM), is intended to fulfill this gap. Additional constraints on CDA R2 header and body elements used in aBPPC Document are defined by this specification, including general header constraints for consenter and informationrecipient as documented in the CPCD DAM graphically presented in the figure below. (See also 2 CDA HeaderConstraints).




Page 18March 2013


Figure 3: Security Domain Analysis: Privacy Consent Structure

The implementation guide specifies a structure for formatting client health information privacy preferences and isonly intended to describe the business requirements and semantics of the information needed to specify a PrivacyConsent Directive (Enterprise and Information viewpoints). This guide does not provide an Engineering point of viewand is not intended to describe a policy language.

Where no constraints are stated in this guide, the Privacy Consent Directive document instances are subject to, andare to be created in, accordance with the base CDA R2 specification. For instance, where the CDA R2 declares anattribute to be optional and the Privacy Consent Directive specification (or any of its parent specifications) containsno additional constraints. That attribute remains optional for use in a Privacy Consent Directive instance.




Page 19March 2013


AudienceThe audience for this document includes software developers, system architects, policy makers and analystsresponsible for implementation of secure Electronic Health Record (EHR) systems, Personal Health Record (PHR)systems, dictation/transcription systems, and document management applications; and local, regional, and nationalhealth information exchange networks that wish to create and/or process CDA documents developed according to thisspecification.

Organization of This GuideThe requirements as laid out in the body of this document are subject to change per the policy on implementationguides (see section 13.02" Draft Standard for Trial Use Documents" within the HL7 Governance and OperationsManual, http://www.hl7.org/documentcenter/public/membership/HL7_Governance_and_Operations_Manual.pdf ).

Templates

Templates are organized by document (see Document Templates), by section (see Section Templates), and by clinicalstatements (see Clinical Statement Templates). Within a section, templates are arranged hierarchically, where a morespecific template is nested under the more generic template that it conforms to.

See Templates by Containment for a list of the higher level templates by containment. The appendix, Templates Usedin This Guide includes a table of all templates Organized Hierarchically.

Vocabulary and Value Sets

Vocabularies recommended in this guide are from standard vocabularies. When SNOMED codes are used, rulesdefined in Using SNOMED CT in HL7 Version 3 are adhered to. In many cases, these vocabularies are furtherconstrained into value sets for use within this guide. Value set names and OIDs are listed in the summary tablecontained in the Value Sets section of this guide. Each named value set in the summary table is stored in a templatedatabase that will be maintained by CHCA.

Use of TemplatesWhen valued in an instance, the template identifier (templateId) signals the imposition of a set of template-defined constraints. The value of this attribute provides a unique identifier for the templates in question.

Originator Responsibilities

An originator can apply a templateId to assert conformance with a particular template.

In the most general forms of CDA exchange, an originator need not apply a templateId for every template that anobject in an instance document conforms to. This implementation guide asserts when templateIds are required forconformance.

Recipient Responsibilities

A recipient may reject an instance that does not contain a particular templateId (e.g., a recipient looking to receiveonly CCD documents can reject an instance without the appropriate templateId).

A recipient may process objects in an instance document that do not contain a templateId (e.g., a recipientcan process entries that contain Observation acts within a Problems section, even if the entries do not havetemplateIds).

Conventions Used in This Guide

http://www.hl7.org/documentcenter/public/membership/HL7_Governance_and_Operations_Manual.pdf




Page 20March 2013


Conformance Requirements

Conformance statements are grouped and identified by the name of the template, along with the templateId and thecontext of the template (e.g., ClinicalDocument, section, observation), which specifies the element under constraint.If a template is a specialization of another template, its first constraint indicates the more general template. In all caseswhere a more specific template conforms to a more general template, asserting the more specific template also impliesconformance to the more general template. An example is shown below.

Template name

[<type of template>: templateId <XXXX.XX.XXX.XXX>]

Description of the template will be here .....

1. Conforms to <The template name> Template (templateId: XXXX<XX>XXX>YYY).2. SHALL contain [1..1] @classCode = <AAA> <code display name> (CodeSystem: 123.456.789 <XXX> Class)

STATIC (CONF:<number>).3. .......

Figure 4: Template name and "conforms to" appearance

The conformance verb keyword at the start of a constraint (SHALL, SHOULD, MAY, etc.) indicates businessconformance, whereas the cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within aninstance. Thus, " MAY contain 0..1" and " SHOULD contain 0..1" both allow for a document to omit the particularcomponent, but the latter is a stronger recommendation that the component be included if it is known.

The following cardinality indicators may be interpreted as follows:

0..1 as zero to one present1..1 as one and only one present2..2 as two must be present1..* as one or more present0..* as zero to many present

Value set bindings adhere to HL7 Vocabulary Working Group best practices, and include both a conformance verb (SHALL , SHOULD , MAY, etc.) and an indication of DYNAMIC vs. STATIC binding. The use of SHALL requiresthat the component be valued with a member from the cited value set; however, in every case any HL7 "null" valuesuch as other (OTH) or unknown (UNK) may be used.

Each constraint is uniquely identified (e.g., "CONF:605") by an identifier placed at or near the end of the constraint.These identifiers are not sequential as they are based on the order of creation of the constraint.

1. SHALL contain [1..1] component/structuredBody (CONF:4082).

a. This component/structuredBody SHOULD contain [0..1] component (CONF:4130) such that it

a. SHALL contain [1..1] Reporting Parameters section (templateId:2.16.840.1.113883.10.20.17.2.1)(CONF:4131).

b. This component/structuredBody SHALL contain [1..1] component (CONF:4132) such that it

a. SHALL contain [1..1] Patient data section - NCR (templateId:2.16.840.1.113883.10.20.17.2.5)(CONF:4133).

Figure 5: Template-based conformance statements example

CCD templates are included within this implementation guide for ease of reference. CCD templates contained withinthis implementation guide are formatted WITHOUT typical KEYWORD and XML element styles.

A WIKI site is available if you would like to make a comment to be considered for the next release of CCD:http://wiki.hl7.org/index.php?title=CCD_Suggested_Enhancements

The user name and password are: wiki/wikiwiki. You will need to create an account to edit the page and add yoursuggestion.

http://wiki.hl7.org/index.php?title=CCD_Suggested_Enhancements

http://wiki.hl7.org/index.php?title=CCD_Suggested_Enhancements




Page 21March 2013


1. The value for "Observation / @moodCode" in a problem observation SHALL be "EVN"2.16.840.1.113883.5.1001 ActMood STATIC. (CONF: 814).

2. A problem observation SHALL include exactly one Observation / statusCode. (CONF: 815).3. The value for "Observation / statusCode" in a problem observation SHALL be "completed"

2.16.840.1.113883.5.14 ActStatus STATIC. (CONF: 816).4. A problem observation SHOULD contain exactly one Observation / effectiveTime, to indicate the biological

timing of condition (e.g. the time the condition started, the onset of the illness or symptom, the duration of acondition). (CONF: 817).

Figure 6: CCD conformance statements example

Keywords

The keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, and NEED NOT in this document are to beinterpreted as described in the HL7 Version 3 Publishing Facilitator's Guide:

• SHALL: an absolute requirement• SHALL NOT: an absolute prohibition against inclusion• SHOULD/SHOULD NOT: valid reasons to include or ignore a particular item, but must be understood and

carefully weighed• MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications

XML Examples

XML samples appear in various figures in this document in a fixed-width font. Portions of the XML content may beomitted from the content for brevity, marked by an ellipsis (…) as shown in the example below.

<ClinicalDocument xmlns=’urn:h17-org:v3’> ...</ClinicalDocument>

Figure 7: ClinicalDocument example

XPath expressions are used in the narrative and conformance requirements to identify elements because they arefamiliar to many XML implementers.

Security ConsiderationsThere are times when clients may wish to constrain sensitive healthcare topics (e.g., HIV status). However, encodingthis restriction to a policy in a CDA R2-Privacy Consent document instance could be viewed as a strong indicator thatthe client is positive for these sensitive healthcare topics. Therefore, the CDA R2 Privacy Consent document instanceitself needs to be similarly constrained and protected. There is nothing more that the HL7 specification can do on thistopic, so it is cataloged here as a risk that requires mitigation during an implementation or deployment. There are afew ways to handle this risk:

1. Sensitive health topics that most clients would wish to block could be blocked by default. However, those clientswho are not sensitive to these blocked-by-default health topics could indicate that they do not want these topicsto be restricted and thus are available for exchange. This will work well if the number of clients that allowunrestrained access to the sensitive topics is a small number, but as this number of clients gets larger, the sameproblem will exist.

2. The CDA R2 Privacy Consent document instance that contains these constraints could be identified with theconfidentialityCode appropriate for the environment. Typically documents that include sensitive topics or forwhich there are other reasons to restrict their access would be labeled with a higher data classification such as“R” for Restricted. Since there are many reasons for a document (object) to be identified as Restricted, this higherdefinition of a data classification will restrict access to the CDA R2 Privacy Consent document instance withoutexposing the specific reason.

http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm




Page 22March 2013


3. The CDA R2 Privacy Consent document instances could be restricted to a document class with very specificaccess permissions/roles, e.g., only the Privacy Office and Access Control engine. In this way, no CDA R2Privacy Consent documents would be viewable by clinicians.




Page 23March 2013


CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | DOCUMENT TEMPLATES | 24



Page 24March 2013


Chapter

2DOCUMENT TEMPLATES

Topics:

• Privacy Consent DirectiveDocument

• Privacy Consent HeaderConstraints

This section contains the document level constraints for CDA documents thatare compliant with this implementation guide.




Page 25March 2013


Privacy Consent Directive Document[ClinicalDocument: templateId 2.16.840.1.113883.3.445]

1. SHALL contain exactly one [1..1] templateId ( CONF-CD-0 ) such that it

a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445"2. SHALL conform to Privacy Consent Header Constraints template (templateId:

2.16.840.1.113883.3.445.1)3. SHALL contain zero or one [0..1] component (CONF:9099)

a. Contains exactly one [1..1] Privacy Consent Details Section (templateId:2.16.840.1.113883.3.445.17)

4. MAY contain zero or one [0..1] component (CONF:9100)

a. Contains exactly one [1..1] Signatures Section (templateId: 2.16.840.1.113883.3.445.18)

1. SHALL conform to Consol General Header Constraints template (templateId:2.16.840.1.113883.10.20.22.1.1)

2. SHALL conform to Privacy Consent Header Constraints template (templateId:2.16.840.1.113883.3.445.1)

3. SHALL contain exactly one [1..1] realmCode/@code="US" (CONF:16791)4. SHALL contain exactly one [1..1] typeId (CONF:5361)5. SHALL contain exactly one [1..1] id (CONF:5363)6. SHALL contain exactly one [1..1] code (CONF:5253)7. SHALL contain exactly one [1..1] title and MAY equal "Authorization for Disclosure" (CONF:9087)8. SHALL contain exactly one [1..1] effectiveTime (CONF:5256)

• Signifies the document creation time, when the document first came into being. Where the CDA document isa transform from an original document in some other format, the ClinicalDocument.effectiveTime is the timethe original document is created. The time when the transform occurred is not currently represented in CDA(CONF:9995)

9. SHALL contain exactly one [1..1] confidentialityCode, where the @code SHALL be selected fromValueSet HL7 BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 STATIC(CONF:5259)

10. SHALL contain exactly one [1..1] languageCode, where the @code SHALL be selected from ValueSetLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC (CONF:5372)

11. MAY contain zero or one [0..1] setId (CONF:5261)12. MAY contain zero or one [0..1] versionNumber (CONF:5264)13. SHALL contain zero or one [0..1] consentAuthor with data type Privacy Consent Header Author

(CONF:9088)

• The author of the document (assignedAuthor) need not be the author of the policy (author). The documentheader may also identify the device used to scan the signed hardcopy document that contains the privacyconsent directive of the client (assignedAuthoringDevice). The following asserts conformance to the PrivacyConsent Directive DSTU.

14. SHALL contain zero or one [0..1] documentedConsentAuthorization with data type Privacy ConsentHeader Documentation Of Service Event (CONF:9090)

• This data element specifies the consent authorization event captured by the document.15. Contains exactly one [1..1] component, where its type is Component2

a. Contains exactly one [1..1] Component216. SHALL contain at least one [1..*] recordTarget (CONF:5266)

The recordTarget records the patient whose health information is described by the clinical document; it mustcontain at least one patientRole element.

http://www.cdatools.org/infocenter/topic/org.openhealthtools.mdht.uml.cda.consol.doc/classes/GeneralHeaderConstraints.html




Page 26March 2013


a. Such recordTargets SHALL contain exactly one [1..1] patientRole (CONF:5268)

a. This patientRole SHALL contain at least one [1..*] addr with data type US Realm Address (CONF:5271)b. This patientRole SHALL contain at least one [1..*] id (CONF:5268)c. This patientRole SHALL contain at least one [1..*] telecom with data type TEL (CONF:5280)d. This patientRole SHALL contain exactly one [1..1] patient (CONF:5283)

a. This patient SHALL contain exactly one [1..1] administrativeGenderCode, wherethe @code SHALL be selected from ValueSet Administrative Gender (HL7 V3)2.16.840.1.113883.1.11.1 DYNAMIC (CONF:6394)

b. This patient SHALL contain exactly one [1..1] birthTime (CONF:5298)c. This patient MAY contain zero or one [0..1] ethnicGroupCode, where the @code SHALL be

selected from ValueSet Ethnicity Value Set 2.16.840.1.114222.4.11.837 STATIC(CONF:5323)

d. This patient SHOULD contain zero or one [0..1] maritalStatusCode (CONF:5303),where the @code SHALL be selected from ValueSet HL7 Marital Status2.16.840.1.113883.1.11.12212 STATIC 1

e. This patient SHALL contain exactly one [1..1] name with data type US Realm Patient Name(CONF:5284)

f. This patient MAY contain zero or one [0..1] raceCode, where the @code SHALL be selected fromValueSet Race 2.16.840.1.113883.1.11.14914 STATIC 1 (CONF:5322)

g. This patient MAY contain zero or one [0..1] religiousAffiliationCode (CONF:5317),where the @code SHALL be selected from ValueSet HL7 Religious Affiliation2.16.840.1.113883.1.11.19185 STATIC 1

h. This patient MAY contain zero or more [0..*] guardian (CONF:5325)

a. Such guardians SHOULD contain zero or more [0..*] addr with data type US Realm Addressb. Such guardians SHOULD contain zero or one [0..1] code, where the @code

SHALL be selected from ValueSet Personal Relationship Role Type2.16.840.1.113883.1.11.19563 STATIC 1 (CONF:5326)

c. Such guardians MAY contain zero or more [0..*] telecom with data type TELd. Such guardians SHALL contain exactly one [1..1] guardianPerson

a. This guardianPerson SHALL contain at least one [1..*] nameb. This guardianPerson The content of name SHALL be a conformant US Realm Person Name

(PTN.US.FIELDED) (2.16.840.1.113883.10.20.22.5.1.1) (CONF:10414)i. This patient MAY contain zero or one [0..1] birthplace (CONF:5395)

a. This birthplace SHALL contain exactly one [1..1] place (CONF:5396)

a. This place SHALL contain exactly one [1..1] addr (CONF:5397)b. This place 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 DYNAMICc. This place This addr MAY contain zero or one [0..1] postalCode, which SHALL be selected

from ValueSet PostalCodeValueSet 2.16.840.1.113883.3.88.12.80.2 DYNAMICd. This place This addr SHOULD contain zero or one [0..1] country, which SHALL be selected

from ValueSet CountryValueSet 2.16.840.1.113883.3.88.12.80.63 DYNAMICj. This patient SHOULD contain zero or more [0..*] languageCommunication (CONF:5406)

a. Such languageCommunications MAY contain zero or one [0..1] preferenceInd (CONF:5414)b. Such languageCommunications SHOULD contain zero or one [0..1] proficiencyLevelCode,

where the @code SHALL be selected from ValueSet LanguageAbilityProficiency2.16.840.1.113883.1.11.12199 STATIC (CONF:9965)

c. Such languageCommunications MAY contain zero or one [0..1] modeCode, wherethe @code SHALL be selected from ValueSet HL7 LanguageAbilityMode2.16.840.1.113883.1.11.12249 STATIC 1 (CONF:5409)




Page 27March 2013


d. Such languageCommunications SHALL contain exactly one [1..1] languageCode, where the@code SHALL be selected from ValueSet Language 2.16.840.1.113883.1.11.11526DYNAMIC (CONF:5407)

k. This patient MAY contain zero or more [0..*] sDTCRaceCode, where the @code SHALL be selectedfrom ValueSet Race 2.16.840.1.113883.1.11.14914 STATIC 1 (CONF:7263)

l. This patient SHALL satisfy: BirthTime precise to yearm. This patient SHOULD satisfy: BirthTime precise to day

e. This patientRole MAY contain zero or one [0..1] providerOrganization (CONF:5416)

a. This providerOrganization SHALL contain at least one [1..*] addr with data type US Realm Address(CONF:5422)

b. This providerOrganization SHALL contain at least one [1..*] id (CONF:5417)c. This providerOrganization SHALL contain at least one [1..*] name (CONF:5419)d. This providerOrganization SHALL contain at least one [1..*] telecom with data type TEL

(CONF:5420)e. This providerOrganization The id SHOULD include zero or one [0..1] id where id/@root

="2.16.840.1.113883.4.6" National Provider Identifier (CONF:9996) (CONF:9996)17. MAY contain exactly one [1..1] componentOf (CONF:9955)

a. This componentOf SHALL contain exactly one [1..1] encompassingEncounter (CONF:9956)

a. This encompassingEncounter SHALL contain exactly one [1..1] effectiveTime (CONF:9958)b. This encompassingEncounter SHALL contain at least one [1..*] id (CONF:9959)

18. SHALL contain at least one [1..*] author (CONF:5444)

a. Such authors SHALL contain exactly one [1..1] time (CONF:5445)b. Such authors SHALL contain exactly one [1..1] assignedAuthor (CONF:5448)

a. This assignedAuthor SHALL contain at least one [1..*] addr with data type US Realm Address(CONF:5452)

b. This assignedAuthor SHOULD contain zero or one [0..1] code (CONF:16787), where the @codeSHOULD be selected from ValueSet Healthcare Provider Taxonomy (NUCC - HIPAA)2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:16788)

c. This assignedAuthor SHALL contain at least one [1..*] id (CONF:5449)d. This assignedAuthor SHALL contain at least one [1..*] telecom with data type TEL (CONF:5428)e. This assignedAuthor SHOULD contain zero or one [0..1] assignedAuthoringDevice

a. This assignedAuthoringDevice SHALL contain exactly one [1..1] manufacturerModelName(CONF:16784)

b. This assignedAuthoringDevice SHALL contain exactly one [1..1] softwareName (CONF:16785)f. This assignedAuthor SHOULD contain zero or one [0..1] assignedPerson

a. This assignedPerson SHALL contain at least one [1..*] name (CONF:16789)g. This assignedAuthor This assignedAuthor SHALL contain exactly one [1..1] assignedPerson or

assignedAuthoringDevice (CONF:16790)h. This assignedAuthor The id SHALL contain exactly one root ="2.16.840.1.113883.4.6" National Provider

Identifier (CONF:9996) (CONF:16786)c. Such authors This time SHALL contain exactly one [1..1] US Realm Date and Time (DTM.US.FIELDED)

(2.16.840.1.113883.10.20.22.5.4) (CONF:5446)19. MAY contain zero or one [0..1] dataEnterer (CONF:5441)

a. This dataEnterer SHALL contain exactly one [1..1] assignedEntity (CONF:5442)

a. This assignedEntity SHALL contain at least one [1..*] addr with data type US Realm Address(CONF:5460)

b. This assignedEntity MAY contain zero or one [0..1] code, where the @code SHOULD be selected from(CodeSystem: 2.16.840.1.113883.6.101 NUCC Health Care Provider Taxonomy)(CONF:9944)




Page 28March 2013


c. This assignedEntity SHALL contain at least one [1..*] id (CONF:5443)d. This assignedEntity SHALL contain at least one [1..*] telecom with data type TEL (CONF:5466)e. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:5469)

a. This assignedPerson SHALL contain at least one [1..*] namef. This assignedEntity id SHOULD include zero or one [0..1] @root ="2.16.840.1.113883.4.6" National

Provider Identifier (CONF:16821)20. SHALL contain exactly one [1..1] custodian (iv., CONF:5519)

a. This custodian SHALL contain exactly one [1..1] assignedCustodian (CONF:5520)

a. This assignedCustodian SHALL contain zero or one [0..1] representedCustodianOrganization(CONF:5521)

a. This representedCustodianOrganization SHALL contain at least one [1..*] addr with data type USRealm Address (CONF:5559)

b. This representedCustodianOrganization SHALL contain at least one [1..*] id (CONF:5522)c. This representedCustodianOrganization SHALL contain exactly one [1..1] name (CONF:5524)d. This representedCustodianOrganization SHALL contain exactly one [1..1] telecom with data type

TEL (CONF:5525)e. This representedCustodianOrganization The id SHOULD include zero or one [0..1] @root

="2.16.840.1.113883.4.6" National Provider Identifier (CONF:9996)21. MAY contain zero or more [0..*] informationRecipient (CONF:5565)

a. Such informationRecipients SHALL contain exactly one [1..1] intendedRecipient (CONF:5566)

a. This intendedRecipient MAY contain zero or one [0..1] informationRecipient (CONF:5568)

a. This informationRecipient SHALL contain at least one [1..*] name (CONF:5470)b. This intendedRecipient MAY contain zero or one [0..1] receivedOrganization (CONF:5577)

a. This receivedOrganization SHALL contain exactly one [1..1] name (CONF:5578)22. SHOULD contain zero or one [0..1] legalAuthenticator (CONF:5579)

a. This legalAuthenticator SHALL contain exactly one [1..1] time (CONF:5580)b. This legalAuthenticator SHALL contain exactly one [1..1] signatureCode/@code="S" (CodeSystem:

2.16.840.1.113883.5.89 Participationsignature) (CONF:5583, CONF:5584)c. This legalAuthenticator Contains zero or one [0..1] assignedEntity


b. This assignedEntity MAY contain zero or one [0..1] code (CONF:17000), where the @codeSHOULD be selected from ValueSet Healthcare Provider Taxonomy (NUCC - HIPAA)2.16.840.1.114222.4.11.1066 DYNAMIC


a. This assignedPerson SHALL contain at least one [1..*] name (CONF:5598)f. This assignedEntity The id MAY include zero or one [0..1] root ="2.16.840.1.113883.4.6" National

Provider Identifier (CONF:9996) (CONF:16823)23. MAY contain zero or more [0..*] authenticator (CONF:5607)

a. Such authenticators SHALL contain exactly one [1..1] time (CONF:5608)b. Such authenticators SHALL contain exactly one [1..1] signatureCode/@code="S" (CodeSystem:

2.16.840.1.113883.5.89 Participationsignature) (CONF:5610)c. Such authenticators SHALL contain exactly one [1..1] assignedEntity (CONF:5612)





Page 29March 2013


b. This assignedEntity MAY contain zero or one [0..1] code (CONF:16825), where the @codeSHOULD be selected from ValueSet Healthcare Provider Taxonomy (NUCC - HIPAA)2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:16826)


a. This assignedPerson SHALL contain at least one [1..*] name (CONF:5625)f. This assignedEntity The id SHOULD include zero or one [0..1] root ="2.16.840.1.113883.4.6" National

Provider Identifier (CONF:9996)24. MAY contain zero or one [0..1] informant (CONF:8001)

a. This informant MAY contain zero or one [0..1] assignedEntity

a. This assignedEntity SHOULD contain zero or more [0..*] addr with data type US Realm Address(CONF:8220)


c. This assignedEntity SHALL contain at least one [1..*] id (CONF:9945)d. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:8221)

a. This assignedPerson SHALL contain at least one [1..*] namee. This assignedEntity The id SHOULD include zero or one [0..1] id where id/@root

="2.16.840.1.113883.4.6" National Provider Identifier (CONF:9996)b. This informant MAY contain zero or one [0..1] relatedEntity

a. This relatedEntity SHOULD contain zero or more [0..*] addr with data type US Realm Address(CONF:8220)

b. This relatedEntity SHALL contain zero or one [0..1] relatedPerson (CONF:8221)

a. This relatedPerson SHALL contain at least one [1..*] namec. This informant SHALL satisfy: contain exactly one [1..1] assignedEntity OR exactly one [1..1] relatedEntity

(CONF:8002)25. MAY contain zero or more [0..*] participant (CONF:10003)

a. Such participants MAY contain zero or one [0..1] time (CONF:10004)b. Such participants Such participants, if present, SHALL have an associatedPerson or scopingOrganization

element under participant/associatedEntity.c. Such participants Unless otherwise specified by the document specific header constraints, when participant/

@typeCode is IND, associatedEntity/@classCode SHALL be selected from ValueSet INDRoleclassCodes2.16.840.1.113883.11.20.9.33 STATIC 2011-09-30.

26. MAY contain zero or more [0..*] inFulfillmentOf (CONF:9952)

a. Such inFulfillmentOfs SHALL contain exactly one [1..1] order (CONF:9953)

a. This order SHALL contain at least one [1..*] id (CONF:9954)27. MAY contain zero or more [0..*] documentationOf (CONF:14835)

a. Such documentationOfs SHALL contain exactly one [1..1] serviceEvent (CONF:14836)

a. This serviceEvent SHALL contain exactly one [1..1] effectiveTime (CONF:14837)b. This serviceEvent SHOULD contain zero or more [0..*] performer (CONF:14839)

a. Such performers SHALL contain exactly one [1..1] @typeCode (CONF:14840)b. Such performers MAY contain zero or one [0..1] functionCode (CONF:16818), where

the @code SHOULD be selected from (CodeSystem: 2.16.840.1.113883.5.88ParticipationFunction) (CONF:16819)

c. Such performers SHALL contain exactly one [1..1] assignedEntity (CONF:14841)




Page 30March 2013


a. This assignedEntity SHOULD contain zero or one [0..1] code (CONF:14842), where the @codeSHALL be selected from (CodeSystem: 2.16.840.1.113883.6.101 NUCC HealthCare Provider Taxonomy) (CONF:14843)

b. This assignedEntity SHALL contain at least one [1..*] id (CONF:14846)c. This assignedEntity The id SHOULD include zero or one [0..1]root ="2.16.840.1.113883.4.6"

National Provider Identifier (CONF:9996) (CONF:14847)c. This serviceEvent effectiveTime SHALL contain exactly one [1..1] low (CONF:14838)

28. MAY contain zero or more [0..*] authorization (CONF:16792)

a. Such authorizations SHALL contain exactly one [1..1] consent (CONF:16793)

a. This consent MAY contain zero or one [0..1] code (CONF:16795)

The type of consent (e.g., a consent to perform the related serviceEvent) is conveyed in consent/code(CONF:16796).

b. This consent MAY contain zero or more [0..*] id (CONF:16794)c. This consent SHALL contain exactly one [1..1] statusCode (CONF:16797)/@code="completed"

Completed (CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass) (CONF:16798)29. SHALL contain exactly one [1..1] custodian (CONF:9089)

This element of the header identifies the custodian of the Privacy Consent Directive document as specified by CDAR2. It may be a provider or a health information exchange.







Information Recipient is used to specify the recipients of the Privacy Consent Directive. In the case ofconsultations and referrals, the Privacy Consent Directive recipient may be the same person/entity as the intendedrecipient of the client IIHI that is disclosed as a result of the permission granted using the Privacy ConsentDirective.




a. This receivedOrganization SHALL contain exactly one [1..1] name (CONF:5578)31. SHALL contain at least one [1..*] recordTarget (CONF:9093)

Each Privacy Consent Directive must specify a healthcare client whose IIHI is affected by the privacy consentdirective. The classes of Patient and patientRole describe the healthcare client whose IIHI is referenced indocument.


a. This patientRole SHALL contain at least one [1..*] addr with data type US Realm Address (CONF:5271)




Page 31March 2013


b. This patientRole SHALL contain at least one [1..*] id (CONF:5268)c. This patientRole SHALL contain at least one [1..*] telecom with data type TEL (CONF:5280)d. This patientRole SHALL contain exactly one [1..1] patient (CONF:5283)









a. Such guardians SHOULD contain zero or more [0..*] addr with data type US Realm Addressb. Such guardians SHOULD contain zero or one [0..1] code, where the @code

SHALL be selected from ValueSet Personal Relationship Role Type2.16.840.1.113883.1.11.19563 STATIC 1 (CONF:5326)
















Page 32March 2013








="2.16.840.1.113883.4.6" National Provider Identifier (CONF:9996) (CONF:9996)32. SHOULD contain zero or more [0..*] relatedDocument (CONF:9094)

a. Contains exactly one [1..1] CDA Related Document33. SHOULD contain at least one [1..*] authenticator (CONF:9095)

In some cases, a Privacy Consent Directive may identify and record the signature of a person who witnessed theconsenter's signature. This may occur if the authenticator/consenter makes a mark instead of a signature







Provider Identifier (CONF:9996)34. SHALL contain zero or one [0..1] legalAuthenticator (CONF:5579)

The legalAuthenticator is as defined in CDA. For a Privacy Consent Document this element may be either theclient or their Substitute Decision Maker. If necessary, the Signatures section may provide the signature associatedwith the consenter's signature.





c. This assignedEntity SHALL contain at least one [1..*] id (CONF:5586)d. This assignedEntity SHALL contain at least one [1..*] telecom with data type TEL (CONF:5595)




Page 33March 2013


e. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:5597)


Provider Identifier (CONF:9996) (CONF:16823)35. SHALL contain zero or one [0..1] component (CONF:9099)

a. Contains exactly one [1..1] Privacy Consent Details Section (templateId:2.16.840.1.113883.3.445.17)

36. MAY contain zero or one [0..1] component (CONF:9100)

a. Contains exactly one [1..1] Signatures Section (templateId: 2.16.840.1.113883.3.445.18)37. SHALL satisfy: The US Realm Clinical Document Date and Time datatype flavor records date and time

information. If no time zone offset is provided, you can make no assumption about time, unless you have made alocal exchange agreement. This data type uses the same rules as US Realm Date and Time (DTM.US.FIELDED),but is used with the effectiveTime element.

38. SHALL satisfy: The US Realm Clinical Document Date and Time datatype flavor records date and timeinformation. If no time zone offset is provided, you can make no assumption about time, unless you have made alocal exchange agreement. This data type uses the same rules as US Realm Date and Time (DTM.US.FIELDED),but is used with the effectiveTime element.

39. typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250)40. typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251)41. id SHALL be a globally unique identifier for the document (CONF:9991)42. code SHALL specify the particular kind of document (e.g. History and Physical, Discharge Summary, Progress

Note). (CONF:9992)43. If setId is present versionNumber SHALL be present (CONF:6380)44. If versionNumber is present setId SHALL be present (CONF:6387)

Privacy Consent Directive Document example

<?xml version="1.0" encoding="UTF-8"?><ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"> <typeId root="2.16.840.1.113883.1.3"/> <templateId root="2.16.840.1.113883.3.445"/> <templateId root="2.16.840.1.113883.3.445.1"/> <id root="MDHT" extension="283361263"/> <code code="1336989148"/> <title>Authorization for Disclosure</title> <effectiveTime/> <confidentialityCode code="20781841"/> <setId root="MDHT" extension="948ebfd8-136f-427a-8817-7f4d9a10a760"/> <versionNumber value="1"/> <recordTarget> <typeId root="2.16.840.1.113883.1.3"/> <patientRole/> </recordTarget> <author> <typeId root="2.16.840.1.113883.1.3"/> <time/> <assignedAuthor/> </author> <custodian/> <component> <structuredBody> <component> <section> <typeId root="2.16.840.1.113883.1.3"/> <templateId root="2.16.840.1.113883.3.445.17"/> <id root="MDHT" extension="1083265006"/>




Page 34March 2013


<code code="57016-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <title>Privacy Consent Directive Details</title> <entry> <act/> <observation/> <observationMedia/> </entry> </section> </component> <component> <section> <typeId root="2.16.840.1.113883.1.3"/> <templateId root="2.16.840.1.113883.3.445.18"/> <id root="MDHT" extension="1819254960"/> <code code="1104717956"/> <title>Signatures</title> <entry> <observationMedia/> </entry> </section> </component> </structuredBody> </component></ClinicalDocument>

Privacy Consent Header Constraints[ClinicalDocument: templateId 2.16.840.1.113883.3.445.1]

Known Subclasses: Privacy Consent Directive Document

The CDA R2 Implementation Guide for Privacy Consent Directives DSTU defines a set of general constraints againstthe CDA R2 header. Conformance to this DSTU carries with it an implicit adherence to Level 1 which asserts headerelement constraints. Conformance to the DSTU at Level 1, whether specified or implicit, asserts header elementconstraints but allows a non-XML body or an XML body that may or may not conform to additional templates definedherein. Likewise, conformance to this DSTU at Level 2 does not require conformance to entry-level templates, butdoes assert conformance to header- and section-level templates. In all cases, required privacy clinical content mustbe present. For example, a CDA R2 Discharge Summary carrying the templateId that asserts conformance with Level1 may use a PDF or HTML format for the body of the document that contains the required health information privacyconsent.A Privacy Consent Directive is enforced if the ClinicalDocument/statusCode is set to "active" or if it is revoked, theClinicalDocument/statusCode code is set to "aborted". If the Consent Directive is expired, the ClinicalDocument/statusCode is set to "completed".


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.1"2. SHALL conform to Consol General Header Constraints template (templateId:

2.16.840.1.113883.10.20.22.1.1)3. SHALL contain exactly one [1..1] title and MAY equal "Authorization for Disclosure" (CONF:9087)4. SHALL contain exactly one [1..1] custodian (CONF:9089)








Page 35March 2013






















a. Such guardians SHOULD contain zero or more [0..*] addr with data type US Realm Address




Page 36March 2013


b. Such guardians SHOULD contain zero or one [0..1] code, where the @codeSHALL be selected from ValueSet Personal Relationship Role Type2.16.840.1.113883.1.11.19563 STATIC 1 (CONF:5326)























2.16.840.1.113883.5.89 Participationsignature) (CONF:5610)




Page 37March 2013


c. Such authenticators SHALL contain exactly one [1..1] assignedEntity (CONF:5612)





Provider Identifier (CONF:9996)9. SHALL contain zero or one [0..1] consentAuthor with data type Privacy Consent Header Author

(CONF:9088)



• This data element specifies the consent authorization event captured by the document.11. SHALL contain zero or one [0..1] legalAuthenticator (CONF:5579)








Provider Identifier (CONF:9996) (CONF:16823)

1. SHALL conform to Consol General Header Constraints template (templateId:2.16.840.1.113883.10.20.22.1.1)

2. SHALL contain exactly one [1..1] realmCode/@code="US" (CONF:16791)3. SHALL contain exactly one [1..1] typeId (CONF:5361)4. SHALL contain exactly one [1..1] id (CONF:5363)5. SHALL contain exactly one [1..1] code (CONF:5253)6. SHALL contain exactly one [1..1] title and MAY equal "Authorization for Disclosure" (CONF:9087)7. SHALL contain exactly one [1..1] effectiveTime (CONF:5256)





Page 38March 2013


• Signifies the document creation time, when the document first came into being. Where the CDA document isa transform from an original document in some other format, the ClinicalDocument.effectiveTime is the timethe original document is created. The time when the transform occurred is not currently represented in CDA(CONF:9995)

8. SHALL contain exactly one [1..1] confidentialityCode, where the @code SHALL be selected fromValueSet HL7 BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 STATIC(CONF:5259)

9. SHALL contain exactly one [1..1] languageCode, where the @code SHALL be selected from ValueSetLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC (CONF:5372)

10. MAY contain zero or one [0..1] setId (CONF:5261)11. MAY contain zero or one [0..1] versionNumber (CONF:5264)12. SHALL contain zero or one [0..1] consentAuthor with data type Privacy Consent Header Author

(CONF:9088)



• This data element specifies the consent authorization event captured by the document.14. Contains exactly one [1..1] component, where its type is Component2

a. Contains exactly one [1..1] Component215. SHALL contain at least one [1..*] recordTarget (CONF:5266)

The recordTarget records the patient whose health information is described by the clinical document; it mustcontain at least one patientRole element.















Page 39March 2013





















="2.16.840.1.113883.4.6" National Provider Identifier (CONF:9996) (CONF:9996)16. MAY contain exactly one [1..1] componentOf (CONF:9955)

a. This componentOf SHALL contain exactly one [1..1] encompassingEncounter (CONF:9956)

a. This encompassingEncounter SHALL contain exactly one [1..1] effectiveTime (CONF:9958)b. This encompassingEncounter SHALL contain at least one [1..*] id (CONF:9959)

17. SHALL contain at least one [1..*] author (CONF:5444)

a. Such authors SHALL contain exactly one [1..1] time (CONF:5445)b. Such authors SHALL contain exactly one [1..1] assignedAuthor (CONF:5448)




Page 40March 2013


a. This assignedAuthor SHALL contain at least one [1..*] addr with data type US Realm Address(CONF:5452)

b. This assignedAuthor SHOULD contain zero or one [0..1] code (CONF:16787), where the @codeSHOULD be selected from ValueSet Healthcare Provider Taxonomy (NUCC - HIPAA)2.16.840.1.114222.4.11.1066 DYNAMIC (CONF:16788)

c. This assignedAuthor SHALL contain at least one [1..*] id (CONF:5449)d. This assignedAuthor SHALL contain at least one [1..*] telecom with data type TEL (CONF:5428)e. This assignedAuthor SHOULD contain zero or one [0..1] assignedAuthoringDevice

a. This assignedAuthoringDevice SHALL contain exactly one [1..1] manufacturerModelName(CONF:16784)

b. This assignedAuthoringDevice SHALL contain exactly one [1..1] softwareName (CONF:16785)f. This assignedAuthor SHOULD contain zero or one [0..1] assignedPerson

a. This assignedPerson SHALL contain at least one [1..*] name (CONF:16789)g. This assignedAuthor This assignedAuthor SHALL contain exactly one [1..1] assignedPerson or

assignedAuthoringDevice (CONF:16790)h. This assignedAuthor The id SHALL contain exactly one root ="2.16.840.1.113883.4.6" National Provider

Identifier (CONF:9996) (CONF:16786)c. Such authors This time SHALL contain exactly one [1..1] US Realm Date and Time (DTM.US.FIELDED)

(2.16.840.1.113883.10.20.22.5.4) (CONF:5446)18. MAY contain zero or one [0..1] dataEnterer (CONF:5441)

a. This dataEnterer SHALL contain exactly one [1..1] assignedEntity (CONF:5442)




a. This assignedPerson SHALL contain at least one [1..*] namef. This assignedEntity id SHOULD include zero or one [0..1] @root ="2.16.840.1.113883.4.6" National

Provider Identifier (CONF:16821)19. SHALL contain exactly one [1..1] custodian (iv., CONF:5519)












Page 41March 2013



a. This receivedOrganization SHALL contain exactly one [1..1] name (CONF:5578)21. SHOULD contain zero or one [0..1] legalAuthenticator (CONF:5579)







Provider Identifier (CONF:9996) (CONF:16823)22. MAY contain zero or more [0..*] authenticator (CONF:5607)







Provider Identifier (CONF:9996)23. MAY contain zero or one [0..1] informant (CONF:8001)

a. This informant MAY contain zero or one [0..1] assignedEntity

a. This assignedEntity SHOULD contain zero or more [0..*] addr with data type US Realm Address(CONF:8220)


c. This assignedEntity SHALL contain at least one [1..*] id (CONF:9945)d. This assignedEntity SHALL contain exactly one [1..1] assignedPerson (CONF:8221)

a. This assignedPerson SHALL contain at least one [1..*] namee. This assignedEntity The id SHOULD include zero or one [0..1] id where id/@root

="2.16.840.1.113883.4.6" National Provider Identifier (CONF:9996)b. This informant MAY contain zero or one [0..1] relatedEntity




Page 42March 2013


a. This relatedEntity SHOULD contain zero or more [0..*] addr with data type US Realm Address(CONF:8220)

b. This relatedEntity SHALL contain zero or one [0..1] relatedPerson (CONF:8221)

a. This relatedPerson SHALL contain at least one [1..*] namec. This informant SHALL satisfy: contain exactly one [1..1] assignedEntity OR exactly one [1..1] relatedEntity

(CONF:8002)24. MAY contain zero or more [0..*] participant (CONF:10003)

a. Such participants MAY contain zero or one [0..1] time (CONF:10004)b. Such participants Such participants, if present, SHALL have an associatedPerson or scopingOrganization

element under participant/associatedEntity.c. Such participants Unless otherwise specified by the document specific header constraints, when participant/

@typeCode is IND, associatedEntity/@classCode SHALL be selected from ValueSet INDRoleclassCodes2.16.840.1.113883.11.20.9.33 STATIC 2011-09-30.

25. MAY contain zero or more [0..*] inFulfillmentOf (CONF:9952)

a. Such inFulfillmentOfs SHALL contain exactly one [1..1] order (CONF:9953)

a. This order SHALL contain at least one [1..*] id (CONF:9954)26. MAY contain zero or more [0..*] documentationOf (CONF:14835)

a. Such documentationOfs SHALL contain exactly one [1..1] serviceEvent (CONF:14836)

a. This serviceEvent SHALL contain exactly one [1..1] effectiveTime (CONF:14837)b. This serviceEvent SHOULD contain zero or more [0..*] performer (CONF:14839)

a. Such performers SHALL contain exactly one [1..1] @typeCode (CONF:14840)b. Such performers MAY contain zero or one [0..1] functionCode (CONF:16818), where

the @code SHOULD be selected from (CodeSystem: 2.16.840.1.113883.5.88ParticipationFunction) (CONF:16819)

c. Such performers SHALL contain exactly one [1..1] assignedEntity (CONF:14841)

a. This assignedEntity SHOULD contain zero or one [0..1] code (CONF:14842), where the @codeSHALL be selected from (CodeSystem: 2.16.840.1.113883.6.101 NUCC HealthCare Provider Taxonomy) (CONF:14843)

b. This assignedEntity SHALL contain at least one [1..*] id (CONF:14846)c. This assignedEntity The id SHOULD include zero or one [0..1]root ="2.16.840.1.113883.4.6"

National Provider Identifier (CONF:9996) (CONF:14847)c. This serviceEvent effectiveTime SHALL contain exactly one [1..1] low (CONF:14838)

27. MAY contain zero or more [0..*] authorization (CONF:16792)

a. Such authorizations SHALL contain exactly one [1..1] consent (CONF:16793)

a. This consent MAY contain zero or one [0..1] code (CONF:16795)

The type of consent (e.g., a consent to perform the related serviceEvent) is conveyed in consent/code(CONF:16796).

b. This consent MAY contain zero or more [0..*] id (CONF:16794)c. This consent SHALL contain exactly one [1..1] statusCode (CONF:16797)/@code="completed"

Completed (CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass) (CONF:16798)28. SHALL contain exactly one [1..1] custodian (CONF:9089)







Page 43March 2013


























Page 44March 2013

























2.16.840.1.113883.5.89 Participationsignature) (CONF:5610)




Page 45March 2013


c. Such authenticators SHALL contain exactly one [1..1] assignedEntity (CONF:5612)





Provider Identifier (CONF:9996)33. SHALL contain zero or one [0..1] legalAuthenticator (CONF:5579)








Provider Identifier (CONF:9996) (CONF:16823)34. SHALL satisfy: The US Realm Clinical Document Date and Time datatype flavor records date and time

information. If no time zone offset is provided, you can make no assumption about time, unless you have made alocal exchange agreement. This data type uses the same rules as US Realm Date and Time (DTM.US.FIELDED),but is used with the effectiveTime element.

35. SHALL satisfy: The US Realm Clinical Document Date and Time datatype flavor records date and timeinformation. If no time zone offset is provided, you can make no assumption about time, unless you have made alocal exchange agreement. This data type uses the same rules as US Realm Date and Time (DTM.US.FIELDED),but is used with the effectiveTime element.

36. typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250)37. typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251)38. id SHALL be a globally unique identifier for the document (CONF:9991)39. code SHALL specify the particular kind of document (e.g. History and Physical, Discharge Summary, Progress

Note). (CONF:9992)40. If setId is present versionNumber SHALL be present (CONF:6380)41. If versionNumber is present setId SHALL be present (CONF:6387)

Privacy Consent Header Constraints example

<?xml version="1.0" encoding="UTF-8"?>




Page 46March 2013


<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xmlns:sdtc="urn:hl7-org:sdtc" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"> <typeId root="2.16.840.1.113883.1.3"/> <templateId root="2.16.840.1.113883.3.445.1"/> <id root="MDHT" extension="1514155040"/> <code code="1449400035"/> <title>Authorization for Disclosure</title> <effectiveTime/> <confidentialityCode code="618187777"/> <setId root="MDHT" extension="f7731b81-4940-4512-a704-3393ea4ce35c"/> <versionNumber value="1"/> <recordTarget> <patientRole> <id root="MDHT" extension="2087126679"/> <patient> <administrativeGenderCode codeSystem="2.16.840.1.113883.5.1" codeSystemName="AdministrativeGenderCode"/> <maritalStatusCode codeSystem="2.16.840.1.113883.5.2" codeSystemName="MaritalStatus"/> <religiousAffiliationCode codeSystem="2.16.840.1.113883.5.1076" codeSystemName="ReligiousAffiliation"/> <raceCode codeSystem="2.16.840.1.113883.6.238" codeSystemName="Race and Ethnicity - CDC"/> <sdtc:raceCode codeSystem="2.16.840.1.113883.6.238" codeSystemName="Race and Ethnicity - CDC"/> <ethnicGroupCode codeSystem="2.16.840.1.113883.6.238" codeSystemName="Race and Ethnicity - CDC"/> </patient> <providerOrganization/> </patientRole> </recordTarget> <author> <typeId root="2.16.840.1.113883.1.3"/> <time/> <assignedAuthor/> </author> <custodian> <assignedCustodian> <representedCustodianOrganization/> </assignedCustodian> </custodian> <informationRecipient> <intendedRecipient> <informationRecipient/> <receivedOrganization/> </intendedRecipient> </informationRecipient> <legalAuthenticator> <time/> <signatureCode code="S"/> <assignedEntity> <id root="MDHT" extension="1777407460"/> <code codeSystem="2.16.840.1.113883.6.101" codeSystemName="NUCC Health Care Provider Taxonomy"/> <assignedPerson/> </assignedEntity> </legalAuthenticator> <authenticator> <time/> <signatureCode code="S"/> <assignedEntity> <id root="MDHT" extension="920614258"/>




Page 47March 2013


<code codeSystem="2.16.840.1.113883.6.101" codeSystemName="NUCC Health Care Provider Taxonomy"/> <assignedPerson/> </assignedEntity> </authenticator> <relatedDocument/> <component/></ClinicalDocument>

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | SECTION TEMPLATES | 48



Page 48March 2013


Chapter

3SECTION TEMPLATES

Topics:

• Privacy Consent Details Section• Signatures Section

This section of the Implementation Guide describes the section templatescomprising a CDA document.




Page 49March 2013


Privacy Consent Details Section[Section: templateId 2.16.840.1.113883.3.445.17]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.17"2. SHOULD contain zero or one [0..1] code (CONF:9147)/@code="57016-8" (CodeSystem:

2.16.840.1.113883.6.1 LOINC) (CONF:9146)3. SHALL contain zero or one [0..1] text (CONF:9082)

• This text represents the human-readable representation of the directive/preferences expressed by in the section.4. SHALL contain zero or one [0..1] title and MAY equal "Privacy Consent Directive Details" (CONF:9083)5. MAY contain zero or more [0..*] entry (CONF:9148)

• The entries specified define specific privacy consent directive or preferences.

a. Contains exactly one [1..1] Consent Directive Entry (templateId: 2.16.840.1.113883.3.445.4)

1. SHOULD contain zero or one [0..1] code (CONF:9147)/@code="57016-8" (CodeSystem:2.16.840.1.113883.6.1 LOINC) (CONF:9146)

2. SHALL contain zero or one [0..1] title and MAY equal "Privacy Consent Directive Details" (CONF:9083)3. SHALL contain zero or one [0..1] text (CONF:9082)

• This text represents the human-readable representation of the directive/preferences expressed by in the section.4. MAY contain zero or more [0..*] entry (CONF:9148)

a. Contains exactly one [1..1] Consent Directive Entry (templateId: 2.16.840.1.113883.3.445.4)

• The entries specified define specific privacy consent directive or preferences.

Privacy Consent Details Section example

<section xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.17"/> <id root="MDHT" extension="1214431268"/> <code code="57016-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <title>Privacy Consent Directive Details</title> <text/> <entry> <act> <code code="827716827"/> <statusCode code="completed"/> <informant/> <participant/> <entryRelationship/> <precondition/> </act> <observation> <code code="99018724"/> <value xsi:type="ED">Text Value</value> </observation> <observationMedia> <value>Text Value</value> </observationMedia> </entry></section>




Page 50March 2013


Signatures Section[Section: templateId 2.16.840.1.113883.3.445.18]

An optional section in a Privacy Consent Directive is intended to hold the signatures (as scanned images of wetsignatures or an XML-Digital signature) . While electronic signatures cannot be captured in a CDA R2 document,CDA R2 supports external digital and scanned wet signatures that can be included using RIM-based extensions. AnXML digital signatures wrapper may be used to wrap the CDA document according to local policy. This section maybe used to authenticate the origin and attest to the integrity of the Privacy Consent.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.18"2. SHALL contain zero or one [0..1] text (CONF:9149)3. SHOULD contain zero or one [0..1] title and MAY equal "Signatures" (CONF:9150)4. MAY contain zero or more [0..*] entry (CONF:9152)

a. Contains exactly one [1..1] Signature Image Entry (templateId: 2.16.840.1.113883.3.445.20)

1. SHOULD contain zero or one [0..1] title and MAY equal "Signatures" (CONF:9150)2. SHALL contain zero or one [0..1] text (CONF:9149)3. MAY contain zero or more [0..*] entry (CONF:9152)

a. Contains exactly one [1..1] Signature Image Entry (templateId: 2.16.840.1.113883.3.445.20)

Signatures Section example

<section xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.18"/> <id root="MDHT" extension="1358919566"/> <title>Signatures</title> <text/> <entry> <observationMedia> <value>Text Value</value> </observationMedia> </entry></section>




Page 51March 2013


CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | CLINICAL STATEMENT TEMPLATES | 52



Page 52March 2013


Chapter

4CLINICAL STATEMENT TEMPLATES

Topics:

• Computable Policy• Confidentiality Act• Consent Action• Consent Directive Definition• Information Definition• Obligation Policy Observation• Refrain Policy Observation• Related Problem• Scanned Privacy Consent• Security Observation• Signature Image Observation

This section of the Implementation Guide details the clinical statement entriesreferenced in the document section templates. The clinical statement entrytemplates are arranged alphabetically.




Page 53March 2013


Computable Policy[Observation: templateId 2.16.840.1.113883.3.445.16]

This template is used to represent an alternative representation of the Privacy Consent Directive (e.g.,ODRL, XrML,XACML).


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.16"2. SHOULD contain exactly one [1..1] code (CONF:9139)/@code="57016-8" Privacy Policy

Acknowledgement Document (CodeSystem: 2.16.840.1.113883.6.1 LOINC) (CONF:9138)

• It specifies the LOINC code corresponding to "Privacy Policy Acknowledgement Document", it is fixed at thisvalue.

3. SHOULD contain zero or more [0..*] value with data type ED (CONF:9140)

• The value contains the computable representation of the policy.

1. Contains exactly one [1..1] @classCode with data type ActClassObservation2. Contains exactly one [1..1] @moodCode with data type x_ActMoodDocumentObservation3. SHOULD contain exactly one [1..1] code (CONF:9139)/@code="57016-8" Privacy Policy


• It specifies the LOINC code corresponding to "Privacy Policy Acknowledgement Document", it is fixed at thisvalue.

4. SHOULD contain zero or more [0..*] value with data type ED (CONF:9140)

• The value contains the computable representation of the policy.

Computable Policy example

<observation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.16"/> <id root="MDHT" extension="414473886"/> <code code="57016-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Privacy Policy Acknowledgement Document"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <value xsi:type="ED">Text Value</value></observation>

Confidentiality Act[Act: templateId 2.16.840.1.113883.3.445.12]

This template is used to specify the confidentiality of the protected information (IIHI) specified in Privacy ConsentDirective.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.12"2. MAY contain exactly one [1..1] code (CONF:9133), where the @code SHALL be selected from ValueSet

x_BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 STATIC (CONF:9132)




Page 54March 2013


• The confidentiality code is specifed and vased on the BasicConfidentialtiy value set.

1. Contains exactly one [1..1] @classCode with data type x_ActClassDocumentEntryAct2. Contains exactly one [1..1] @moodCode with data type x_DocumentActMood3. MAY contain exactly one [1..1] code (CONF:9133), where the @code SHALL be selected from ValueSet

x_BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 STATIC (CONF:9132)

• The confidentiality code is specifed and vased on the BasicConfidentialtiy value set.

Confidentiality Act example

<act xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.12"/> <id root="MDHT" extension="1390397509"/> <code codeSystem="2.16.840.1.113883.5.25" codeSystemName="ConfidentialityCode"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime></act>

Consent Action[Act: templateId 2.16.840.1.113883.3.445.8]

Template used to represent the action allowed and problem associated with the information allowed by the PrivacyConsent Directive.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.8"2. MAY contain zero or one [0..1] @negationInd (CONF:9120)

• The negation indicator is used to specify whether the action referenced by the code is precluded by the consentdirective.

3. SHALL contain exactly one [1..1] code (CONF:9119), where the @code SHALL be selected from(CodeSystem: 2.16.840.1.113883.1.11.19897 ActConsentType) (CONF:9118)

• The code specifies the action authorized or precluded by the consent directive (e.g. IDSCL is the code forInformation Disclosure).

4. SHOULD contain zero or more [0..*] entryRelationship (CONF:9066)

• This entry relationship is used to represent the entire set of protected information (IIHI) including specificattributes of that information (e.g., category type, related diagnosis, sensitivity/confidentiality).

a. Contains exactly one [1..1] Information Definition Set Reference (templateId:2.16.840.1.113883.3.445.9)

1. Contains exactly one [1..1] @classCode with data type x_ActClassDocumentEntryAct2. Contains exactly one [1..1] @moodCode with data type x_DocumentActMood3. MAY contain zero or one [0..1] @negationInd (CONF:9120)

• The negation indicator is used to specify whether the action referenced by the code is precluded by the consentdirective.

4. SHALL contain exactly one [1..1] code (CONF:9119), where the @code SHALL be selected from(CodeSystem: 2.16.840.1.113883.1.11.19897 ActConsentType) (CONF:9118)




Page 55March 2013


• The code specifies the action authorized or precluded by the consent directive (e.g. IDSCL is the code forInformation Disclosure).

5. SHOULD contain zero or more [0..*] entryRelationship (CONF:9066)

a. Contains exactly one [1..1] Information Definition Set Reference (templateId:2.16.840.1.113883.3.445.9)

• This entry relationship is used to represent the entire set of protected information (IIHI) including specificattributes of that information (e.g., category type, related diagnosis, sensitivity/confidentiality).

Consent Action example

<act xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.8"/> <id root="MDHT" extension="1761830886"/> <code codeSystem="2.16.840.1.113883.1.11.19897" codeSystemName="ActConsentType"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <entryRelationship> <observation> <code code="148553103"/> <entryRelationship/> </observation> <observationMedia/> </entryRelationship></act>

Consent Directive Definition

Consent Directive Definition example

Information Definition[Observation: templateId 2.16.840.1.113883.3.445.10]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.10"2. SHALL contain exactly one [1..1] @moodCode/@code="DEF" Definition (CodeSystem:

2.16.840.1.113883.5.1001 HL7ActMood) (CONF:9068)3. SHOULD contain exactly one [1..1] code (CONF:9125), where the @code SHALL be selected from

(CodeSystem: 2.16.840.1.113883.6.1 LOINC) (CONF:9124)

• This code is used to specify the code corresponding to the information type (IIHI) included in the authorizationcontained in the Privacy Consent Directive document

4. Contains zero or one [0..1] effectiveTime5. Contains zero or more [0..*] entryRelationship

• This association specifies additional criteria besides the "code" to specify the data intended to be covered bythe privacy consent directive document.

a. Contains exactly one [1..1] Information Criteria References (templateId:2.16.840.1.113883.3.445.25)




Page 56March 2013


1. Contains exactly one [1..1] @classCode with data type ActClassObservation2. SHALL contain exactly one [1..1] @moodCode/@code="DEF" Definition (CodeSystem:

2.16.840.1.113883.5.1001 HL7ActMood) (CONF:9068)3. SHOULD contain exactly one [1..1] code (CONF:9125), where the @code SHALL be selected from

(CodeSystem: 2.16.840.1.113883.6.1 LOINC) (CONF:9124)

• This code is used to specify the code corresponding to the information type (IIHI) included in the authorizationcontained in the Privacy Consent Directive document

4. Contains zero or one [0..1] effectiveTime5. Contains zero or more [0..*] entryRelationship

a. Contains exactly one [1..1] Information Criteria References (templateId:2.16.840.1.113883.3.445.25)

• This association specifies additional criteria besides the "code" to specify the data intended to be covered bythe privacy consent directive document.

Information Definition example

<observation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" moodCode="DEF"> <templateId root="2.16.840.1.113883.3.445.10"/> <id root="MDHT" extension="1929839294"/> <code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <entryRelationship> <act> <code code="403382285"/> </act> <observation> <id root="MDHT" extension="118468109"/> <code code="497943039"/> <text>Text Value</text> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <value xsi:type="CD" code="1154927635"/> </observation> </entryRelationship></observation>

Obligation Policy Observation[Observation: templateId 2.16.840.1.113883.3.445.14]

This template is used to specify an security observation associated with an information type specified in the privacyconsent document or information instance that appears in a CDA document. This template specifies the obligationpolicy, specifically.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.14"2. SHALL conform to Security Observation template (templateId: 2.16.840.1.113883.3.445.21)3. SHALL contain zero or more [0..*] value (CONF:9136), where the @code SHOULD be selected from

ValueSet ObligationPolicy 2.16.840.1.113883.1.11.20445 STATIC (CONF:9137)




Page 57March 2013


• This attribute specifies a type of obligation policy, specifically.

1. SHALL conform to Security Observation template (templateId: 2.16.840.1.113883.3.445.21)2. Contains exactly one [1..1] @classCode with data type ActClassObservation3. Contains exactly one [1..1] @moodCode with data type x_ActMoodDocumentObservation4. SHALL contain exactly one [1..1] code, where the @code SHALL be selected from (CodeSystem:

2.16.840.1.113883.3.445.200 SecurityObservationType) (CONF:9073)

• The code identifies the observation as a security observation.5. Contains zero or one [0..1] statusCode6. SHALL contain zero or more [0..*] value (CONF:9136), where the @code SHOULD be selected from

ValueSet ObligationPolicy 2.16.840.1.113883.1.11.20445 STATIC (CONF:9137)

• This attribute specifies a type of obligation policy, specifically.7. Contains zero or more [0..*] author

a. Contains exactly one [1..1] CDA Author8. Contains zero or more [0..*] informant

a. Contains exactly one [1..1] CDA Informant129. Contains zero or more [0..*] precondition

a. Contains exactly one [1..1] Policy Precondition (templateId: 2.16.840.1.113883.3.445.23)

Obligation Policy Observation example

<observation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.14"/> <templateId root="2.16.840.1.113883.3.445.21"/> <id root="MDHT" extension="634142624"/> <code codeSystem="2.16.840.1.113883.3.445.200" codeSystemName="SecurityObservationType"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <value xsi:type="CE" code="2005817979"/></observation>

Refrain Policy Observation[Observation: templateId 2.16.840.1.113883.3.445.22]

This template is used to specify an security observation associated with an information type specified in the privacyconsent document or information instance that appears in a CDA document. This template specifies the refrain policy,specifically.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.22"2. SHALL conform to Security Observation template (templateId: 2.16.840.1.113883.3.445.21)3. SHALL contain zero or more [0..*] value (CONF:9134), where the @code SHOULD be selected from

ValueSet RefrainPolicy 2.16.840.1.113883.1.11.20446 STATIC (CONF:9135)

• This attribute specifies a type of refrain policy, specifically.

1. SHALL conform to Security Observation template (templateId: 2.16.840.1.113883.3.445.21)2. Contains exactly one [1..1] @classCode with data type ActClassObservation




Page 58March 2013


3. Contains exactly one [1..1] @moodCode with data type x_ActMoodDocumentObservation4. SHALL contain exactly one [1..1] code, where the @code SHALL be selected from (CodeSystem:


• The code identifies the observation as a security observation.5. Contains zero or one [0..1] statusCode6. SHALL contain zero or more [0..*] value (CONF:9134), where the @code SHOULD be selected from

ValueSet RefrainPolicy 2.16.840.1.113883.1.11.20446 STATIC (CONF:9135)

• This attribute specifies a type of refrain policy, specifically.7. Contains zero or more [0..*] author




Refrain Policy Observation example

<observation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.22"/> <templateId root="2.16.840.1.113883.3.445.21"/> <id root="MDHT" extension="562003956"/> <code codeSystem="2.16.840.1.113883.3.445.200" codeSystemName="SecurityObservationType"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <value xsi:type="CE" code="677744182"/></observation>

Related Problem[Observation: templateId 2.16.840.1.113883.3.445.11]

This template specifies the problem that is related to the information. This allows EHRs to specify the diagnosis orproblem associated with the information intended for disclosure.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.11"2. SHALL conform to Consol Problem Observation template (templateId:

2.16.840.1.113883.10.20.22.4.4)3. SHALL contain exactly one [1..1] code (CONF:9129), where the @code SHOULD be selected from ValueSet

Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18 (CONF:9128)4. SHALL contain exactly one [1..1] value (CONF:9131), where the @code SHOULD be selected from ValueSet

Problem 2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC (CONF:9130)

1. SHALL conform to Consol Problem Observation template (templateId:2.16.840.1.113883.10.20.22.4.4)

2. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem:2.16.840.1.113883.5.6 HL7ActClass) (CONF:9041)

http://www.cdatools.org/infocenter/topic/org.openhealthtools.mdht.uml.cda.consol.doc/classes/ProblemObservation.html

http://www.cdatools.org/infocenter/topic/org.openhealthtools.mdht.uml.cda.consol.doc/classes/ProblemObservation.html




Page 59March 2013


3. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem:2.16.840.1.113883.5.1001 HL7ActMood) (CONF:9042)

4. MAY contain zero or one [0..1] @negationInd (CONF:10139)

• Use negationInd="true" to indicate that the problem was not observed (CONF:16880)5. SHALL contain at least one [1..*] id (CONF:9043)6. SHALL contain exactly one [1..1] code (CONF:9129), where the @code SHOULD be selected from ValueSet

Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18 (CONF:9128)7. SHOULD contain zero or one [0..1] text (CONF:9185)8. SHALL contain exactly one [1..1] statusCode/@code="completed" Completed (CodeSystem:

2.16.840.1.113883.5.14 ActStatus) (CONF:9049)9. SHOULD contain zero or one [0..1] effectiveTime (CONF:9050)10. SHALL contain exactly one [1..1] value (CONF:9131), where the @code SHOULD be selected from ValueSet

Problem 2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC (CONF:9130)11. MAY contain zero or one [0..1] entryRelationship (CONF:9059, CONF:9060, CONF:15590)

a. Contains @typeCode="SUBJ" SUBJb. Contains exactly one [1..1] Age Observation (templateId: 2.16.840.1.113883.10.20.22.4.31)

12. MAY contain zero or one [0..1] entryRelationship (CONF:9063, CONF:9068, CONF:15591)

a. Contains @typeCode="REFR" REFRb. Contains exactly one [1..1] Problem Status (templateId: 2.16.840.1.113883.10.20.22.4.6)

13. MAY contain zero or one [0..1] entryRelationship (CONF:9067, CONF:9064, CONF:15592)

a. Contains @typeCode="REFR" REFRb. Contains exactly one [1..1] Health Status Observation (templateId:

2.16.840.1.113883.10.20.22.4.5)14. The text, if present, SHOULD contain zero or one [0..1] reference (CONF:15587)15. reference, if present, SHALL contain exactly one [1..1] @value (CONF:15588)16. reference/@value SHALL begin with a '' and SHALL point to its corresponding narrative (using the approach

defined in CDA Release 2, section 4.3.5.1) (CONF:15589)17. The effectiveTime element , if present, SHALL contain exactly one [1..1] low (CONF:15603)18. effectiveTime, if present, SHOULD contain zero or one [0..1] high (CONF:15604)19. If the problem is known to be resolved, but the date of resolution is not known then the high element SHALL be

present, and the nullFlavor attribute SHALL be set to 'UNK'. Therefore, the existence of an high element within aproblem does indicate that the problem has been resolved (CONF:16881)

20. value MAY contain zero or one [0..1] @nullFlavor (CONF:10141)21. If the diagnosis is unknown or the SNOMED code is unknown, @nullFlavor SHOULD be UNK. If the code is

something other than SNOMED, @nullFlavor SHOULD be OTH and the other code SHOULD be placed in thetranslation element (CONF:10142)

22. entryRelationship with target entry Age Observation SHALL contain exactly one [1..1] @inversionInd="true"True (CONF:9069)

23. value MAY contain zero or more [0..*] translation (CONF:16749)24. translation, if present, MAY contain zero or one [0..1] @code (CodeSystem: ICD10 2.16.840.1.113883.6.3)

(CONF:16750)

Related Problem example

<observation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.11"/> <id root="MDHT" extension="651487149"/> <code codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMEDCT"/> <text>Text Value</text> <effectiveTime> <low value="2013"/>




Page 60March 2013


<high value="2013"/> </effectiveTime> <value xsi:type="CD" code="862358174"/></observation>

Scanned Privacy Consent[ObservationMedia: templateId 2.16.840.1.113883.3.445.15]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.15"2. SHALL contain exactly one [1..1] value (CONF:9142)

1. Contains exactly one [1..1] @classCode with data type ActClassObservation2. Contains exactly one [1..1] @moodCode with data type ActMood3. SHALL contain exactly one [1..1] value (CONF:9142)

Scanned Privacy Consent example

<observationmedia xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.15"/> <id root="MDHT" extension="1744128551"/> <value>Text Value</value></observationmedia>

Security Observation[Observation: templateId 2.16.840.1.113883.3.445.21]

Known Subclasses: Refrain Policy Observation, Obligation Policy Observation

This template is used to specify an security observation associated with an information type specified in the privacyconsent document or information instance that appears in a CDA document.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.21"2. SHALL contain exactly one [1..1] code, where the @code SHALL be selected from (CodeSystem:


• The code identifies the observation as a security observation.3. SHALL contain zero or more [0..*] value with data type CE (CONF:9074)

• The value specifies the security tag using a policy code.4. Contains zero or one [0..1] statusCode5. Contains zero or more [0..*] author




1. Contains exactly one [1..1] @classCode with data type ActClassObservation2. Contains exactly one [1..1] @moodCode with data type x_ActMoodDocumentObservation




Page 61March 2013


3. SHALL contain exactly one [1..1] code, where the @code SHALL be selected from (CodeSystem:2.16.840.1.113883.3.445.200 SecurityObservationType) (CONF:9073)

• The code identifies the observation as a security observation.4. Contains zero or one [0..1] statusCode5. SHALL contain zero or more [0..*] value with data type CE (CONF:9074)

• The value specifies the security tag using a policy code.6. Contains zero or more [0..*] author




Security Observation example

<observation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.21"/> <id root="MDHT" extension="1445520407"/> <code codeSystem="2.16.840.1.113883.3.445.200" codeSystemName="SecurityObservationType"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <value xsi:type="CE" code="852870958"/> <author/> <informant/> <precondition> <criterion> <code code="1210309399"/> </criterion> </precondition></observation>

Signature Image Observation[ObservationMedia: templateId 2.16.840.1.113883.3.445.19]

This observationMedia template is intended to provide observationMedia for each signature (e.g.,legalAuthenticator,authenticator) or a scanned version of the entire privacy consent directive form including the signatures.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.19"2. SHALL contain exactly one [1..1] value (CONF:9153)

1. Contains exactly one [1..1] @classCode with data type ActClassObservation2. Contains exactly one [1..1] @moodCode with data type ActMood3. SHALL contain exactly one [1..1] value (CONF:9153)

Signature Image Observation example

<observationmedia xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.19"/>




Page 62March 2013


<id root="MDHT" extension="92130010"/> <value>Text Value</value></observationmedia>




Page 63March 2013


CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | OTHER CLASSES | 64



Page 64March 2013


Chapter

5OTHER CLASSES

Topics:

• Consent Action ObligationSecurity ObservationRelationship

• Consent Directive Entry• IIHI Receiving Provider• Information Criteria References• Information Definition Set

Reference• Policy Precondition• Policy Precondition Criterion• Privacy Consent Header Author• Privacy Consent Header

Documentation Of ServiceEvent

• Signature Image Entry

This section of the Implementation Guide describes other classes that are notCDA Clinical Documents, Sections, or Clinical Statements but a type of HL7V3 RIM association (e.g. participations, entry relationships, etc.).




Page 65March 2013


Consent Action Obligation Security Observation Relationship[EntryRelationship: templateId 2.16.840.1.113883.3.445.22]

This template supports specifying an action or an obligation/refrain policy.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.22"2. SHOULD contain zero or one [0..1] act (CONF:9117)

• The ConsentAction is specified based on the type of action authorized by the document. This represent theactivity or action at the center of the directive.

a. Contains exactly one [1..1] Consent Action (templateId: 2.16.840.1.113883.3.445.8)3. MAY contain zero or one [0..1] observation (CONF:9121)

• The SecurityObservation may be an ObligationPolicyObservation or a RefrainPolicyObservation.

a. Contains exactly one [1..1] Security Observation (templateId: 2.16.840.1.113883.3.445.21)

1. Contains exactly one [1..1] @typeCode with data type x_ActRelationshipEntryRelationship2. SHOULD contain zero or one [0..1] act (CONF:9117)

a. Contains exactly one [1..1] Consent Action (templateId: 2.16.840.1.113883.3.445.8)

• The ConsentAction is specified based on the type of action authorized by the document. This represent theactivity or action at the center of the directive.

3. MAY contain zero or one [0..1] observation (CONF:9121)

a. Contains exactly one [1..1] Security Observation (templateId: 2.16.840.1.113883.3.445.21)

• The SecurityObservation may be an ObligationPolicyObservation or a RefrainPolicyObservation.

Consent Action Obligation Security Observation Relationship example

<entryrelationship xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.22"/> <act> <code code="1304325856"/> <entryRelationship> <observation/> <observationMedia/> </entryRelationship> </act> <observation> <code code="1517026296"/> <value xsi:type="CE" code="1345509926"/> <author/> <informant/> <precondition> <criterion/> </precondition> </observation></entryrelationship>

Consent Directive Entry[Entry: templateId 2.16.840.1.113883.3.445.4]




Page 66March 2013


This template is used to specify a consent directive using a structure based on the CDA Entry. The implementershave three choices to represent their privacy consent directives: as structured entry using ConsentDirective, asComputablePolicy, or as Scanned Document


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.4"2. SHOULD contain zero or one [0..1] act (CONF:9101)

• This structured representation of a privacy consent directive/preference.

a. Contains exactly one [1..1] Consent Directive Definition (templateId: 2.16.840.1.113883.3.445.5)3. MAY contain zero or one [0..1] observation (CONF:9102)

• The computable policy representation of the privacy consent

a. Contains exactly one [1..1] Computable Policy (templateId: 2.16.840.1.113883.3.445.16)4. SHOULD contain zero or one [0..1] observationMedia (CONF:9103)

a. Contains exactly one [1..1] Scanned Privacy Consent (templateId: 2.16.840.1.113883.3.445.15)

1. SHOULD contain zero or one [0..1] act (CONF:9101)

a. Contains exactly one [1..1] Consent Directive Definition (templateId: 2.16.840.1.113883.3.445.5)

• This structured representation of a privacy consent directive/preference.2. MAY contain zero or one [0..1] observation (CONF:9102)

a. Contains exactly one [1..1] Computable Policy (templateId: 2.16.840.1.113883.3.445.16)

• The computable policy representation of the privacy consent3. SHOULD contain zero or one [0..1] observationMedia (CONF:9103)

a. Contains exactly one [1..1] Scanned Privacy Consent (templateId: 2.16.840.1.113883.3.445.15)

Consent Directive Entry example

<entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.4"/> <act> <code code="1752973201"/> <statusCode code="completed"/> <informant/> <participant> <participantRole/> </participant> <entryRelationship> <act/> <observation/> </entryRelationship> <precondition> <criterion/> </precondition> </act> <observation> <code code="1939497549"/> <value xsi:type="ED">Text Value</value> </observation> <observationMedia> <value>Text Value</value> </observationMedia></entry>




Page 67March 2013


IIHI Receiving Provider[Participant2: templateId 2.16.840.1.113883.3.445.7]

This template is used to represent the provider organization or person intended to use, access, collect information asallowed or prevented by the action specified in this privacy consent directive.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.7"2. SHALL contain exactly one [1..1] @typeCode (CONF:9114)/@code="IRCP" Information Recipient

(CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType) (CONF:9115)

• The participation is used to specify the information recipient.3. SHALL contain exactly one [1..1] participantRole (CONF:9116)

a. Contains exactly one [1..1] CDA Participant Role

1. SHALL contain exactly one [1..1] @typeCode (CONF:9114)/@code="IRCP" Information Recipient(CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType) (CONF:9115)

• The participation is used to specify the information recipient.2. Contains exactly one [1..1] participantRole, where its type is Participant Role

a. Contains exactly one [1..1] Participant Role3. SHALL contain exactly one [1..1] participantRole (CONF:9116)

a. Contains exactly one [1..1] CDA Participant Role

IIHI Receiving Provider example

<participant2 xmlns="urn:hl7-org:v3" typeCode="IRCP"> <templateId root="2.16.840.1.113883.3.445.7"/> <time> <low value="2013"/> <high value="2013"/> </time> <participantRole/></participant2>

Information Criteria References[EntryRelationship: templateId 2.16.840.1.113883.3.445.25]

This template supports the definition of additional information criteria to identify the information referenced by theprivacy consent.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.25"2. MAY contain zero or one [0..1] act (CONF:9126)

• This is a workaround the fact that the Observation CDA class does not support a confidentialityCode. Itspecifies a template (Confidentiality Act) intended to convey the confidentiality level of the informationintended.

a. Contains exactly one [1..1] Confidentiality Act (templateId: 2.16.840.1.113883.3.445.12)3. MAY contain zero or one [0..1] observation (CONF:9127)




Page 68March 2013


• This observation relates to the problem - a protected problem typically - referenced by the privacy consentdirective.

a. Contains exactly one [1..1] Related Problem (templateId: 2.16.840.1.113883.3.445.11)

1. Contains exactly one [1..1] @typeCode with data type x_ActRelationshipEntryRelationship2. MAY contain zero or one [0..1] act (CONF:9126)

a. Contains exactly one [1..1] Confidentiality Act (templateId: 2.16.840.1.113883.3.445.12)

• This is a workaround the fact that the Observation CDA class does not support a confidentialityCode. Itspecifies a template (Confidentiality Act) intended to convey the confidentiality level of the informationintended.

3. MAY contain zero or one [0..1] observation (CONF:9127)

a. Contains exactly one [1..1] Related Problem (templateId: 2.16.840.1.113883.3.445.11)

• This observation relates to the problem - a protected problem typically - referenced by the privacy consentdirective.

Information Criteria References example

<entryrelationship xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.25"/> <act> <code code="1547139889"/> </act> <observation> <id root="MDHT" extension="913584667"/> <code code="879902360"/> <text>Text Value</text> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime> <value xsi:type="CD" code="1979944427"/> </observation></entryrelationship>

Information Definition Set Reference[EntryRelationship: templateId 2.16.840.1.113883.3.445.9]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.9"2. SHOULD contain zero or one [0..1] observation (CONF:9122)

a. Contains exactly one [1..1] Information Definition (templateId: 2.16.840.1.113883.3.445.10)3. MAY contain zero or one [0..1] observationMedia (CONF:9123)

a. Contains exactly one [1..1] CDA Observation Media

1. Contains exactly one [1..1] @typeCode with data type x_ActRelationshipEntryRelationship2. SHOULD contain zero or one [0..1] observation (CONF:9122)

a. Contains exactly one [1..1] Information Definition (templateId: 2.16.840.1.113883.3.445.10)3. MAY contain zero or one [0..1] observationMedia (CONF:9123)

a. Contains exactly one [1..1] CDA Observation Media




Page 69March 2013


Information Definition Set Reference example

<entryrelationship xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.9"/> <observation> <code code="1986015270"/> <entryRelationship> <act/> <observation/> </entryRelationship> </observation> <observationMedia/></entryrelationship>

Policy Precondition[Precondition: templateId 2.16.840.1.113883.3.445.23]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.23"2. SHALL contain exactly one [1..1] criterion (CONF:9143)

a. Contains exactly one [1..1] Policy Precondition Criterion (templateId: 2.16.840.1.113883.3.445.24)

1. SHALL contain exactly one [1..1] criterion (CONF:9143)

a. Contains exactly one [1..1] Policy Precondition Criterion (templateId: 2.16.840.1.113883.3.445.24)

Policy Precondition example

<precondition xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.23"/> <criterion> <code code="1551132015"/> </criterion></precondition>

Policy Precondition Criterion[Criterion: templateId 2.16.840.1.113883.3.445.24]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.24"2. SHALL contain zero or one [0..1] code (CONF:9145), where the @code SHOULD be selected from ValueSet

ActPolicyType 2.16.840.1.113883.1.11.19886 STATIC (CONF:9144)

1. SHALL contain zero or one [0..1] code (CONF:9145), where the @code SHOULD be selected from ValueSetActPolicyType 2.16.840.1.113883.1.11.19886 STATIC (CONF:9144)

Policy Precondition Criterion example

<criterion xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.24"/> <code code="1765741806"/>




Page 70March 2013


</criterion>

Privacy Consent Header Author[Author: templateId 2.16.840.1.113883.3.445.2]


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.2"2. SHOULD contain zero or one [0..1] functionCode (CONF:9084), where the @code

SHALL be selected from (CodeSystem: 2.16.840.1.113883.1.11.19930ConsenterParticipationFunctionDecisionMaker) (CONF:9085)

1. SHOULD contain zero or one [0..1] functionCode (CONF:9084), where the @codeSHALL be selected from (CodeSystem: 2.16.840.1.113883.1.11.19930ConsenterParticipationFunctionDecisionMaker) (CONF:9085)

2. Contains exactly one [1..1] time with data type TS3. Contains exactly one [1..1] assignedAuthor, where its type is Assigned Author

a. Contains exactly one [1..1] Assigned Author

Privacy Consent Header Author example

<author xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.2"/> <functionCode codeSystem="2.16.840.1.113883.1.11.19930" codeSystemName="ConsenterParticipationFunctionDecisionMaker"/> <time/> <assignedAuthor/></author>

Privacy Consent Header Documentation Of Service Event[ServiceEvent: templateId 2.16.840.1.113883.3.445.3]

Each Privacy Consent Directive may have an explicit duration by specifying the related service associated withissuing a privacy consent directive. The effective duration of a Privacy Consent Directive establishes the valid periodfor the privacy consent or authorization as directed by the client or Substitute Decision Maker. This constraint appliesspecifically for those jurisdictions where Privacy Consent Directives are issued for a pre-defined length of time.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.3"2. SHOULD contain exactly one [1..1] code (CONF:9097)/@code="57016-8" Privacy Policy


• These constraints are intended to be fully backwards-compatible to IHE BPPC.3. MAY contain zero or one [0..1] effectiveTime (CONF-CD-7)

• ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value element SHOULD be present. ItMAY be different than the value of the ClinicalDocument/effectiveTime/@value and represents the first time thePrivacy Consent Directive takes effect.ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value element MAY be present tospecify the date/time when the Privacy Consent Directive expires.

4. MAY contain zero or more [0..*] id (CONF:9059)

1. MAY contain zero or more [0..*] id (CONF:9059)




Page 71March 2013


2. SHOULD contain exactly one [1..1] code (CONF:9097)/@code="57016-8" Privacy PolicyAcknowledgement Document (CodeSystem: 2.16.840.1.113883.6.1 LOINC) (CONF:9096)

• These constraints are intended to be fully backwards-compatible to IHE BPPC.3. MAY contain zero or one [0..1] effectiveTime (CONF-CD-7)

• ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value element SHOULD be present. ItMAY be different than the value of the ClinicalDocument/effectiveTime/@value and represents the first time thePrivacy Consent Directive takes effect.ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value element MAY be present tospecify the date/time when the Privacy Consent Directive expires.

Privacy Consent Header Documentation Of Service Event example

<serviceevent xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.3"/> <id root="MDHT" extension="1025678090"/> <code code="57016-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Privacy Policy Acknowledgement Document"/> <effectiveTime> <low value="2013"/> <high value="2013"/> </effectiveTime></serviceevent>

Signature Image Entry[Entry: templateId 2.16.840.1.113883.3.445.20]

This entry template is intended to provide observationMedia for each signature (e.g.,legalAuthenticator,authenticator) or a scanned version of the entire privacy consent directive form including the signatures.


a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.20"2. Contains zero or one [0..1] observationMedia

a. Contains exactly one [1..1] Signature Image Observation (templateId: 2.16.840.1.113883.3.445.19)

1. Contains zero or one [0..1] observationMedia

a. Contains exactly one [1..1] Signature Image Observation (templateId: 2.16.840.1.113883.3.445.19)

Signature Image Entry example

<entry xmlns="urn:hl7-org:v3"> <templateId root="2.16.840.1.113883.3.445.20"/> <observationMedia> <value>Text Value</value> </observationMedia></entry>

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | VALUE SETS | 72



Page 72March 2013


Chapter

6VALUE SETS

Topics:

• Act Consent Type• Act Policy Type• Obligation Policy• Purpose Of Use• Refrain Policy• Security Observation Type• x Basic Confidentiality Kind

The following tables summarize the value sets used in this ImplementationGuide.




Page 73March 2013


Act Consent Type

Value Set ActConsentType

Description This coding system is used to specify the action referred by a consent directive.

Code Code System Print Name

ICOL Information Collection

IDISCL Informatoin Disclosure

INFASO Access and save only

IRDSCL Information redisclosure

RESEARCH Research

RSDID De-identified information access

RSREID De-identified information access

INFAO Access Only.

Act Policy Type

Value Set ActPolicyType - 2.16.840.1.113883.1.11.19886

Description This value set identifies a privacy policy as a coded value.

Obligation Policy

Value Set ObligationPolicy - 2.16.840.1.113883.1.11.20445

Description Conveys the mandated workflow action that an information custodian, receiver, or user mustperform . Description: Per ISO 22600-2, ObligationPolicy instances 'are event-triggeredand define actions to be performed by manager agent'. Per HL7 Composite Security andPrivacy Domain Analysis Model: This value set refers to the action required to receive thepermission specified in the privacy rule. [Nov Harm - Per OASIS XACML, an obligationis an operation specified in a policy or policy that is performed in conjunction with theenforcement of an access control decision.]


CPLYCD Comply with consent directive

ENCRYPT Encrypt informaiton

Purpose Of Use

Value Set PurposeOfUse - 2.16.840.1.113883.1.11.20448

Definition Reason for performing one or more operations on information, which may be permitted bysource system's security policy in accordance with one or more privacy policies and consentdirectives.




Page 74March 2013


Description The rationale or purpose for an act relating to the management of personal healthinformation, such as collecting personal health information for research or public healthpurposes.


TREAT Treatment

ETREAT Emergency Treatment

HPAYMT Healthcare payment

Refrain Policy

Value Set RefrainPolicy - 2.16.840.1.113883.1.11.20446

Description Conveys prohibited actions which an information custodian, receiver, or user isnot permitted to perform unless otherwise authorized or permitted under specifiedcircumstances. Description: ISO 22600-2 species that a Refrain Policy "defines actionsthe subjects must refrain from performing". Per HL7 Composite Security and PrivacyDomain Analysis Model: May be used to indicate that a specific action is prohibited basedon specific access control attributes e.g., purpose of use, information type, user role, etc.


NORDSCLCD Prohibit redisclosure without consent directive

NOMOU Prohibit disclosure without MOU

Security Observation Type

Value Set SecurityObservationType

Description This a proposed coding system to specify a security tag associated with data referenced inthe privacy consent or in a CDA document instance.

x Basic Confidentiality Kind

Value Set x_BasicConfidentialityKind - 2.16.840.1.113883.1.11.16926

Code System ConfidentialityCode - 2.16.840.1.113883.5.25

Description Confidentiality code.


V ConfidentialityCode Very Restricted

R ConfidentialityCode Restricted

N ConfidentialityCode Normal




Page 75March 2013


CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | REFERENCES | 76



Page 76March 2013


REFERENCES

1. HL7 Version 3 Domain Analysis Model: Security, Release 1- contains the Harmonized Security and PrivacyDomain Analysis Model that specifies the contents of a Privacy Consent Directive document. The full DomainAnalysis Model publication is available for review and comment on the HL7 DSTU page.

2. ONC S&I Data Segmentation for Privacy Initiative (DS4P) has leveraged the DSTU version of this specification.A Privacy Consent Directive document is required in the Data Segmentation for Privacy Use Cases referenced inthe Implementation Guide developed for the DS4P Initiative.

3. HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD) A CDA implementation ofASTM E2369-05 Standard Specification for Continuity of Care Record© (CCR) April 01, 2007 available throughHL7 .

4. HL7 Implementation Guide for CDA Release 2 Quality Reporting Document Architecture (QRDA) DraftStandard for Trial Use March 2009. Available at: Quality Reporting Document Architecture (QRDA)

5. HL7 Implementation Guide for CDA Release 2 CDA for Public Health Case Reports (PHCR) InformativeStandard October 2009. Available through HL7 .

6. HL7 Implementation Guide for CDA Release 2: NHSN Healthcare Associated Infection (HAI) Reports, Release 2Draft Standard for Trial Use January 2009 Available at: NHSN Healthcare Associated Infection (HAI) Reports

7. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A, (Editors). HL7 Clinical DocumentArchitecture, Release 2.0. ANSI-approved HL7 Standard; May 2005. Ann Arbor, Mich.: Health Level Seven, Inc.Available through HL7 or if an HL7 member with the following link: CDA Release 2 Normative Web Edition.

8. LOINC® : Logical Observation Identifiers Names and Codes, Regenstrief Institute.9. SNOMED CT® : SNOMED Clinical Terms SNOMED International Organization.10. Extensible Markup Language, www.w3.org/XML .11. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A., HL7 Clinical Document Architecture,

Release 2. J Am Med Inform Assoc. 2006;13:30-39. Available at: http://www.jamia.org/cgi/reprint/13/1/30 .12. Using SNOMED CT in HL7 Version 3; Implementation Guide, Release 1.5. Available through HL7 or if an HL7

member with the following link: Using SNOMED CT in HL7 Version 3


http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+Cases

http://www.hl7.org

http://www.hl7.org/documentcenter/ballots/2008sep/downloads/CDAR2_QRDA_R1_DSTU_2009APR.zip

http://www.hl7.org

http://www.hl7.org/documentcenter/ballots/2009JAN/downloads/CDAR2L3_IG_HAIRPT_R2_DSTU_2009MAR.zip

http://www.hl7.org

http://www.hl7.org/documentcenter/private/standards/cda/r2/cda_r2_normativewebedition.zip

http://www.regenstrief.org/loinc

http://www.ihtsdo.org/

http://www.w3.org/XML

http://www.jamia.org/cgi/reprint/13/1/30

http://www.hl7.org

http://www.hl7.org/v3ballot/html/infrastructure/terminfo/terminfo.htm

CDAR2_IG_CONSENTDIR_R1 _ N1 _ 2013MAY | REFERENCES | 77



Page 77March 2013
