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 Shakir
President 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 Shakir
Hi3 Solutions | your healthcare standards conformance partner
3500 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 Organizations
Lab/Images Government
Medicare/Medicaid
Orders
Results
Images
Hospitals
Lab results
Patient Data
Medical Records
County/Community
Entities
Mental Health
Family Planning
Medical Society
Public Health
Patients/Consumers
Employers
Health Information
Insurance Updates
Enrollment
Payors
Eligibility
Referral Process
Claim 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
HL7
HL7
HL7, X12N
HL7, X12N
HL7
HL7
DICOM
IEEE MIB,
ASTM
X12N / HL7 (Non-US only)
X12N
NCPDP
Healthcare Data Interchange Standards

Leading U.S. Healthcare Data Interchange SDOs
IEEE
Institute of Electrical and Electronic
Engineers
NCPDP
National Council for Prescription
Drug Programs
X12N
Insurance 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.
HL7
Clinical / Administrative
X12N
Insurance / 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 & Interoperability19 of 55
Canada
New
Zealand
Finland Germany
Netherlands
Japan
United States
United
Kingdom
India
Taiwan
China
Czech Republic
Mexico
France
Argentina
Brazil
Australia
Denmark Greece
Ireland
Italy
Spain
Sweden
Switzerland
South
Korea
Turkey
Uruguay
Singapore
Romania
CroatiaAustriaColombia
Chile
Puerto Rico
Russia
Pakistan
Bosnia and
Herzegovina

An X12N Data Interchange Scenario
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
B to A
Transformation
A to B
Transformation
Patient Billing
Application
System
Claims Processing
Application
System
Patient Billing
Application
System
Claims Processing
Application
System

User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
B to A
Transformation
A to B
Transformation
Order Entry
Application
System
Laboratory
Application
System
Order Entry
Application
System
Laboratory
Application
System
An HL7 Data Interchange Scenario

Reaching the Limits of Application
Interfaces
Lab
Order Entry ADT
Pharmacy
Radiology
Decision
Support
Electronic
Health Record
Administrative
Systems
?
Enterprise
Systems
?
External
Systems
?

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
0
20
40
60
80
100
120
Interfaces
Parties Involved
Interfaces Requirements
With STD
W/O STD
HIE Standards: Why
Tolerable Painful Intolerable

User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
User Interface
Program
Module
Dataset
Outbound
Transformation
Inbound
Transformation
B to A
Transformation
A to B
Transformation
Order Entry
Application
System
Laboratory
Application
System
Order Entry
Application
System
Laboratory
Application
System
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® productlines while leveraging the
latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular componentscalled “Resources”. These
resources can be easily assembled into working systems that solve real world clinical and administrative problems.
• Clinical Document Architecture
The 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 Model
The 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 functionsfor healthcare settings. HL7
has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health andvital statistic reporting.
• Service Oriented Architecture
The 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 Suite
Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includesstandards for
communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version3 represents a new
approach to clinical information exchange based on a model driven methodology that produces messages and electronic documentsexpressed in XML
syntax.
• HL7 Version 2 Product Suite
HL7’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® productlines while leveraging the
latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular componentscalled “Resources”. These
resources can be easily assembled into working systems that solve real world clinical and administrative problems.
 Clinical Document Architecture
The 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 Model
The 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 functionsfor healthcare settings. HL7
has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health andvital statistic reporting.
• Service Oriented Architecture
The 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 Suite
Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includesstandards for
communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version3 represents a new
approach to clinical information exchange based on a model driven methodology that produces messages and electronic documentsexpressed in XML
syntax.
 HL7 Version 2 Product Suite
HL7’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 Diagram
Version 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="pertinentInformation" />
</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" />

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>
- <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>
</locatedParticipatingPharmacy>
</scopedParticipatingPharmacyLocation>
</location>
</playedReportingPharamacyLocation>
</retailerReportingPharmacy>
</retailedProduct>
</subject>
- <pertinentInformation>
- <pertinentPromotion>
<value value="false" />
</pertinentPromotion>

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

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: P11179
Structure: SQL
Semantics: CTS
Structure: SQL
Semantics: DL
Structure: OWL
Information
Models
Controlled
Terminologies
Bio-Medical
Ontologies
Binding
Binding
Rules
Rule
Services
Semantics: RuleML
Structure: XML
Transformation
Rules
Binding
Semantic Infrastructure

Metadata
Metadata
Metadata
Services
Semantics: P11179
Structure: 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: CTS
Structure: 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: DL
Structure: 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: RuleML
Structure: XML
Transformation
Rules
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
Enterprise
Data
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
Receiving Public Health
Agency
Accountable Public Health
Agency
ELR HUB
ELR Repository
Business Analysts
and Statisticians

Canonical Message Profile
Message Profile Message Profile Message Profile
MSH
EVN
PID
[PD1]
[ { NK1 } ]
MSH
EVN
PID
[ NK1 ]
OBX
MSH
EVN
{ PID }
[PD1]
[ { GT1 } ]
MSH
EVN
{ PID }
[PD1]
[ { NK1 } ]
[ { GT1 } ]
[ OBX ]

Lab Message
Supplier
Inbound
Laboratory
Message
Inbound
Message Profile
Transform
Translate
Inbound
Message Mapping
Canonical
Laboratory
Message
Canonical
Message Profile
Transform
Translate
Outbound
Message Mapping
Outbound
Laboratory
Message
Lab Message
Consumer
Knowledge
Management
Service
Knowledge
Management
Service
Object Graph
Generation
Laboratory
Message
Objects
Object
Relational
Mapping
Laboratory
Message
Respository
Object Relational
Map
ELR Database
Design Model
CA Public Health
Logical Data
Model
HL7 RIM &
CDC PHLDM
Canonical
Message Profile
Laboratory
Message Object
Model
Extract,
Transform,
and Load
Laboratory
Datamart
Business
Intelligence
Application
Business
Intelligence
Application
Business
Intelligence
Application
Outbound
Message Profile
Extract,
Transform,
and Load
Additional Data
Sources

Inbound Message Processing Outbound Message Processing
Data Persistence
Business Intelligence
Lab Message
Supplier
Inbound
Laboratory
Message
Inbound
Message Profile
Transform
Translate
Inbound
Message Mapping
Canonical
Laboratory
Message
Canonical
Message Profile
Transform
Translate
Outbound
Message Mapping
Outbound
Laboratory
Message
Lab Message
Consumer
Knowledge
Management
Service
Knowledge
Management
Service
Object Graph
Generation
Laboratory
Message
Objects
Object
Relational
Mapping
Laboratory
Message
Respository
Object Relational
Map
ELR Database
Design Model
CA Public Health
Logical Data
Model
HL7 RIM &
CDC PHLDM
Canonical
Message Profile
Laboratory
Message Object
Model
Extract,
Transform,
and Load
Laboratory
Datamart
Business
Intelligence
Application
Business
Intelligence
Application
Business
Intelligence
Application
Outbound
Message Profile
Extract,
Transform,
and Load
Additional Data
Sources

Healthcare
Information Integration Infrastructure

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

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

Hi3 Solutions Product Suite

Healthcare
Information Integration Infrastructure
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
Inbound
Information
Processing
Inbound
Information
Processing
Outbound
Information
Processing
Outbound
Information
Processing
Source
Information System
Source
Information System
Receiving
Information System
Receiving
Information System
Information
Transformation
Services
Information
Transformation
Services
Integrated Data
Repository
HL7 Reference
Information 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
Inbound
Information
Processing
Inbound
Information
Processing
Source
Information System
Source
Information System
Information
Transformation
Services
Information
Transformation
Services
Analysis,
Visualization,
and Reporting
Analysis,
Visualization,
and Reporting
Integrated Data
Repository
Business Intelligence
& Decision
Support Services
HL7 Reference
Information Model

Hi3 Solutions Product Suite

Hi3 Solutions
3500 W. Olive Ave, Suite
300
Burbank, 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 Shakir
Hi3 Solutions
3500 West Olive Ave, Suite # 300, Burbank, CA 91505
Skype: +1 9098334661  Mobile: (626) 644-4491
Email: abdulmalik.shakir@hi3Solutions.com

HIE technical infrastructure

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à HIE technical infrastructure

Similaire à HIE technical infrastructure (20)

Plus de Abdul-Malik Shakir

Plus de Abdul-Malik Shakir (16)

Dernier

Dernier (20)

HIE technical infrastructure