The Rotherham NHS Foundation Trust has been found in significant breach of its terms of authorisation by Monitor, with its electronic patient record implementation identified as a key issue.
The trust this month admitted it was facing "persistant serious issues" with the deployment of its Meditech EPR including "clinician and staff acceptance and usability."
It has stopped all go-lives of the system and has hired an external consultant, Larry Blevins, to conduct an immediate review of the system.
A statement from Monitor said The Rotherham had significantly underperformed on its financial plans leading to concerns about the way it was governed.
Key concerns included the trust’s failure to successfully implement a new EPR which led to problems booking patient appointments and loss of income.
A letter from Monitor to The Rotherham says: “The trust has not managed EPR implementation in an effective way and significant operational and financial risks will remain until the trust has a robust and operationally effective EPR system."
“It is unclear whether the trust has sufficient visibility over operational performance and quality issues, including incidents of patient harm,” it adds.
“Data quality remains a significant risk. The trust is currently unable to rely on coding, case mix or activity data from the EPR system, significantly compromising the trust’s ability to manage performance effectively.”
Earlier this month, the trust issued a statement regarding the appointment of an interim chief executive. This said it had discovered “significant issues of operational and financial performance” which needed to be addressed urgently.
“The board will institute a strategy to correct or take other actions concerning the EPR system in such a way that it does not hinder or slow the work of clinicians, nurses, AHPs and others during their time caring for patients.
“We have engaged an independent external EPR expert, with experience in multiple types of implementations,” said the statement.
“His job will be to review and resolve the issues causing the EPR situation from an independent standpoint.”
The trust went live with its Meditech EPR last summer, two years after the original planned go-live, and has experienced difficulties with the system since.
Board minutes from the trust’s EPR programme board meeting in October last year, obtained by EHI via the Freedom of Information Act, revealed that the trust had stopped the phased go-live of the system.
“Until all current issues had been resolved there should be no further implementation of EPR phased go-lives,” the document says.
The following month’s EPR board minutes reference the non-executive director chair of the audit and assurance committee raising concerns that there may be financial pressures and risks related to the system.
“As such he suggested that the trust should consider allocation of a further financial contingency or reinvestment in EPR,” the minutes say.
Stephen Hay, managing director for provider regulation at Monitor, said it was concerned that the trust's failure to address its financial issues was due to "the lack of adequate strength and capacity within the management team.”
The trust board has engaged a specialist healthcare management firm, Bolt Partners LLP, based in London, to lead the trust’s recovery.
Michael Morgan has replaced Matthew Lowry as interim chief executive after former chief executive, Brian James retired last year.
“Bolt Partners will provide three recovery and restructuring professionals on an interim basis, Michael [Morgan] will be engaged with immediate effect as the trust’s interim chief executive to lead the recovery and restructuring,” said a statement from the trust.
The trust has also taken out a full page advertisement in the local paper to reassure the public and staff that it has sufficient cash to meet all payroll and creditor obligations.
The Rotherham was one of the first trusts to go outside the National Programme for IT in the NHS for an EPR and was the first NHS trust to purchase the latest Meditech system. The value of the deal has been put at £40m over ten years.
In October last year, Unison claimed the trust planned to cut 750 jobs over the next three years to save £50m over four years from its £220m budget.
© 2013 EHealth Media.
Value of EPRsHealthCTO 90 weeks ago
Here's another recently published article on the value of EPR/EHR...
It is a US perspective but it reference several peer reviewed articles. Happy reading!
How did the CCIO get on?Jack Barker 90 weeks ago
Much has been made of the role of a CCIO in successful IT implementations. This must have been a traumatic time for Kim Ashall but it would be very interesting to hear from her what she thinks went wrong.
The Kaiser Storytimbenson 90 weeks ago
The Kaiser story is fascinating, because there are two good books on it:
(1) Louise Lang: Connected for Health: Transforming Care Delivery at Kaiser Permanente. Jossey-Bass 2010 "Kaiser Permanente has implemented the largest nongovernmental electronic health record in the world, serving more than 8.6 million Kaiser Permanente members. Called KP HealthConnect, its impact on patient care outcomes, efficiency, safety, and patient engagement and satisfaction already is of intense interest throughout the health care industry. In this volume, Louise L. Liang, MD, who led the massive KP HealthConnect implementation, collects lessons learned from the organization%u232s successful deployment strategy and highlights ways in which the new technological tools are changing and improving %u213 the health care provided to patients and the operations and culture of the organization"
(2) Tim Scott. Implementing an Electronic Medical Record System: Successes, Failures, Lessons. Radcliffe 2007. This is the story of the failure to implement the rival CIS system which had been successful in Kaiser Colorado in Kaiser Hawaii.
Data Quality IssuesLaburn 91 weeks ago
Everyone mentions systems and expertise failures, but not a single comment about data quality and data migration. This is one of the biggest failures in these sorts of projects and not having the expertise in these areas for an EPR project is a recipe for disaster.
Migrating data from very old existing systems with structures and data collection processes that do not support current working practices, into structures that are markedly different (and hopefully should support more recent initiatives) and getting this done in a timely manner by people who may not necessarily understand the complexities of NHS data, and its linkages has always caused problems with these projects.
So don't always blame the systems to which the Trusts are migrating.
That Old ChestnutCanUseeTheLight 91 weeks ago
1) Data migration is not difficult assuming that
a) One has an understanding of the Relational Model
b) One has an understanding of the source system schema
c) One has an understanding of the target system schema and the rules which govern it operation
d) One has an understanding of the processes involved in coded data mapping
e) One has an understanding of role based access control assuming source and target systems support it
2) Any data to be migrated from an existing patient administration system to an EPR should not be difficult at all assuming that
a) All points in 1) above are met
b) The source system was compliant with the NHS Data Dictionary (as any system in use in the NHS MUST be) and the target system is so compliant to the extent that it incorporates patient administration functions as an EPR.
Laburn implies that EPRs have a completely different structure, they don’t, or at least they should not. Any EPR should comply with those aspects of the NHS Data Dictionary with all the extra clinical content structured around the core PAS content. An EPR must after all support both. There should never be any issues with data migration only the manner in which it is performed. If point 1 and 2 above a met then failure must be due to execution which points to supplier failure.
NHS data is no more or less complex than any other large scale enterprise it is, after all, just a bunch of strings, numbers, dates and blobs (over simplification but you get the idea) organised in a particular way. Data is just data.
reply to its not as simple as that - I still think it is and this is whyCanUseeTheLight 90 weeks ago
Understanding is not a little thing – my use of it was deliberate and applies at two levels, 1. the relational model in respect of physical database design and 2. When applied to NHS specific data,.
As I said in 2.b, systems which are sold to the NHS are required to be NHS data dictionary compliant, many are but many are not (although they claim to be). I have migrated data from many such systems as an NHS employee and as a supplier. What I think is required is a certification process which warrants the supplied system is NHS Data Dictionary compliant, no certification no permission to deploy or sell to the NHS.
At that point a generic data migration process could be defined for the core data structures with variations being made for system specific functionality where it can be mapped following the rules of relational logic.
I must respectfully disagree with your assertion in respect of data quality however. The problem arises from systems not adhering to the NHS model and the subsequent Type 1 and 2 validation errors which then lead to poor data quality.
Forgive me teaching you to suck eggs, but, Type 1 errors occur when inappropriate structures are used to store data (supplier shortcuts or someone thinks it’s a good idea) e.g. a predominant use of STRING fields to hold alphanumeric data (good) or dates (bad) or numbers (bad). Type 2 errors occur when the physical data model is not appropriately constrained (all relational database platforms support constraints). Omission of constraints (which should be at the database level but can also be in the application layer) means the possibility of orphaned rows is greatly increased e.g. a ward stay record with no corresponding hospital provider spell or ward record. Adherence to the points I mention and an understanding of relational theory and practice is all you need to migrate data from system A to system B.
Here is my recipe for data migration success distilled to its essentials
1. Pick a migration strategy predicated on the data domain, in this case health care – I like to migrate data on a patient by patient basis, after all its all about the patient with a bunch of other data around the core patient dataset
2. Obey the rules of the strategy – data to be migrated must pass Type 1 and 2 validation checks and said checks must be performed against the entire data set not a sample or subset.
3. Identify all failures and why, only process the resulting passed records. Meanwhile Trust staff can attempt to rectify the Type 1 and 2 errors in the source system.
4. Migration process should be iterative and non destructive
5. Test migration of a subset of patients (ensure subset covers entire source system data to be migrated) to validate the process and compare the results in the target system with the source system side by side at the application level.
6. When processing the data, if any part of a patients record fails to obey the rules of the target model the error is logged and the entire patients record is rejected. This allows for the possibility of fault rectification in the source system by Trust staff, who now know what the problem is and said data is ready for resubmission during the next iteration. It also guarantees the data quality in terms of dates being dates numbers being numbers and things like ward stays not starting before admission or referral records.
7. ON NO ACCOUNT MANIPULATE DATA IN ANY WAY WHICH ALTERS ITS VALUE – obvious I know but it hammers home the fact that data migration is just that and is not a data cleansing exercise. It is a like for like data transfer with no reference to data values. This ensures that the only resulting data quality issues are ones of omission i.e. the data is not there in source system or data entry i.e. wrong spelling wrong date wrong number. If the target system is appropriately designed such validation checks would be handled.
I / we have been doing this since 1994, migrating data to a target database from a single or multiple source systems from the same or multiple suppers. Our processes have never achieved less than 95% of source data migration of 10’s of millions of rows. It is a complex process but the complexity comes from quantitative not qualitative issues, as such I stand by my premise that it is just not difficult irrespective of the data being banking, utility payments or healthcare.
Happy to discuss on or offline :)
Its not always as simple as thatLaburn 91 weeks ago
I do agree with your points 1 a - d (not entirely sure what RBAC has to do with data migration though), however the key thing is that little word 'understanding', which in many cases just isn't evident at most Trusts. Without a DM expert (and even with, in most cases) the project are fraught with difficulty.
And sorry, but the source systems are often not compliant otherwise why do so many Trusts have to employ data workarounds for data collection and to handle such things as RTT correctly?
'NHS data is no more or less complex than any other large scale enterprise it is, after all, just a bunch of strings, numbers, dates and blobs (over simplification but you get the idea) organised in a particular way'
Yes what you are suggesting is an oversimplification, yes its 'just data' but not always stored coherently or in a nice standard format as is evidenced from the many disaster tales of data migration in PAS upgrades. Take away bad quality data and the information teams could suddenly be a whole lot more useful in their roles within the Trust. And yes, sorry, but healthcare data is more complex than that found in a banking or insurance system.
EPRs WorksHealthCTO 91 weeks ago
My team successfully implemented a commercial EPR (happened to be Epic) in a US health system with 9 million patients, 32 hospitals, and 12,000 physicians (plus 70,000 nurses and other health professionals). It happens to be Kaiser Permanente for those who are curious.
It works really well...because the chief executive was the sponsor, clinicial leadership was committed, and the project was properly resourced by both clinical and IT staff who were trained to develop and deploy the system. One of the realities is that you WILL need to evolve the approach to the patient experience to get the right data - into and the value out of - your EPR investment.
It is really, really hard work and you must deal with policy, process, work rule, and other factors as part of the EPR adoption. Implementing and EPR because you are told to do so will usually fail (DoH requiring NPfIT and doing it centrally was doomed from the start.) The minister demanding the NHS take another swing at it and not providing the proper foundation support to prepare trusts for the work involved is nothing more than preparing for the next failure.
EPRs provide a foundation of computable information that will allow you to manage chronic disease populations, integrate care, measure results and engage patients...just not all at once. You can build the new house AFTER you attend to the foundation. EPR is your foundation.
One last observation: There are a lot of bad consultants out there. Unless you are clear about what you want, do good diligence, contract well (including right to pick your consultant team instead of using whatever recent university graduate they throw your way), and actively manage them - you deserve the lousy value you get.
I would encourage you to seek understanding of the value an EPR can provide and drive to achieve that value through a properly managed project (which is a whole lot more than IT screwing the software into the organization!). There is enough evidence of EPR success (unfortunately not enough of it in England) that you should focus the debate on how to get there - not whether.
Not every one agreesOzLurker 91 weeks ago
It is almost impossible to get objective verification of the 'success' of the Kaiser P EPIC implementation that I believe cost $4+bn (some say $6bn), yes billion.
For less positive views see the ED Chief's opinion & some of the comments contained and appended to the NYT article below. There was also a public outcry about chaos and fears for patient safety at a large hospital in San Francisco after an EPIC switch-on(see; hcrenewal.blogspot.com.au/2012/09/in-addition-to-nurses-doctors-now-air.html ) where nurses and doctors spoke out to local press, but funnily enough a US journalist contact of mine says that suddenly no one will any longer go on the record.
I have not seen EPIC and there are no UK or Australian reference sites, but posts like the one above remind me more of the spruiking of the currently over valued Australian property market by all self-interested parties, rather than an objective independent analysis (NB USB says Aussie houses are 20-40% too expensive).
Please show me the peer reviewed scientific paper that proves Kaiser saved more than $4bn as a direct cause of implementing a new integrated EHR over the last decade.
Interesting, but not relevant...HealthCTO 91 weeks ago
Let's deal with some numbers...
The original investment for KP was $1.2 billion. With additional investments (read more stuff, not project overruns), it grew to a little over $2 billion in capital investment. What did that buy Kaiser?
- 9 million members have an electronic record with instant availability to any of the health works in the system (the old paper charts were "unavailable" 35% of time when needed (from time/motion studies) at unknown cost of clinical decision errors caused by not having the information when you needed it
- 16,000 physician (from GP through all specialties) trained and using a SINGLE EPR which now allows a whole raft of new clinical activities unavailable under the old paper-based system
-37 hospitals and over 600 medical offices wired together and receiving 7x24 access to the health record 365 days per year with 99.99% uptime
- Those 9 million member having the ability to see their health record, order prescription refills, email their caregivers, and perform many activities that used to require them to undergo the inconvenience of an office visit
I could go on but there are any number of studies done - both by Kaiser staff and 3rd parties - that discuss both the ROI (return on investment) and ROH (return on health) benefits that Kaiser has achieved through their investments in moving from a paper-based, craft-oriented model to one that is changing how care is provided (including on average 20% reduction in cost of delivered care with significantly higher clinical quality indicators).
You can always find examples of projects that don't work (and you cited several including the San Francisco failure that I am familiar with). Those are interesting and even educational as examples of how not to implement an EPR. They are emphatically NOT a reason to avoid the hard work and the rewards of implementing one.
I will take the $2+ billion success that Kaiser achieved (and documented...just go look, starting at http://www.kp.org) any day over the $20+ billion failure of NPfIT. You should seek to learn from both of these examples so that you do it right the next time...not shirk from doing it at all.
IMHO (stands for "In My Humble Opinion").
This is about management, skills and shared experiencePhilC273 91 weeks ago
Implementing EPR is really complex, but surely that is no reason to start doubting why we should do it? Implementing in bits rather than in a small number of large applications doesn't necessarily fix the issue.
Health processes, systems and data are just about the most complex in general use and the implications of error some of the greatest. We accept this and yet expect individuals and organisations who are not specialist in procuring and implementing these to run a massive programme once only in their working lives. They cannot have experience (they've not done it before) and they don't get to pass on the learnings (they get back to their day jobs and don't do it again).
The Rotherham and Berkshire issues are, for the most part, about failings in management; management of the procurement and management of the implementation. It's too trite to say the big EPRs are flawed or we need best of breed and it will be OK etc. Several solutions could and should work satisfactorily, but only if the programmes were run like a civil engineering project rather than choosing a laptop or a TV.
We should be looking to address the biggest problem here, namely the lack of skills and the lack of shared experience. We should find a way of pooling expertise across the NHS, sharing skills for these programmes by seconding staff and back filling posts. This isn't so much about implementing the right solution as implementing the solution right.
Half RightOzLurker 91 weeks ago
Your first two paragraphs are correct and you are also correct un stating that poor management (and by inference poor contracting) has contributed to the problem.
However you are incorrect in your assessment of the underlying problem at Rotheram, Reading and elsewhere. Unfortunately it IS the software that's at fault and more specifically it is the inflexibility of the programs and the assumptions that have gone into their creation that guarantee failure. To acknowledge the complexity and variability inherent in any doctor-patient interaction and then to try to create a digital mirror of the event as if it were part of a nineteenth century manufacturing industry is just a complete intellectual contradiction. It is exactly this kind of thinking that has created the current EHR crisis for Secondary and Tertiary care in England and beyond. If you think these systems are all flying through the work Stateside please disabuse yourself by reading this and the comments appended;
Thereneeds to be an entirely new approach of clinical analysis of workflows & processes in hospitals supported by a new plastic software platform that can be easily reconfigured by front line staff and data managers, that captures what can by truly digitalised and acknowledges what can not (Such a process will produce many opportunities for efficiency gains and problem solving even before new IT is created). Any such new product will have to have an intutitive interface, preferably be touch screen and web enabled and with NO clickorrhoea, as well as being easily used when hand held. The building blocks for all of this exist, the political and incidentally the medical will for more accurate data capture and recording of events by technology exists, but for the most part the Industry stil thinks it can force mechanical workflows on the most intensely individualised biological work place in the world and the bureaucrats still (for some completely obscure reason) believe that spending millions on Management Consultants who know nothing about IT nor Healthcare will ensure smooth implementation of e-Health!
Let's get the best people together who know what they are talking about in Health, IT and and workplace analysis (eg Porsche Consulting - I'm not kidding they did wonders for Hospitals in the former East Germany), really attempt to understand the current failures and then grab a blank piece of paper and start again.
Health Story is an interesting projectNeelam Dugar 91 weeks ago
Standardising unstructured narrative medical documentation is essential for NHS Informatics. HL7 CDA is the document format globally supported & also supported by IHE.
Pay for interoperabilityNeelam Dugar 91 weeks ago
Tim, I don't think getting the clinical recipients to pay is really going to work.
Using the PACS example
1. adopt global standards--DICOM, CDA, XDS, XDR etc
2. Standards should be developed by vendors themselves--DICOM & IHE are a collaborative effort by vendors
3. standards should be free--allowing SMEs to use & develop them--DICOM, HL7 etc
4. Clinical users should be able to understand what the standards will do for clinical usage--
This is what I like with IHE concepts are easy to understand for clinical users.
5. Connectathons used for testing interoperability between vendors--IHE uses this.
Clinical users in secondary would like this
1. A single viewer which can be loaded in 3seconds which displays all medical documents & images for that patients--referral letters, clinic letters, discharge summaries, path reports, radiology reports, endoscopy reports, medical images--radiology, ECG, blood results, etc (what I have decsribed here is the medical notes but without the day-to-day ward entry.
2. electronic transfer of medical documents between primary & secondary care in a readable document format--with ability to paragraph, bold, high-light & emphasise narrative documents.
It is based on these requirements I feel that the way forward for NHS lies with CDA, DICOM, XDS & XDR
Now the big question is who will pay for patient & clinical needs. In the PACS world, the vendors invest in DICOM standards in their products because they KNOW they cannot sell unless they comply.
My view for Commission Board staff to visit IHE connectathons & see for themselves the power of vendor collaboration & interoperability & use IHE for the way forward
There is nothing simple about ePRs or interoperability-and I live thiswilliamlumb 91 weeks ago
Sure we need the technical ability enabled by common standards-but that gets you no-where without sorting the politics, the clinical standards, the information governance, the transformational change agenda, the capacity of staff to learn IT systems, the cross organisational care planning, the sharing of clinical records and data standards, the governance process and the designing out of variability in clinical care.
This process must be clinically lead with close IM&T support and quality project management to enable deployment. It can be done but not with a patchwork of software products from SME's- if no other reason than because your staff cannot attain the proficiency needed to operate multiple systems built with differing design concepts. We have the tools already-what we lack is the ability to link strategy, tactics and operational deployment in a coherent fashion.
Come and look at ICT in Primary Care in the UK-it works because our job satisfaction, working hours and pay depend on effective ePRs with interoperability.
It is not the same.OzLurker 91 weeks ago
Will, Much of what you say is completely right - without the organisational processes and standards being in the right place you can not get anywhere, but there is a real problem with the last paragraph.
Across the English speaking world the idea that "it works in GP surgeries so it will be easy to scale up for secondary and tertiary care" has been a simplistic and dare I say it lazy intellectual cul-de-sac. GP's appointed to run such National scale ups have struggled badly I can assure you. As a paralell, we (seven consultantrs) run a simple EHR in our rooms for an O&G private practice. It is good at some things not so good at others, but serves a purpose, more for activity than for fully functional e- medical records. It is a very successful commercial product, but lacks proper tracking and many other features. I would not let ths software anywhere near my hospital Department as the only instrument of record or administration, and I have not even mentioned our hospital based UG and PG teaching requirements and complex in-house and international research program some funded by grants other by pharma etc etc.
Please see and understand my reply to PhilC273 above if you want to understand how we need to work to get functional e-Health into major hospitals. Big versions of GP systems simply will not cut the mustard.
Good luck with the rest of it,
One of your former Consultant/mentor colleagues.
Pay for interoperabilitytimbenson 92 weeks ago
Surely the answer is just to pay for information delivered to the people who need it when they need it, and not for lumps of kit or software.
Users should be able to work out what information they need when and where, even if they are not capable of evaluating whether computer salesmen are talking nonsense or not.
We have to accept that nobody knows a good way to procure healthcare IT systems (hardware and software). We do know that none of the ways of procuring IT for health care that have been tried to date are not fit for purpose. It is doubtful if, after more than 30 years of failure, they can be made fit for purpose. Perhaps the solution is to pay for information instead.
The new CCGs could take a lead in making this happen.
Not fairMrDog 91 weeks ago
Throw away statements like "30 years of failure" are not helpful. People do this all the time saying things like "the NHS is terrible at securing your data", and they just become embedded truisms.
There have been lots of successes where people have been allowed to rationally assess their priorities and work within their local architectures etc. Two main things have failed however:
- Where some national body has tried to impose a large piece of software or technology within an already complex environment, thinking that they somehow knew what was needed. This is about to happen again where someone is talking about forcing in systems that will produce data that someone thinks that someone else will need or use.
- Local intransigence, and either buying or hanging on to legacy products. I go back to the 90s and the basic levels of compliance. Start there, and if an acute trust cannot deliver solid patient index with solid real time interfacing to that to all of its systems, they should be performance managed. Then onto the next level of compliance. Anything overblown has indeed been shown to fail, time and again.
30years of failure?george385 91 weeks ago
I could not agree with MrDog's comment more - there are examples out there in the NHS that are working. IT is an enabler of the business and needs investment - ongoing investment. IT is not a magic bullet and just installing a computer system and expecting improvements is not the answer.
Resourcing of these programmes needs to be realistic and managed effectively throughout the duration of the programmes lifetime.
Government ResponsibilityNurse Sandy 92 weeks ago
Excellent points. It is the responsibility of the governments of each country, perhaps an international agreement, requiring the use of universal language and interfaces. Rather than setting capricious targets, spending billions of pounds and dollars for consultants and systems not fit for purpose, the leaders whould have required by law and treaty the universal language and codes to enable interoperability.