Networking and Health Information Exchange: Basic Health Data Standards

Audio Transcript

Slide 1
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 thats 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.

Slide 2
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

This lecture, lecture e, focuses on building data structures

Slide 3
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,

Health IT Workforce Curriculum Networking and Health Information Exchange 1

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
 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,

Slide 4
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.

Slide 5
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.

Slide 6
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,

Health IT Workforce Curriculum Networking and Health Information Exchange 2

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
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.

Slide 7
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.

Slide 8
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, e-mail 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.

Health IT Workforce Curriculum Networking and Health Information Exchange 3

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
Slide 9
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.

Slide 10
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

Health IT Workforce Curriculum Networking and Health Information Exchange 4

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
models are being explored in various implementable technologies that have their own
formal language.

Slide 11
As noted, templates may be incorporated into CDAs and permit a generic CDA to be
used 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 generic CDA 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.

Slide 12
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.

Slide 13
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.

Health IT Workforce Curriculum Networking and Health Information Exchange 5

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
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.

Slide 14
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.

Slide 15
Archetypes are defined in the ISO/CEN 13606 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 HL7s Templates.

Health IT Workforce Curriculum Networking and Health Information Exchange 6

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
Slide 16
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.

Slide 17
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.

Slide 18
A new collaborative was started in 2011with 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 13606.2) 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.

Slide 19
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

Health IT Workforce Curriculum Networking and Health Information Exchange 7

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.
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.

Slide 20
No audio.

End

Health IT Workforce Curriculum Networking and Health Information Exchange 8

Version 3.0/Spring 2012 Basic Health Data Standards
Lecture e
This material Comp9_Unit4e 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 IU24OC000024.