Presented by: Shane Downey,Mater Health Services, Brisbane, Australia

October 29, 2014

A Team Approach to Data Quality

1

Overview

In 2012 the Australian Government announced changes tohospital funding that required accurate and complete Patient datafor funding (as opposed to aggregated totals presently reported).

This presentation will take you along the journey that we took inaddressing this challenge, and some valuable lesson learned alongthe way.

2

3

The Mater Story

106 Year old institution established by the Sisters of Mercy to providecompassionate care to the sick and needy

7 hospitals providing public & private adults, women’s and children’sservices

>1,000 beds, >7,500 staff

180,000 outpatient attendances, 95,000 ED attendances,

290,000 inpatient days, 40,000 theatre cases,10,000 births

Academic Centre for both Nursing and Medical Students

Tertiary services in Obstetrics, Neonatology and Paediatrics

Centres of Excellence in Neurosurgery, Oncology,

Interventional Cardiology and Child & Youth Mental Health

Introduction of Activity BasedFunding at the Mater

4

6 month project to investigate the impacts to the business, systems andprocesses.

Review of all the outpatient clinics, services and current reporting andcounting methods revealed a number of unfunded services being provided,inconsistencies in counting, reporting and capture of information.

Identified new data elements required for the national reportingrequirements and gaps in existing solutions.

Identified some issues relating to data completeness and accuracy.

Set of recommendations including the need for a better approach tomeeting our statutory reporting requirements.

The introduction of the national pricing model for public outpatient servicesrepresented a real challenge to an organisation using best-of-breed healthsolutions.

Solution environment

Mater are a “best of breed” adopter. Each Clinical area has its own Patient Administration System:

» Mater Adults and Children’s uses iPM» Mater Private uses PractiX

» Allied Health uses TAHDIS (an in-house solution)

» Mater Children ’s Cardiac Service uses HealthTrack» Mater Cancer Care Centre uses CHARM

Each system has different capabilities for reporting, anddifferent data structures for storing and representing data.

Not every system captures the required data.

5

The challenge

6

With data and information being capturedin several key systems (i.e. separate PAS forpublic and private patients, theatre bookingand management systems, pathology,pharmacy, and oncology) - how could wemeet this new requirement to provideaccurate Patient level administrative,demographic and scheduling data withinthe required timeframes?

Current state informationarchitecture

iPM is the source of truth for Patient demographics and the Master PatientIndex, but not necessarily for service event and schedule management.

Current reporting involves manually running system reports and SQLqueries, loading data into Excel and then massage into something useful.

Our BI team report the same data but use different processes and oftenthere is misalignment between results due to data having changed betweenactivities.

Our Casemix team provide a third report (subset of the same data) usingtheir own processes and so again we often see a misalignment of data.

The problem of misaligned data and reporting is not specific to Healthcare!

All 5 systems are integrated via the Mater Clinical Data Repository(MCDR); an integration hub based on InterSystems HealthshareFoundations.

7

The Vision

To create an extensible solution that centralises all of the datarequired for statutory and corporate reporting in relation tooutpatient service events, based on robust and transparent

business rules and error management.

8

Solution design

Adopted a Master Data Management approach:

» MDM principles of Governance, Intelligence, Integration& Security.

Utilised agile principles» Established a combined business and

Technology working party including

key decision makers

» Frequent build and test cycles

» Minimal documentation

9

Data model

10

Z

P

Z

PersonContactPersonContactID

PersonID (FK)AddressLine1AddressLine2SuburbStateStateCodePostcodeGeographicalLocationCodeCountry CodeCountry DescEmailAddressFax NoHomePhoneNoMobilePhoneNoWorkPhoneNoBestContactPhoneNoLettersToPostalAddressFlagIsPostalAddressFlagCreatedOnCreatedByLastUpdatedOnLastUpdatedByIsActiv e

AppointmentAppointmentID

PatientID (FK)ReferralID (FK)

AppointmentIdentifier

AppointmentDateAppointmentTy peAppointmentCreatedDateAppointmentUpdatedDateAppointmentDeletedDateAppointmentDeletedFlagAppointmentCancellationReasonCodeAttendanceDateServ iceDeliv ery ModeFailedToAttendFlagSettingOfCareClinicFundingSourceServ iceProv iderTy peCareTy peSessionTy pePay mentClassChargeableStatusHospitalClinicCodeClinicTy peClinicTy peCodeClinicianCodeProv iderFundingSourceCorporateClinicCodeStandardUnitCodeInitialAttendanceFlagInterpreterBookedAdmissionEpisodeNumberLastUpdatedByLastUpdatedOnIsActiv e

ReferralReferralID

ReferralIdentifierReferralIssueDateReferralReceiptDateReferralSourceReferralClinicCodeReferralCategorisationDateClinicallUrgency CategorisationDateClinicallUrgency CategoyDoctorCodeReasonCategory ChangedReferralRemov alReasonCodeReferralCreatedDateReferralDeletedFlagReferralDeletedDateLastUpdatedByLastUpdatedOnIsActiv e

ReferralStatusReferralStatusID

ReferralID (FK)StatusDateStatus

WaitListStatusWaitListStatusID

WaitListID (FK)StatusDateStatus

WaitListWaitListID

ReferralID (FK)WaitingListIdentifierWaitListEntry NumberWaitListDoctorCodeWaitListPlacementDateWaitListSpecialty CodeNotReady ForCareStartDateNotReady ForCareEndDateNotReady ForCareDay sNotReady ForCareComentsReferralCategorisationDateClinicalUrgency CategoryClinicalUrgency Category ModifiedDateWaitingTimeLastUpdatedByLastUpdatedOnIsActiv e

PersonPersonID

TitleGiv enNameSurnameFullNameInitialsPreferredNameAgeAgeBracketDateOfBirthDateOfDeathDateOfBirthEstimatedFlagGenderGenderCodePriorSurnameMaritalStatusInterpreterRequiredLanguageSpokenLanguageSpokenCodeIndigenousStatusSouthSeaIslanderStatusEthnicBackgroundCountry OfBirthLastUpdatedByLastUpdatedOnIsActiv e

PatientPatientID

PersonID (FK)PatientIdentifierMajorURNumberMinorURNumberPatientIHIDVAFileNumberDVACardTy pePay mentClassMedicareEligibilityMedicareNumberMedicareSuffixPatientCreatedDatePatientLastModifiedDatePatientDeletedDatePatientDeletedFlagLastUpdatedByLastUpdatedOnIsActiv e

PatientEpisodePatientEpisodeID

PatientID (FK)EpisodeNumberStandardUnitCode

AppointmentStatusAppointmentStatusID

AppointmentID (FK)StatusDateStatus

Governance

11

Governance (cont.)

Access to the data must be authorised by the Manager Data Servicesin conjunction with our Privacy Office.

Requests must satisfy acceptable use criteria in accordance withboth Mater policy and State and Federal laws. This is for bothPatient and Employee data.

Data is cleansed on the way in. Any errors are sent to the relevantClinical Administration Team Leader on a nightly basis via email.

All reported errors must be corrected within 4 business days. Errors not corrected within that time are flagged on a weekly &

monthly KPI report that is sent to the Nursing Director for followup.

Framed by our Information Management Framework, andInformation Security & Control Policy.

12

Intelligence

Dashboards are available to enable review of the KPIsrecorded by the system.

Practice Manager has access to an analytics engine to enablead-hoc query and drill down on KPI data in order to keep trackof data quality trends.

We provide an interface to our BI/Analytics team for thepurpose of providing the business with detailed reporting onthe data.

13

Security

There is no direct access to the database – all access is eitherby report or by interface.

Interfaces and reports utilise role based security and soauthentication is required.

All usage of interfaces and reports is audited. We capture: Name of the interface/report

Date/time of use

Username and IP address of the user

Input parameters provided

We don’t record the result set as this will consume too much storage,and impact performance. Plus the data is relatively static so rerunningthe query will largely reproduce the same results.

14

Integration

Data is warehoused internally based on either HL7 messagetriggers or over night data pull.

Data is stored based on a simple star schema.

An interface provides service activity data to our Casemixteam for costing and billing.

This same interface is used to send data to Queensland Healthto meet our statutory reporting requirements.

15

Data Flow

16

Business process change

Data quality was used to drivebusiness process review andchange.

Education to staff around theimportance of getting the dataright the first time.

A net resulting decrease in dataquality errors by 80%!

17

Daily trending

18

Monthly trending

19

Key metrics

20

KPIs – July 2012 to Jan 2014281,130 Outpatient Appointments since July 201264,949 Outpatient Appointments that contain errors23% Error rate since July 201222% Invalid Outcome328 Clinics with 100% error rate

Feb 2013 Feb 2014Outpatient Appointments 13,521 15,537 (+13%)Outpatient Appointmentsthat contain errors

4,550 1,300 (-71%)

Error Rate 34% 8%Invalid Outcome 33% 8%Clinics with 100% error rate 26 7 (-73%)

Key metrics (cont.)

21

Data Quality Cost – 2013 Calendar Year33,431 Outpatient appointments that contain errors2 mins Average time to fix an appointment

$33,431Hidden cost of repairing all outpatientappointments with errors ($228 per day)

147 Work days spent correcting data quality errors

$6,987,079The “cost of doing nothing” in terms of potentiallost revenue.

Operational46 Administration FTE (59 staff)

235 Outpatient Clinics$0 Total capital investment in the solution

Lessons learned

Administrative data quality will get you every time. wash,rinse & repeat!

Start measuring the data quality before you make any changes.You need to quantify “how bad is bad” and have a baseline tobenchmark changes against.

Use the data to drive business process change. Look for brightspots and focus on areas with the highest errors first.

Service review – “just because we can doesn’t mean weshould”

Resource effectively – a second Data Analyst would havesignificantly reduced the overall delivery time.

22

Lessons learned (cont.)

MDM is a great approach – but is hard going unless you havea project to drive it.

Bring front of house and back of house together to collaborateon the rules and the data management processes.

The data is ALWAYS right. If it doesn’t look right check yourprocesses back to source.

Data quality begins at the point of capture. Everything thathappens after that is WASTE.

23

Team award

Winner IAIDQ Data Quality Award 2014 – Team Project

24

Role Person

Manager Data Services / Information Architect Shane DowneyPractice Manager Susan Gardiner

Senior Data Analyst Specialist Fiona King

Senior Data Integration Specialist Andy Richards

Thank You!

Shane Downeyshane.downey@mater.org.au

@shane_downeyhttp://au.linkedin.com/in/sjdowney/

Please complete the evaluation form

.

© 2014 IDQS. All rights reserved.

25