CLINICIAN-LED E-HEALTH RECORDS. (AKA GETTING THE LITTLE DATA RIGHT) Dr Heather Leslie Ocean Informatics/openEHR Foundation

Transcription

1 CLINICIAN-LED E-HEALTH RECORDS (AKA GETTING THE LITTLE DATA RIGHT) Dr Heather Leslie Ocean Informatics/openEHR Foundation

2 An ongoing issue In attempting to arrive at the truth, I have applied everywhere for information but in scarcely an instance have I been able to obtain hospital records fit for any purpose of comparison. If they could be obtained, they would enable us to decide many other questions besides the one alluded to. They would show subscribers how their money was being spent, what amount of good was really being done with it or whether the money was not doing mischief rather than good. Florence Nightingale, 1863

3 Why is sharing health information so difficult? If the banks can do it, why can t health? Complex & dynamic clinical domain Lifelong records Requirements for clinical diversity Privacy & Security Increasing health costs Safety & Prevention Mobile population Mobile providers... IT S. ALL. ABOUT. THE. DATA!

4 Healthcare's Big Problem With Little Data Gartner s hype cycle: Big Data heading toward the Peak of Inflated Expectations In the meantime, however, little data in healthcare continues to give us all peptic ulcers Clinical data at the unit level is chaotic and dysfunctional because it s not easily transferable or usable outside of the system that first created it. In a world of competing financial interests and an increasingly mobile population every patient encounter represents an opportunity for technology vendors to lock-in providers. Historically, the crutch that many software vendors have relied on is the format of the data itself. April 28, 2013

5 Health Knowledge Complexity Both the total number of concepts and the rate of change is high SNOMED medical terminology >400,000 atomic concepts and over 1 million relationships Not only is health care big, it is open-ended: In breadth, because new information is always being discovered or becoming relevant In depth, because finer-grained detail is always being discovered or becoming relevant In complexity, because new relationships are always being discovered or becoming relevant Clinical knowledge changes! Acknowledgement: Sam Heard

6 Complexity: Medication timing Dose frequency every time period n times per time period n per time period every time period range Maximum interval Maximum per time period Examples every 4 hours three times per day 2 per day 6 per week every 4-6 hours, 2-3 times per day not less than every 8 hours to a maximum of 4 times per day Acknowledgement: Sam Heard

7 Complexity: Medication timing Time specific Morning and/or lunch and/or evening Examples take after breakfast and lunch Specific times of day 06:00, 12:00, 20:00 Dose duration Time period via a syringe driver over 4 hours Acknowledgement: Sam Heard

8 Complexity: Medication timing Event related After/Before event n time period before/after event Duration n time period before/after event Examples after meals before lying down after each loose stool after each nappy change 3 days before travel on days 5-10 after menstruation begins Acknowledgement: Sam Heard

9 Complexity: Medication timing Treatment duration Examples Date/time to date/time 1-7 January 2005 Now and then repeat after n time period/s n time period/s n doses stat, repeat in 14 days for 5 days Take every 2 hours for 5 doses Acknowledgement: Sam Heard

10 Complexity: Medication timing Triggers/Outcomes Examples If condition is true if pulse is greater than 80 until bleeding stops Start event Finish event Start 3 days before travel Apply daily until day 21 of menstrual cycle Acknowledgement: Sam Heard

11 Clinical diversity Variety of data represented Free-text vs Structured Normal statements Nil significant, NAD Graphical Fractal nature of medicine Different clinicians: Prefer different approaches Need different levels of detail Image eg homunculus Multimedia eg video, ECG wave format Questionnaires, checklists etc Need to record/exchange information on a per patient basis MYTH: One size fits all

12 The challenge We are analog beings trapped in a digital world We are compliant, flexible, tolerant. Yet we have constructed a world of machines that requires us to be rigid, fixed, intolerant. Donald Norman phenomena data

13

14

15

16

17 Lego brick ecosystem openehr infostructure

18 2 level modelling Archetypes Archetypes Templates Archetypes CLINICAL TECHNICAL Software is built independently of the content

19 openehr content models + Terminology ALL THE CONTENT Domain experts model their expertise!

20 Clinicians driving EHR content!

21 openehr content models Foundation building blocks = Computable specification for one single clinical concept Blood pressure Medication order Symptom Diagnosis Family History Maximal data set Universal use-case Design once, re-use over & over Strong governance critical

22

23 Archetype classes Clinical Process Published evidence base Personal knowledge base Compositions Sections Entries Domain Expert Clusters 2 Evaluation clinically interpreted findings 1 Observations measurable or observable order or initiation of a workflow process 3 Instructions Subject 4 Actions recording data against each order Investigator s agents

24 openehr content models Foundation building blocks = Computable specification for one single clinical concept Blood pressure Medication order Symptom Diagnosis Family History Maximal data set Universal use-case Design once, re-use over & over Strong governance critical Flexible expression of clinical requirements = Computable specification for a specific clinical purpose: Message content Document Form Report Constrain sensible for the specific clinical use-case 1- archetypes per template Governance NOT critical if archetypes are controlled

25

26 Template complexity

27 Clinical diversity

28 Archetype Re-use

29 Archetypes as Little data Requires a change of mindset Requires upfront planning & coordination Not more time Requires CLINICIAN LEADERSHIP & ENGAGEMENT Ensure quality of clinical data Warrant data is safe & fit for purpose Fulfils quality remit for professional clinical colleges

30 Semantic interoperability Level 1: Non-electronic data. Examples include paper, mail, and phone call. Level 2: Machine transportable data. Examples include fax, , and unindexed documents. Level 3: Machine organisable data ie structured messages, unstructured content Examples include indexed (labeled) documents, images, and objects. Walker et al, 2005 Level 4: Machine interpretable data (structured messages, standardised content) Examples include the automated transfer from an external lab of coded results into a provider s EHR. Data can be transmitted (or accessed without transmission) by health IT systems without need for further semantic interpretation or translation. Walker et al, 2005

31 openehr ecosystem Decision- Support Code Skeletons UI Forms Data Sets Health records Data registries XML Schemas Messages SNOMED CT LOINC FEST ICD Terminology Mappings/ Subsets Semantic Queries HTML Display HL7 v2 CDA FHIR Acknowledgements: Hugh Leslie, Thomas Beale One record Population health

32 Achievable? archetypes core clinical information to save a life 100 archetypes primary care EHR 2000 archetypes hospital EHR [compared to >400,000 concepts in SNOMED] Because openehr combines: Structure of archetypes/templates Terminology codes/value sets

33 Achievable? 2 Initial core clinical content is common to all disciplines and will be re-used by other specialist colleges and groups Online archetype consensus in CKM: Achieved in weeks/archetype Minimises need for F2F meetings Multiple archetype reviews run in parallel Leverage existing and ongoing international work

34 HUMAN PROBLEM Terms, value sets Can clinicians agree? What is a heart attack? 5 clinicians, 6 answers probably accurate! What is an issue vs problem vs diagnosis? BUT No consensus in HL7 for years There is generally agreement on the structure and concepts first principles Problem/Diagnosis name Status Date of initial onset Age at initial onset Severity Clinical description Date clinically recognised Anatomical location Aetiology Occurrences Exacerbations Related problems Date of Resolution Age at resolution Diagnostic criteria

35 The openehr Foundation Non-profit organisation based at UCL Managed by UCL All specifications & schemas publicly & freely available 2/2015 elections for Management Board Expert volunteers managing the operations Growing and active industry group Commercial and open source implementations International Community

36 openehr architecture Archetype Query Language Terminology Subset Syntax Virtual EHR Terminology Service Demographic Service EHR Service Archetype Service RM Domain Patterns Core EHR Extract EHR Demographic Integration Composition Template OM openehr Archetype profile Security Common AOM Data Structures Data Types Support (Identifiers, Terminology Access)

37 The openehr difference... Data independent of technology & applications Universal health record data (cf application) Lifelong health information Caters for clinical diversity Caters for dynamic knowledge Supports data liquidity/exchange Enables re-use of health information Multilingual solution Terminology agnostic

38

39 Template Demonstration