1. Networking and Health Information Exchange
Welcome to Networking and Health Information Exchange, Basic Health Data Standards. This is Lecture f.
This component, Networking and Health Information Exchange, addresses what is required to accomplish networking across and among disparate organizations who have heterogeneous systems. As one might imagine, this topic covers a lot of territory fraught with new topics and a lot of acronyms. Our apologies, but that’s what it is. We suggest you keep your glossary beside you as you study this material.
Unit 4 covers Basic Health Data Standards and consists of six lectures. Over these 6 lectures, we will identify the set of standards necessary to establish semantic interoperability.
Lecture f presents three related document standards that are in major use globally today.
Basic Health Data Standards
Lecture f
This material (Comp 9 Unit 4) was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated by Normandale Community College, funded under Award Number 90WT0003.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. Basic Health Data Standards Learning Objectives
Understand why it is necessary to use a common set of data elements with common names to be able to exchange and understand data from other places
Understand what is meant by semantic interoperability
Understand many of the sets of controlled vocabularies in use today – how they are used and who requires their use
The Objectives for this unit, Basic Health Data Standards, are to:
Understand why it is necessary to use a common set of data elements with common names to be able to exchange and understand data from other places,
Understand what is meant by semantic interoperability,
Understand many of the sets of controlled vocabularies in use today – how they are used and who requires their use,

3. Basic Health Data Standards Learning Objectives
Understand the use, purpose and interrelation among sets of controlled vocabularies in use today
Identify the more common controlled vocabularies in use today: ICD, CPT, DRG, NDC, RxNorm, and LOINC,
identify the more common controlled vocabularies in use today: SNOMED, MEDCIN, MedDRA, Nursing terminologies, MeSH and UMLS,
Understand data elements; attributes of data elements
Additional Objectives for this unit, Basic Health Data Standards, are to:
Understand the use, purpose and interrelation among sets of controlled vocabularies in use today,
Identify the more common controlled vocabularies in use today: ICD, CPT, DRG, NDC, RxNorm, and LOINC,
Identify the more common controlled vocabularies in use today: SNOMED, MEDCIN, MedDRA, Nursing terminologies, MeSH and UMLS,
Understand data elements; attributes of data elements,

4. Basic Health Data Standards Learning Objectives
Understand contribution of master meta-dictionary of data elements to semantic interoperability
Explain how data structures can be built from basic data components
Explain how templates and archetypes facilitate networking and information interchange and
Discuss Clinical Data Architecture (CDA), Continuity of Care Document (CCD), and Continuity of Care Record (CCR) Standards
Additional Objectives for this unit, Basic Health Data Standards, are to:
Understand contribution of master meta-dictionary of data elements to semantic interoperability,
Explain how data structures can be built from basic data components,
Explain how templates and archetypes facilitate networking and information interchange, and
Discuss Clinical Data Architecture (CDA), Continuity of Care Document (CCD), and Continuity of Care Record (CCR) Standards.
This lecture is the last of the series and focuses on a higher level of data structures.

5. Clinical Document Architecture
Document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange.
Defined information object that can include text, images, sounds, and other multimedia content.
The architecture specifies the schemas required for exchange.
The CDA is a document markup standard that specifies the structure and semantics of clinical documents. The architecture should impose minimal constraints or requirements on document structure and content required for exchange. The CDA can include text, images, sounds, and other multimedia content. A CDA document can exist outside a message. The architecture specifies the schemas required for exchange.
The CDA typically contains observations and services of a specific patient. The current version is Release 2 (R2).
We will begin by defining the term “health.” We often think of health as the absence of disease but this is a somewhat narrow description of the term. In 1946, representatives of 61 countries attended the International Health Conference in New York to ratify the Preamble to the Constitution of the World Health Organization, which is the specialized agency of the United Nations that deals with global health. The WHO [hoo] definition of health is that health is the state of complete physical, mental, and social well being and not merely the absence of disease or infirmity. Thus, illness represents a state of poor health.

6. Characteristics of CDA
Persistence
Stewardship
Potential for authentication
Context
Wholeness
Human readability
This slide presents characteristics of the CAD.
Persistence continues to exist in an unaltered state, for a time period defined by local and regulatory requirements; it may or not be important, depending on what happens on the receiving end. It can be stored as a persistent document, or its contents can be extracted and included in an EHR.
Stewardship is maintained by an organization entrusted with its care. Its potential for authentication is an assemblage of information that is intended to be legally authenticated.
Context establishes the default context for its contents.
Wholeness means that authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
Human readability means the contents can be read by a human. Why is this important? CDA can include both structured data for input into EHR in systems that have a structured EHR, or, for systems that are text based, can include human readable narrative that can be directly displayed. In the absence of interoperability, this still provides a method for sharing data.

7. Key Aspects of CDA
The CDA specification is richly expressive and flexible.
Encoded in XML.
Data elements derive their meaning from the HL7 RIM.
Uses the HL7 Data Types.
The CDA specification is richly expressive and flexible. CDA uses XML as the markup language. It is based on the HL7 Reference Information Model, and it uses the HL7 data types which are consistent with the ISO data types. Data elements derive their meaning from the HL7 RIM. CDA uses HL7 data types. Document-level, section-level and entry-level templates can be used to constrain the generic CDA specification.

8. CDA
Allow cost effective implementation across as wide a spectrum of systems as possible.
Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
Promote exchange that is independent of the underlying transfer or storage mechanism.
The CDA allows a cost effective implementation across a wide spectrum of systems. Promotes longevity of all information encoded according to this architecture. It enables a wide range of post-exchange processing applications. It is compatible with a wide range of document creation applications.
CDA documents are human-readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language.
The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
The CDA promote exchanges that is independent of the underlying transfer or storage mechanism.

9. Major Components
A CDA document is wrapped by the <ClinicalDocument> element, and contains a header and a body.
The header lies between the <ClinicalDocument> and the <StructuredBody> elements and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers.
A CDA document is wrapped by a <ClinicalDocument> element. The major components of the CDA are a Header and a Body. The header includes all data necessary to identify the document, sender and receiver, date and time, and other data discussed in detail in a following slide. The body contains all the clinical data.
The CDA is expressed in XML. The document wrapper is the XML Tag <ClinicalDocument> with the ending tag </ClinicalDocument>.  The Body is wrapped by the tag <StructuredBody>.

10. XML Markup for CDA XML tag is defined <tag>
Data is expressed as data element name
Data value is “value”
Each entry has a start tag <tag> and a stop tag </tag>.
<code> code = “ ” </code>
Entries may be nested.
Note the syntax for the XML markup language. An XML tag is expressed as <tag>. Data is identified by the data element name. Data has a value. These fields are identified by the XML tags. Each entry has a start <tag> and a stop </tag>. An example is: start <code> code = “ ” stop </code>
Nested structures are indented to make it easier to see the structure of the content. Programs can check syntax – conformant document – to make sure all beginnings have an end and that structures are intact.

11. Major Components of a CDA Document
This slide shows a graphic of a complete CDA. Note the sections of Document, Header, Body, Section, Entries, and External references.
The Header will be discussed in detail in the next slide.
BODY
The body contains the clinical report and can be either an unstructured blob or can be comprised of structured markup.
A structured body, which is wrapped by the <StructuredBody> element, is divided up into recursively nest-able document sections.
SECTION
Is wrapped by the <Section> element.
It can contain a single narrative block and any number of entries {0 to many}
It may have external references.
NARRATIVE BLOCK
The CDA narrative block is wrapped by the <text> element within the <Section> element and provides a slot for the human readable content needing to be rendered.
EXTERNAL REFERENCES
External references refer to things that exist outside the CDA document - such as some other image, some other procedure, or some other observation
Wrapped by the <ExternalObservation> element.
These sections may repeat.
Source: Dr. Bob Dolin, Chair HL

12. sets context for the entire document
Header Components
Contextual header
Author
Confidentiality
Data enterer
Human language
Informant
Legal authenticator
Participant
Record target
sets context for the entire document
This is the structure for the header;
Author
Confidentiality
Data enterer
Human language
Informant
Legal authenticator
Participant
Record target
The header sets the context for the entire body. However, structure can be changed within the document or for a section of a document. For example, the header can set the confidentiality as public, but within the document can set confidentiality to private for an indicated section.

13. Major Components <ClinicalDocument> ... CDA Header ...
<StructuredBody>
<section>
<text>...</text>
<Observation>...</Observation>
<Observation>
<reference>
<ExternalObservation>...</ExternalObservation>
</reference>
</Observation>
</section>
<section>...</section>
</StructuredBody>
</ClinicalDocument>
This slide shows the major components of the CDA with the XML tags in place. Creating an XML by hand will consist of putting in the specific tags, data names, and the data. Sections would be repeated as necessary.
CDA Conformance specifies the principles governing the representation of the narrative block, conformance requirements on the part of originators when populating the block, and recipients when rendering it.
Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for a computer. CDA entries encode content present in the narrative block of the same section.
CDA external references always occur within the context of a CDA entry and are wrapped by the <reference> element.
The CDA entry that wraps the external reference can be used to encode the specific portions of the external reference that are addressed in the narrative block.
This hierarchical structure reflects the structural diagram on slide 11.

14. CDA Specification
The CDA specification permits the use of document codes and section codes. Thus, it is possible to differentiate a "Consultation Note" from a "Discharge Summary" because the two will have distinct document codes in the document instance.
The CDA specification permits the definition of many documents and identifies them by assigned codes. Sections within the document can also be identified by codes. Thus, it is possible to differentiate a "Consultation Note" CDA from a "Discharge Summary" CDA because the two will have distinct document codes in the document instance.
An HL7 Template provides a formal mechanism to say that a particular consultation note or discharge summary must contain certain sections, or that an assessment or plan section must contain certain observations.
The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser. CDA, Release Two, with its blend of narrative and CDA entries, presents new challenges to this requirement.

15. Rendering Tags <section> <text>
<content emphasis="bold">
This is rendered bold,
<content emphasis="italics">
this is rendered bold and italicized,
</content>
this is rendered bold.
</text>
</section>
This example shows the use of rendering tags – in this case BOLD to enhance the presentation of the data.

16. Example CDA Section section>
<code code=" " codeSystem=" “
codeSystemName="LOINC"/>
<title>Past Medical History</title>
<text>
There is a history of <content ID="a1">Asthma</content>
</text>
<entry>
<Observation>
<code code="
codeSystem=" "
codeSystemName="SNOMED CT"
displayName="history taking (procedure)"/>
<value xsi:type="CD" code=" "
displayName="Asthma">
<originalText>
<reference value="#a1"/>
</originalText>
</value>
</Observation>
</entry>
</section>
This slide illustrates the use of a section code to identify and specify the content of a section = past history. If there was no past history, that section would be omitted.

17. LOINC Document Codes 28568-4 Visit Note Emergency Department Physician
Admission Evaluation Note Inpatient Attending General Medicine
Consultation Note {Setting} {Provider}
The LOINC terminology set includes LOINC codes for CDA documents.
Examples include:
Visit Note Emergency Department Physician
Admission Evaluation Note Inpatient Attending General Medicine
Consultation Note {Setting} {Provider}

18. Continuity of Care Document
The content of the CCR was reflected into the CDA in a manner consistent with other models being developed by HL7.
This method accelerated convergence within HL7 around a common clinical statement model, leading to closer collaboration with several domain committees, such as results, family history, allergies, problems and medications.
The Continuity of Care Document is the union of the ASTM CCR standardized data set that is used to constrain CDA specifically for patient summary document.
The approach taken in the development of CCD is to reflect the CCR requirements in a CDA R2 framework, and to do so in such a way that CDA is constrained in accordance with models being developed by other HL7 committees.
This process has helped accelerate convergence within HL7 around a common “clinical statement” model, leading to closer collaboration with several domain committees, such as results, family history, allergies, problems and medications.

19. CCD Sections Medications Medical Equipment Immunizations Vital Signs
Results
Procedures
Encounters
Plan of Care
Payers
Advance Directives
Support
Functional Status
Problems
Family History
Social History
Alerts, allergies, AE
The sections of CCD have been extended beyond the CCR and now include:
Payers,
Advance Directives,
Support,
Functional Status,
Problems,
Family History,
Social History,
Alerts, allergies, adverse events,
Medications,
Medical Equipment,
Immunizations,
Vital Signs,
Results,
Procedures,
Encounters, and
Plan of Care.

20. CCD Example Part 1 <Results> <Result>
<CCRDataObjectID>
</CCRDataObjectID>
<DateTime>
<Type>
<Text>Assessment Time</Text>
</Type>
<ExactDateTime>
</ExactDateTime>
</DateTime>
<Text>Hematology</Text>
<Description>
<Text>CBC WO DIFFERENTIAL</Text>
<Code>
<Value> </Value>
<CodingSystem>SNOMED CT</CodingSystem>
</Code>
</Description>
<Status><Text>Final Results</Text></Status>
This slide shows a sample CCD. The section shown is the Result Section and provides the result for a hematology test. In this example both LOINC codes and SNOMED-CT codes are used. The date and time of the test are included as part of the Result Section.

21. CCD Example Part 2
<section> <templateId root=" "/> <code code=" “ codeSystem=" " codeSystemName="LOINC"/> <title>Laboratory results</title> <text> CBC (04/07/2000): HGB 13.2; WBC 6.7; PLT 123* </text> <entry> <organizer classCode="BATTERY" moodCode="EVN"> <templateId root=" "/> <id root=" " extension="1"/> <code code=" " codeSystem=" " codeSystemName="SNOMED CT" displayName="CBC WO DIFFERENTIAL"/> <statusCode code="completed"/> <effectiveTime value=" "/>
Another sample of a CCD section continues. This section provides laboratory results for a battery.

22. Continuity of Care Record
Patient health summary detail
Flexible document
Relevant and timely core information about patients for exchange among patients
Standard from ASTM
XML syntax
The primary use case for the ASTM CCR is to provide a snapshot in time containing a summary of pertinent clinical, demographic and administrative data for a specific patient. The CCR provides a patient health summary detail. It is a flexible document and can contain whatever the sender wishes. It provides relevant and timely core information about patients for exchange among patients. The CCR is available from ASTM at a cost. CCR uses the XML syntax.

23. CCR Content Demographics Diagnosis Problem list Medication Allergies
Insurance
Care Plan
The CCR content includes:
Demographics,
Diagnosis,
Problem list,
Medication,
Allergies,
Insurance, and
Care Plan.
Compare this content with the content of the CCD.

24. Basic Health Data Standards Summary
Structured documents have great power to enable interoperability
Structure complicated but content simple – data elements with XML tags
Permits migration from narrative text to coded data – key to migration to interoperability
Internationally becoming the exchange document of choice.
This concludes Basic Health Data Standards.
The increased power of these structured documents to enable interoperability holds great promise for HIT. The structure might be considered complicated but the content is simple – data elements with XML tags.
The structured/narrative section of the CDA clearly provides a gradual pathway from unstructured free text to highly structured data. The capability provided by this technology opens a new opportunity to exchange data on a significantly elevated level in which true information is exchanged. Internationally, the CCD is becoming the exchange document of choice.

25. Basic Health Data Standards References – Lecture f
Acknowledgement: Material used in this lecture comes from HL7 CDA standards and ASTM CCR Standard.
Health Level Seven International. (n.d.). Retrieved from Health Level Seven International website:
Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F. M., & Biron, P. V. (2004). HL7 Clinical Document Architecture, Release 2.0. Retrieved from Health Level Seven®, Inc. website:
HL7 Structured Documents Technical Committee. (2004, August 20). Health Level Seven Releases Updated Clinical Document Architecture (CDA) Specification.. Retrieved from
Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F. M., Biron, P. V. & Shabo (Shvo), A. HL7 Clinical Document Architecture, Release 2. (2006, Jan-Feb). Journal of the American Medical Informatics Association, 13(1), PMCID: PMC
Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F. M., & Biron, P. V. (2004). HL7 Clinical Document Architecture, Release 2.0. Retrieved from Health Level Seven®, Inc website:
Boone, K. W., Dolin, R. H., Mitchell-Jones, P., Peters, R., Russler, D., Shabo (Shvo), A., ... Auckerman, A. (2006, March 26). HL7/ASTM Implementation Guide for CDA Release 2 – Continuity of Care Document (CCD.05March2006.DRAFT-1.doc). Retrieved from HL7 website:
Images
Slide 11: Dolin, R. H., Alshuler, L., Boyer, S., Beebe, C., Behlen, F., Biron, P. V., & Shvo, A. S. (2006). HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc, 13,
No audio

26. Basic Health Data Standards Lecture f
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated by Normandale Community College, funded under Award Number 90WT0003.
No audio
Health IT Workforce Curriculum Version 4.0