The most interesting to me is this document of the release is this one:
Vic IHI Integration Clinical Risk Assessment Report v1.1
The document is one of a series of specifications and so on produced as part of a IHI Pre-Implementation Project between NEHTA and HealthSMART.
An overview is found here:
Vic IHI Integration Project Deliverable Release Note 1.0
Overall the project is to deliver the following we are told:
“Project deliverables include:
• Business Requirements
• IHI Integration Functional Design
• IHI Clinical Risk Assessment
• IHI Best Practice Guide
• IHI Integration Technical Design
• IHI Integration Solution Architecture.”
Interestingly the IHI Solution Architecture itself was held back for a later release as it was not ready yet (as of 11-02-2011).
As mentioned, I was especially interested to read this document. Interestingly the risks around the use of the CDMS as the source data for the HI Service seem to not get much discussion or review as far as I can tell.
2.2 Clinical Risk Assessment
This document provided an important input to the Vic IHI Integration Design, and much of the design exists to address the risk areas identified. This document was prepared by the project team with input from health service and other staff well versed in evaluating and mitigating clinical risks.
This document is user and clinician focussed, but may also be of interest to designers and architects of health IT systems.
This is the Table of Contents:
Table of Contents
1. Document Overview
1.1 PURPOSE
1.2 INTENDED AUDIENCE
1.3 REFERENCES
2. Introduction
3. Scope
4. Risk Assessment Report Summary
4.1 APPROACH
4.2 IMPLEMENTATION ASSUMPTIONS
4.3 RESULTS OVERVIEW
4.4 DISCUSSION OF THE HAZARDS ASSESSED AS MEDIUM
4.5 DISCUSSION OF THE HAZARDS ASSESSED AS LOW
5. Detailed Hazards Assessment and Recommended Controls
5.1 HAZARD 001: MISIDENTIFICATION OF THE PATIENT ASSOCIATED WITH AN IHI
5.2 HAZARD 002: INABILITY TO IDENTIFY PATIENT BY IHI IN CLINICAL CARE SETTING
5.3 HAZARD 003: PRIVACY OF PATIENT INFORMATION IS BREACHED
5.4 HAZARD 004:WHOLE OF PART OF THE SYSTEM IS UNAVAILABLE OR ACCESS IS INAPPROPRIATELY DENIED
6. Appendix: NEHTA Sentry Clinical Safety Risk Assessment Criteria
6.1 CLINICAL RISK SEVERITY CATEGORIES
6.2 LIKELIHOOD CATEGORIES
6.3 CLINICAL RISK CLASSIFICATION MATRIX
7. Glossary.
Just a few comments:
First just why is this the first time we have heard of this document?
NEHTA Hazard Assessment Report – Health Identifiers Release 1, v 1.0 , Feb, 2010
Second on page 6 we read:
“A constraint upon this review was that specialist training in NEHTA Clinical Safety Management methodology, and NEHTA Clinical Risk Assessment of Release 3 HI Service functionality was not available at the time of this Risk Assessment. Capacity to participate in Jurisdictional Clinical Safety Management was identified during this project as a gap in NEHTA support. The NHCIOF have subsequently sponsored a Gap Analysis and Clinical Safety Management Model to be delivered by NEHTA in January 2011.”
Translation from bureaucratese - The team were not ready and not trained to undertake the review!
Further on we read:
”The introduction of healthcare identifiers, whilst designed to improve quality and safety in clinical communication and electronic identification of patients to support clinical care can also increase risk of harm to patients.
The Australian Commission on Safety and Quality in Health Care, Report ‘Review of Technology Solutions to Patient Misidentification’ (2008) notes that:
Throughout the healthcare sector, the failure to identify patients correctly and to correlate that information to an intended clinical intervention continues to result in wrong person, wrong site procedures, medication errors, transfusion errors and diagnostic testing errors.
In examining the potential for technology to assist in solving this problem, the Commission’s key finding noted:
· Diligent execution of appropriate process/workflow remains the key aspect of patient identification. Technology is an enabler, not a sole solution.
· To be successful in the long term, implementation implies ubiquitous deployment of the technology throughout the patient journey.
· The importance of formally developed corporate implementation strategies, planning, and process scoping should not be underestimated.”
So this implementation all needs to happen pretty carefully - or some big issues can flow!
Third on page 8 we then read:
The preferred architecture for the IHI capture in the Victorian health service is as an alternate identifier. The local URN will not be replaced in the short term by the IHI in Victorian health services.
This Risk Assessment did not consider the obtaining and use of healthcare identifiers beyond the individual healthcare identifier (IHI), i.e. the scope does not include Provider Healthcare Identifiers, HPI-I and HPI-O.
This leads one to ask just when the system will actually be trusted in use. Not soon would seem to be the answer.
It seems to me the real ‘guts’ of the assessment is here. On Page 10.
4.3 Results Overview
“Assessment of the level of Clinical Risk associated with the introduction and use of the IHI was seen to be mitigated internally for health services through its use in conjunction with a local UR number. The effect of not relying solely on the IHI was that it reduced overall risk levels. Therefore it is important to realise that the ratings noted in the following review would have been assessed as higher in a situation where the IHI is used singularly to identify a patient.
Where the IHI is used singularly at the point of exchange between health services, ie the sending or receiving a patient referral with an IHI, increased checking of patient demographics with the HI Service to verify the IHI has been included in the controls.
There were two key Clinical Hazards reviewed where the clinical risk was assessed as Medium, however only where the IHI is used in conjunction with a local UR number. If the IHI is used in isolation then these Clinical Hazards would result in High risks.
The identified Hazards were:
· Misidentification of the patient associated with an IHI.
· Inability to identify the patient by IHI in a clinical care setting.
The rating of Medium defines that the clinical risk is of moderate severity and that it may create a situation that is serious and potentially life threatening, however the clinical risk may also be avoided/prevented by a Clinician. This level risk requires that stakeholders be notified of the risk as soon as practicable and appropriate mitigating actions agreed.
If the IHI is used singularly these Clinical Hazards would be considered High risk. High Risk signifies major or catastrophic severity risks that create a situation that is inherently and immediately threatening to a patient’s life. The clinical Hazard may results in permanent harm and/or death to a patient. Harm is unlikely to be prevented by a Clinician in these circumstances. This category will also apply to a Clinical Hazard that causes many occurrences of Moderate or Major Severity.”
This really seems to be saying that, at present, relying on the IHI alone is not recommended and hence the decision to go with both the URN and IHI.
If ever there was a case for staged careful implementation of this service this assessment seems to make it pretty strongly.
It also seems to me that developing a PCEHR service to rely on the HI Service, with unproven work practices and flows, until we are sure all the wrinkles of the foundation are fully managed would be very silly indeed. The technology really does not matter unless the HI Service is a real improvement on what is happening now - and it is not obvious that is true.
We won’t even mention that the overall situation of the HealthSMART Program also seems to be under review!
David.
0 comments:
Post a Comment