Action point 18. Inventory and consolidation registries. healthdata data we care for. RTREH 2015, Brussels,

Transcriptie

1 Action point 18 Inventory and consolidation registries RTREH 2015, Brussels, healthdata

2 AP18 Deliverables Overzicht Status a. Inventory registers n > 160: (2014(Q4)); + CRUD (2015(Q2)). b. Variables by profession & insgtugon : Meta- data by profession & insbtubon (2014(Q4)); Variables by profession & insgtugon (2015(Q4)); : HD- projects Wave 1: technical specificagons variables, validabon rules, reference lists (2015(Q1)). c. Governance ConvenGon RIZIV- WIV (2015): basics of govern. fed. registries + SteerComm HD; Tasks SteerCom HD: Procedures & criteria registries + evaluabon & prioribsabon; SteerCom HD in acbon: 2015Q2; HD: detailed descripbon of BP available (2014(Q2); BP for each project available in web portal (2015(Q4); d. StandardisaGon of variables 80 registries: variables (incl. doubles) HD: 1 st mapping towards MZG variables (2014) HD: POC: mapping of 2 registries towards SNOMED

3 AP18 Deliverable (Cont.) Overzicht Status d. StandardisaGon of variables (Cont.) HD: analysis of Clinical Building Blocks [CBB s] (Ned. Fed. Uni. Med. Centr. & NICTIZ) as framework: aligned with clinical pracbce, not specialism- specific, & technology neutral) (2015(Q1)). HD- NICTIZ POC with 2 registries: most variables can be easily covered with CBB s (2015(Q2)). Belgian validabon of CBB s: short term implementagon in HD registries possible (2016(Q1)) e.+f.+h.+i. : Architecture to extract variables from Vaults & hubs Not feasible: see g). g. S2S- Architecture for mulgfunct. registries HD S2S- Architecture for mono- & mulgfunct. registries + support transibon period with HD4DP; Approved by: WG Architecture, Sect. Comm. Health, ehealth; Successful test installagons HD4DP: UZLeuven, UZAntwerp, UZBrussels (2015(Q1-2)), planned: CHU Charleroi, UZGhent, ZNA, Inkendaal (2015(Q2)); Roll out: all hospitals + laboratories (before 2016(Q1)), all GP s (2017(Q2));

4 AP18 Deliverable (Cont.) Overzicht g. S2S- Architecture for mulgfunct. registries (Cont.) Status projects (WIV & RIZIV) redesigned in 3 waves by 2017(Q2) (2015: 2 data collecbons stopped: HD will re- use other DB). j. Cancer Registry: batch > congnuous S2S SKR: Development 1st drah own XML + XSD for anatomopathologists 1st phase: S2S for anatomopathologists 2015(Q2) 2nd phase: S2S for care programs in oncology 3rd phase: S2S for specific oncology registries AP18 Issues a. HD: If large administragve data collecgons (MZG, MPG, Doc PH, ) have higher freq. in collecbon, use (coded) INSZ, and have shorter processing Bme > higher re- use by registries; b. HD: lack of nabonal minimal set of stable, structured, specialism independent, technical neutral, and reusable data specificabons for (hospital) EPD > HD proposal: clinical building blocks; c. HD: need 4 vision, architecture & roadmap for Next GeneraGon Sequencing (NGS) data collecbon; d. HD: AP18 (like other AP s) has a significant impact on data providers, data users, governemental policy: CHANGE on level of organisabon, informabon, applicabons, infrastructure, nabonal and internabonal reporbng obligabons (ECDC, WHO, EMCDDA, EUROSTAT, ). CHANGE MGMT and transigon policy on all levels needed; e. SKR: standard format for data transfer adopted by all stakeholders; f. SKR: Gming.

5 AP18 new acgon points Overzicht 1. Een publiek toegankelijke webapplicabe met gedetailleerde inventaris van alle in België bestaande recurrente beleidsondersteunende wetenschappelijke gegevensverzamelingen in domein van gezondheid en gezondheidszorg, wordt permanent geactualiseerd (hop:// 2. De taak tot aanmelding en actualisage van inventaris wordt in overeenkomst tussen opdrachtgevende overheid en de projectverantwoordelijken van de beleidsondersteunende wetenschappelijke gegevensverzamelingen opgenomen. 3. De procedures en criteria voor opstarten van nieuwe en congnueren van bestaande recurrente beleidsondersteunende wetenschappelijke gegevensverzamelingen, worden vastgelegd en ter beschikking gesteld via publiek toegankelijke webapplicabe. 4. De goedgekeurde generieke architectuur (met HD4DP- sohware) van healthdata- plarorm wordt geïmplementeerd in (a) alle Belgische ziekenhuizen en medische laboratoria, en bij (b) alle Belgische huisartsen. 5. De goedgekeurde generieke architectuur (met HD4DP- sohware) van healthdata- plarorm wordt toegepast op alle (a) nieuwe en (b) bestaande recurrente beleidsondersteunende wetenschappelijke gegevensverzamelingen. Target vanaf 2015_Q3 vanaf 2015_Q3 vóór 2016_Q1 vóór 2016_Q2 (a) vóór 2017_Q4 (b) vanaf 2015_Q2 (a); vanaf 2016_Q1 (b: voor allen, vlgs. kalender); vóór 2017_Q4 (b: voor 42 prjct. WIV & RIZIV)

6 AP18 new acgon points (Cont.) Overzicht 6. Het gebruik van goedgekeurde generieke architectuur (met HD4DP- sohware) van healthdata- plarorm bij (a) nieuwe en (b) bestaande recurrente beleidsondersteunende wetenschappelijke gegevensverzamelingen wordt in overeenkomst tussen opdrachtgevende overheid en de verantwoordelijken van de gegevensverzamelingen opgenomen. 7. Afspraken, architectuur, en planning voor beleidsondersteunende gegevensverzamelingen met meervoudige bestemming (MyCarenet, hubs & kluizen, nabonaal implantatenregister, ). 8. Afspraken, architectuur, en planning voor verzameling, beheer en ontsluiten van humane Next GeneraGon Sequencing (NGS) data. 9. Een Belgische adaptage wordt uitgevoerd van elke beschikbare specialisme- oversbjgende en technisch neutrale NFU- NICTIZ Clinical Building Block, en wordt na validabe in een publiek toegankelijke centrale digitale catalogus gepubliceerd (hop:// dcd/). 10. Alle (a) nieuwe en (b) bestaande recurrente beleidsondersteunende wetenschappelijke gegevensverzamelingen worden inhoudelijk samengesteld doormiddel van de voor België beschikbare gevalideerde Clinical Building Blocks; Target vanaf 2015_Q3 vóór 2016_Q1 vóór 2016_Q1 vóór 2016_Q1 vanaf 2016_Q1 (a); vanaf 2016_Q1 (b: voor allen, vlgs. kalender); vóór 2017_Q4 (b: voor 42 prjct. WIV & RIZIV)

7 AP18 new acgon points (Cont.) Overzicht 11. De waardenlijsten van Clinical Building Blocks in alle (a) nieuwe en (b) bestaande recurrente beleidsondersteunende wetenschappelijke gegevensverzamelingen in domein van gezondheid en gezondheidszorg, worden prioritair met SNOMED- CT concepten opgemaakt; Target vanaf 2016_Q1 (a) ; vanaf 2016_Q1 (b: voor allen, vlgs. kalender); vóór 2017_Q4 (b: voor 42 prjct. WIV & RIZIV).

8 APPENDIX Inventarisering en consolidatie registers RTREH 2015, Brussels, healthdata

9 The challenge for sciengfic data collecgon Signalitics, typical available in authentic sources Variables needed for scientific research question Register A Register B Information needed in context of continuity of care or internal administration Register C Clinical building blocks Register D Information mostly not available in primary systems EPD, HIMS, LIMS, )

10 Example Clinical Building block: breathing Values: SNOMED- CT

11 Care transfer that can be used in different contexts Stable, reuseable building blocks Research Quality indicators PaGent summaries

12 Registries & Terminology: the Challenge Now: A lot (>150) of data collecbons with even more (>8000) Parameters Maximal reuse from primary systems is our key objecbve Hospitals, laborabes and general pracbboners need to be able to provide this data in a structured way How can we create a mutually understandable language between the reasearchers and the data providers? Basis for data exchange Maximum simplificabon of the administrabve work at the data provider s side Tangible results within 2 years

13 ApplicaBve IntegraBon Common Understanding Detailed Terminology Messages (e.g. SUMEHR, Recip- e PrescripBon) N..M Building Blocks (e.g. PaBent, Concern, ) 1..N Concepts & Reference Lists (e.g. ID, sex) KMEHR Messages HL7 Messages Implicit No Broad coverage (yet) KMEHR CodeTables LOINC SNOMED CT

14 SuggesGon ObjecBve: Inventory of building blocks Data providers make sure they can provide the building blocks (in KMEHR or other structured standard) Researchers primarily use building blocks for their data collecbons Approach: Make the exisbng building blocks in KMEHR messages (more) explicit and document them separately at conceptual level Liaise with NICTIZ to exchange building block experience and define a common building block roadmap