From Patient Encounter to European Registry

EHI Live 6th Nov 2013

EHI Live Birmingham NEC 6th Nov 2013

From Patient Assessment to European Registry

European Cystic Fibrosis Experience

Mel McIntyre


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•Teaming with IBM and DSS Inc Florida USA to bring VistA

to Europe

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.


European Cystic Fibrosis Patient Registry - ECFSPR


23 countries - approx 220 hospitals/cf centres


Goals for the software

•Make it easy for countries and centres to participateoAccomodate countries with existing CF Registry software and

countries and centres with no existing softwareoAccomodate countries with strict data protection

interpretationsoAllow countries and centres to extend the core data model to

collect ‘more’ data and transfer or share dataoNo barriers to participation - low or no costs

•Make it easy for doctors/providers to participateoProvide feedback on patient and centre preformanceoEasy as possible for doctors to complete patient assessmentsoAccurate summary process oExtend towards a richer encounter - labs, meds, other

1.


OpenApp goals

•Build a platform that can serve more clinical programmesoCurrently building Irish National Joint Registry and

one other Clinical Program• Integrate easily with external systems - PAS, Lab,

Surgery, et al•Underpin with clinical data models (OpenEHR, EN

13606) and Clinical Tems and Ternilologies (SnomedCT, ICD, ATC, )


Three types of Registry Participants Use

EuropeanSystem

Use Own System

Own instance of Europe 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 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

AustriaBulgariaGreeceIsraelLatvia

PortugalSerbiaSpainSloveniaSwitzerland

BelgiumCzech RepublicDenmarkFranceGermanyItaly

HungaryMoldovaRussiaSlovakiaSwedenUK

IrelandHolland


Software system components

Patient IdConsent management

User ManagementNetwork and

Application Security

Patient Identification

Patient Centre Id

Name, DOB, Other

File accessible only from within the Centre network

PatientIdentifcation

Annual Summary Process

AS

• 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

CCore Data

• Registration• Demo

graphics• Diagnosis• Duplicate

and sharing mgmt

Annual Return

VerificationAR

• Download Country and/or Centre returns

• Upload error reports for Centre attention

• Mark data as complete

Encounter Data Entry

• Data Entry• L1 - Field

validation• Patient

Identification• Offline data

collection and synchronisation

• Centre specific styling

• Centre level reporting

En European Registry Database

• Fixed reports• Reporting tools

and charts• Data Export• Mutation

management• Other tables


European Registry Database

Software deployment . . with error reporting

ECFSTracker

Annual Return AR

Own SystemUK, Germany, France . .

Partition within European System

Austria, Slovenia, Greece . . .

CCore Data

Encounter Data Entry En

Annual Return

VerificationAR

Centre Country

ARAnnual

Summary Process

ETL UK

Holland

Annual Summary Process

CCore Data

Encounter Data Entry En

Own copy of ECFSTracker SoftwareIreland

Spain

AS

AS


Data protection . .

1.Patient identification only in Centre/Hospitalo Label encryption process under control of the hospital

2.Only de-identified data managed in ECFS Registry


Hospital - Centre Country Registry European Registry



Patient Centre Id

Name, DOB, Other

Hospital MRN Centre Patient Id Name Date of Birth National Reg Id National Centre Id

File accessible only from within the Centre network

HASH - Name/DOB National Reg Id National Centre Id European Reg Id European Country or Centre Id

National Reg Id European Reg Id European Country or Centre Id


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.


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


Form Designer


Share or transfer patient record


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).

Data Quality Control - Spec


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


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


Reporting• Europe, Country, Centre• Patient level reports


Data protectionReporting . .

•Same reporting facilities available at Centre, Country, Europe•Reporting permissionsoUSER and Centre Administrator at Centre onlyoCountry Coordinator ALL CENTRES in that CountryoEuropean Coordinator can see all Centres and Countries

•PIVOT Table for Ad-Hoc reportsoWhat variables to expose - still under discussionoCounts and Proportions (Yes/Total Records) as report

type• Fixed Reports for Centre• Fixed Reports for Patient


Europe, Country, Centre - as available


Patient encounter and reports


Patient encounter and reports

Planned for Irish CFR - Shared Enhanced Encounter Mgt

Patient Summary• Some indicators • Complications• Patient report

Hospital Data• Lab test results• Inpatient encounters

Medications • Current• History

Patient Schedule• Clinic dates (assessments)• Other


John DoeDOB 12 Oct 1997CFRI Id - 1234512 Main St, Athy, Co

Kildare

• Hospital MRN• Next of Kin• Referring GP etc• Treating Consultant• Other provider

Key Clinical Indicators

Patient reports

Visualisation

Data input

Technologies used

1. PostgreSQL database2. Django wep app framework3. 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

Thanks

[email protected]

Health & Medicine

From Patient Encounter to European Registry