Sharing Clinical Data in a
Distributed System
Overview
Challenges
Core Components
Data Flow
Healthcare Information Exchange (HIE)
• What is it?
– An environment in which different data sources and services share clinical
data to support emerging scenarios:
• Longitudinal electronic health records
• Cross disciplinary/integrated care
• Patient centric care
• A growing market
– Massive failures in the UK
• e.g. NHS CfH
– Big opportunities in the US
• Obama’s Meaningful Use
• A variety of existing and emerging standards to support interoperability
–
–
–
–
HL7 (Health Level 7)
CDA (Clinical Document Architecture)
DICOM (Digital Imaging and Communications in Medicine)
IHE (Integrating the Healthcare Enterprise)
? Or just a nice picture?
Horizontal Integration
• Integration across the patient path
– Across physical boundaries (institutional, geographic, national)
– Across data models and syntaxes (Continua device readings, consent documents,
EHR)
– Data is stored close to home
– The system can evolve to include new partners
• Supports patient-centric longitudinal storage and query
WORK
HOSPITAL
COMMUNITY
INDEPENDENT
CLINIC
SOCIAL
CARE
GYM
MOBILE
?
Vertical Integration
Beyond just HIE
Layer 4: Population Analysis/Prediction
Layer 3: Aggregation/Extraction/anonymization
Research
Health care
Layer 2: HIE
Layer 1: input
HIE Challenges
• Integration of different facilities
– With their own representations of
• Patient identity
• Clinical data
• Health data is sensitive
– Need to manage access
– Need to manage patient consent
– Need to manage patient identity
– Need to audit
Data
• Data is never clean in the real world
–
–
–
–
Demographics are sloppy
Identifiers are not unique even though they should be
Different sources use different codes and formats to represent data
Health domain is intrinsically complex in terms of the concepts it needs to
capture
• E.g. for an inpatient encounter
–
–
–
–
–
–
–
–
–
Patient (identity, medical history, allergies etc.)
Complaint
Diagnosis
Treatments (procedures, meds, lab tests)
Attending specialist physician
Location (hospital, floor, ward, bed)
Treatment start/end (might not have ended yet)
Patient Primary Care Provider (GP)
Other attending physicians
• More complex encounters may involve care teams
– Multi-disciplinary team of providers
– May follow a prescribed care path that moves through states over time.
Relationships
• Much of the data that needs to be captured and
understood is related to the concept of relationships
– Relationships between patients and providers
– Relationships between providers and organisations
– Relationships between events
• Processes can be long running, e.g., a referral.
– Made up of a number events – primary care appointment, referral
request, referral acceptance, possible appointment with specialist,
treatment, admission, reports etc.
– Implies some sort of state management so that at the
business level a user can ask things like:
• Who is currently caring for patient X?
• That will depend on whether they are an inpatient or outpatient,
what their recent history is etc.
Data Normalization
• To understand the data coming from different sources, data needs
to be normalized in order for the HIE system to understand what it
is dealing with.
– There are standards but they are interpreted in different ways
• HL7 V2 describes a wire syntax for modeling encounters, admissions,
discharges, patient demographics, etc.
• A number of different versions
– Like XML, you can define a wire format, but that does not solve the
semantic understanding of the data.
• HL7 V3 uses more comprehensive model (RIM – Reference Information Model)
including concepts of Roles, Acts, Encounters, etc.
• Is rendered in XML
– Some systems don’t support standards
• You get a CSV file which maps to their internal database :-(
• Implies you need a canonical domain object model.
Sidebar: HL7 V2 messages:
You thought XML was ugly
ADT A04 (Register a patient):
MSH|^~\&|IBM_BRIDGE_TLS|IBM|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|20
090224104145-0600||ADT^A04^ADT_A01|0851077658473390286|P|2.3.1
EVN||20090224104145-0600
PID|||101^^^IBOT&1.3.6.1.4.1.21367.2009.1.2.370&ISO||FARNSWORTH^STEVE||196
61109|M PV1||O
Ack:
MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS_TLS|ALLSCRIPTS|IBM_BRIDGE_TLS|IB
M|200902241141490500||ACK^A04|OpenPIXPDQ10.243.0.65.19767899354465|P|2.3.1
MSA|AA|0851077658473390286
Data Coding
• Health Informatics uses coded values (aka concept descriptors) to define
concepts and tag data items with those concepts
– A simple coded value is made up of a code, a code system, code system name,
code system version, display name
– There are multiple coding systems
– E.g. LOINC (Logical Observation Identifiers Names and Codes) focuses on lab
observation
• Over 69,000 terms
– E.g. SNOMED CT (Systematized Nomenclature Of Medicine Clinical Terms)
more general and pretty complicated – concepts can be built up from preexisting simpler concepts (post coordination)
• Over 311,000 terms
– There are many others
– Overlap in what they describe
– Have different ways of describing concepts
• Implies you need to code mapping in order to normalize the data to a
canonical model
Diastolic Blood Pressure
•
The simplest case of something like Diastolic Blood Pressure reading:
–
–
–
•
LOINC: 8462-4
SNOMED-CT: 271650006
Mapping looks simple
But concepts can be hierarchical
–
Parents of SNOMED 271650006:
•
–
Children of SNOMED 271650006:
•
•
•
•
•
•
•
•
•
Blood pressure (observable entity) {75367002 , SNOMED-CT }
Average diastolic blood pressure (observable entity) {314453003 , SNOMED-CT }
Diastolic blood pressure on admission (observable entity) {446226005 , SNOMED-CT }
Lying diastolic blood pressure (observable entity) {407557002 , SNOMED-CT }
Maximum diastolic blood pressure (observable entity) {314452008 , SNOMED-CT }
Minimum diastolic blood pressure (observable entity) {314451001 , SNOMED-CT }
Sitting diastolic blood pressure (observable entity) {407555005 , SNOMED-CT }
Standing diastolic blood pressure (observable entity) {400975005 , SNOMED-CT }
Target diastolic blood pressure (observable entity) {315613000 , SNOMED-CT }
Or simply related
–
–
–
–
–
–
–
LOINC 11377-9 – BP dias at first encounter
LOINC 8472-3 – BP dias 24h Mean
LOINC 8467-3 — BP dias 24h Max
LOINC 8468-1 — BP dias 1h Mean
LOINC 8469-9 — BP dias 8h Mean
LOINC 8470-7 — BP dias 10h Mean
Etc...
Push and Pull models
• The data that comes into systems is typically modeled
as events – a push model
– Encounters between patients and providers
– Can arrive as a feed in real time or in nightly bulk loads.
– So the system needs to be event driven
• Respond, update to events from other system components
• The data extracted from the system, e.g. for
presentation to users in a web portal is request
response oriented – pull model
– Show me all haematology lab results for patient X
• Need to harmonize those two approaches
Typical Components
Browser
Presentation layer
Web
Server
Security
Service layer
Patient
search
Clinical
search
Consent
mgmt
Workflow
mgmt
Relationship
mgmt
Data layer
Patients
Providers
Clinical
Orgs
Codes
Rules
Relations
Audit
Identity
mgmt,
Roles,
Attributes
Access
control
Core Components
• Enterprise Master Patient Index (EMPI)
– Able to perform matching between patient
demographics and identifier correlation.
– Aggregates multiple patient records into a master
record
• So that you know you talking about the same individual
person across different systems.
– Many different approaches to this problem
• Deterministic
– E.g., exact match
• Probabilistic
– E.g. String distance, Soundex, Metaphone etc.
Identity Domains
Community/global domain
Identity domain A
EMPI
Facility C
Facility A
Facility B
Identity domain B
Core Components
• Vocabulary Service/Data Dictionary
– Defines the codes/data types that are supported
in the HIE
– Can map between representations of data types
– So you know that systolic readings from multiple
data sources represented in different ways all
refer to a systolic reading.
Core Components
• Provider Directory
– Contains all providers/healthcare professionals
involved
•
•
•
•
So they can be identified
Associated with organizations/facilities
Accessed via Secure Email by other providers
Discovered by patients and external bodies
Core Components
• Clinical Document Repository (CDR)
– Persistent storage of clinical data
• Maps data items to patients
• And to events, e.g. an encounter between patient and
provider
• Has a single data model
– Not always present
• Queries for clinical data may go directly to underlying
sources
– Without a single data model
• Results are aggregated at the service layer.
Core Components
• If there is no HIE CDR, then you need some way of
knowing where data is
– So you don’t do an open federated query each time
• Record Locator Service (RLS)
– Different flavours
• Store patient identifier mapped to data source
– This doesn’t promise that data is there, but says the patient presented
there, so there might be
• Store patient identifier mapped to clinical data ID
– This points to actual clinical data items such as encounters
– More efficient but more complex
– RLS is usually tied to the EMPI, so that identifier resolution
can take place
– Does not store data like a CDR, just pointers
Core Components
• Identity Management System
• Not specific to HIE but needed in any enterprise environment
–
–
–
–
–
Often login back bone is LDAP
Mapping of users to login groups
Mapping of login groups to Roles
Mapping of Roles to permissions
Other attributes also required
• E.g. what organizations does provider X belong to?
–
–
–
–
–
Used for login/logout
Session management
Single Sign on
Access Control and Consent management
Break the Glass – give a reason why you need to see data you do not usually
have access to
• This is heavily audited so that proper use can be verified after the event and breaches
can be detected.
business
Web Portal
service
data
Find
Patient
Log in
Identities
Provider
Directory
Query
Clinical Data
View
Patient
EMPI
Feed
Clinical Events
RLS
View
Patient
Clinical
Data
CDR?
Feed
Patient Data
Data Flow
Initial reading
132 mm[Hg]
78 mm[Hg]
Add Context
Device: xyz
Patient name: Leigh Halfpenny
Patient id: abc
Author: Dr Seuss
Facility: Seuss GP Practice
Encounter ID: 1
Time: 202005231056020000+0000
132 mm[Hg]
78 mm[Hg]
Group and Code
Device: xyz
Patient name: Leigh Halfpenny
Patient id: abc
Author: Dr Seuss
Facility: Seuss GP Practice
Encounter ID: 1
Time: 202005231056020000+0000
Blood Pressure: code=123 codeSystem=LOINC
Systolic: code=456 codeSystem=LOINC
Diastolic: code=789 codeSystem=LOINC
Blood Pressure
132 mm[Hg]
78 mm[Hg]
Send data into system
Local system
Data + context
Send data
Local CDR
Associate with patient xyz record.
Patient xyz is a VIP!
HIE
Send event
Local PAS
Process data in HIE
LOINC bp = iii
LOINC sys = qqq
LOINC dia = kkk
Data + context
3. Persist pointer
1. Map codes
Data Dictionary
audit,
relationships,
etc.
2. Resolve local patient ID
Global: 000
Seuss GP practice: Xyz
Community Care: Abc
Name: Leigh Halfpenny
RLS
Global: 000
Seuss GP practice
Encounter ID: 1
EMPI
Query for data
Portal
Global: 000
Seuss GP practice: Xyz
Community Care: Abc
Name: Leigh Halfpenny
1. Find patient (name)
EMPI
audit,
relationships,
etc.
2. Find data(000)
RLS
Global: 000
Seuss GP practice
Encounter ID: 1
3. lookup(000)
Clinical Data Service
4. Get(xyz, 1)
Dr Suess CDR
Query for data
Portal
Global: 000
Seuss GP practice: Xyz
Community Care: Abc
Name: Leigh Halfpenny
VIP = true
1. Find patient (name)
EMPI
2. Find data(000)
audit,
relationships,
etc.
4. Access denied
BTG required
3. Check consent
Consent rules
Clinical Data Service
Dr Suess CDR
Sharing Clinical Data in a
Distributed System
1. Understand the challenges
2. Understand the core components
3. Data is everything – understand how
data flows through the system