sharing clinical data in a distributed system overview challenges core components data flow
TRANSCRIPT
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 care
Research
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