HISI Stakeholders Summit 20th November 2013 From Patient Assessment to European Registry European Cystic Fibrosis Experience

Transcription

1 HISI Stakeholders Summit 20th November 2013 From Patient Assessment to European Registry European Cystic Fibrosis Experience Mel McIntyre

2 About OpenApp Software development and support focused on healthcare, patient assessments, quality assurance, spatial analysis and planning. Deliver solutions on Open Source technologies, Python, Postgresql, Linux, Django, Zope. Cloud delivered Patient Assessment Platform for Clinical Programs and Patient Registries Teaming with IBM and DSS Inc Florida USA to bring VistA to Europe

3 European Cystic Fibrosis Patient Registry - ECFSPR The ECFS Patient Registry s aim is to measure, survey and compare aspects of cystic fibrosis and its treatment in the participating countries, encouraging new standards of dealing with the disease, providing data for epidemiological research identifying special patient groups suitable for multi-centre trials.

4 23 countries - approx 220 hospitals/cf centres

5 Goals for the software Make it easy for countries and centres to participate oaccomodate countries with existing CF Registry software and countries and centres with no existing software oaccomodate countries with strict data protection interpretations oallow countries and centres to extend the core data model to collect more data and transfer or share data ono barriers to participation - low or no costs Make it easy for doctors/providers to participate oprovide feedback on patient and centre preformance oeasy as possible for doctors to complete patient assessments oaccurate summary process oextend towards a richer encounter - labs, meds, other 1.

6 OpenApp goals Build a platform that can serve more clinical programmes ocurrently building Irish National Joint Registry and one other Clinical Program Integrate easily with external systems - PAS, Lab, Surgery, et al Underpin oclinical data models (OpenEHR, EN13606) oclinical Terms and Termilologies (SnomedCT, ICD, ATC,)

7 Three types of Registry Participants Use European System Centres and/or Countries who will use the ECFSPR software system to generate the Patient Annual Summary record and submit to the European Registry Database Austria Bulgaria Greece Israel Latvia Portugal Serbia Spain Slovenia Switzerland Use Own System Own instance of Europe System Centres and/or Countries who have their own means of developing the Annual Summary submission and will submit a file once per year to be included in the European Registry Database Centres and/or countries who will manage their own instance/server running the ECFSPR software and will submit a file once per year to be included in the European Registry Database Belgium Czech Republic Denmark France Germany Italy Ireland Holland Hungary Moldova Russia Slovakia Sweden UK

8 Software system components Core Data C Encounter Data Entry En Annual Summary Process AS Annual Return AR Verification European Registry Database Registration Demo graphics Diagnosis Duplicate and sharing mgmt Patient Identifcation File accessible only from within the Centre network Patient Identification Name, DOB, Other Patient Centre Id Data Entry L1 - Field validation Patient Identification Offline data collection and synchronisation Centre specific styling Centre level reporting Each Centre has it s own data tables Each country has it s own database Data import or Excel upload Level 1 and 2 validation Error highlighting and correction Error over-rides Add country specific field additions Country level reporting Download Country and/or Centre returns Upload error reports for Centre attention Mark data as complete Patient Id Consent management User Management Network and Application Security Fixed reports Reporting tools and charts Data Export Mutation management Other tables

9 Software deployment.. with error reporting Partition within European System Centre Country Austria, Slovenia, Greece... Annual Annual Core Encounter Data C Data Entry En ASSummary AR Return Process ETL Verification ECFSTracker AR European Registry Database Own System UK, Germany, France.. Spain UK Holland Annual Return AR Core Data Own copy of ECFSTracker Software Ireland C Encounter Data Entry En Annual Summary Process AS

10 Data protection.. 1.Patient identification only in Centre/Hospital o Label encryption process under control of the hospital 2.Only de-identified data managed in ECFS Registry

11 Patient Identification Hospital - Centre Country Registry European Registry Hospital MRN File accessible only from within the Centre network Centre Patient Id Name Patient Identification Name, DOB, Other Patient Centre Id Date of Birth National Reg Id HASH - Name/DOB National Reg Id National Reg Id National Centre Id National Centre Id European Reg Id European Reg Id European Country or Centre Id European Country or Centre Id

12 Patient Identification - two methods We use a Labels File to associate the patients real name with the CFRI Identifier 1.Hospital hosts the Labels File on a web server only accessible from within the hospital network and only accessed by the CF application 2.CFRIReg or ECFSTracker hosts the Encrypted Labels File and only the hospital can retrieve and decrypt with a hospital controlled password.

13 Extending the Data Collected - Adding fields at Country level... Locally defined fields can be added to the Annual Summary at Country level and reflected in the Centre s Encounter Data Collection Form Fields are not mandatory at Centre level - you don t have to use them Visibility of fields and form layout can be customised at Centre level

14 Form Designer

15 Share or transfer patient record

16 Data Quality Control - Spec Level 1: data control through input masks and validation rules at input level. This is to prevent a user to put in really faulty data e.g. FEV 15 litre; validation rules, e.g. FEV1 <= FVC or e.g. a user fills in: sterile or normal flora in sputum, then the pseudomonas and other should become grey and impossible to choose; Level 2: automatic data control of the whole set before saving. A user should have the possibility to input partial data, after leaving the internet it should be possible to continue the same patient later. Once a patient is complete, the user clicks the button make this registration complete. From that moment on, there should be a control of missing values, incompatible combinations of data, data coherence etc. to give the user the possibility to correct the errors. Summarising: Automatic data-coding control; Automatic control of miscalculations; Automatic control of missing values or values outside the allowed range; Automatic control double entries, e.g. records that are doubled by mistake; Automatic data-coherence controls (according to a list that will be provided). Level 3: once everything is in order, data are admitted to the general working database where level 3 validation is done (many of these items will be done manually by statisticians).

17 Error reporting from Level 3 Validation (Statistician)... Set of tools for use by CF Registry Statistician Based on Annual Return of Annual Summaries on a Centre or Country basis All Centre or Country data available to download Upload of Error Reports by Statistician Errors are posted back to appropriate Centre and specific fields highlighted for correction Error over-ride available

18 Error Reporting Module - Spec Prevents the user from entering/modifying the data when the procedure is started; The user should receive notification of the errors present in their database; Each error should be accompanied by a short explanation of the nature of the error; The user should be automatically directed to the page where the errors are present; The wrong values should be clearly evident (either by highlighting the field or by writing it in a different colour; All the fields that do not need correction should be blocked (i.e. the user should not be allowed to modify them); After the errors have been corrected, the software should re-carry out all the usual and agreed data-quality controls; If the correction of one error generates another error in the database, then the software should notify the user and the user should be directed to the page where the new error is found, the user should be allowed to modify the relevant fields

19 Analytics and Reporting Europe o Country Centre Consultant Patient level reports

20 Data Reporting protection and Analytics.. Same facilities available at Centre, Country, Europe Reporting permissions o USER and Centre Administrator at Centre only o Country Coordinator ALL CENTRES in that Country o European Coordinator can see all Centres and Countries PIVOT Table for Ad-Hoc reports o What variables to expose - still under discussion o Counts and Proportions (Yes/Total Records) as report type Fixed Reports for Centre Fixed Reports for Patient

21 Europe, Country, Centre - as available

22 Europe by Country

23 Patient assessment

24 Patient encounter and reports

25 Planned for Irish CFR - Shared Enhanced Encounter Mgt John Doe DOB 12 Oct 1997 CFRI Id Main St, Athy, Co Kildare Key Clinical Indicators Hospital MRN Next of Kin Referring GP etc Treating Consultant Other provider Patient Summary Some indicators Complications Patient report Hospital Data Lab test results Inpatient encounters Medications Current History Patient Schedule Clinic dates (assessments) Other Patient reports Visualisation Data input

26 Technologies used 1. PostgreSQL database 2. Django wep app framework 3. Indivo PCHR - we used the Indivo design pattern but have removed the code as we use more Provider than Patient control 4. Lots of Javascript - D3, Flot, JQuery

27 Thanks