Sharing Clinical Data in a Distributed System

OverviewChallenges

Core ComponentsData 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

HOSPITALCOMMUNITY

SOCIALCARE

INDEPENDENTCLINIC

GYM

MOBILE

WORK

?

• 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

Vertical Integration

Layer 1: input

Layer 2: HIE

Layer 4: Population Analysis/Prediction

Health careResearch

Layer 3: Aggregation/Extraction/anonymization

Beyond just HIE

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|20090224104145-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||19661109|M PV1||O

Ack:

MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS_TLS|ALLSCRIPTS|IBM_BRIDGE_TLS|IBM|20090224114149-0500||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 pre-existing 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:

• Blood pressure (observable entity) {75367002 , SNOMED-CT }– Children of SNOMED 271650006:

• 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

Presentation layer

Service layer

Data layer

Security

Identity mgmt,Roles,

AttributesAccesscontrol

Patients Providers Clinical Orgs

Codes Rules Relations

Patientsearch

Clinicalsearch

Consentmgmt

Workflowmgmt

Relationshipmgmt

Audit

Web ServerBrowser

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

Facility A

Facility B

Facility C

EMPI

Identity domain A

Identity domain B

Community/global domain

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.

Web Portal

Clinical Events

FindPatient

Identities EMPI CDR?ProviderDirectory

ViewPatient

ViewPatientClinical

Data

Log in

Feed

Patient DataClinical Data

business

service

data RLS

Query Feed

Data Flow

78 mm[Hg]

Initial reading

132 mm[Hg]

Add Context

Time: 202005231056020000+0000

Device: xyz

Patient id: abcAuthor: Dr SeussFacility: Seuss GP PracticeEncounter ID: 1

Patient name: Leigh Halfpenny

78 mm[Hg]

132 mm[Hg]

Group and Code

Blood Pressure: code=123 codeSystem=LOINCSystolic: code=456 codeSystem=LOINC

Diastolic: code=789 codeSystem=LOINC

Time: 202005231056020000+0000

Device: xyz

Patient id: abcAuthor: Dr SeussFacility: Seuss GP PracticeEncounter ID: 1

Patient name: Leigh Halfpenny

Blood Pressure

78 mm[Hg]

132 mm[Hg]

Local system

Send data into system

Local CDR

Local PAS

Associate with patient xyz record.Patient xyz is a VIP!

Send dataData + context

HIESend event

Process data in HIE

Data Dictionary

EMPI

1. Map codesData + context

3. Persist pointer

RLS

2. Resolve local patient ID

Global: 000Seuss GP practice: XyzCommunity Care: Abc

Name: Leigh Halfpenny

LOINC bp = iiiLOINC sys = qqqLOINC dia = kkk

Global: 000Seuss GP practiceEncounter ID: 1

audit, relationships,

etc.

Query for data

EMPI1. Find patient (name)

RLS

Global: 000Seuss GP practiceEncounter ID: 1

Portal

2. Find data(000)

Dr Suess CDR

Clinical Data Service3. lookup(000)

4. Get(xyz, 1)

Global: 000Seuss GP practice: XyzCommunity Care: Abc

Name: Leigh Halfpenny

audit, relationships,

etc.

Query for data

EMPI1. Find patient (name)

Consent rules

Portal

2. Find data(000)

Dr Suess CDR

Clinical Data Service3. Check consent

Global: 000Seuss GP practice: XyzCommunity Care: Abc

Name: Leigh HalfpennyVIP = true

4. Access deniedBTG required

audit, relationships,

etc.

Sharing Clinical Data in a Distributed System

1. Understand the challenges2. Understand the core components3. Data is everything – understand how data

flows through the system