Sponsored by Healthdata.be Standardisation of & data reuse for Belgian health registries 2017.05.10, HL7 Conference, Madrid Maarten Landuyt & Johan Van Bussel

n = 3000 Clinical registries are necessary! Beneficial (11%) BMJ Clinical Evidence (2014) Likely to be beneficial (24%) Unknown effectiveness (50%) n = 3000 Trade-off between benefits and harms (7%) Unlikely to be beneficial (6%) Likely to be ineffective or harmful (3%)

Epidemiological surveillances are necessary! Sabbe et al., (2012) Measles resurgence in Belgium, Eurosurveillance

BUT ! ?   ?   ? ?   ?   ?   ? ? ?  

The main cause of burn-out in physicians? #1: increase administrative burden (70.4%)

“René, listen very carefully, I shall say this only once” “Only once” = key principle of Action plan eHealth 2013-2018

1 Healthdata’s ambition for healthcare registries technical implementation: free & open information architecture: technically neutral technical service desk set of business processes Maximal reuse of existing data and linking of previously collected data (“only once” registration) Each data provider receives timely feedback reports within 1 reporting environment Less administrative burden & higher efficiency = more time for patient ► higher quality of care = more time for research ► higher quality of research = lower costs

Healthdata.be at a glance Use of National Registry Number as ID Technical description of each data collection HD4DP HD4RES DATAWAREHOUSE (SAS) HEALTHSTAT          Registration in Primary System Data Capture Secure Data Transfer & encoding of IDs Data Monitoring Data Validation Data Storage Analysis BI-Reporting Annotation & Correction Request Trusted Third Party for encryption and pseudonymization Generic healthdata.be architecture approved by: WG Architecture: Positive advise (12/12/2014 & 06/03/2015) Sectorial Committee health (Privacy commission): Authorization (21/04/2015) eHealth-platform : Authorization (22/04/2015)

In production N = 20 “To do” N > 100

Interoperability Information architecture

Identification, typically available in authentic sources Typology based on inventory of 8,000 variables collected by ca. 50% of current registries Information needed in the context of continuity of care or internal administration. Information should be available in primary systems (EHR, LIMS, …) in a structured and coded way Registry A Registry B Identification, typically available in authentic sources Registry C Variables needed for scientific research question Information mostly not available in primary systems (EHR, HIMS, LIMS, …) Registry D

The collection of health care data: need for interoperability Organization A Organization B Legal and regulatory Policy Care process Information Applications IT Infrastructure Compatible legislation and regulations Collaboration agreements Alignment of care processes and workflows Data model, terminologies, formatting Integration in healthcare applications Communication and network protocols Information Data model, terminologies, formatting Information Redefined eHealth European Interoperability Framework (IHE)

Standardisation of registry content Implementation by NFU: “Clinical Building Blocks” International standard: ISO/TS 13972:2015(en): Health informatics — Detailed Clinical Modeling, characteristics and processes. Assets (products) N=42 Method The following organizers and participants contributed to the Technical Specification: Health Level 7 International (HL7) (USA), — National ICT Institute in Health Care (NICTIZ, Netherlands), National Health Service (NHS) (England), Canada Infoway (Canada), National E-Health Transition Authority (NEHTA),(Australia), OpenEHR (International), EN 13606 association (Europe), Intermountain Healthcare (USA), …

Example of a Clinical Building Block “Breathing” Values: SNOMED-CT

Standardisation of healthdata registries

42 CBB’s 46 Projects mapped 100% 3142 items items match w/a CBB items do not match w/a CBB 100%

covers 63% of 3142 variables

Registry standardisation in 3 phases Map existing registries to CBBs Phase 2 Adjust questions to CBB structure Phase 3 CBB-based registries

REUSE of data through a cbb-based API on hd4dp

Interfacing without CBBs Input formats (m) Registries (n) Basic dataset KMEHR EMR Registry 1 HL7v3 CDAr2 LIMS Registry 2 HL7 FHIR EHR Registry 3 … … … m * n connections (max)

versus m*n connections from previous slide Interfacing with CBBs Input formats (m) Registries (n) Basic dataset KMEHR EMR Registry 1 HL7v3 CDAr2 CBBs LIMS Registry 2 HL7 FHIR EHR Registry 3 … … … m + n connections (max) versus m*n connections from previous slide

Q&A www.healthdata.be healthdata@wiv-isp.be healthdata be Sponsored by