Why is ‘IT’ all so hard in Pathology?
At the heart of a modern Pathology laboratory is a complex set of Information Technology (IT) systems that are critical to its operation. Users are often frustrated and disappointed at the difficulties they experience when systems fail, when requesting changes or seeking new IT functionality. Having worked in a number of industries before coming to Healthcare four years ago, I have tried to make some sense of why IT is so hard in Pathology.We’re talking normal, run of the mill Pathology, not bio-informatics databases, leading edge cell imaging or shiny, ground breaking test developments. So why is it so hard to get some seemingly simple functionality from your IT Department? Why do all those small things that would make life a bit easier turn into long, drawn out projects that are around so long they become part of the family?
I'm sitting here at my desk massaging my temples. As the IT Manager, I've been handed the unenviable task of replacing the Laboratory Information Management System (LIMS), a job that will earn me no awards, applause or praise. We already know from past experience that it will be a difficult and traumatic project for my team as well as the whole organisation. We will grapple with new technology, interfacing and new ways of performing old processes. And for all that, we are not even expecting new functionality. We are not alone in this dilemma. At this time the IT managers of major Pathology providers in NSW, VIC, SA and WA are actively investigating replacing their LIMS. Some to modernise and consolidate, others, like ourselves, as a result of a pullout from the Australian market by a significant LIMS vendor. None will get any major new functionality. It may be easier to maintain, interface or get better reports, but it is unlikely that any new pathology breakthroughs will come as a direct result of these efforts.
There are many reasons why my temples need massaging. We must choose a new system that will provide functionality to a range of pathology disciplines with quite varied requirements. Invariably each discipline knows of a system that will work just right for them and invariably the other departments will detest that particular choice. There is no one system that fits all and there is not a lot of choice in the market. With so many country specific requirements for compliance and billing, many of those who would be the vendors of choice in Europe or the USA have little or no presence in Australia. So we must try to find a system that suits everyone from a very limited market place.
That, however, is not the major problem. We have done this before and, though it will be painful, we will do it again. The reason I've got my thumbs grinding the sides of my skull is that this is just the start of quite a few stress headaches. Information Technology is generally acknowledged as hard work. Telecommunications, Finance, Airlines and other sectors are not immune to IT difficulties and they have seen their fair share of difficult implementations, major computer failures and systems that did not at all match the sales pitch. There are studies available on project failure such as the Chaos Report by The Standish Group which indicate that somewhere between 24% and 68% of IT projects from all types of industries fail, depending on how you define 'project failure' (e.g. not delivered or over-budget, time). While some in the industry debate the accuracy, underlying data and methods of the Standish Group, from experience it feels right to say that only one in five projects will result in general satisfaction.
We have implemented quite a few features and systems in the past four years. We would consider that most of those projects were successful but they were hard fought wins and dogged by unforseen complexity. Functionality requests that appeared simple and straightforward became mired in, amongst other things; coding issues, regulation, process inflexibility and interfacing difficulties with other departments and systems. In my opinion, IT in Pathology is harder than other industries. Much harder and there are some identifiable underlying reasons why I believe this is so. We could broadly group them into the following:
- Lack of standards or lack of adherence to those that exist
- Underlying complexity
- Software development is a 'degraded science'
- Spending on IT systems
- Chasm between IT Department capability and the Big Expectaction
Lack of standards or lack of adherence to those that existIt is surprising to find in Health, an Industry steeped in SOPs, quality assurance, audits and standards, an almost complete lack of unity across IT systems. It seems we need to build each piece of functionality from the ground up with a variety of local requirements embedded, reducing future use and value to other health entities. This appears to be a feature of the siloed and insular nature of Healthcare entities along with the tendency towards fairly static IT evolution. Systems are developed primarily for local processes, not for interaction with external entities and so adherence to standards is not as important as in the Finance or Telecommunications Industries for example.
This may go some way to explain why an Instrument Interface works fine for one LIMS but we could spend four years connecting it to ours, going back and forth between developers, instrument vendors and users in an attempt to bully the software code into place.
Sending a HL7 message to a General Practitioner, a standard generally accepted as de facto, is another excellent example. Implementing this for our organisation required a huge amount of IT resources. Most of this was spent analysing and then coding exceptions because the different receiving applications have varied from the HL7 standard in order to meet local customer demands or save time. Why is this? We started down the road of sending our results using HL7 messaging because of government pressure on GP practices for reporting purposes, a reasonable expectation. The previously widely accepted standard message, PIT, is local to Australia and doesn't allow for database-like reporting. This should not have been a major ordeal given we already produce HL7 for internal reporting systems. That existing HL7 message did have customisations made to suit our local processes which caused us some trouble, so we immediately found ourselves victims of our own non-compliance, I suppose.
Following the development effort to set up the new HL7 environment, we applied our messages to one of the GP Practice software packages prominent in Australia. We found the reporting display quite deficient; missing headers, result history, contact details, etc. and, in the opinion of the reviewing Pathologist, clinically unacceptable. When this outcome was discussed with customers we discovered that other large providers had come across this a long time ago and found a way to 'embed' PIT into the HL7 message in order for the message to display nicely as before. Those providers did not insist that GP Practice software developers evolve their software to suit the HL7 standard, which has been knocking around Australia for over 15 years. Providers like ourselves must now have the local standard (PIT) 'added' to the HL7 message in order to be broadly acceptable. There are other nuances such as ensuring the 'copy to doctor' is read from the PIT part of the HL7 and not from the HL7 part. If this gets confusing for you, there was nothing out there on Google to explain it to us! We found that many other GP practice software providers have used something similar but, of course, not all. The result was that, after adjusting our HL7 message from the standard, we must now move slowly through the 20 or so other GP Practice software packages used by clients to see what variances they may require. We must also evaluate if we can adapt our IT environment to cater for the variances and determine whether it is worth the complexity. This is a long and tedious process for something that should be ‘standard’.
Another area where standards are at odds with practice is the identification of a pathology test between providers. Whilst SNOMED CT has been chosen by the Government and NEHTA, pathology providers have already implemented LOINC but not consistently. So the code we use for a Sodium test may be different from another provider. Some practice software products have built in mapping to cope with these variations from the standard but not all. And, again, someone has to maintain the variations. There is an AACB Working Party progressing towards standardising LOINC, however, until both senders and receivers agree on the terminology it will remain piecemeal. NEHTA is also reconsidering its position on using SNOMED CT versus LOINC. The picture at this stage is very cloudy and appears that it will take years for any real standard to be in place.
This lack of Industry-wide consistency in its approach to IT systems will remain for some time to come. Given the complexity, cost restrictions and trauma of changing Pathology systems, the application lifecycle is so long that change can not be dramatic. In pathology we can see the evidence of this amongst our peers given the longevity of not just their systems, but even down to the versions they have remained on for considerable years.
Even though this is normal, run-of-the-mill Pathology IT operations work and not the shiny leading-edge stuff, it is time to acknowledge in this paper that it is a fairly complex environment with a lot of interfacing, interactions and human interventions. The underlying complexity of all these systems, how they connect, the workflow and the exceptions quickly builds up to a picture that we can no longer fully grasp in one sitting.
As we have evolved over the years to become automated, integrated pathology organisations, we would have put in place processes and systems to handle the complexity of delivering service to multiple, distinct clients such as hospitals, GPs, health bodies and clinical trials. Each of these require distinct functionality or service so that the workflow can be very different. In particular, the supporting functions of IT, billing and Specimen Reception are very complex, partly as a result of being involved in all the approaches across all pathology disciplines.
Over those years of automation, we had, and still have, what we can call "uncontrolled evolution". That is, we keep changing and adding more localised processes without consideration about how this affects complexity and our ability in the IT department to manage it.
There comes a point when the complexity of our systems and processes becomes a hindrance to the effective delivery of service. This would be seen in difficulty to add / change a service, process or IT system. It is also evident when trying to troubleshoot a problem or in dealing with a failure. Basically, it takes a long time to unravel a hill of spaghetti. When things go wrong, reverse engineering a process, code, script or interface can take a long time. The resulting fix to a problem quite often appears to be easy and obvious, now that the process is understood. The length of time to discover it, however, is possibly a better gauge of the functionality/complexity mix (rather than how inept the IT Analyst is!).
In our organisation, a Lean Process approach was invaluable in documenting and highlighting both obvious and hidden complexity. It turned out to be quite a visual insight into the many variances and exceptions in our processes and systems. It also gave us the opportunity to challenge the benefits of some of them.
Overall, I suggest we do not have a good handle on how much complexity is in a given process or across a whole organisation. Anecdotally, when I see a multitude of spreadsheets, small pieces of code, manual interventions, workarounds and local knowledge required for many processes and still they require constant maintenance, then over-complexity is highly likely to be a hindrance to efficiency.
Software development is a ‘degraded science’
I recently stood in front of a meeting following a horrendous application upgrade that affected the whole organisation, resulting in slowness, loss of functionality, lots of bugs appearing, workarounds and late nights. There were a lot of questions but two still stand out: "Is it normal for vendors to deliver software with bugs in it?" and "Aren’t they supposed to test it first?"
The answers are ‘yes’ and ‘yes’. Software is a degraded science. We never get software delivered free from potential bugs although we can be confident the vendors test it according to their typical scenarios. I say software is a science because I have a degree in Computer Science. It is a degraded science because we now accept the vendor will give us an outcome as fact and ask us to let them know if any bits of their theory don’t work out. It is now the worldwide commercial standard that the software package we receive will come with bugs . We accept this because we get the software quicker, cheaper and it will probably do 90% of what we want, 90% of the time. Consider the "good old days" in the 1970’s when you could ask for an application, spend a year defining the specifications, get it delivered three years later for extortionate amounts of money, well tested and by then it was no longer needed or didn’t meet your original demands.
It’s our fault and we don’t want to go back to the old days so now we must accept the present reality. Our job now is to find the best case reality.
Spending on IT systems
Somebody asked me in a corridor to justify spending money maintaining an IT system over providing a patient with a bed. My immediate response was "turn off the computer system". That may sound like a smart remark and I was a little pleased with how easily it rolled off the tongue but the question was a valid one. How much are these systems worth? Pathology has undergone a big wave of automation to the point that any provider with volume must have a considerable system underpinning it.
According to a 2008 Deloitte report on E-Health Strategy , the estimated Australian IT spending in health care for 2007 was $1.25 billion compared with $7.4 billion in the financial services sector. That is approximately 1.4% of total spend compared with 9% invested by the financial services sector. This is not very surprising but given our heavy reliance on IT in pathology and a constant downward pressure on IT budgets, it is possible that this is squeezing out innovation at an enterprise level. By that I mean it is not an attractive industry for major software developers to invest in. There are fits and starts with large packets of high-profile Government money slotted in for special projects that attract vendors but it is hard to see any lasting momentum. Some global players such as Intel and Oracle have shown some interest in the past few years which is encouraging but they will have a limited impact for some time.
Smaller software developers can achieve limited traction with just one or two customers but the realities of the tight budgets and very long system life must be that the IT industry for healthcare is stifled.
On the flip side, almost by necessity, there is an extraordinary amount of in-house development done by pathology and hospital IT departments. There are propriety Anatomical Pathology, Instrument Interfacing, Pathology Ordering, Reporting and Billing systems developed in various IT Departments around the nation. This approach is typically easier to get approved, looks cheaper in the near term and sometimes gets the solution delivered in a reasonable time frame. I believe that, in the long run, this contributes significantly to our other problems of stifled industry innovation and our own internal over-complexity.
Software evolution has been a cycle of invest, develop and sell/share but this does not typically happen with in-house software development. For example, three private providers servicing nearly 60% of the pathology market in Australia have taken LIMS packages and heavily modified them beyond recognition to suit their internal needs. While this is good for them and provides some 'competitive advantages', an unintended consequence is that we are left wondering where the next generation of LIMS is coming from for this nation? It takes away a large amount of momentum from the technology evolution. The next generation of Australian LIMS is being left to others to reverse engineer rather than build upon. I suggest that getting all pathology providers HL7, LOINC / SNOMED CT, Unique Health Identifier and Medicare compliant would remove a large burden from all pathology IT departments. They are functions in the national interest, are a fundamental demand from the government and therefore, not a competitive advantage. Wouldn't it be great if the next LIMS chosen by all those now seeking included them as standard, evolved, tried and tested?
If the same principle of in-house development applied to other industries, there would be no impressive Oracle Financials, Siebel CRM or even a half decent Microsoft Word.
Chasm between IT Department capability and the Big Expectation
So we struggle to maintain what we have. Doesn’t everybody? It’s a bit like telling friends about your cold. You get back more rival sickness stories than the sympathy you were expecting. Yet the operational side of IT in Pathology will struggle that bit harder to meet benchmarks which are taken from other better funded industries. It will also have a very hard time to deliver on the high-level ‘strategic’ initiatives that are proposed by Government, NEHTA and other Health Informatics agencies. I am not at all suggesting that these initiatives are not sorely needed or that we will not benefit from them in the long term but for the short term we are asking organisations who already have a lot of complexity to introduce more. It is not so much the implementation of a system but the transition of current systems, interfacing and workflow to accommodate them that is of concern.
These larger health initiatives, such as Medicare Online, Unique Health Identifiers and Electronic Health Records are where the big money is supposed to be going. While Medicare did provide some funds to assist with implementation, it was barely enough for tea, doughnuts and a pack of headache tablets, in order to implement our side of the Medicare Online interface. There was, however, a rather firm deadline set, some vendor negotiations that didn’t go well, a very limited ‘Test Environment’ and the overshadowing thought that significant amounts of revenue would not be coming in after a certain date set by Medicare. Basically the transition was not easy and it fell on IT and billing staff to do it. The same people who still have their day job doing the other things they do.
With regards to project staffing, I have noticed that the public sector in particular has a habit of considering staff time as ‘free’. They are on payroll and not a capital outlay but staff are still a limited resource. Both IT and Lab staff need to be allocated to the project, de-allocated from what they are doing and backfilled. Otherwise we must accept that it won’t get done or will not be done very well.
Considering staff time as ‘free’ also tends to undervalue or ignore the amount of effort required for a task. We began tracking all significant IT requests and found a vast gulf between the estimate made by the requesting department ("That little report should only take a day. Why am I still waiting?") and the actual effort involved ("That little report took 60 hours because the underlying data came from two different systems"). This is a constant feature but at least now we can associate the amount of effort alongside what may sound like excuses to explain delays in delivery.
A lot of IT staff around the country are working hard to achieve poorly defined functionality in loose standards environments or to shoehorn in functionality determined by entities outside the realities of Operational Pathology IT. All this is done with limited budgets, training, salaries and career development prospects. Many projects are ‘successfully’ delivered more due to the goodwill and determination of IT and Laboratory staff rather than good project support.
The Pathology IT Industry is suffering from being quite ugly. The shiny, leading edge parts are mostly done by academics and the boring operational bits left to IT Departments but with no career connection between them. Running on tight budgets, it is not particularly attractive to Software Vendors or other industry IT staff.
At a high level, some skills are clearly in short supply in the industry but these deficiencies must vary from organisation to organisation. Strong leadership, decision making, project management as well as being able to understand the breadth of a system, its implications on the organisation, communicating and setting expectations would help any significant project, IT or otherwise.
I have found that IT managers from both public and private organisations are willing to share approaches and information. There is ambiguity around what are the boundaries when it comes to 'commercially sensitive information' and so some conversations come to a reluctant end but the willingness is there. Is there an enthusiastic agency out there to facilitate communication?
For those larger initiatives, more time and money needs to be given to the practical realities of handling transitions, implementations and support.
Strategically, it would be beneficial to consider IT solutions in the context of the whole organisation with a view to consolidating functionality and reducing complexity where possible. This involves challenging the value of requested functionality and requires a support mechanism from Management.
For those who have great expectations for Pathology IT departments, we need to get back to the reality – we are limited in our ability just to achieve the basic functionality. The shiny, leading edge IT part appears to be, unfortunately, another domain. Or we need a serious champion to go about changing it – in a big way.
So the next time you find yourself storming down to the IT Department with a formulated complaint regarding why something ‘easy’ has still not been delivered, bring chocolates. And two paracetamol for the IT Manager.
IT Manager, SydPath
St Vincent’s Hospital, Darlinghurst
- "Computer failure causes terminal chaos" AAP December 15, 2009. http://www.news.com.au/breaking-news/thousands-put-out-as-airline-computers-go-down/story-e6frfku0-1225810736052#ixzz11YnRhMOa (Accessed 20 October 2010)
- "Virgin cancels flights to fix computer glitch" - The West Australian October 6, 2010. http://au.news.yahoo.com/thewest/business/a/-/national/8078824/virgin-cancels-flights-to-fix-computer-glitch/(Accessed 20 October 2010)
- "Westpac fault ends in payment chaos" Sydney Morning Herald July 4, 2008. http://www.smh.com.au/news/national/westpac-fault-ends-in-payment-chaos/2008/07/03/1214950951494.html (Accessed 20 October 2010)
- "Chaos Report 1995", The Standish Group. http://www.projectsmart.co.uk/docs/chaos-report.pdf (Accessed 20 October 2010) More recent reports do not show major change
- "Introduction to HL7." http://www.hl7.com.au/FAQ.htm (Accessed 20 October 2010)
- "I. Colclough, Secure Health Messaging - Where to tomorrow? An independent commentary on "A Connected Health Sector", February 2007" http://aushealthit.blogspot.com/2007/02/guest-article-ii-supporting-diversity.html (Accessed 20 October 2010)
- "Medical Software & Computing." http://www.drsref.com.au/medsoftware.html (Accessed 20 October 2010)
- "NEHTA launches the first release of SNOMED CT-AU, December 2009" http://www.nehta.gov.au/media-centre/feature-story/574-nehta-launches-the-first-release-of-snomed-ct-aur (Accessed 20 October 2010)
- "NEHTA - National E-Health Transition Authority." http://www.nehta.gov.au/ (Accessed 20 October 2010)
- "LOINC background." http://loinc.org/background (Accessed 20 October 2010)
- "AACB Working Party LOINC." http://www.aacb.asn.au/web/Scientific_&_Regulatory_Affairs/Working_Parties/LOINC (Accessed 20 October 2010)
- "Apple to fix DST alarm bug" Sydney Morning Herald October 7, 2010." http://www.smh.com.au/digital-life/iphone/apple-to-fix-dst-alarm-bug-20101007-168um.html (Accessed 20 October 2010)
- "Hotfixes and Security Updates in Windows Server 2008 SP2 and Windows Vista SP2." http://technet.microsoft.com/en-us/library/dd335033%28WS.10%29.aspx (Accessed 20 October 2010)
- "National E-Health and Information Principal Committee - National E-Health Strategy, Deloitte Touche Tohmatsu, 2008" http://www.health.gov.au/internet/main/publishing.nsf/Content/604CF066BE48789DCA25751D000C15C7/$File/National%20eHealth%20Strategy%20final.pdf (Accessed 20 October 2010)
- "INTEL IN HEALTHCARE." http://www.intel.com/about/companyinfo/healthcare/index.htm (Accessed 20 October 2010)
- "Oracle – Healthcare." http://www.oracle.com/us/industries/healthcare/index.html (Accessed 20 October 2010)
- "The National E-Health Transition Authority Strategic Plan (2009-2012)." http://www.nehta.gov.au/about-us/strategy (Accessed 20 October 2010)
Posted in Australian eHealth