Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sharing Clinical Data in a Distributed System

Similar presentations


Presentation on theme: "Sharing Clinical Data in a Distributed System"— Presentation transcript:

1 Sharing Clinical Data in a Distributed System
Overview Challenges Core Components Data Flow

2 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)

3 ? Or just a nice picture?

4 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 HOSPITAL COMMUNITY SOCIAL CARE INDEPENDENT CLINIC GYM MOBILE WORK ?

5 Vertical Integration Layer 4: Population Analysis/Prediction
Beyond just HIE Layer 4: Population Analysis/Prediction Layer 3: Aggregation/Extraction/anonymization Research Health care Layer 2: HIE Layer 1: input

6 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

7 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.

8 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.

9 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.

10 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| ||ADT^A04^ADT_A01| |P|2.3.1 EVN|| PID|||101^^^IBOT& &ISO||FARNSWORTH^STEVE|| |M PV1||O Ack: MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS_TLS|ALLSCRIPTS|IBM_BRIDGE_TLS|IBM| ||ACK^A04|OpenPIXPDQ |P|2.3.1 MSA|AA|

11 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

12 Diastolic Blood Pressure
The simplest case of something like Diastolic Blood Pressure reading: LOINC: SNOMED-CT: Mapping looks simple But concepts can be hierarchical Parents of SNOMED : Blood pressure (observable entity) { , SNOMED-CT } Children of SNOMED : Average diastolic blood pressure (observable entity) { , SNOMED-CT } Diastolic blood pressure on admission (observable entity) { , SNOMED-CT } Lying diastolic blood pressure (observable entity) { , SNOMED-CT } Maximum diastolic blood pressure (observable entity) { , SNOMED-CT } Minimum diastolic blood pressure (observable entity) { , SNOMED-CT } Sitting diastolic blood pressure (observable entity) { , SNOMED-CT } Standing diastolic blood pressure (observable entity) { , SNOMED-CT } Target diastolic blood pressure (observable entity) { , SNOMED-CT } Or simply related LOINC – BP dias at first encounter LOINC – BP dias 24h Mean LOINC — BP dias 24h Max LOINC — BP dias 1h Mean LOINC — BP dias 8h Mean LOINC — BP dias 10h Mean Etc...

13 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

14 Typical Components Presentation layer Security Identity mgmt, Roles,
Attributes Access control Browser Web Server Service layer Patient search Clinical search Consent mgmt Workflow mgmt Relationship mgmt Data layer Patients Providers Clinical Orgs Codes Rules Relations Audit

15 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.

16 Identity Domains Community/global domain Identity domain A EMPI
Facility C Facility A Facility B Identity domain B

17 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.

18 Core Components Provider Directory
Contains all providers/healthcare professionals involved So they can be identified Associated with organizations/facilities Accessed via Secure by other providers Discovered by patients and external bodies

19 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.

20 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

21 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.

22 Web Portal business Log in Find Patient View Patient View Patient Clinical Data service Identities Provider Directory EMPI RLS CDR? data Query Feed Feed Clinical Data Clinical Events Patient Data

23 Data Flow Initial reading 132 mm[Hg] 78 mm[Hg]

24 Add Context Device: xyz Patient name: Leigh Halfpenny Patient id: abc
Author: Dr Seuss Facility: Seuss GP Practice Encounter ID: 1 Time: 132 mm[Hg] 78 mm[Hg]

25 Group and Code Device: xyz Patient name: Leigh Halfpenny
Patient id: abc Author: Dr Seuss Facility: Seuss GP Practice Encounter ID: 1 Time: Blood Pressure: code=123 codeSystem=LOINC Systolic: code=456 codeSystem=LOINC Diastolic: code=789 codeSystem=LOINC Blood Pressure 132 mm[Hg] 78 mm[Hg]

26 Send data into system Local system Local CDR Send data Data + context
Associate with patient xyz record. Patient xyz is a VIP! HIE Local PAS Send event

27 audit, relationships, etc.
Process data in HIE LOINC bp = iii LOINC sys = qqq LOINC dia = kkk Data Dictionary 1. Map codes Data + context audit, relationships, etc. 3. Persist pointer 2. Resolve local patient ID RLS Global: 000 Seuss GP practice: Xyz Community Care: Abc Name: Leigh Halfpenny EMPI Global: 000 Seuss GP practice Encounter ID: 1

28 audit, relationships, etc.
Query for data Global: 000 Seuss GP practice: Xyz Community Care: Abc Name: Leigh Halfpenny EMPI Portal 1. Find patient (name) audit, relationships, etc. 2. Find data(000) RLS Clinical Data Service 3. lookup(000) Global: 000 Seuss GP practice Encounter ID: 1 4. Get(xyz, 1) Dr Suess CDR

29 audit, relationships, etc.
Query for data Global: 000 Seuss GP practice: Xyz Community Care: Abc Name: Leigh Halfpenny VIP = true EMPI Portal 1. Find patient (name) 2. Find data(000) audit, relationships, etc. 4. Access denied BTG required Consent rules 3. Check consent Clinical Data Service Dr Suess CDR

30 Sharing Clinical Data in a Distributed System
Understand the challenges Understand the core components Data is everything – understand how data flows through the system


Download ppt "Sharing Clinical Data in a Distributed System"

Similar presentations


Ads by Google