Networking and Health Information Exchange

Slides:



Advertisements
Similar presentations
Archetypes in HL7 v2 Andrew McIntyre Medical-Objects HL7 International May 2009.
Advertisements

HL7 Templates A means to Manage Complexity. Objectives What is an HL7 Template? What types of constraints can HL7 Templates define? What types of HL7.
Health IT Workforce Curriculum Version 1.0 Fall Networking and Health Information Exchange Unit 4e Basic Health Data Standards Component 9/Unit.
Catherine Hoang Ioana Singureanu Greg Staudenmaier Detailed Clinical Models for Medical Device Domain Analysis Model 1.
CIMI Modelling Taskforce Progress Report
Introduction to openEHR
SRDC Ltd. 1. Problem  Solutions  Various standardization efforts ◦ Document models addressing a broad range of requirements vs Industry Specific Document.
NHS Modelling Efforts – ISO13606 adoption and beyond Dr. Rahil Qamar Siddiqui Health and Social Care Information Centre, NHS, England.
Object-Oriented Analysis and Design
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
FHIM Overview How the FHIM can organize other information modeling efforts.
Terminology in Health Care and Public Health Settings
Unit 11C: Data Quality Attributes Data Quality Improvement This material was developed by Johns Hopkins University, funded by the Department of Health.
Introduction to MDA (Model Driven Architecture) CYT.
CountryData Technologies for Data Exchange SDMX Information Model: An Introduction.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Networking and Health Information Exchange Unit 6b EHR Functional Model Standards.
Clinical Document Architecture. Outline History Introduction Levels Level One Structures.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Networking and Health Information Exchange Unit 5b Health Data Interchange Standards.
EuroRec Annual Conference 2006 EHR systems and certification Archetypes: the missing link? Dr Dipak Kalra Centre for Health Informatics and Multiprofessional.
Health IT Workforce Curriculum Version 1.0 Fall Networking and Health Information Exchange Unit 3b National and International Standards Developing.
Component 3-Terminology in Healthcare and Public Health Settings Unit 17-Clinical Vocabularies This material was developed by The University of Alabama.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Health Level 7- Templates SIG By Peter Elkin, Mayo Clinic Martin Kernberg, UCSF Angelo Rossi-Mori, Italy.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Networking and Health Information Exchange Unit 6a EHR Functional Model Standards.
Commentary: The HL7 Reference Information Model as the Basis for Interoperability George W. Beeler, Jr. Ph.D. Co-Chair, HL7 Modeling & Methodology.
Approach to building ontologies A high-level view Chris Wroe.
SNOMED CT Vendor Introduction 27 th October :30 (CET) Implementation Special Interest Group Tom Seabury IHTSDO.
CDA Overview HL7 CDA IHE Meeting, February 5, 2002 Slides from Liora Alschuler, alschuler.spinosa Co-chair HL7.
CCD and CCR Executive Summary Jacob Reider, MD Medical Director, Allscripts.
Informatics for Scientific Data Bio-informatics and Medical Informatics Week 9 Lecture notes INF 380E: Perspectives on Information.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
Database Principles: Fundamentals of Design, Implementation, and Management Chapter 1 The Database Approach.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
Databases and Database User ch1 Define Database? A database is a collection of related data.1 By data, we mean known facts that can be recorded and that.
COP Introduction to Database Structures
- The most common types of data models.
Chris K. Kim, MS Information Systems Manager
eHealth Standards and Profiles in Action for Europe and Beyond
UNIFIED MEDICAL LANGUAGE SYSTEMS (UMLS)
Networking and Health Information Exchange
Business System Development
Implementing the Surface Transportation Domain
Networking and Health Information Exchange
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
OASIS Quantities and Units of Measure Ontology Standard (QUOMOS) An Introduction v Rev. D / April
WP1: D 1.3 Standards Framework Status June 25, 2015
Models & Modelling Heather Leslie Sebastian Guard Heather Grain
Unit 5 Systems Integration and Interoperability
Abstract descriptions of systems whose requirements are being analysed
Networking and Health Information Exchange
Chapter 2 Database Environment.
Electronic Health Information Systems
Terminology and HL7 Dr Colin Price
an alliance among HL7, CEN and OpenEHR ?
Lec 3: Object-Oriented Data Modeling
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Modelling Clinical Information Using UML
2. An overview of SDMX (What is SDMX? Part I)
2. An overview of SDMX (What is SDMX? Part I)
SDMX Information Model: An Introduction
HingX Project Overview
, editor October 8, 2011 DRAFT-D
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Lecture 10 Structuring System Requirements: Conceptual Data Modeling
Presentation transcript:

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 IU24OC000024. 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 http://creativecommons.org/licenses/by-nc-sa/4.0/

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,

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,

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.

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.

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.

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.

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

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.

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.  

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.  

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.

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.

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.

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 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 HL7’s Templates.  

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.

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.

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

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.

Basic Health Data Standards References – Lecture e Detailed Clinical Models. (n.d.). Retrieved from HL7 International website: http://wiki.hl7.org/index.php?title=Detailed_Clinical_Models Acknowledgement: Material used in this lecture comes from the following sources Health Level Seven International. (n.d.). Retrieved fromHealth Level Seven International website: www.hl7.org openEHR. (n.d.). Retrieved fromopenEHR website: www.openehr.org International Organization for Standardization. (n.d.). Retrieved fromISO website: www.iso.org/iso/iso_technical_committee?commid=54960 cen - European Committee for Standardization. (n.d.). Retrieved fromCEN website: www.cen.eu/cen/Sectors/TechnicalCommitteesWorkshops/CENTechnicalCommittees/Pages/default.aspx?param=6232&title=CEN/TC%20251 No audio.

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 IU24OC000024. This material was updated by Normandale Community College, funded under Award Number 90WT0003. No audio Health IT Workforce Curriculum Version 4.0