CDAR2_OPNOTE_R1_D1_2008MAY
Implementation Guide for CDA Release 2.0
Levels 1, 2 (and 3)
Operative Note (US Realm)Based on HL7 CDA
Release 2.0
Draft Standard for Trial Use
First Ballot
May 2008
© 2008 Health Level Seven, Inc.
Ann Arbor, MI
All rights reserved.
Co-Chair/Co-Editor:
Liora Alschuler
Alschuler Associates, LLC
liora@alschulerassociates.com
Co-Chair/Co-Editor:
Calvin Beebe
Mayo Clinic
cbeebe@mayo.edu
Co-Chair/Co-Editor:
Keith W. Boone
GE Healthcare
keith.boone@ge.com
Co-Chair/Co-Editor:
Robert H. Dolin, MD
Kaiser Permanente
robert.h.dolin@kp.org
Co-Editor:
Laura Bryan
AHDI
Laura@MTWerks.com
Co-Editor:
Rick Geimer
Alschuler Associates, LLC
rick@alschulerassociates.com
Co-Editor:
Gay Giannone
Alschuler Associates, LLC
gay@alschulerassociates.com
Kate Hamilton
Alschuler Associates, LLC
kate@alschulerassociates.com
Crystal Kallem
AHIMA
crystal.kallem@ahima.org
Current Working Group also
includes:
[Name, Name, Name, Name, Name]
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 2
MAY 2008
Acknowledgments
This Draft Standard for Trial Use (DSTU) was produced and developed through the
efforts of a project called CDA for Common Document Types (CDA4CDT) founded by
M*Modal, the American Health Information Management Association (AHIMA), and the
Association for Healthcare Documentation Integrity (AHDI), formerly the American
Association for Medical Transcription (AAMT), now affiliated with the Medical
Transcription Industry Association (MTIA).
These founders have been joined by industry benefactors Spheris, MedQuist, InterFix,
Precyse Solutions, wedmedx, MdinTouch, 3M, ImageTek, ALife, Misys and QuadraMed.
Without their support and participation, this DSTU would not have been possible.
In addition, this project has benefited from the participation of Kaiser Permanente,
Mayo Clinic, Military Health System, University of Pittsburgh Medical Center, and GE
Healthcare. Project management was provided by Alschuler Associates, LLC.
The co-editors would also like to express their appreciation for the support and
sponsorship of the Structured Documents Technical Committee.
Finally, we would like to acknowledge the foundational work on Health Level Seven
(HL7) Version 3 and the Reference Information Model (RIM), the HL7 domain
committees, especially Patient Care, and the work done on CDA itself. We would also
like to acknowledge the development of the Care Record Summary, the first published
Implementation Guide for CDA, the development of a series of implementation profiles
based on CRS by Integrating the Healthcare Enterprise (IHE) and the collaborative effort
of ASTM and HL7, which produced the Continuity of Care Document (CCD). All these
efforts were critical ingredients to the development of this DSTU and the degree to
which it reflects these efforts will foster interoperability across the spectrum of
healthcare.
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 3
MAY 2008
Revision History (to be removed prior to putting up for ballot)
Rev
Date
By Whom
Changes
Note
1
2008_2_27
Gay Giannone
NEW
First Draft Begun
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 4
MAY 2008
Table of Contents
1
INTRODUCTION ............................................................................................................ 10
1.1
Purpose ................................................................................................................... 10
1.2
Audience ................................................................................................................. 10
1.3
Approach ................................................................................................................ 10
1.4
Organization of this Guide ....................................................................................... 11
1.5
Use of Templates ..................................................................................................... 11
1.5.1
Originator Responsibilities ................................................................................ 11
1.5.2
Recipient Responsibilities ................................................................................. 12
1.6
Conventions Used in This Guide .............................................................................. 12
1.6.1
Explanatory Statements ................................................................................... 12
1.6.2
Conformance Requirements .............................................................................. 13
1.6.3
Vocabulary Conformance .................................................................................. 13
1.6.4
XPath Notation ................................................................................................. 14
1.6.5
Keywords ......................................................................................................... 14
1.6.6
XML Samples ................................................................................................... 14
1.6.7
Content of the Ballot Package ........................................................................... 14
1.7
Scope ...................................................................................................................... 15
1.7.1
Levels of Constraint .......................................................................................... 15
1.7.2
Future Work ..................................................................................................... 15
2
CDA HEADER – GENERAL CONSTRAINTS .................................................................... 17
3
CONSTRAINTS ON HEADER ELEMENTS – OPERATIVE NOTE SPECIFIC
CONSTRAINTS .............................................................................................................. 19
3.1.1
ClinicalDocument ............................................................................................. 19
3.1.2
ClinicalDocument/templateID .......................................................................... 19
3.1.3
ClinicalDocument/code .................................................................................... 19
3.1.4
ServiceEvent .................................................................................................... 19
3.1.5
Performer ......................................................................................................... 20
3.2
4
Rendering Header Information for Human Presentation ............................................ 20
BODY ........................................................................................................................... 21
4.1
Section Descriptions ................................................................................................ 21
4.2
Required Sections .................................................................................................... 22
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 5
MAY 2008
4.2.1
Pre-Operative Diagnosis 10219-4 (question for cda4cdt; see display name several
ways – what do we want for this IG) ............................................................................... 22
4.2.2
Post-Operative Diagnosis 10218-6 .................................................................... 22
4.2.3
Details of Procedure 10223-6 ............................................................................ 22
4.2.4
Findings 10215-2 ............................................................................................. 23
4.2.5
Anesthesia 10213-7 .......................................................................................... 23
4.2.6
Estimated Blood Loss 8717-1 ........................................................................... 23
4.2.7
Specimens Removed 10221-0 ........................................................................... 23
4.3
Optional Sections .................................................................................................... 23
4.3.1
Indications 10217-8 ......................................................................................... 23
4.3.2
Complications 10830-8 ..................................................................................... 24
4.3.3
Plan 18776-5 Note: need to determine if The template identifier for the Assessment
and Plan section 2.16.840.1.113883.10.20.2.7 from the previous CDA4CDT and CCD is
appropriate or useful for this section. ............................................................................. 24
5
REFERENCES .............................................................................................................. 25
VALIDATION ........................................................................................................................ 26
Introduction ..................................................................................................................... 26
Vocabulary ....................................................................................................................... 26
Extending the Vocabulary Tables for Local Use ............................................................... 26
Administrative Contact Role Type ................................................................................... 26
Administrative Gender ................................................................................................... 26
Ethnicity ....................................................................................................................... 26
Marital Status ............................................................................................................... 26
Null Flavors ................................................................................................................... 26
Personal Relationship Role Type ..................................................................................... 26
Race
26
EXTERNAL CONSTRAINTS ................................................................................................... 27
Introduction ..................................................................................................................... 27
XXX Constraints ............................................................................................................... 27
Medications (Template ID 9.99.999.9 ….) ....................................................................... 27
Social History (Template ID 9.99.999.9 ….) ..................................................................... 27
YYY Constraints................................................................................................................ 27
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 6
MAY 2008
TERMPLATE IDS DEFINED IN THIS GUIDE ......................................................................... 28
LIST OF ADDITIONAL OPTIONAL SUBSECTIONS ................................................................. 29
SECTION CARDINALITY ....................................................................................................... 30
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 7
MAY 2008
Table of Figures
Figure 1. ClinicalDocument example .................................................................................... 14
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 8
MAY 2008
Table of Tables
Table 1: Contents of the Ballot Package ................................................................................ 14
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 9
MAY 2008
1 INTRODUCTION
1.1 Purpose
The purpose of this document is to describe constraints on the CDA Header and Body
elements for Operative Note documents.
The Operative Note or Report is created immediately following a surgical or other highrisk procedure and records the pre and postsurgical diagnosis, pertinent events of the
procedure, as well as the condition and disposition of the patient following the
procedure. The report should be detailed enough to support the diagnoses, justify the
treatment, document the course of the procedure, and provide continuity of care. 1
1.2 Audience
The audience for this document includes software developers and consultants
responsible for implementation of U.S. realm Electronic Health Record (EHR) systems,
Electronic Medical Record (EMR) systems, Personal Health Record (PHR) systems,
dictation/transcription systems, document management applications, and local,
regional, and national health information exchange networks who wish to create and/or
process CDA documents created according to this specification.
1.3 Approach
The approach taken in the development of this specification was to review existing draft
and final specifications or Implementation Guides for similar artifacts in the U.S.,
specifically:

ASTM’s Standard Specifications for Healthcare Document Formats (E2184.02)
(Headings and subheadings used in the health care industry and associated
with specific report types)

Clinical LOINC® document and section codes

HL7 ASIG CDA R2 Attachment for Clinical Notes

IHE profiles, including the content profiles within Patient Care Coordination

HL7 Implementation Guide for CDA Release 2:
History and Physical (H&P) Notes

HL7 Implementation Guide for CDA Release 2:
Consultation Notes
1
http://www.jointcommission.org/AccreditationPrograms/OfficeBasedSurgery/Standards/FAQs/Management+of+Info/Patient+Specific+Info/Operative_Reports.htm
http://www.jointcommission.org/NR/rdonlyres/A032623D-02AF-4955-AF7C-08F3D5802E64/0/06_obs_im.pdf
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 10
MAY 2008

Joint Commission Operative Note Requirements: Standard IM.6.30, Elements of
Performance for IM.6.30

Centers for Medicare & Medicaid Services (CMS) Operative Note Requirements:
Survey Protocol, Regulations and Interpretive Guidelines for Hospitals: A-0396
§482.51

Non-CDA sample documents supplied by participating providers and vendors
In addition, M*Modal provided statistical analysis of approximately 20,000 sample
reports and AHIMA, AHDI, and participating providers contributed extensive subject
matter expertise. The design was matched against operational templates from
transcription vendors and reviewed with the HL7 Structured Documents Technical
Committee. While current divergent industry practices cannot be perfectly reflected in
any consensus model, this design is optimized for widespread conformance and
adoption with minimal disruption to current practice and workflow.
1.4 Organization of this Guide
The requirements laid out in the body of this document are normative and are subject
to change only through the ballot process. These cover the header and high-level body
and section requirements.
The document is organized into the following major sections:
 list
Each major section or subsection of the document is organized to provide:
• A narrative overview – provides an overview and scope for the subsection.
• CDA R2 constraints –The base standard for this guide is the HL7 Clinical Document
Architecture, Release 2.0.
1.5 Use of Templates
Templates are collections of constraints that specify and validate agreed-to
requirements for exchange. Collecting individual constraints and assigning a unique
template identifier to the collection establishes a shorthand mechanism for the instance
creator to assert conformance to those constraints. The template identifier itself carries
no semantics. Validation errors against a template must not be construed as anything
other than failure to meet the exact requirements of the template, and absence of a
template identifier need not be construed as failure to meet the constraints required by
the template.
1.5.1 Originator Responsibilities
An originator shall apply a templateId in order to assert conformance with a particular
template (e.g., an originator must include the templateId to assert that an instance is a
CCD document).
An originator does not need to apply a templateId for every template that an object in an
instance document conforms to (e.g., an originator does not have to include the
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 11
MAY 2008
Medications section templateId in a CDA R2 operative report, even though the
medication representation may conform to the template).
1.5.2 Recipient Responsibilities
A recipient may reject an instance that does not contain a particular templateId (e.g., a
recipient looking to only receive CCDs can reject an instance without the CCD
templateId).
A recipient may process objects in an instance document that do not contain a
templateId (e.g., a recipient can process substanceAdministration acts within the
Medications section, even though the acts do not have templateIds).
A recipient shall not report a conformance error about a failure to conform to a
particular template on classes that do not claim conformance to that template and that
are not required to be conformant by other templates (e.g., substanceAdministration
acts within the CCD Medications section that do not have a templateId need not
conform to the CCD template for medication clinical statements. However, within a
CCD Payers section, the Act representing the patient coverage is only allowed, and is
further required, to have components that meet the requirements of the policy act
template. Therefore, a recipient may indicate that those acts present inside the
coverage act that do NOT meet the requirements of the policy act template are not
allowed).
1.6 Conventions Used in This Guide
This Implementation Guide is a conformance profile, as described in the Refinement
and Localization section of the HL7 Version 3 standards. The base standard for this
Implementation Guide is the HL7 Clinical Document Architecture, Release 2.0. As
defined in that document, this Implementation Guide is both an annotation profile and
a localization profile. Every aspect of the CDA R2 may not be described in this guide.
1.6.1 Explanatory Statements
As an annotation profile, portions of this Implementation Guide summarize or explain
the base standard portions of this DSTU summarize or explain the base standard;
therefore, not all requirements stated here are original to the DSTU. Some originate in
the base specification. Those requirements that do not add further constraints to the
base standard and which can be validated through CDA.xsd do not have corresponding
conformance statements.
Where no constraints are stated in this guide, Operative Note instances are subject to
and are to be created in accordance with the base CDA R2 specification. Where, for
instance, the CDA R2 specification declares an attribute to be optional and the
Operative Note specification contains no additional constraints, that attribute remains
optional for use in an Operative Note instance.
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 12
MAY 2008
1.6.2 Conformance Requirements
Conformance requirements for this DSTU are of two types: those that are collected
within a published template of CDA/V3 conformance statements and those that are not
associated with a published template.
● Where not associated with a published template, they are numbered sequentially
and listed within the body of the DSTU as follows:
CONF-OP-1: This is an example conformance requirement original to this DSTU.
● Where conformance requirements from another DSTU or Implementation Guide
are associated with a template, they are included through assertion of that
template Identifier and listed in two ways:
o In the body of the DSTU, they are listed as follows: Might want to change this
example eventually since there won’t be a medications template used
CONF-OP--66: All constraints from this section are from the CCD Medications
section. See Appendix B —Externally Defined Constraints for CCD conformance
requirements. This section SHALL include the CCD template identifier for the
medications section (2.16.840.1.113883.10.20.1.8).
o In Appendix ?, they are listed using the original numbering sequence from the
Source Guide:
Medications (Template ID: 2.16.840.1.113883.10.20.1.8)
CCD-CONF-299: CCD SHOULD contain exactly one and SHALL NOT contain…
Note: Every effort has been made to ensure consistency between this specification and
the referenced specifications – CDA, CCD and the History and Physical DSTU and
Consult DSTU. In case of discrepancy, the original specification is authoritative..
1.6.3 Vocabulary Conformance
Formalisms for value set constraints are based on the latest recommendations from the
HL7 Vocabulary Committee. Value set constraints can be “STATIC,” meaning that they
are bound to a specified version of a value set, or “DYNAMIC,” meaning that they are
bound to the most current version of a value set. A simplified constraint is used when
binding is to a single code.
Syntax for vocabulary binding to DYNAMIC or STATIC value sets is as follows:
The value for (“pathName of coded element”) (SHALL | SHOULD | MAY) be selected
from ValueSet valueSetOID localValueSetName (DYNAMIC | STATIC
(valueSetEffectiveDate)).
CONF-ex5: The value for “ClinicalDocument / code” SHALL be selected from ValueSet
2.16.840.1.113883.1.11.10870 DocumentType DYNAMIC.
CONF-ex6: The value for “ClinicalDocument / code” SHALL be selected from ValueSet
2.16.840.1.113883.1.11.10870 DocumentType STATIC 20061017.
Syntax for vocabulary binding to a single code is as follows:
The value for (“pathname of coded element”) (SHALL | SHOULD | MAY) be (“code”
[“displayName”] codeSystemOID [codeSystemName] STATIC.
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 13
MAY 2008
CONF-ex7: The value for “ClinicalDocument / code” SHALL be “34133-9”
“Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.
1.6.4 XPath Notation
Instead of the traditional dotted notation used by HL7 to represent RIM classes, this
document uses XPath notation in conformance statements and elsewhere to identify the
XML elements and attributes within the CDA document instance to which various
constraints are applied. The implicit context of these expressions is the root of the
document. The purpose of using this notation is to provide a mechanism which will be
familiar to developers for identifying parts of an XML document.
1.6.5 Keywords
The keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, and NEED NOT in this
document are to be interpreted as described in the HL7 Version 3 Publishing
Facilitator's Guide.
1.6.6 XML Samples
XML Samples appear in various figures in this document in a fixed-width font.
Portions of the XML content may be omitted from the content for brevity, marked by an
ellipsis (…) as shown in the example below.
<ClinicalDocument xmins='urn:h17-org:v3'>
...
</ClinicalDocument>
Figure 1. ClinicalDocument example
Within the narrative, XML element and attribute names will appear in this fixed
character font (ElementName). Literal attribute values will appear in this italic
character font (AttributeValue).
XPath expressions are used in the narrative and conformance requirements to identify
elements because they are familiar to many XML implementers.
1.6.7 Content of the Ballot Package
The ballot package contains the following files:
Filename
Description
Filename.pdf
This Guide
SampleName.xml
The sample ….
whatever
A stylesheet for displaying the content of the sample
document in HTML…
Table 1: Contents of the Ballot Package
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 14
MAY 2008
1.7 Scope
This specification defines additional constraints on CDA Header and Body elements
used in an Operative Note document in the US realm, and provides examples of
conforming fragments in the body of the document and an example of a conforming
XML instance as an appendix.
1.7.1 Levels of Constraint
Within this DSTU, the required and optional clinical content within the body is
identified.
This DSTU specifies three levels of conformance requirements:
● Level 1 requirements specify constraints upon the CDA header and the content of
the document.
● Level 2 requirements specify constraints at the section level of the structuredBody
of the ClinicalDocument element of the CDA document.
● Level 3 requirements specify constraints at the entry level within a section. Any
level 3 requirements are not new to this DSTU but are drawn from the HL7
Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD)
Note that these levels are rough indications of what a recipient can expect in terms of
machine-processable coding and content reuse. They do not reflect on clinical content and
many additional distinctions in reusability could be defined
Conformance to the DSTU at Level 1 asserts header element compliance. Conformance to
the DSTU with no level specified or at Level 1 allows use of a non-XML body or an XML
body that may not conform to the coded section or entry templates defined herein.
Likewise, conformance to the DSTU at Level 2 does not require conformance to entry-level
templates, but does assert conformance to header- and section-level templates. In all
cases, required clinical content must be present. For example, a CDA Operative Note
carrying the templateId that asserts conformance with Level 1 may use a PDF or HTML
format for the body of the document.
1.7.2 Future Work
Future work includes the definition of increasingly refined (granular) machine-verifiable
processing structures, including mapping all requirements for processing the
components of the Evaluation and Management service level.
This work will be performed in conjunction with other HL7 technical committees and in
cooperation with professional societies and other Standards Development Organizations
(SDO).There are many parallel efforts to create CDA Implementation Guides (IGs) and
standards based on CDA. Future work will address libraries of templates, including
those defined and reused here, and refinement of the document type hierarchy.
Future related work may create a broad Procedure Note with constraints according to
type of procedure, specialty or clinical setting. The Operative Note is a frequently used
type of procedure note with very specific requirements set forth by regulatory agencies.
Implementation and use of this DSTU’s guidelines will enhance development of an all
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 15
MAY 2008
encompassing Procedure Note implementation guide. Should the 2 sentences (also) be
in the purpose section??
Development of closely related specifications for the History and Physical Note,
Consultation Note, Discharge Summary, and others may lead to consolidation of
requirements into a single publication providing guidance across a range of document
types.
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 16
MAY 2008
2 CDA HE ADER – GENERAL CONSTRAINTS
General constraints that apply to the Operative Note and to other types of CDA
documents defined for general exchange are defined in the first of the CDA4CDT
specifications, the History & Physical. The template defined there should be reused
wherever these “general header constraints” are applied.
Note also that elements defined here may be further constrained within this
Implementation Guide. For example, The General Constraints limits the document type
code to the LOINC document type vocabulary. In Section 3.2, ClinicalDocument/code,
the document type code is further constrained, specifically for Operative Note or
Surgical Operation Note documents.
CONF-1: A document conforming to the general header constraints in this DSTU
SHALL indicate so by including the following template id in the header of the
document or by including a template id in the header for a template that
requires use of the general header constraint template: <templateId
root=“2.16.840.1.113883.10.20.3”/>
<ClinicalDocument xmlns='urn:hl7-org:v3'>
<typeId extension='POCD_HD000040' root='2.16.840.1.113883.1.3'/>
<templateId root='2.16.840.1.113883.10.20.X'/> <!-- indicates conformance with the DSTU -->
<!-- templateId root='2.16.840.1.113883.10.20.3'/ -->
<!-- indicates conformance with CDA4CDT general header constraints;
not required here because the DSTU asserts usage of the general header constraints -->
<id extension='999021' root='2.16.840.1.113883.19'/>
<code code=”34874-8” codeSystem='2.16.840.1.113883.6.1'
codeSystemName='LOINC' displayName=Operative Note'/>
<title>Operative Note</title>
<effectiveTime value='20050329224411+0500'/>
<confidentialityCode code='N' codeSystem='2.16.840.1.113883.5.25'/>
<languageCode code='en-US'/>
<setId extension='999021' root='2.16.840.1.113883.19'/>
<versionNumber value='1'/>
…
</ClinicalDocument>
Figure 1: ClinicalDocument/general header constraints templateId example
The general constraints apply to:
● Clinical document and associated metadata
● ID, type ID
● Level of constraint
● Code, title
● SetID and Version number
● Effective time, confidentiality code,
● Language code, realm code
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 17
MAY 2008
● copyTime
● Participants
● Record target (patient)
● Author
● Authenticator and legal authenticator
● Custodian
● Data enterer (transcriptionist)
● Informant
● Healthcare providers
● Personal relations and unrelated persons
● Information recipient (entered in “cc” field)
● Participant telephone number
In addition to these constraints, implementation should follow the guidelines defined in
the H&P DSTU for rendering the CDA header. These guidelines state that metadata
carried in the header may already be available for rendering from EMRs or other
sources external to the document, therefore there is no strict requirement to render
directly from the document. An example of this would be a doctor using an Electronic
Medical Record (EMR) which already contains the patient’s name, date of birth, current
address, and phone number. When a CDA document is rendered within that EMR,
those pieces of information may not need to be displayed since they are already known
and displayed within the EMR’s user interface.
Good practice would recommend that the following be present whenever the document
is viewed:
● Document title and document dates
● Service and encounter types and date ranges as appropriate
● All persons named along with their roles, participations, participation date ranges,
identifiers, address, and telecommunications information
● Selected organizations named along with roles, participations, participation date
ranges, identifiers, address, and telecommunications information
● Date of birth for recordTarget(s)
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 18
MAY 2008
3 CONSTRAINTS ON HE ADE R ELEMENTS –
OPERATIVE NOTE SPECI FIC CONSTRAINTS
This section describes constraints specific to Operative Note Documents
3.1.1 ClinicalDocument
The namespace for CDA Release 2.0 is urn:hl7-org:v3. Appropriate namespace
declarations shall be used in the XML instance of the ClinicalDocument. In the
examples in this specification, all elements are shown un-prefixed, assuming that the
default namespace is declared to be urn:hl7-org:v3.
3.1.2 ClinicalDocument/templateID
CONF-2: ClinicalDocument/templateId element shall be present with the value
2.16.840.1.113883.10.20.X
3.1.3 ClinicalDocument/code
CDA Release 2.0 states that LOINC is the preferred vocabulary for document type
specification. This DSTU goes further, stating that only the codes as described below
are to be used for a Operative Note.
CONF-3: ClinicalDocument/code element SHALL be present and specifies the type of
the clinical document.
CONF-4: The value for “ClinicalDocument / code” SHALL be any LOINC Code whose
‘Scale_Type’ is ‘Doc’ and whose ‘Component’ is Operative Note or Surgical
Operation Note TypeCode DYNAMIC.
3.1.4 ServiceEvent
This class represents the main Act, such as a colonoscopy or an appendectomy, being
documented. A ServiceEvent can further specialize the act inherent in the
ClinicalDocument.code, such as where the ClinicalDocument.code is simply "Operative
Report" and the procedure was an " appendectomy ". ServiceEvent is required in the
Operative Note and it must be equivalent to or further specialize the value inherent in
the ClinicalDocument.code, and shall not conflict with the value inherent in the
ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed
to the encounter surrounding the event) took place.
CONF-5: The value of “Clinical Document/documentationOf /serviceEvent / code”
SHALL be present and SHALL be from one or more of ICD-9 (put oid in), CPT –
procedure codes (oid), or SNOMED-CT (codeSystem (just number)oid) code
systems.
CONF-6: The “ServiceEvent / effectiveTime” SHALL be present. The date SHALL be
present. The time SHOULD be present. The duration SHOULD be present. (do we
need to put details in of how to handle the time?)
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 19
MAY 2008
3.1.5 Performer
The performer participant represents clinicians who actually and principally carry out
the ServiceEvent.
CONF-7: The primary performer (PPRF) SHALL be identified.
CONF-8: For all performers: ServiceEvent / performer / assignedEntity / code
SHOULD be present
CONF-9: The value of ServiceEvent/performer/assigned entity / code SHALL be
selected from Healthcare Provider Taxonomy Code (NUCC) get oid for NUCC(any
b/c in some places a family practice doc might have surgical privileges)
CONF-10: Any assistants SHALL be identified and SHALL be identified as secondary
performers (SPRF)
3.2 Rendering Header Information for Human Presentation
Metadata carried in the header may already be available for rendering from EMRs or
other sources external to the document, therefore there is no strict requirement to
render directly from the document. An example of this would be a doctor using an EMR
that already contains the patient’s name, date of birth, current address, and phone
number. When a CDA document is rendered within that EMR, those pieces of
information may not need to be displayed since they are already known and displayed
within the EMR’s user interface.
In an Operative Note it is imperative that the following be displayed in the EMR and/or
rendered within the document:
 The performers of the surgery, including any assistants
 The surgery performed (ServiceEvent)
 The date of the surgery
Good practice would recommend that the following be present whenever the document
is viewed:
● Document title and document dates
● Service and encounter types, and date ranges as appropriate
● All persons named along with their roles, participations, participation date ranges,
identifiers, address, and telecommunications information
● Selected organizations named along with their roles, participations, participation date
ranges, identifiers, address, and telecommunications information
● Date of birth for recordTarget(s)
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 20
MAY 2008
4 BODY
An Operative Note shall have either a structuredBody or nonXMLBody element. The
content of this element makes up the human readable text of the document. This
information shall be organized into sections and may have subsections. A nonXMLBody
element may contain the actual CDA content or may reference it by URL.
4.1 Section Descriptions
This Implementation Guide defines required and optional sections.
All section elements in the body of the document shall have a code and some
nonblank text or one or more subsections, even if the purpose of the text is only to
indicate that information is unknown.
CONF-11: These codes SHALL be used with the sections shown in Table 1: LOINC
codes for sections for Level 2 conformance.
CONF-12: Sections not appearing in this table MAY be included where necessary in
the Operative Note according to local policy; such sections SHOULD be coded
using the appropriate LOINC Section codes per Table 1: LOINC codes for
sections.
CONF-13: All sections MAY occur in any order and MAY be nested under other
sections according to local policy. The order and arrangement of sections and
subsections SHOULD follow the ASTM E2184 guidelines
CONF-14: Sections and subsections SHALL have a title and the title SHALL not be
empty.
Note that section titles are shown in full caps per ASTM’s Standard Specifications for
Healthcare Document Formats (E2184.02).
Section Category
R/O
Code
Component Name
Pre-Op Diagnosis
R
10219-4
OPERATIVE NOTE-PREOPERATIVE DX
Post-Op Diagnosis
R
10218-6
OPERATIVE NOTE - POSTOPERATIVE DX
R
10223-6
OPERATIVE NOTE SURGICAL PROCEDURE
Findings
R
10215-2
OPERATIVE NOTE FINDINGS
Anesthesia
R
10213-7
OPERATIVE NOTE ANESTHESIA
Estimated Blood
Loss
R
8717-1
OPERATIVE NOTE ESTIMATED BLOOD LOSS
Specimens
Removed
R
10221-0
OPERATIVE NOTE SPECIMENS TAKEN
Indications
O
10217-8
Complications
O
10830-8
OPERATIVE NOTE COMPLICATIONS
Plan
O
18776-5
PLAN OF TREATMENT
Details of Procedure
(Description)
OPERATIVE NOTE INDICATIONS
Table 1: LOINC codes for sections
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 21
MAY 2008
4.2 Required Sections
CONF-15: An Operative Note SHALL contain the sections described hereunder.
CONF-16: A required section for which no content is available SHALL contain some
indication in the narrative block for that section that no content is available.
“Blank” or “None Recorded” are examples of indications that no content is available.
Local practice must ensure that the legal authenticator is aware that this statement will
be part of the legally authenticated content.
4.2.1 Pre-Operative Diagnosis 10219-4
(question for cda4cdt; see display name several ways – what do we want for this IG)
The Pre-op Diagnosis section records the diagnosis or diagnoses (findings) that justifies
the surgery or is the reason for the surgery. The Pre-op diagnosis is often thought of by
the surgeon as, “this is my assumption what I will find during the surgery”.
Good practice would recommend that the recorded Pre-op Diagnosis be from ICD-9
codeSystem or SNOMED-CT codeSystem
CONF-17: The section code for the Pre-Op Diagnosis section SHALL be 10219-4
(OPERATIVE NOTE-PREOPERATIVE DX)
4.2.2 Post-Operative Diagnosis 10218-6
The Post-Op Diagnosis section records the diagnosis or diagnoses (findings) discovered
or confirmed during the surgery.
Good practice would recommend that the recorded Post-op Diagnosis be from ICD-9
codeSystem or SNOMED-CT codeSystem
CONF-18: The section code for the Post-Op Diagnosis section SHALL be 10218-6
(OPERATIVE NOTE - POSTOPERATIVE DX)
4.2.3 Details of Procedure 10223-6
The Details of Procedure section records particulars of the surgery with an extensive
narrative and may include surgical site preparation, some details of sedation,
measurements and markings, waiting times, incision approaches, instruments used,
sponge counts, tissue manipulation, the process of closing the wound, sutures used,
vital signs and other monitoring done, complications may be recorded in this section
and the disposition of the patient at the completion of the procedure. Local practice
often identifies the level and type of detail required based on the procedure or by
specialty.
CONF-19: The section code for the Details of Procedure Section SHALL be 10223-6
(OPERATIVE NOTE SURGICAL PROCEDURE)
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 22
MAY 2008
4.2.4 Findings 10215-2
The Findings section records details of the Post-op diagnosis or diagnoses or other
discoveries. Often this section is a subsection of the Details of Procedure section.
CONF-20: The section code for the Findings section SHALL be 10215-2 (OPERATIVE
NOTE FINDINGS)
4.2.5 Anesthesia 10213-7
The Anesthesia section briefly records the type of anesthesia (general or local) and may
state the actual agent. This may or may not be a subsection of the Details of Procedure
Section. The full details of Anesthesia are usually found in a separate Anesthesia Note.
CONF-21: The section code for the Anesthesia section SHALL be 10213-7
(OPERATIVE NOTE ANESTHESIA)
CONF-22: The Anesthesia section SHOULD state whether general vs. local. MAY state
the actual agent.
4.2.6 Estimated Blood Loss 8717-1
The Estimated Blood Loss section records the projected amount of blood that the
patient lost during the surgery. This may be a subsection of the Details of Procedure
section.
CONF-23: The section code for the Estimated Blood Loss section SHALL be 87171(OPERATIVE NOTE ESTIMATED BLOOD LOSS)
CONF-24: The Estimated Blood Loss section SHALL include a statement providing a
quantitative estimate of the amount of blood lost during the procedure, even if
minimal or none
4.2.7 Specimens Removed 10221-0
The Specimens Removed section records the samples taken from the patient during
surgery. The narrative may include a description of the specimens.
CONF-25: The section code for the Specimens Removed section shall be 10221-0
(OPERATIVE NOTE SPECIMENS TAKEN)
CONF-26: The Specimens Removed section SHALL list all specimens removed OR
SHALL explicitly state that no specimens were removed
4.3 Optional Sections
An Operative Note may contain additional sections that provide additional information.
4.3.1
Indications 10217-8
The Indications section records further detail about the reason for the surgery. This
section may be a subsection of another section such as the Pre-p Diagnosis section or
Detail of Procedure Section.
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 23
MAY 2008
CONF-27: The Operative note SHOULD contain an Indications section.
CONF-28: The section code for the Indications section SHALL be 10217-8
(OPERATIVE NOTE INDICATIONS)
4.3.2 Complications 10830-8
The Complications Section records problems that occurred during surgery. The
complications may have been known risks or unanticipated problems. The
Complications section may be a subsection of another section such as the Details of
Procedure section. Complications may also be written as narrative text in another
section such as The Details of Procedure Section.
CONF-29: The Operative Note MAY contain a complications section
CONF-30: The section code for the Complications section SHALL be 10830-8
(OPERATIVE NOTE COMPLICATIONS)
CONF-31: If the Complications section is present the narrative SHALL include a
statement providing details of the complication(s) OR SHALL explicitly state there
were no complications
4.3.3 Plan 18776-5
Note: need to determine if The template identifier for the Assessment and Plan section
2.16.840.1.113883.10.20.2.7 from the previous CDA4CDT and CCD is appropriate or
useful for this section.
The Plan section contains recommendations for care of the patient. It may contain
recommendations for care in the immediate post-surgical time frame or longer term
recommendations. The Plan section may be a subsection of another section such as the
Details of Procedure section. Plans may also be written as narrative text in another
section such as The Details of Procedure Section.
CONF-32: The Operative Note MAY contain a Plan section.
CONF-33: The section code for the Plan section shall be 18776-5 (PLAN OF
TREATMENT)
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 24
MAY 2008
5 REFERENCES

A bulleted list with hyperlinks

Probably many items with hyperlinks
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 25
MAY 2008
VALIDATION
Introduction
This appendix describes the vocabularies used or defined by this specification, and the
Schematron schema that may be used to validate the content of the CDA header for
[DocType] documents.
Vocabulary
Extending the Vocabulary Tables for Local Use
Administrative Contact Role Type
Administrative Gender
Ethnicity
Marital Status
Null Flavors
Personal Relationship Role Type
Race
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 26
MAY 2008
EXTERNAL CONSTRAINTS
Introduction
This appendix lists all of the external conformance statements referenced from the body
of this document. For a complete description of these constraints, please refer to the
original specification they were derived from.
XXX Constraints
The following constraints are from …
Medications (Template ID 9.99.999.9 ….)
CONF-34: ZZZ SHOULD contain exactly one and SHALL NOT contain more than one
<element> section (templateID 9.9.99999…)
Social History (Template ID 9.99.999.9 ….)
CONF-35: ZZZ SHOULD contain exactly one and SHALL NOT contain more than one
<element> section (templateID 9.9.99999…)
CONF-36:
YYY Constraints
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 27
MAY 2008
TERMPLATE IDS DEFINED IN THIS GUIDE
Template ID
Description
2.16.999.9.999999.99.99.9
CDA for …
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 28
MAY 2008
LIST OF ADDITIONAL OPTIONAL SUBSECTIONS
Below is the list of additional optional subsections that MAY be used …..
99999-9
MENTAL STATUS
88888-8
PSYCIATRIC FINDINGS
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
Page 29
MAY 2008
SECTION CARDINALITY
The following table summarizes the use of sections within the XX, this guide, and the
QQQ.
Section
XX
<This Guide>
Implementation Guide for CDA R2
Operative Note (US Realm)
Draft text
1.0
© 2008 Health Level Seven, Inc. All rights reserved.
<QQQ>
Defined In
Page 30
MAY 2008