1. Networking and Health Information Exchange
Basic Health Data Standards
Lecture e
Welcome to Networking and Health Information Exchange, Basic Health Data Standards. This is Lecture e.
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 e deals with building data structures from basic data elements. As in most cases, we have different standards, different groups, and different ways of doing this. The results are similar, and the content can be the same, but the structure and syntax are different. Even within the same SDO, there are overlapping and competing ways to create data structures.
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.
A key requirement for semantic interoperability is to be able to understand what the other person is saying. Data elements are the building blocks for this communication, and we will discuss this topic in some detail. Terminology can be considered to be a subset of data elements. We will look at many of the more popular controlled vocabularies today, and understand the source. We will describe the use, purpose and interrelation among sets of controlled vocabularies in use today.

5. Building Data Structures
Starting with well-defined, finely-grained data elements, it is useful to build data structures for consistency in content, collection, and presentation.
Structures permit binding related data components into a single structure.
This concept is familiar because we see it on paper forms.
Examples include person names and addresses as well as many health data components.
The scope ranges from simple compound elements to data collection protocols.
There are many reasons to build structures. One is that a structure is able to bind all of the components of a concept into a manageable and understandable object. Structures facilitate the capture of data in the sense of completeness. Structures guide data entry and provide a template for the presentation of results.
To build structures, we start with well-defined, finely-grained data elements. It is useful to build data structures for consistency in content, collection and presentation. This concept of structures is familiar because we see it on paper forms. Examples include person names and addresses as well as many health data components.
The scope ranges from simple compound elements, to data collection protocols.

6. Compound Data Elements
Attributes similar to data elements
Examples include blood pressure, heart murmur, titers
Expressed as
Templates (HL7)
Archetypes (openEHR)
Common Message Element Type (CMET)
Clinical Statement
Use XML syntax
A compound data element is a structure that includes other data elements. The attributes are similar to those for simple data elements. The advantage of a compound element is that linked components with tags can be included as an encapsulated set, but can be addressed as a whole unit or by components. An example is blood pressure. The parts of a blood pressure are systolic, diastolic, which arm, position of the patient, cuff size, manual or automated. Other examples include a heart murmur or titers.
Compound elements can be built into higher level structures such as templates (HL7), archetypes (openEHR), Common Message Element Type (CMET)(HL7) and clinical statements (HL7) and other structures.
Compound data elements most frequently use XML syntax.

7. Complex Data Elements Attributes similar to data elements
Examples include drug sensitivity, microbiology results, body mass index, pulmonary functional tests
May include description logic and mathematical calculations
May invoke an action
For a complex data element, the attributes are similar to data elements. Examples include drug sensitivity, microbiology results, body mass index, and pulmonary functional tests. Complex data elements may include description logic and mathematical calculations. Complex data elements may include calculations, logic statements, or actions. They may invoke an action.
They may be extended into data groupings such as: patient admit profile, TB screen, Well-baby workup, or a clinical trial component.
Complex data elements may support trigger-driven data transport profiles such as data required when a patient is transferred from hospital to nursing home.
Complex data elements may support Disease Management Profiles.

8. Common Message Element Type
Administrative complex data elements defined by groups within HL7.
Examples include person names, addresses, telephone numbers, etc.
Support international variations
Reusable components
Can be reused without redefining the data object
Common Message Element Types (CMET) were originally meant to be administrative objects defined by groups within HL7. The first CMETs were simple and obvious constructs such as person name, address, telephone numbers, addresses, etc. Different CMETs could accommodate the differences in naming structure internationally, and deal with such issues as surname vs family name vs last name, etc. It permits building prefixes and suffixes into the name structure in a manageable way.
As the power of CMETs was appreciated, the group defining CMETs expanded both the scope and the dimension of CMETS. There is a fine line between CMETs and Templates which will be discussed later.
A CMET may contain other CMETs. CMETs are reusable without redefining the data object.

9. What Is An HL7 Template?
Formally, an HL7 Template is a registered set of constraints on a balloted HL7 static model.
HL7 balloted static models are all derived from the HL7 Reference Information Model.
Templates are used in the HL7 standards Clinical Document Architecture.
An HL7 template defines a higher level data structure and may extend to such things as a well-baby exam, a school physical, an employment physical, a diabetic screen, etc. The templates are defined using an XML syntax.
For example, templates can be coupled to a clinical guideline and bundle the data collected from the guideline into the clinical note. Static models describe the information structure of message documents that are defined according to the Clinical Document Architecture (CDA). The CDA will be discussed in the next lecture. The static models may be balloted.
Templates can also bundle data collection definitions based on the presence of specific data element values.
Templates specify the actual data elements at class or item levels. They can include any kind of data types, including media. Non-structural templates permit mathematical algorithms to generate new data items incorporated into the template.
Other examples of template uses include:
Document Templates (of which CDA is one example)
Atomic Concept Definition Templates
CEN Archetypes
Aggregate Measures Templates are compound data elements
Computed Measures Templates are complex data elements and
“Assembly” or “Sub-Assembly” Templates are structures within structures
Some of these examples will be discussed in later slides.

10. Types of Constraints
HL7 Templates constrain both structure and content
Structural constraints further restrict model elements such as cardinality, new class clones derived from balloted class clones, their attributes, relationships and HL7 data-types
Non-structural constraints include valid value set expressions and conditional constraints affecting more than one model element
Object Constraint Language may be used to define constraints on the model
HL7 Templates constrain both structure and content.
The structural constraints further restrict model elements such as cardinality, new class clones derived from balloted class clones, their attributes, relationships and HL7 data-types.
Non-structural constraints include valid value set expressions and conditional constraints affecting more than one model element.
Currently, non-structural constraints are to be expressed in Object Constraint Language (OCL).
OCL can specify most of the desirable constraints. OCL has few tools available to help correctly author constraints in a static model. Other approaches to constraining static models are being explored in various implementable technologies that have their own formal language.

11. Document Templates
Applied to the CDA schema to produce a desired level of information structure and content for a particular purpose
A particular type of document
Various templates structures may be use as document templates
As noted, templates may be incorporated into CDAs for specific applications or data exchanges based on specific triggers. We can define a CDA to be used for a primary care patient visit. Templates can be included into the CDA to provide flexibility in the visit-specific, event-specific, test-specific, or any other tailoring of the encounter data, but retain interoperability within a single structure.
Templates permit a CDA-based document to be tailored in a defined, constrained way to meet many data structure requirements. This approach is analogous to a paper form with mandatory and optional sections and described level of detail for each section. If sections can be coded, the specific coding scheme and any additional constraints are usually specified. Templates can define requirements in such a way that conformance can be determined.
Templates may reference other templates applied to specific sections or entries.

12. Atomic Concept Definition Templates
A template applied to part of a static model that specifies the structure and permitted coding to completely define a particular clinical concept
Atomic concept definition templates are designed to be reusable in many different contexts
The stereotypical example is Blood Pressure, composed of two numerical measures with optional additional information about patient positioning, cuff size, etc.
An atomic concept definition template is a template applied to part of a static model that specifies the structure and permits coding to completely define a particular clinical concept. Any constraints on coded elements or value ranges are specified. Optional relevant components that may add nuances in particular circumstances can be included.
Atomic Concept Definition Templates are designed to be reusable in many different contexts.
CEN defines Archetypes as atomic concept definitions formally approved by recognized clinical bodies.
The stereotypical example is Blood Pressure, composed of two numerical measures with optional additional information about patient positioning, cuff size, etc.

13. Computed Measures Templates
A template applied to an observation that has multiple components.
The constraints apply to the content and relationships of the components, but also describe the computational algorithm that derives a computed measure from the component measures
A computed measures template is applied to an observation that has multiple components.
The template describes the computational algorithm that creates the data element. It is, in effect, a complex data element.
The constraints apply to the content and relationships of the components, but also describe the computational algorithm that derives a computed measure from the component measures.
An Apgar score is one example and a Glasgow Coma score is another example.

14. How Are Templates Created?
Different approaches have been used
A static model derived from a balloted static model using the HL7 Design tools
Derive and then hand refine a static model schema
New tools that start with a balloted static model and add constraints
Schematron may be use to validate business rules
Rule-based validation language
How are templates created? Ideally, we would have a tool that would prompt for data elements and relationships and automatically create templates. Other required parts of the template would be prompted for. Such tools are currently being developed.
Building some templates is very similar to defining a schema.
Templates can be built manually. This approach relies on human judgment to ensure derived model validity.
You may use Schematron in templates to validate business rules. The Schematron is a rule-based validation language for making assertions about the presence or absence of patterns in XML trees. It is a structural schema language expressed in XML using a small number of elements and Xpath. Registries are being created to register templates for shared use and reusability.

15. Archetypes
Archetype denotes a model defining some domain concept, expressed using constraints on instance structures of an underlying reference model
Uses Archetype Description Language
Similar to XML
Easily redefined in XML
Archetypes are defined in the ISO/CEN standard, discussed in a previous unit. Archetype development is a major activity of the openEHR organization in Australia and is spreading in use globally. The openEHR archetypes use a syntax known as Archetype Development Language (ADL) rather than XML. Archetypes are a major part of the NHS applications in the UK.
Archetype denotes a model defining some domain concept, expressed using constraints on instance structures of an underlying reference model.
Archetypes enable users in a domain to formally express concepts. They enable information systems to guide and validate user input. They guarantee interoperability at knowledge level in addition to data structure level.
Archetypes provide a well-defined basis for efficient querying of complex data.
Archetypes are similar to HL7’s Templates.

16. Detailed Clinical Model
Combines knowledge, data specification, and terminology
Conceptual specification of the semantics of discrete structured clinical information
Defines data elements and attributes, including the possible values
Provides unambiguous detail that cross clinical; permits consistent use of medical data; is reusable
“Detailed Clinical Models (DCM) are descriptions of items of clinical information that include the clinical knowledge [about] the concept, the data specification, a model and, where possible, technical implementation specifications. A DCM is a conceptual specification of the semantics of discrete, structured clinical information. It provides the data elements and attributes, including the possible values and types of the attributes, needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and modelers. [DCM] provides unambiguous detail which is intended to be cross-domain and cross-discipline and standardized and reusable over domains, purposes, standards and implementations.” (HL7 International, Detailed Clinical Models)
DCM is now being harmonized across ISO and HL7.

17. DCM Template Examples Apgar Score Glasgow Coma Score Barthel Index
Pulse Rate
Blood Pressure
Respiration
Body Height
Body Temperature
Body Weight
This slide illustrates some of the DCMs that currently have been defined. DCMs are balloted and a repository is being set up to include normative DCMs. Details about these DCMs can be found on the HL7 web site. Examples include Apgar Score, Barthel Index, Blood Pressure, Body Height, Body Temperature, Body Weight, Glasgow Coma Score, Pulse Rate, and Respiration.

18. Clinical Information Modeling Initiative (CIMI)
Organized in 2011
International with participation from SDOs, vendors, providers, governments, and interested parties
Dedicated to providing a common format for detailed specifications for the representation of health information content
A new collaborative was started in 2011 with international participation from SDOs, vendors, providers, government organizations, consultants, and other interested parties.
It is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents.
CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO ) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.

19. Basic Health Data Standards Summary – Lecture e
Introduction to the concept and kinds of data structures
Types of data structures including complex and compound structures
Groups creating data structures include HL7 (CMETS, templates, clinical statements, CDAs), CEN, ISO, openEHR
This concludes Lecture e of Basic Health Data Standards.
This lecture provided a short look at data structures. Unfortunately there are multiple groups creating these structures, using different approaches. These groups include HL7, CEN, ISO and openEHR. Data structures may be compound or complex. The structures range from simple to complex.
Data structures provide another level of consistency, reusability, and data sharing.
This topic is important in terms of the power of building consistent and interoperable data structures. Of more importance is the ability to incorporate data and knowledge into work-flow objects. Structured objects play an important role in meaningful use. If the content is good, a mapping tool can bring harmony and receive benefit from both groups. Data structures provide another level of consistency, reusability, and data sharing.

20. Basic Health Data Standards References – Lecture e
Detailed Clinical Models. (n.d.). Retrieved from HL7 International website:
Acknowledgement: Material used in this lecture comes from the following sources
Health Level Seven International. (n.d.). Retrieved fromHealth Level Seven International website:
openEHR. (n.d.). Retrieved fromopenEHR website:
International Organization for Standardization. (n.d.). Retrieved fromISO website:
cen - European Committee for Standardization. (n.d.). Retrieved fromCEN website:
No audio.

21. Basic Health Data Standards Lecture e
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