HIE technical infrastructure

August 2015 Page: 1 of 97Hi3 Solutions ~ Your healthcare standards conformance Partner

Technical Infrastructure to Support Information Sharing

and Data Analysis

AbdulMalik ShakirPresident and Chief Informatics Scientist

Hi3 Solutions | your healthcare standards conformance partner

July 13, 2015 Page: 2 of 97Hi3 Solutions ~ Your healthcare standards conformance Partner

About Me• My information technology experience

spans more than four decades, including 35+ years in healthcare.

• I have contributed to the advancement of healthcare related standards since 1991 through volunteer participation in:

Health Level Seven (HL7), X12N Healthcare Task Group, OMG Healthcare Domain Task

Force, the Workgroup for Electronic Data

Interchange (WEDI), and the IEEE Joint Workgroup for a

Common Data Model.

• I served on the HL7 Board of Directors for three terms (a total of six years) and as co-chair of the HL7 Modeling and Methodology workgroup since 1994.

• I received the HL7 Fellowship award in 2012

AbdulMalik ShakirPresident and Chief Informatics

ScientistHi3 Solutions | your healthcare standards

conformance partner3500 West Olive Ave, Suite # 300, Burbank, CA 91505.


SESSION OVERVIEW

The focus of this skill building session is to present case stories of client experience with establishing or enhancing information exchange capabilities while at the same time developing a technical infrastructure to support clinical analytics.

The objectives of this skill building session is to raise awareness of the value of a technical architecture which considers information exchange standards, clinical terminologies, robust data structures, and effective business/clinical analytics.

This 90 minute presentation includes time for Q&A. The presentation will cover three main topics: 1. Conformance to applicable data exchange standards

2. Requirements for data cleansing, transformation , and integration capabilities

3. Data analytics support structures and information delivery applications


SEQUENCE OF TOPICS COVERED

• ELECTRONIC HEALTH INFORMATION EXCHANGE

• HEALTH INFORMATICS STANDARDS

• HEALTHCARE INFORMATION EXCHANGE FORMATS

• CONTROLLED CLINICAL TERMINOLOGY

• HEALTHCARE INFORMATION INTEGRATION INFRASTRUCTURE

• INFRASTRUCTURE TECHNOLOGIES


Electronic Health Information Exchange


Electronic Health Information Exchange

Pharmacies

Claims/Prescriptions

Testing OrganizationsLab/Images Government

Medicare/Medicaid

Orders

ResultsImages

HospitalsLab results

Patient Data

Medical Records

County/Community Entities

Mental Health

Family Planning

Medical Society

Public Health

Patients/Consumers

Employers

Health InformationInsurance Updates

Enrollment

Payors

Eligibility

Referral ProcessClaim Status

Physicians

Referral Process

Claim/Status

Eligibility


Health Information Exchange

Effective, meaningful health information exchange requires that all parties involved in

information exchange adhere to predetermined transaction formats, usage

constraints, and encoding rules.

Data

Technical Infrastructure


Healthcare Informatics Standards


Healthcare Informatics Standards Collaboration

Healthcare organizations have found it advantageous to collaborate in the pursuit of solutions to healthcare information management issues.

Healthcare provider, payor, vendor, consulting, and regulatory organizations have formed industry groups to study information management issues and develop standard solutions to their common problems.

These standards include standards for data interchange, clinical vocabularies, services, security, document architectures, and many others.


Healthcare Information

System

Clinical System

Images, pictures

Bedside Instruments

Billing, claimsreimbursement

Adverse Events Reporting

Immunization Database

MaterialsManagement

Agency Reporting

ProviderRepository

HL7

HL7

HL7, X12N

HL7, X12N

HL7

HL7

DICOM

IEEE MIB,ASTM

X12N / HL7 (Non-US only)

X12N

Waveforms

Retail Pharmacy Orders & Reimbursement NCPDP

Healthcare Data Interchange Standards


Leading U.S. Healthcare Data Interchange SDOs

IEEEInstitute of Electrical and

Electronic Engineers

NCPDPNational Council for

Prescription Drug Programs

X12NInsurance Subcommittee of

X12

ASTM

American Society for Testing and Materials

DICOM

Digital Imaging and Communications in Medicine

HL7

Health Level Seven


IEEE

Instrumentation communication standards and generalized

information interchange standards

NCPDP

Standards for communication of prescription, billing, and other

pharmacy material

X12N

Standards for exchange of healthcare insurance and billing

information

ASTM

Lab reporting standards and standard guide for content and structure of computer-based

patient records

DICOM

Standards for exchanging digital radiology images

HL7

Inter-application interoperability standards for healthcare

Leading U.S. Healthcare Data Interchange SDOs


HL7 and X12N HL7 and X12N are standards

development organizations accredited by the American National Standards Institute (ANSI).

Each organization adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest.

HL7 develops standards that enable disparate healthcare applications to exchange key sets of clinical and administrative data.

X12N develops specification that enable the electronic interchange of healthcare insurance and claims processing data.

HL7Clinical / Administrative

X12NInsurance / Billing


ASC X12 brings together business and industry professionals in a cross-industry forum to develop and support electronic data exchange standards and related documents for the national and international marketplace to enhance business processes, reduce costs and expand organizational reach


ASC X12 Organization


X12 HIPAA Transactions

Health Claims or Equivalent Encounter Information Standard Transaction Form:

X12-837 - Health Care Claim

Claims Payment and Remittance Advice Standard Transaction Form: X12-835 - Health

Care Claim Payment/Advice Standard

Healthcare Claims Status Standard Transaction Form: X12-276/277 - Health Care Claim Status

Request and Response

Coordination of Benefits Standard Transaction Form: X12-837 - Health Care Claim

Referral Certification and Authorization Standard Transaction Form: X12-278 - Health

Care Services Review - Request for Review and Response

Enrollment and Disenrollment in a Health Plan Standard Transaction Form: X12-834

Premium Payments Standard Transaction Form: X12-820

Eligibility for a Health Plan Standard Transaction Form: X12-270/271

First Report of Injury Standard Transaction Form: X12-148

Claims Attachments Standard Transaction Form: X12-275


Health Level Seven

Health Level Seven (HL7) is an American National Standards Institute (ANSI) Accredited Standards Developer.

The mission of HL7 is to provide standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among its stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients.


HL7 Board()

and Workgroup Committees Architectural Review Board• Arden Syntax• Attachments• CCOW• Clinical Decision Support• Clinical Genomics• Clinical Guidelines Clinical Research Outreach Committee • Community Based Health Services• Conformance• Control/Query Education• Electronic Health Records• Financial Management• Government Project• Imaging Integration Implementation International Affiliates• Java• Laboratory• Laboratory, Automated, and Testing

Marketing• Medical Records/Information Management• Medication• Modeling and Methodology• Orders/Observations Organization Review Committee• Patient Administration• Patient Care• Patient Safety• Pediatric Data Standards• Personnel Management Process Improvement Publishing• Regulated Clinical Research Information

Mgmt.• Scheduling and Logistics• Security and Accountability• Structured Documents Technical Steering Committee• Template• Vocabulary• XML


HL7 International Affiliates

April 08, 2009Informatics Standards & Interoperability

19 of 55

Canada

NewZealand

Finland Germany

Netherlands

Japan

United States

United Kingdom

India

Taiwan

China

Czech Republic

Mexico

France

Argentina

Brazil

Australia

Denmark Greece

Ireland

Italy

SpainSweden

Switzerland

SouthKorea

Turkey

Uruguay

Singapore

Romania

CroatiaAustriaColombiaChile

Puerto Rico

Russia

Pakistan

Bosnia and Herzegovina

http://www.theodora.com/maps/greece_map.html

http://www.hl7.org.pk/


An X12N Data Interchange Scenario

User InterfaceUser InterfaceProgram

Module

ProgramModuleDataset

Dataset

OutboundTransformation


InboundTransformation



Module


Dataset





B to ATransformation


A to BTransformation


Patient Billing Application

System

Claims Processing Application

System

Cl a

im

Tr a

nsa

c ti o

nPatient Billing

ApplicationSystem

Claims ProcessingApplication

System

Rem

itta

nce

T

ran

sact

ion



Module


Dataset






Module


Dataset









Order Entry Application

System

Laboratory Application

System

Lab

Ord

er

Tra

nsa

ctio

nOrder Entry Application

System


System

Lab

Res

ult

T

ran

sact

ion

An HL7 Data Interchange Scenario


Reaching the Limits of Application Interfaces

LabLab

Order EntryOrder Entry ADTADT

PharmacyPharmacy RadiologyRadiology

DecisionSupport

DecisionSupport

ElectronicHealth Record

ElectronicHealth Record

AdministrativeSystems

AdministrativeSystems

?

EnterpriseSystems

EnterpriseSystems

?ExternalSystems

ExternalSystems

?


HIE Standards: Why

• The number of interfaces between N systems is given by the formula (N2-N)/2.

• Linking 2 systems only needs 1 interface, (22 – 2) / 2 = 1

• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15

• The benefits of using standard increase rapidly with the number of systems involved.

• The use of standards and a hub-n-spoke infrastructure reduces the problem to linear progression

; (32 – 3) / 2 = 3; (42 – 4) / 2 = 6; (52 –5) / 2 = 10.


2 3 4 5 6 7 8 9 10 11 12 13 14 15

W/O HL7 1 3 6 10 15 21 28 36 45 55 66 78 91 105

With HL7 2 3 4 5 6 7 8 9 10 11 12 13 14 15

10

30

50

70

90

110

Interfaces Requirements

Parties Involved

Inte

rfa

ce

s

With STD

W/O STD

HIE Standards: Why

Tolerable Painful Intolerable



Module


Dataset






Module


Dataset









Order Entry Application

System


System

Lab

Ord

er

Tra

nsa

ctio

nOrder Entry Application

System


System

Lab

Res

ult

T

ran

sact

ion

An HL7 Data Interchange Scenario


Information Exchange Framework

Sending Application

Receiving Application

Information Package (i.e., Message)

Exchange ProtocolEncoding Rules Implementation Profile

[ ]


Healthcare Information Exchange Formats

Encoding Rules Implementation Profile

[ ]


HL7 Family of Standards• Fast Healthcare Interoperability Resources Specification (FHIR)

FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular components called “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative problems.

• Clinical Document ArchitectureThe HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchange.

• Electronic Health Record System Functional ModelThe HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functions for healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic reporting.

• Service Oriented ArchitectureThe Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup will explore the implications of emerging technologies (such as Cloud computing and advanced distributed systems) for health-related environments.

• Context Management Architecture Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Specification is a standard for both internal applications programming and runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts, CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources.

• HL7 Version 3 Product SuiteHealth Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includes standards for communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version 3 represents a new approach to clinical information exchange based on a model driven methodology that produces messages and electronic documents expressed in XML syntax.

• HL7 Version 2 Product SuiteHL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems.


HL7 Information Exchange of Standards Fast Healthcare Interoperability Resources Specification (FHIR)

FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular components called “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative problems.

Clinical Document ArchitectureThe HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchange.

• Electronic Health Record System Functional ModelThe HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functions for healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic reporting.

• Service Oriented ArchitectureThe Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup will explore the implications of emerging technologies (such as Cloud computing and advanced distributed systems) for health-related environments.

• Context Management Architecture Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Specification is a standard for both internal applications programming and runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts, CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources.

HL7 Version 3 Product SuiteHealth Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includes standards for communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version 3 represents a new approach to clinical information exchange based on a model driven methodology that produces messages and electronic documents expressed in XML syntax.

HL7 Version 2 Product SuiteHL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems.


HL7 v2 Standard

31

Human Readable Summary

Standard Data Content: MRN Name Gender Date of Birth Provider

Extension with reference to its definition

HL7 FHIR Standard


Normative R6 RIM Class DiagramVersion 2.44 11/22/2013


Sample HL7 V3 Message Schema <?xml version="1.0" encoding="UTF-8" standalone="no" ?> - <xs:schema xmlns:xs="http:/ / www.w3.org/ 2001/ XMLSchema" targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified" xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/ voc" xmlns:hl7="urn:hl7-org:v3" xmlns:msg="urn:hl7-org:v3/ mif" xmlns: fo="http:/ / www.w3.org/ 1999/ XSL/ Format"> <xs: include schemaLocation="../ dt/ datatypes.xsd" /> <xs: include schemaLocation="../ voc/ voc.xsd" /> - <xs:group name="PHIM_ MT000001"> - <xs:sequence> <xs:element name="OTCSaleEvent" type="PHIM_ MT000001.OTCSaleEvent" /> </xs:sequence> </xs:group> - <xs:complexType name="PHIM_ MT000001.OTCSaleEvent"> - <xs:sequence> <xs:element name="activityTime" minOccurs="1" maxOccurs="1" type="TS" /> <xs:element name="quantity" minOccurs="1" maxOccurs="1" type="PQ" /> <xs:element type="PHIM_ MT000001.Subject" minOccurs="1" maxOccurs="1" name="subject" /> <xs:element type="PHIM_ MT000001.PertinentInformation" minOccurs="1" maxOccurs="1" name="pertinentI nformation" /> </xs:sequence> <xs:attribute name="type" type="Classes" default="Supply" /> <xs:attribute name="classCode" type="ActClass" /> <xs:attribute name="moodCode" type="ActMood" /> </xs:complexType> - <xs:complexType name="PHIM_ MT000001.Subject"> - <xs:sequence> <xs:element type="PHIM_ MT000001.RetailedProduct" minOccurs="1" maxOccurs="1" name="retailedProduct" /> </xs:sequence> <xs:attribute name="type" type="Classes" default="Participation" /> <xs:attribute name="typeCode" type="ParticipationType" /> </xs:complexType> - <xs:complexType name="PHIM_ MT000001.RetailedProduct"> - <xs:sequence> <xs:element type="PHIM_ MT000001.ManufacturedMaterialKind" minOccurs="1" maxOccurs="1" name="retailedManufacturedMaterialKind" /> <xs:element type="PHIM_ MT000001.ReportingPharmacy" minOccurs="1" maxOccurs="1" name="retailerReportingPharmacy" /> </xs:sequence> <xs:attribute name="type" type="Classes" default="RoleHeir" /> <xs:attribute name="classCode" type="RoleClass" /> </xs:complexType>

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> - <xs:schema xmlns:xs="http:/ / www.w3.org/ 2001/ XMLSchema" targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified" xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/ voc" xmlns:hl7="urn:hl7-org:v3" xmlns:msg="urn:hl7-org:v3/ mif" xmlns: fo="http:/ / www.w3.org/ 1999/ XSL/ Format"> <xs: include schemaLocation="../ dt/ datatypes.xsd" /> <xs: include schemaLocation="../ voc/ voc.xsd" /> - <xs:group name="PHIM_ MT000001"> - <xs:sequence> <xs:element name="OTCSaleEvent" type="PHIM_ MT000001.OTCSaleEvent" /> </xs:sequence> </xs:group> - <xs:complexType name="PHIM_ MT000001.OTCSaleEvent"> - <xs:sequence> <xs:element name="activityTime" minOccurs="1" maxOccurs="1" type="TS" /> <xs:element name="quantity" minOccurs="1" maxOccurs="1" type="PQ" /> <xs:element type="PHIM_ MT000001.Subject" minOccurs="1" maxOccurs="1" name="subject" /> <xs:element type="PHIM_ MT000001.PertinentInformation" minOccurs="1" maxOccurs="1" name="pertinentI nformation" /> </xs:sequence> <xs:attribute name="type" type="Classes" default="Supply" /> <xs:attribute name="classCode" type="ActClass" /> <xs:attribute name="moodCode" type="ActMood" /> </xs:complexType> - <xs:complexType name="PHIM_ MT000001.Subject"> - <xs:sequence> <xs:element type="PHIM_ MT000001.RetailedProduct" minOccurs="1" maxOccurs="1" name="retailedProduct" /> </xs:sequence> <xs:attribute name="type" type="Classes" default="Participation" /> <xs:attribute name="typeCode" type="ParticipationType" /> </xs:complexType> - <xs:complexType name="PHIM_ MT000001.RetailedProduct"> - <xs:sequence> <xs:element type="PHIM_ MT000001.ManufacturedMaterialKind" minOccurs="1" maxOccurs="1" name="retailedManufacturedMaterialKind" /> <xs:element type="PHIM_ MT000001.ReportingPharmacy" minOccurs="1" maxOccurs="1" name="retailerReportingPharmacy" /> </xs:sequence> <xs:attribute name="type" type="Classes" default="RoleHeir" /> <xs:attribute name="classCode" type="RoleClass" /> </xs:complexType>


Sample HL7 V3 Message Instance

<?xml version="1.0" encoding="utf-8" standalone="no" ?> - <OTCSaleEvent xmlns="urn:hl7-org:v3"

xmlns:xsi="http:/ / www.w3.org/ 2002/ XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PHIM_ HD000001.xsd">

<activityTime value="20040109" /> <quantity value="5" unit="" /> - <subject> - <retailedProduct> - <retailedManufacturedMaterialKind> <code code="Cough/ Cold" /> </retailedManufacturedMaterialKind>

- <retailerReportingPharmacy> <quantity value="1" unit="" /> - <playedReportingPharamacyLocation> - <location> <id root="2.16.840.1.113883.19.3.2409" extension="88019" displayable="true" /> - <playedPartOfCounty> - <wholeCounty> <name>Some County</name> - <playedPartOfState> - <wholeState> <name>CA</name> </wholeState> </playedPartOfState> </wholeCounty> </playedPartOfCounty>

- <scopedParticipatingPharmacyLocation> - <locatedParticipatingPharmacy> <quantity value="1" unit="" /> </ locatedParticipatingPharmacy> </scopedParticipatingPharmacyLocation> </ location> </playedReportingPharamacyLocation> </retailerReportingPharmacy> </retailedProduct> </subject>

- <pertinentInformation> - <pertinentPromotion> <value value="false" /> </pertinentPromotion> </pertinentInformation> </OTCSaleEvent>

<?xml version="1.0" encoding="utf-8" standalone="no" ?> - <OTCSaleEvent xmlns="urn:hl7-org:v3"

xmlns:xsi="http:/ / www.w3.org/ 2002/ XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PHIM_ HD000001.xsd">

<activityTime value="20040109" /> <quantity value="5" unit="" /> - <subject> - <retailedProduct> - <retailedManufacturedMaterialKind> <code code="Cough/ Cold" /> </retailedManufacturedMaterialKind>

- <retailerReportingPharmacy> <quantity value="1" unit="" /> - <playedReportingPharamacyLocation> - <location> <id root="2.16.840.1.113883.19.3.2409" extension="88019" displayable="true" /> - <playedPartOfCounty> - <wholeCounty> <name>Some County</name> - <playedPartOfState> - <wholeState> <name>CA</name> </wholeState> </playedPartOfState> </wholeCounty> </playedPartOfCounty>

- <scopedParticipatingPharmacyLocation> - <locatedParticipatingPharmacy> <quantity value="1" unit="" /> </ locatedParticipatingPharmacy> </scopedParticipatingPharmacyLocation> </ location> </playedReportingPharamacyLocation> </retailerReportingPharmacy> </retailedProduct> </subject>

- <pertinentInformation> - <pertinentPromotion> <value value="false" /> </pertinentPromotion> </pertinentInformation> </OTCSaleEvent>


Clinical Document Architecture RMIM

Clinical Document

Participating Entities

Structured Document Sections

Section Entries and Sub-Entries


Templated CDA

Age Observation: templateId 2.16.840.1.113883.10.20.22.4.31 (open)

1. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6 STATIC) (CONF:7613).

2. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001 STATIC) (CONF:7614).

3. SHALL contain exactly one [1..1] templateId (CONF:7899) such that it SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.4.31"

(CONF:10487).

4. SHALL contain exactly one [1..1] code (CONF:7615). This code SHALL contain exactly one [1..1] @code="445518008" Age At Onset

(CodeSystem: SNOMED-CT 2.16.840.1.113883.6.96 STATIC) (CONF:16776).

5. SHALL contain exactly one [1..1] statusCode (CONF:15965). This statusCode SHALL contain exactly one [1..1] @code="completed"

Completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14 STATIC) (CONF:15966).

6. SHALL contain exactly one [1..1] value with @xsi:type="PQ" (CONF:7617). This value SHALL contain exactly one [1..1] @unit, which SHALL be selected from

ValueSet AgePQ_UCUM 2.16.840.1.113883.11.20.9.21 DYNAMIC (CONF:7618).


Template Constraint Statement

SHALL contain exactly one [1..1] statusCode (CONF:15965).

This statusCode SHALL contain exactly one [1..1] @code="completed" Completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14 STATIC) (CONF:15966).

Terminology Binding


Standards and Profiles Ecology


Partial list of CDA Implementation Guides (by country)

USA

CCD (Continuity of Care Document) Rel.1

CRS (Care Record Summary)

SPL – Structured Product Label

HAI (Healthcare associated infections)

HITSP C32 –Summary Documents Using HL7 Continuity of Care Document

(CCD)

C37 – Lab Report

C48 –Encounter Document Using IHE Medical Summary (XDS-MS) Component

Consultation Notes

History and Physical

Operative Notes

Imaging Integration, Basic Imaging Reports

Canada

e-MS (electronic Medical Summary)

Germany

VHitG-Arztbrief v1.50 (discharge summary)

Addendum Laboratory

Addendum Medication

Addendum notifiable diseases (in progress)

DRV Reha-Enlassbrief

Reha-Kurzarztbrief

Nursing Summary (ePflegebericht)

South Korea CDA conference 2004

Austria ELGA (currently in progress)

Switzerland CDA-CH v1.1

France French CRS CDA Body implementation Guide (in

French)

Finland seamless Care and CDA Finnish (CDA) implementation guides: CDA R2,

V3, Medical Records, V2, CDA R (in Finnish)

Japan Japanese Clinical Summary document (in

Japanese)


Controlled Clinical Terminologies


Controlled Clinical Terminologies

In addition to standards for data interchange, it is essential to employ a common set of clinical terminology and ontology systems.

Clinical problems and diagnoses are usually coded with International Classification of Diseases Coding Systems (ICD-9 or ICD-10)

Medical procedures are commonly designated using Current Procedural Terminology Codes (CPT).

Clinical observations procedures and observation result values are encoded using a variety of standard, proprietary, and locally defined code. LOINC and SNOMED are widely utilized clinical coding schemes.


www.regenstrief.org/loinc [GO]

LOINC

http://www.regenstrief.org/loinc


SNOMED


HL7 Common Terminology Services Project Scope Establish a common model for terminology, and how it is

related to meta-data (models of data) and data (the information itself)

Specify both an information and functional model that addresses the relationships and use of terminology in data – how data elements are constrained to ranges of possible codes, how selection lists built and queried, how terminological information is validated.

Specify the interactions between terminology providers and consumers – how users can submit unambiguous requests for corrections and extensions and how revisions to content are identified, distributed and integrated into running systems.

Specify how mapping between compatible terminologies and data models is defined, exchanged and revised.

Specify how logic-based terminologies can be queried about subsumption, classification and inferred relationships.


Semantic Interoperability Infrastructure

“…Behold, they are one people, and they have all one language; and this is only the beginning of what they will do;

and nothing that they propose to do will now be impossible for them.” ~ Genesis 11:6



Metadata Terminology Ontology

Metadata Services

Terminology Services

Ontology Services

Semantics: P11179Structure: SQL

Semantics: CTSStructure: SQL

Semantics: DLStructure: OWL

Information Models

Controlled Terminologies

Bio-Medical Ontologies

Binding

Binding

Rules

Rule Services

Semantics: RuleMLStructure: XML

TransformationRules

Binding

Semantic Infrastructure


Metadata

Metadata

Metadata Services

Semantics: P11179Structure: SQL

Information Models

Binding

The metadata repository contains a representation of the concepts depicted in information models of interest to the domain.

It includes descriptions of classes, class relationships, class attributes, attribute datatypes, and attribute terminology bindings.

Information models of interest include domain information models, legacy databases, and service information exchange payloads.

The metadata repository contains equivalence mappings between the constituent elements of information models.

The semantics of the metadata repository are based upon the ISO P11179 standard.

The metadata repository is constructed as a relational database.


Terminology

Terminology

Terminology Services

Semantics: CTSStructure: SQL

Controlled Terminologies

Binding

Binding

The terminology repository maintains the code system terms which comprise the values sets bound to attributes in information models.

It includes code systems, code system terms, code system term relationships, value sets, and value set members.

Code systems of particular interest include SNOMED CT, MedDRA, LOINC and other clinical code systems maintained in the NCI Metathesaurus.

The terminology repository includes equivalence relationships between code system terms from independent code systems.

The semantics of the terminology repository structure are based upon the HL7 Controlled Terminology Services specification.

The terminology repository is constructed as a relational database.


Ontology

Ontology

Ontology Services

Semantics: DLStructure: OWL

Bio-Medical Ontologies

Binding

Binding

The ontology repository contains semantic webs of clinical concepts specified in or derived from concepts depicted in information models and associated terminologies.

Ontologies describe individuals (instances), classes (concepts), attributes, and relations

Many of the ontologies of interest can be obtained from the National Center for Biomedical Ontologies (NCBO)

The ontology repository includes semantic links between terms in the terminology repository that go beyond taxonomic hierarchic, and subsumption relationships

The semantics of the ontology repository are base upon description logic.

The ontology repository is constructed as a collection of OWL-DL expressions.


Rules

Rules

Rule Services

Semantics: RuleMLStructure: XML

TransformationRules

Binding

The rules repository maintains the rules used to specify queries, inferences, derivation, semantic mappings, and dynamic behaviors of workflows and services.

Rules include IF..Then..Else constructs using terms defined in the metadata, terminology, and ontology repositories

The semantics of the rules repository are based upon Rule Markup Language (RuleML), permitting both forward and backward rules in XML for deduction, rewriting, and further inferential-transformational tasks.

The structure of the rules repository is XML. A rule engine will be used to house, interpret,

and enforce rules


Healthcare Information Integration Infrastructure


Health Information Exchange

Interface Engines and Enterprise Service Bus


Standards Compliance and Conformance

Syntax Conformance


Semantics Compliance and Conformance

Semantic Harmonization


Health Information Standards Compliance


Messaging Data Persistence

Data Warehousing


HL7 RIM Based Integrated Data Repository

EnterpriseData

Model


Health Information Transformation and Integration


Data Warehousing and Business Intelligence

Conformant Dimensional Data marts


Healthcare Quality and Performance Monitoring


California Department of Health Services

Electronic Laboratory Reporting Project


CA ELR Project Use Cases

UC01: Report Laboratory Result UC02: Reroute Misdirected

Laboratory Result

UC03: Persist Laboratory Result Message Content

UC04: Laboratory Result Business Intellegence /

Analytics

Reporting Laboratory

Receiv ing Public Health Agency

Accountable Public Health Agency

ELR HUB

ELR Repository

Business Analysts and Statisticians


Canonical Message Profile

Message Profile Message Profile Message Profile

MSHEVNPID [PD1][ { NK1 } ]

MSHEVNPID[ NK1 ]OBX

MSHEVN{ PID } [PD1][ { GT1 } ]

MSHEVN{ PID } [PD1][ { NK1 } ][ { GT1 } ][ OBX ]


Lab MessageSupplier

InboundLaboratoryMessage

InboundMessage Profile

Transform

Translate

InboundMessage Mapping

CanonicalLaboratoryMessage

CanonicalMessage Profile

Transform

Translate

OutboundMessage Mapping

OutboundLaboratoryMessage

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service

Object GraphGeneration

LaboratoryMessageObjects

ObjectRelationalMapping

LaboratoryMessage

Respository

Object RelationalMap

ELR DatabaseDesign Model

CA Public HealthLogical Data

Model

HL7 RIM &CDC PHLDM


LaboratoryMessage Object

Model

Extract,Transform,and Load

LaboratoryDatamart

BusinessIntelligenceApplication



OutboundMessage Profile


Additional DataSources


Inbound Message Processing Outbound Message Processing

Data Persistence

Business Intelligence

Lab MessageSupplier

InboundLaboratoryMessage

InboundMessage Profile

Transform

Translate

InboundMessage Mapping

CanonicalLaboratoryMessage


Transform

Translate

OutboundMessage Mapping

OutboundLaboratoryMessage

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service

Object GraphGeneration

LaboratoryMessageObjects

ObjectRelationalMapping

LaboratoryMessage

Respository

Object RelationalMap

ELR DatabaseDesign Model

CA Public HealthLogical Data

Model

HL7 RIM &CDC PHLDM


LaboratoryMessage Object

Model


LaboratoryDatamart




OutboundMessage Profile


Additional DataSources


Infrastructure Technologies


Conformance Profile Authoring Tools

Message Workbench (MWB)

Model Driven Health Tools (MDHT)

ART-DECOR

Trifolia Workbench

MS Word


Messaging Workbench


The Messaging Workbench (MWB)

For those who: Design HL7 2.x messages

Manage specification repositories

Collaborate on varied messaging projects within and outside of their organizations

Free of charge from HL7 Web site (www.hl7.org)

Current version supports up to HL7 v2.6

NIST is working on the future plans

First level support provided by Mayo Clinic volunteer

http://www.hl7.org/


Model Driven Health Tools (MDHT) is an open source framework that enables community authoring.


What is ART-DECOR?

DECOR (Data Elements, Codes, OIDs and Rules) is a methodology to record the information model used by health professionals.

DECOR uses this model to generate various artifacts: documentation, XML- and test-tooling, etc.

With DECOR it is possible to improve the recorded information model by generating and resolving issues per item.

DECOR registers (amongst others) datasets, datatypes, valuesets, codes, identifications, and business rules.

The underlying data-format is XML. Generation of HTML-documentation and XML-materials is possible through transformations with stylesheets.

DECOR consists of two parts: DECOR methodology: a framework to model artifacts (including documentation) DECOR software: XML-schemas, XML-schematrons, XML-stylesheets.

ART (Advanced Requirement Tooling) is the DECOR user interface to create and adapt DECOR files, and to generate artifacts from DECOR files.

ART is based on the eXist-db XML database, XQuery and Orbeon XForms.


Trifolia Workbench


Instance Validation Technologies

HL7 v2 Schema Specification

MWB Profile Validation

CDA Schema Specification

MDHT Generated Java Objects

Trifolia Generated Schematron Logic


Instance Validation Services

NIST HL7 v2 and v3 CDA Validation

SMART C-CDA Collaborative

CDC PHIN Message Quality Framework

Lantana Consulting Group CDA Validator

IHE Gazelle HL7 Validator


NIST Standards and Testing


NIST CDA Guideline Validation


SMART C-CDA Collaborative


CDC PHIN MQF


Lantana Consulting Group CDA Validator


IHE Gazelle HL7 Validator


Instance Validation Commercial Products

Middleware Vendor Products

Interface Engine Product Adapters

Hi3 Solutions Product Suite


Middleware Vendor Products


Interface Engine Adapters Interface engine adapters take advantage of

public APIs made available by leading interface engine vendors.

Interface engine adapters are typically product specific and provide capabilities not otherwise available in the base product.

The CDC’s PHIN Messaging System takes advantage of the APIs provided by Orion Health Rhapsody.

Caristix has developed adapters that facilitate the reverse engineering of message instances into HL7 message profiles that are compatible with many of the leading interface engines APIs.


PHIN Messaging System


Caristix HL7 Message Profiler



Solutions


Health Information Standards Compliance

Hi3 Solutions’ STANDARDS CONFORMANCE VALIDATOR™ (SCV) is a comprehensive suite of application

services that validates compliance with healthcare information exchange standard specifications and

conformance with related implementation guides and profiles.


Health Information Integration

Hi3 Solutions’ HEALTH INFORMATION INTEGRATOR™ (HII) is a comprehensive suite of application and database

services that facilitate the transformation of data structures, translation of clinical terminologies, and integration of

health information.

Health Information Integration

Health Information Transformation

InboundInformationProcessing


OutboundInformationProcessing

OutboundInformationProcessing

SourceInformation System

SourceInformation System Receiving

Information SystemReceiving

Information System

Information Transformation

Services


Services

Integrated Data Repository

HL7 ReferenceInformation Model


Healthcare Quality and Performance Measurement

Hi3 Solutions’ HEALTHCARE QUALITY MONITOR™ (HQM) is a comprehensive suite of data warehousing and business intelligence solutions geared specifically toward monitoring quality and performance in healthcare in accordance with

established measurement standards.

Healthcare Quality and Performance Monitoring






Services


Services

Analysis, Visualization,and Reporting

Analysis, Visualization,and Reporting

Integrated Data Repository

Business Intelligence& Decision

Support Services

HL7 ReferenceInformation Model


Hi3 Solutions 3500 W. Olive Ave, Suite

300Burbank, CA 91505

ww.hi3solutions.com +1 800 918-6520

Healthcare Information Integration Infrastructure Solutions (Hi3 Solutions), is a privately owned, Health Information Technology vendor, headquartered

in Burbank, California.

Hi3 Solutions, along with its affiliates, provides assistance to public health, healthcare, and health research organizations attempting to utilize

informatics standards to overcome barriers to interoperability.

The mission of Hi3 Solutions is to assist healthcare organizations with leveraging their information assets to discover and prosper from evidence-

based best practices in healthcare through proven information management methods, standards, and techniques.


Thank You!

Peace...AMS

Abdul-Malik ShakirPresident and Chief Informatics Scientist

Hi3 Solutions 3500 West Olive Ave, Suite # 300, Burbank, CA 91505

Skype: +1 9098334661 Mobile: (626) 644-4491Email: [email protected]

HIE technical infrastructure

Technology

Transcript of HIE technical infrastructure