From Patient Encounter to European Registry

EHI Live Birmingham NEC
6th Nov 2013

From Patient Assessment to
European Registry
European Cystic Fibrosis Experience
Mel McIntyre

EHI Live 6th Nov 2013

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

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.


23 countries - approx 220 hospitals/cf centres


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.

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 with clinical data models (OpenEHR, EN
13606) and Clinical Tems and Ternilologies (SnomedCT,
ICD, ATC, )


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

Use Own

Centres and/or Countries who have their own

System

means of developing the Annual Summary
submission and will submit a file once per year to
be included in the European Registry Database

Own instance

Austria
Bulgaria
Greece
Israel
Latvia

Portugal
Serbia
Spain
Slovenia
Switzerland

Belgium
Czech Republic
Denmark
France
Germany
Italy

Hungary
Moldova
Russia
Slovakia
Sweden
UK

Centres and/or countries who will
manage their own instance/server

of Europe

running the ECFSPR software and will

System

submit a file once per year to be included
in the European Registry Database


Ireland
Holland

Software system components
Core
Data

C

• 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

Encounter
Data Entry

En

• Data Entry
• L1 - Field
validation
• Patient
Identification
• Offline data
collection and
synchronisation
• Centre specific
styling
• Centre level
reporting

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


Annual
Return AR
Verification
• 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

European
Registry
Database
• Fixed reports
• Reporting tools
and charts
• Data Export
• Mutation
management
• Other tables

Software deployment . . with error reporting
ECFSTracker

Partition within European
System
Austria, Slovenia, Greece . . .
Core
Encounter
C Data Entry En
Data

Own System
UK, Germany, France . .
Annual
Return

Centre
Country
Annual
ASSummary AR
Process
ETL

Spain

UK
Holland

AR

Own copy of ECFSTracker Software

Ireland
Core
Data

C

Encounter
Data Entry

En

Annual
Summary
Process

AS


Annual
Return AR
Verification

European
Registry
Database

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


Hospital - Centre

Country Registry

European Registry

Hospital MRN

File accessible only
from within the
Centre network
Name,
DOB, Other

Patient
Centre Id

Centre Patient Id
Name
Date of Birth

HASH - Name/DOB

National Reg Id

National Reg Id

National Centre Id

National Centre Id

National Reg Id

European Reg Id

European Reg Id

European Country or
Centre 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


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


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


Reporting . .
Data protection
• Same reporting 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


Europe, Country, Centre - as available


Patient encounter and reports


Planned for Irish CFR - Shared Enhanced Encounter Mgt
John Doe
DOB 12 Oct 1997
CFRI Id - 12345
12 Main St, Athy, Co
Kildare

Patient Summary
• Some indicators
• Complications
• Patient report
Hospital Data
• Lab test results
• Inpatient encounters
Medications
• Current
• History
Patient Schedule
• Clinic dates (assessments)
• Other

Key Clinical Indicators

Patient
reports

•
•
•
•
•

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

Data
input

Visualisation


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

Thanks
mel.mcintyre@openapp.ie

From Patient Encounter to European Registry

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to From Patient Encounter to European Registry

Similar to From Patient Encounter to European Registry (20)

Recently uploaded

Recently uploaded (20)

From Patient Encounter to European Registry