Sharing Clinical Data in a Distributed System

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 WORK COMMUNITY INDEPENDENTCLINIC SOCIALCARE GYM ? MOBILE

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

6. HIEChallenges • 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|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

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

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 Relationship mgmt Consent mgmt Workflow mgmt Data layer Patients Providers Clinical Orgs Relations Codes Rules 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 Email 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 RLS CDR? EMPI Provider Directory data Feed Query Feed Clinical Data Clinical Events Patient Data

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

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

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

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

29. 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 3. Check consent Consent rules Clinical Data Service DrSuessCDR

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