1. HIE Technical Informational
Overview

2. HIE Technical Informational
Overview
March, 2011
2
©2011 HIMSS

3. Agenda
• HIE/HIO Definitions
• HIE Technical Models
• HIE Commonly Offered Services
• HIE Technical Components
Primary Source for this Presentation:
HIMSS Guide to Participating in an HIE
http://www.himss.org/ASP/topics_FocusDynamic.asp?faid=148
3
©2011 HIMSS

4. Definitions
Health Information Exchange (HIE)
• The electronic movement of health-related information among disparate
organizations according to nationally recognized standards in an
authorized and secure manner.
Health Information Organization (HIO)
• An organization that oversees and governs the exchange activities of
health-related information among independent stakeholders and
disparate organizations according to nationally recognized standards in
an authorized and secure manner. The primary purpose is to facilitate
exchange of relevant health information supporting patient care
coordination, quality patient care outcomes and demonstration of
meaningful use.
• An HIO can be described by many acronyms, including state level
health information exchange (SLHIE), a Regional Health Information
Exchange (RHIO), and Regional Health Information Network (RHIN).
4
©2011 HIMSS

5. HIE Technical Models
5
©2011 HIMSS

6. Common HIE Technical Models
• Centralized
• Decentralized (Federated)
• Hybrid
6
©2011 HIMSS

7. Common HIE Technical Models
Centralized A centralized architecture model requires organizations
to send patient demographic and clinical health
information to a shared repository. This centralized
repository is always queried to obtain a patient’s health
information and other indices and usually acts as the
authoritative source of the requested data.
Federated A federated architecture model provides organizational
control of the health information and provides the
framework for data-sharing capability to organizations
widely distributed across regions. This model allows the
data source organizations to manage and store the
patient health information and indices. When requested,
data is queried from the data source organization and not
stored centrally.
Hybrid A hybrid architecture model uses a system where some
health information and data is physically stored and
managed in a central location and other data is stored
and managed by data source organizations with a
common framework for data-sharing capability. When
requested, data is queried from either the central
repository or the source organizations depending on use
cases.
©2011 HIMSS

8. Centralized Model
8
©2011 HIMSS

9. Centralized Model
Overview
A typical centralized architecture is implemented as a logical, single database that
aggregates identified data from multiple sources in one location. All data exists in a
single warehouse. Participants send their data to a central repository.
Benefits/Advantages
• The querying system’s response to a data request can be quicker than other
models
• Data is centrally managed, maintained and consolidated
- Requires cohesive, defined methods, policies and procedures
- Provides uniform data format with high degree of data interoperability
• Less real-time dependence on external participating systems
• Facilitates community-wide data analysis
• Economies of scale can be achieved through use of centralized resources as long
as appropriate investments are made
- Centralized leverage of expertise/resources
9
©2011 HIMSS

10. Centralized Model
Limitations/Challenges
• Strong central coordination required:
-Requires strong technology oversight and data management control
-Requires strong political and governance oversight
• Dependent on large central database for inter-system queries
• Data submissions from participating systems may lag, resulting in
inaccurate consolidated records at query time
• From a technology perspective, requires a heavy investment in a single
vendor and system integrator to build a logical central repository that
makes it functional for all stakeholder organizations
• More challenging and complex implementations – especially with
incremental implementation.
- Large, up-front investment in central resources is required.
- Requires the most planning, coordination and development to be
successful
• Fairly expensive option to implement, not only technically but
organizationally.
10
©2011 HIMSS

11. Centralized Model
Limitations/Challenges
• Requires significant effort to minimize duplicate records (demographic and
clinical)
• Data matching efforts:
- Requires accurate patient data matching between the local systems and
the central repository or other systems
- In the absence of shared identifiers, other algorithms or strategies must
be employed:
o Efforts require to ensure data is linked to the correct person
o If the patient is new to the centralized system, there can be
significant burden to match records on the repository side
• Requires resolution of database congruency issues where data collection
standards, messaging formats and field naming conventions are
inconsistent.
11
©2011 HIMSS

12. Decentralized (Federated) Model
12
©2011 HIMSS

13. Decentralized (Federated) Model
Overview
The decentralized or federated model provides organizational control of the
healthcare record and provides the framework for data-sharing capability to
enterprises, perhaps widely distributed across regions or even nationally.
• The local entity owns their data and the Record Locator Services
manages the pointers to the information; data stays at the source
• Updates and access to healthcare records are provided only when
needed
• Allows the initiator of a health record, such as a provider, to maintain
ownership and control over the record while providing access to the
record to authorized personnel
• Participants (providers) form a single administrative entity or governing
body at the regional level, with each retaining control of its own internal
business activity
13
©2011 HIMSS

14. Decentralized (Federated) Model
Benefits/Advantages
• Easiest/fastest way to achieve exchange as compared to other models.
• Limits data ownership conflicts
• Data is stored locally at the point of service; accessed only when needed for
exchange:
- Minimizes conflict of who owns the data
• Data is more likely to be current and up to date
• Failure of a single system does not cripple the ‘whole’ and others in the
exchange:
- Failure may make some patient data unavailable at the time of a query
• Any system may be connected to the HIE, assuming the identified standards
and interoperable requirements of the HIE is observed
• Minimizes the degree of risk due to potential hackers as compared to the
centralized model:
- Requires focused security of the RLS function
14
©2011 HIMSS

15. Decentralized (Federated) Model
Limitations / Challenges
• Setup is complex, expensive and costly to maintain
• Multiple potential points of failure with the technology platform, data
management and maintenance of confidentiality and security
• Participants ,including consumers, may have concerns with the
degree of data distribution in an interconnected set of frameworks
• Data standards and interoperable profiles being defined
• Focused effort required to ensure authorized and legitimate access to
the third-party systems
• Management of the consent process:
- Consent to opt in and opt out of the decentralized network, thus
ensuring legitimacy for data usage
- Consumer stakeholder consent opt in and opt out process
• Data control and availability may not be guaranteed
©2011 HIMSS 15

16. Hybrid Model
16
©2011 HIMSS

17. Hybrid Model
Overview
The hybrid model is a cross between centralized and decentralized
architecture. It provides the interface engine for which
organizational entities in the HIE communicate and exchange
data.
Example hybrid model:
• The HIE entity uses a system where data is physically stored
and managed in a central location, but the data is logically
separated into “vaults” controlled by each participating
organization that provides their data.
©2011 HIMSS 17

18. Hybrid Model
Overview
• Stores key record identifiers and specific requests for the information that is distributed
across the HIE network
• The record locator key is used to gather and transfer data to the requesting entity
• The hybrid model may also include elements where data is produced locally and the
original is stored centrally, but the centralized repository and locator registry are
dependent on federated EHR adapters for production of links to the original patient
information
• Algorithms exist within the applications in the HIE network to ensure positive probability
of gathering candidate patient records
• The hybrid model may also include elements where data is produced locally and stored
centrally. This type of centralized repository and locator registry is dependent on
federated EHR adapters for production of links to the original patient information
• The central database may store a minimum of clinical data or a “minimum clinical data
set” that may include data such as current medications, current diagnoses and
allergies. There can be also pointers to where additional data is stored
©2011 HIMSS 18

19. Hybrid Model
Benefits/ Advantages
• Best of both worlds from setup, socio-economic, political and
management perspectives.
• Only some of the actual data is replicated to the central data
repository.
• Most flexible of models.
©2011 HIMSS 19

20. HIE Technical Model Benefit
Analysis Score Card
©2011 HIMSS 20

21. HIE Risk Analysis
Risk Area Centralized Federated Hybrid
Maintaining strong data security
Single point of failure
Patient data privacy perception
Technical implementation costs
Resolving data conflicts
Dependence on external systems
Ongoing operation costs
Support organization complexity
Gaining community buy-in/adoption
Maintaining strong governance
Sustaining value over time
Legend: Low Med High
©2011 HIMSS

22. HIE Benefits Analysis
HIE Model Benefits Centralized Federated Hybrid
Data Availability
Architecture Flexibility
Cost Effectiveness
Leverages HIE Investments
Allows Rapid Implementation
Data Currency
Maintain High Service Levels
Allows Incremental Builds
Management of Patient Consent
Legend: Low Med High
©2011 HIMSS

23. HIE Commonly Offered Services
©2011 HIMSS 23

24. HIE Commonly Offered Services
Data Services
• Secure data delivery, and confirmation of delivery, to EHRs, PHRs,
other systems and networks
• Data look-up, retrieval and data location registries
• Support for notification of the availability of new or updated data
• Subject-data matching capabilities
• Summary patient record exchange
• Data integrity and non-repudiation checking
• Audit logging and error handling for data access and exchange
• Support for secondary use of clinical data including data
provisioning and distribution of data transmission parameters
• Data anonymization and re-identification ,as well as HIPAA de-
identification
©2011 HIMSS

25. HIE Commonly Offered Services
Consumer Services
• Management of consumer-identified locations for the storage of their
PHRs
• Support of consumer information location requests and data routing to
consumer-identified PHRs
• Management of consumer-controlled providers of care and access
permissions information
• Management of consumer choices to not participate in network
services
• Consumer access to audit logging and disclosure information for PHR
and HIE data
• Routing of consumer requests for data corrections
©2011 HIMSS

26. HIE Commonly Offered Services
User and Identity Management Services
• User identity proofing and/or attestation of third-party identity
proofing for those connected through that HIE
• User authentication and/or attestation of third-party
authentication for those connected through that HIE
• Subject and user identity arbitration with like identities from other
HIEs
• Management of user credentialing information (including medical
credentials as needed to inform network roles)
• Support of an HIE-level, non-redundant methodology for
managed identities
©2011 HIMSS

27. HIE Commonly Offered Services
Management Services
• Management of available capabilities and services information for
connected users and other HIEs
• HIE system security including perimeter protection, system
management and timely cross-HIE issue resolution
• Temporary and permanent de-authorization of direct and third-party
users when necessary
• Emergency access capabilities to support appropriate individual and
population emergency access needs
©2011 HIMSS

28. HIE Commonly Offered Services
The infrastructure workgroup considered only technical
architecture models that could support the delivery of the
following most commonly offered HIE services:
• Patient portals
• Clinical messaging
• Clinical data interoperability services
• Testing and results reporting
• Other clinical documentation sharing
• Electronic health record
• Personal health record
• Record locating services (technology model dependency)
• Administrative services (claims, authorization, payment systems)
• Disease management services
• Community and public health reporting
• Other value added services
©2011 HIMSS

29. HIE Technology Components
29
©2011 HIMSS

30. HIE Technology Components
Network Infrastructure
• High speed reliable, secure connections
HIE Applications
• Exchange software applications that facilitate the delivery of HIE services
Middleware
• Services modules that facilitate the integration of data and application
software to exchange data. Four types:
- Integration engine
- Patient matching Algorithms & enterprise master patient/person index
- Record locator services
- Provider matching
30
©2011 HIMSS

31. HIE Technology Components
Applicable Standards
Core standards
• Basic standards used in all exchanges over the Internet
Transaction Standards
• Data transaction standards
Semantic Standards
• Defines the range of values and related description of variables
Process Standards
• Processes communicated in standard transactions and data
standards. Example is use cases/ HITSP HIE use cases
31
©2011 HIMSS

32. HIE Technology Components
Core Standards
TCP/IP ~ Transmission Control Protocol/Internet Protocol
General standard for the Internet and most internal networks.
HTTP ~ Hypertext Transfer Protocol
Basic language of Web pages. May also include Java, Javascript, Active Server
Pages and other languages.
LDAP ~ Lightweight Directory Access Protocol
Application protocol for querying and modifying directory services running over
TCP/IP. May be used to access the person directory of a record locater
system.40
SSL or TLS Secure Sockets Layer ~ Transport Layer Security
Cryptographic protocols that provide security and data integrity for communications
over TCP/IP networks such as the Internet.41
3DES ~ Triple Data Encryption Standard
This is three-time successive application of DES designed to overcome the limitation
of a 56-bit key without changing the encryption algorithm.42
URL ~ Uniform Resource Locator
Specifies where an identified resource is available and the mechanism for retrieving
it. Translates to a Web address of the form nnn.nnn.nnn.nnn.
32
©2011 HIMSS

33. HIE Technology Components
Transactional Standards
Message Formats
HL7~ Health-Level Seven
• A family of standards used in many aspects of health data exchange
X12 ~ ANSI ASC X12
• Official designation of the U.S. national standards body for the development
and maintenance of Electronic Data Interchange (EDI) standards. Includes
many XML standards for healthcare and insurance
NCPDP~ National Council for Prescription Drug Programs
• A family of pharmacy data standards.
33
©2011 HIMSS

34. HIE Technology Components
Transactional Standards
Message Formats
DICOM~ Digital Imaging and Communication in Medicine
• Standard for handling, storing, printing, and transmitting information in medical
imaging; both a transaction and a semantic standard
IHE Integration Profiles ~ Integrating the Healthcare Enterprise Integration
Profiles
• IHE developed a family of interoperability profiles by utilizing HL7 standards for
specific purposes
HITSP ~ Interoperability Specifications Health Information Technology Standard
Panel
• HITSP has developed a whole system of specifications including creating
processes to harmonize standards, certify EHR applications, develop nationwide
health information network prototypes and recommend necessary changes to
standardize diverse security and privacy policies
34
©2011 HIMSS

35. HIE Technology Components
Transactional Standards
Message Formats
CDA~ Clinical Document Architecture
• XML-based “standard” intended to specify the encoding, structure and
semantics of clinical documents for exchange
CCR~ Continuity of Care Record
• Patient health summary standard developed by ASTM, several medical
societies and a number of vendors
CCD~ Continuity of Care Document
• XML-based markup “standard” intended to specify the encoding, structure
and semantics of a patient summary clinical document for exchange; the
CCD specification is a constraint on the HL7 CDA (further limits it). HITSP
has selected the CCD (not the CCR)
35
©2011 HIMSS

36. HIE Technology Components
Transactional Standards
Message Transport
SOAP~ Simple Object Access Protocol
• Protocol specification for exchanging structured information in
the implementation of Web Services in computer networks.
Used with XML.
XML~ Extensible Markup Language
• Data exchange language using tags to designate variables.
Simple and powerful.
36
©2011 HIMSS

37. HIE Technology Components
Semantic Standards
ICD ~ International Classification of Diseases
Published by the World Health Organization
CPT ~ Current Procedural Terminology
Describes medical, surgical and diagnostic services
Maintained by the American Medical Association.
HCPCS ~ Healthcare Common Procedure Coding System
Based on CPT and designed to provide a standardized coding system for describing
the specific items and services provided in the delivery of healthcare. Used for
reporting to Medicare, Medicaid and other payers.
LOINC ~ Logical Observation Identifiers Names and Codes
Database and universal standard for identifying medical laboratory observations
developed by Regenstrief Institute.
SNOMED ~Systematized Nomenclature of Medicine
A multiaxial, hierarchical classification system where 11 axes represent
classification features.
RxNorm ~ Standardized nomenclature for clinical drugs
Produced by the U.S. National Library of Medicine.
NDC ~ National Drug Code
Universal product identifier for human drugs. 37
©2011 HIMSS

38. Additional Resources
• HIMSS HIE Toolkit
http://www.himss.org/ASP/topics
• HIMSS State HIT Dashboard
http://www.himss.org/statedashboard/
• HIMSS Guide to Participating in an HIE
http://www.himss.org/ASP/topics_FocusDynamic.
asp?faid=148