Individual Healthcare Identifiers (IHIs) Not just a number Antonio Abbenante Manager, Design Authority, OCIO
Some History and Current Context COAG Business Case for National Identifiers in 2006 Australian Standards for Identification in 2007 NEHTA design of HI Concept of Operations in 2009 HI Service Act with Medicare as Service Operator, Office of the Australian Information Commissioner as regulator 1 July 2010 Victorian Wave 1 and Wave 2 PCEHR using identifiers in 2011 Victorian Rapid Integration Project in 2013. epip incentive and NEHTA panel for GPs and Aged Care 2013 Independent Review of HI legislation and service operations 2013 MoU on National EHealth Capability 2013 Refresh of National EHealth Strategy and Business case 2013
HI Service and IHI Overview HI Service Designed by NEHTA Implemented and operated by DHS (Medicare) live 1/7/10 Supports IHI, HPI-I and HPI-O All active Medicare and DVA enrolees have been assigned an IHI NASH implemented in 2013 Technical controls Compliance Certification Accreditation (CCA) Security controls Security Access Framework (SAF) Diagram courtesy NEHTA
IHI key attributes 1. Concept of one person, one IHI will apply for the vast majority of people, but cannot be assumed to work in all cases 2. An IHI record may have 3 Record States and 5 Statuses, which potentially require different processing and locally implemented business rules 3. Even Verified IHI s will change over time i. Will change state to Deceased and Retired ii. iii. May be merged if a duplicate exists May be demoted to Unverified (unusual) 4. Consideration i. A health service that will only support Verified IHI s may receive Provisional or Unverified IHI s from external sources #: 123 Unverified Resolved #: 323 Verified Resolved #: 789 Verified Active #: 555 Provisional Resolved #: 898 Unverified Resolved #: 456 Provisional Expired
Victorian Health Services Current State Even smaller Victorian hospitals are likely to have over 1 million (electronic) patient records The largest Victorian health service (Southern Health) has approximately 7.7 million patient records Estimated total number of patient records for health services using the ipm system is between 30 and 40 million records Based on our analysis the Medicare number field is completed in approximately 50% of records Patient admission / registration is distributed within the health service with most health services having over 20 registration points
IHI Business Processes The Functional Design has been based on three typical Public Health Business Processes : Referral before Presentation Patient Presentation Un-Referred Presentation ED and Walk-ins These Business Processes have been used to capture the occasions of use of IHI over the end to end patient pathway; including Registration, through treatment, to discharge and referral on.
IHI end to end process IHI Processing Pathway Primary Care Out of scope Referral Registration Presentation Care Co-ordination Referral health Patient/Client Health Service HI Service service Match and return IHI for patient search Obtain IHI Health Service retrieved IHI Start Match and return IHI for patient search Check IHI Referral Received with IHI Patient Attends health service and Clinician Refers on Is the patient in the PAS? Yes No Obtain IHI Register New patient Match Existing Patient Match and return IHI for patient search Check IHI Obtain IHI Validate Referral IHI to PAS IHI Triage & Book Patient Appointment/WL Send Referral Acknowledgment Receives Referral acknowledgm ent Update IHI if Required Patient Receives appointment booking Obtain IHI Register New patient No Is the patient in the PAS / has appointment Patient Presentation Start Yes Match and return IHI for patient search Check IHI Obtain IHI Match Existing Patient/ Appointment Produce patient Identification data Broadcast patient Identification data to downstream systems Patient Treatment/ service Event Notification/ Referral Update Check IHI Referral On Required Check IHI Orders including IHI Receive Order with IHI Receive Referral with IHI Recieve copy of Referrals and/or Discharge Match and return IHI for patient search Check IHI Discharge Summary prepared Check IHI Receive Discharge Summary with IHI End
Use Case List Obtain IHI Search for IHI Update IHI Generate IHI Exception Check IHI Send IHI Request Send Unverified IHI Request Request Bulk IHI Check Send Death Details Validate IHI Resolve IHI Number Discrepancy Resolve IHI Record Status Discrepancy Create Patient record Update Patient record Merge Patient Records Unmerge Patient Records Process IHI Exceptions Scan for Patient Record Anomalies View Exception Report Send Referral Send Discharge Summary Send Order Receive Referral Process Referral Create Waiting List entry Create Appointment Send Referral Update Send Referral Cancellation Receive Discharge Summary Send Discharge Summary update Receive Order Send Results Receive Results
IHI Use in Clinical Settings Within a health service 1. Current state i. Health services have many internal systems that store patient data, and not all support automated mechanisms for creating or updating patient information ii. iii. Many systems produce patient reports that currently include the service URN, and would be expected to have the IHI included in the future In Victorian health services the PAS usually acts as the patient master, distributing patient data to other applications via HL7 2. Future State (IHI adopted) i. Health service staff are familiar with the IHI and put trust in it as an identifier for a patient, although the Service URN number remains in use ii. iii. Many more internal clinical requests (eg orders) are now electronic, and the IHI is included in all internal electronic messages (HL7 PID segment) The IHI will be incorporated on all patient reports, and all health service applications support storing the IHI, enabling users to locate a patient using the IHI
The Design Authority Best Practice Guide The Best Practice Guide outlines: Practice Principles, Business Requirements and Recommendations Phased Change Management approach Business Processes applied IHI Use Case Functions issues explored IHI Exception management processes explored Policies and Procedures recommended It is not a full implementation guide outlining detailed implementation activities an Implementation Planning Study is still required.
Implementation Stages Phase Clinical Staff Admissions Clerks HIM s IT PAS Team Development & Preparation No impact Obtain Medicare (MC) numbers Support obtaining of MC numbers Pre-deployment No impact Testing Testing Initial Data Load planning IHI Transition Awareness Continue to obtain MC numbers Use IHI to support functions IHI Steady State Awareness Use IHI to support functions PCEHR Steady State Training and adoption Use and benefits As above & process for patient consent Resolve issues and ensure max number of IHI s are obtained Use IHI to support dupe mgmt As above As above, impacts of clinical records Limited impact Deployment & IDL planning Support for system level errors, eg badly formed msg Maintain system Deploy enhanced system, and maintain As above As above Maintain system Design and development Testing & app support App support & maintenance App support & maintenance Enhancements to support PCEHR/CEHR App support & maintenance
Wave 1 Exchange of referral and discharge Eastern Health Sends standard CDA Discharge Summaries to GPs 100 GP Practices Companion Tool GPs send standard CDA Referrals to Eastern Health
Technical Architecture for Wave 1 Health Service Systems OCIO Production Gateway Wave 1 Gateway Eastern Health Production Gateway Clinicals Cerner Millenium ESB Oracle JCAPS ESB Oracle JCAPS ESB Oracle JCAPS AMT /, SNOMED Discharge Summary Ref^I12 Production Discharge Summary Flow EH Ref^I12 DS Redirection Ref^I12 Obtain IHI (HI Service I/F) Obtain HPIs (HSD I/F) MDM^T02 EH Prod Disch Summary Flow EH MDM Routing Ref^I12 Generate CDA Disch Summ y IHI Extraction and Storage Encapsulate DS Generate MDM Transmit MDM Legend New Wave 1 Functionality Ref^I12 Certificate Store Web Services request / response Web Services request / response External Services MDM^T02 Ref^I12 IEMML GP Practices MDM^T02 Internal network ehealth Foundation Services Provider Directory Services Messaging Services Via Internet HI Service Human Services Directory HealthLink Production DS flow
Rapid Integration Project Wave 1 successfully implemented including all national identifiers and AMT but limited by GP vendor capacity (now resolved) Barwon integrated with HI Service as part of Wave 2 Medications project using HL7 message from BossNet (proprietary) Design approach for Eastern Health is independent of clinical system (based on JCAPS middleware used across Victoria) Rapid Integration Project involves posting discharge summaries to the PCEHR (with consent) and enabling public health staff to view the PCEHR in Eastern Health and Barwon Project is on track to implement in October 2013 in Eastern Health Implementation Planning Study is underway in Barwon Extending functionality to other sites under the Rapid Integration Program will be subject to availability of funding from NEHTA
IHI Clinical Context The use of a universal IHI will assist in making healthcare safer and increase quality through prevention of patient identification errors and streamlined communication (right patient, right place, right time). Patient Identification Errors can be characterised as being caused by: The identity of the patient not being clearly established, such as when one patient is mistaken for another, and / or The nature of the intended care (including procedures / treatments / medications) is not clearly established, which may result in the correct procedures / treatments / medication not being applied to the correct patient The Australian Commission on Safety and Quality in Health Care, Technology Solutions to Patient Misidentification, Report of Review, 2008,
IHI clinical context For these errors to be minimised the ACSQHC advises that: Every patient must be uniquely identified in an unambiguous manner This identification must be maintained consistently throughout the period of care Each procedure / treatment / medication must be uniquely identified in an unambiguous manner This identification must be explicitly tied to all requests, medications, procedures, devices, etc applied to the patient
Implementation Challenges and Opportunities Challenges There is a large data cleansing and change management task the IHI is not just a number it must be properly managed The variety of patient administration systems in use across Victoria adds complexity and cost The national HI Service is still maturing and is likely to undergo some changes following on from the HI service review Opportunities Adoption of IHIs supports Victorian government policy, the National EHealth Strategy and has strong stakeholder endorsement Victoria has acknowledged expertise in the safe use of identifiers The Rapid Integration Project provides the ability to leverage work in both lead sites and other jurisdictions, reducing vendor costs Programs like VCCC provide the opportunity to gain support and direction from NEHTA in the use and adoption of identifiers