Clinical Interoperability Services

1. Clinical Interoperability Services Dr Dipak Kalra University College London d.kalra@chime.ucl.ac.uk

2. Goals for clinical information interoperability • To support patient safety, quality of care, chronic disease management, extended homecare, patient empowerment • To enable care providers to work to consistent clinical care and information standards • enable the safe, meaningful sharing and combining of health record data between heterogeneous systems and actors / care providers • enable the integration and safe use of computerised protocols, alerts and care pathways by EHR systems • link EHR data to explanatory and educational materials to support patient and family engagement and professional development • ensure the necessary data quality and consistency to enable meaningful and reliable use of longitudinal and heterogeneous data for public health, research, health service management

3. Recommended priority use cases: for safe shared care • New medication prescriptions • requiring comprehensive information on concurrent medication and details of known allergies and conditions (not simple ETP) • Reminders and prompts • for overdue or overlooked health care actions and interventions • Evidence based care • the use of clinical guidelines and other forms of evidence to determine the optimal management strategy and care pathway for a given patient • Care transfers • referrals and within-team workflow such as the degree of urgency and the expectations of the referring clinician from another team member • Care co-ordination • ensuring that a high-level view can be taken of distributed (multi-team) care to protect against duplication, delay and incompatible interventions • Medical summaries • Personal Health Records

4. The challenge Many clinical systems can today achieve semantic interoperability using data that has been captured within their own applications, because the organisation and meaning of the data can be dictated in advance by each system designer Semantic interoperability is most needed when EHR data are to be shared and combined from different systems (or across modules within a large system) Clinical meaning (data, information, knowledge) must be capable of being represented consistently in order to be shared and understood

5. Clinical trials,functional genomics,public health Decision support, knowledge management Date: 1.7.94 EHR repositories Whittington Hospital Healthcare Record John Smith DoB : 12.5.46 Personnel registers,security services Mobile devices Clinical applications Clinical devices, instruments

6. Levels of semantic interoperability(as defined by the SemanticHealth Roadmap) • Level 1 = Technical • data structures permit mapping of corresponding parts of an information structure between systems • i.e. the data can be imported • Level 2 = Unidirectional semantic interoperability • the receiver can interpret the data, from the perspective of the sender • i.e. the data can be processed meaningfully • Level 3 = Full semantic interoperability • received data can be combined seamlessly with local data and processed homogeneously • i.e. the data can be processed seamlessly

7. Goals of EHR semantic interoperability • Full semantic interoperability (Level 3) is required across heterogeneous EHRs in order to gain the benefits of computerised support for reminders, alerts, decision support, workflow management and evidence based health care • i.e. to improve effectiveness and to reduce clinical risk • We need to be able to recognise, transform and process information with semantic equivalence

8. EuroRec contributions • Support of EHR interoperability standards (CEN and ISO) • Catalogue of EHR Requirements • Quality labelling of clinical archetypes • Register of clinical terminologies • Europe-wide promotion of quality labelling for EHR systems and informatics resources

9. Procedure Diagnosis Appendicectomy 1993 Diagnosis Acute psychosis 2003 Meningococcal meningitis 1996 Procedure Termination of pregnancy 1997 Diagnosis Schizophrenia 2006 What context information is needed to safely interpret this entry and to use it clinically? Problem List

10. Emergency Department “They are trying to kill me” Symptoms Reason for encounter Brought to ED by family Mental state exam Hallucinations Delusions of persecution Disordered thoughts Management plan Admission etc..... Diagnosis Schizophrenia Working hypothesis Certainty Seen by junior doctor Junior doctor, emergency situation, a working hypothesis so schizophrenia is not a reliable diagnosis

11. EHR Reference Model (e.g. EN 13606-1) • provides a generic set of context meta-data for all record entries • compositional record hierarchy • persons: record subject, authorship, signatures, information provider • dates and times: real world event times and record time-stamping • instance identifiers and version management • demographic model to describe persons and organisations • role based access approach with options for national extension

12. ISO EN 13606-1 Reference Model

13. EHR systems need to be consistentExamples of EuroRec requirements • Interoperability • The system accepts structured health items sent in a standardised format from an external source and integrates them in the patient's record. • Security • The system assigns a default level of access to each version of a health item, depending on the nature of the health item and/or the access level of the author. • Each update of a health item results in a new version of that health item. A complete history of the versions of a health item can be presented. • Clinical data standards • The system enables the use of templates as a way of structured data entry when documenting patient encounters. • The template structure, pick lists, reference tables and coding schemes offered by the system are compliant with or mapped to national or regionally agreed clinical data standards. • Workflow • The system enables the user to link one or more medication items to one or more clinical statements (problems, diagnosis, health issues). • The system alerts the user, when entering a new clinical statement (diagnosis, problem), on potential contra-indications for a current medication item.

14. openEHR Archetypes (also EN13606-2) • Archetypes are a formal, rigorous and standardised (interoperable) specification for an agreed consensus or best practice representation of a clinical data structure within an EHR • Archetypes are knowledge-related data structures that strongly support semantic interoperability of EHRs. They help to ensure • reliable and easy sharing of meaningful sets of data between different health care providers • while allowing the re-use of their 'atomic' data components separately or within other archetypes

17. Assembly of Archetypes into TemplatesPortion of ENT Discharge Summary (NHS England)

18. openEHR Archetype specification TRANSFORM Archetype Library Query EN 13606 Care Pathway Extract Merge TRANSFORM EHR-A EHR-B Archetypes Archetypes System B Receiver System A Sender Interpretation Data Capture using based on using FORM conforms to uses selected from points to EHR Extract

19. Archetypes need to be quality labelled • If record-sharing communities are to construct safe EHR instances in accordance with archetypes, and to trust EHR data conforming to archetypes, a formal process of verification and certification is needed for archetypes in the same way as EHR systems need to be certified • It is important that the design of individual archetypes is an accurate and faithful reflection of good practice for the clinical disciplines in which each of them might be used

20. Example quality issues • How can a clinical team lead know that an archetype is clinically trustworthy? • is it clear what clinical situations it is to be used for? • how inclusive is it of the kinds of patients we treat? • is it flexible enough for our needs? • what kinds of patients is it intended for? (children?, elderly?) • has it been designed with multi-professional input, and with suitable domain experts? • what clinical evidence and guidelines does it follow? • or, is its model based on an existing well-accepted system? • has the archetype been peer reviewed? • has it been endorsed by one or more professional bodies? • has it been quality labelled by a body that I trust?

21. Example quality issues • How can a regional care manager know where an archetype is suitable for use? • what clinical use cases has it been designed for? • will it be used consistently and safely across care teams? • does it align with other archetypes we use: it is clear how they fit together? • has it been approved by my national health service? • what national data sets does it conform to? • what terminologies (and versions) does it bind to? • will it align with national audit and governance reporting? • how up to date is it? • when and who will review and maintain it? how frequently? • has it been quality labelled by a body that I trust?

22. Example quality issues • How can a CTO or vendor know if an archetype is safe to implement? • which use cases and users should have access to it? • does it clash with any other archetypes we already implement? • does it conform to a technical standard? • has it been tested? • can I verify the authenticity of the copy I have? • can I verify its currency (is it the latest version)? • how will I be notified of updates? • how are terminology bindings maintained and disseminated? • it is published by a certified repository? • has it been quality labelled by a body that I trust?

23. The contribution of Q-REC • EuroRec is partnering the openEHR Foundation in developing • governance practices for archetype development • quality criteria and editorial policies by which certified libraries of EHR Archetypes can be recognised • The first major publication of archetype quality criteria and potential certification measures will be in Deliverable 3.1 (June 2008)