Why is ‘IT’ all so hard in Pathology?

Pathology IT

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[1][2][3]. There are studies available on project failure such as the Chaos Report by The Standish Group[4] 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 exist

It 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[5] 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[6], 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[7] 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[8] has been chosen by the Government and NEHTA[9], pathology providers have already implemented LOINC[10] 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[11] 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.

Underlying complexity

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[12][13] . 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[14] , 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[15] and Oracle[16] 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[17] 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.

Conclusions

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.

Robert Flanagan
IT Manager, SydPath
St Vincent’s Hospital, Darlinghurst

References

  1. "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)
  2. "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)
  3. "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)
  4. "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
  5. "Introduction to HL7." http://www.hl7.com.au/FAQ.htm (Accessed 20 October 2010)
  6. "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)
  7. "Medical Software & Computing." http://www.drsref.com.au/medsoftware.html (Accessed 20 October 2010)
  8. "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)
  9. "NEHTA - National E-Health Transition Authority." http://www.nehta.gov.au/ (Accessed 20 October 2010)
  10. "LOINC background." http://loinc.org/background (Accessed 20 October 2010)
  11. "AACB Working Party LOINC." http://www.aacb.asn.au/web/Scientific_&_Regulatory_Affairs/Working_Parties/LOINC (Accessed 20 October 2010)
  12. "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)
  13. "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)
  14. "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)
  15. "INTEL IN HEALTHCARE." http://www.intel.com/about/companyinfo/healthcare/index.htm (Accessed 20 October 2010)
  16. "Oracle – Healthcare." http://www.oracle.com/us/industries/healthcare/index.html (Accessed 20 October 2010)
  17. "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

Comments   

# Christopher Toon 2011-02-20 05:09
Interesting piece. I worked with NEHTA as a clinical terminology analyst on the first iteration of the SNOMED CT Pathology Domain Reference Set back in 2007-8, and the NEHTA pathology structured reporting information model back then was incredibly primitive and did not address real-world concerns. There was crippling internal debate regarding the integration of LOINC and the use of HL7 v2.4 vs v3 as a messaging standard. Pathology IT needs involvement by practising pathologists who are IT literate, because of the complexity of the information model and the need to integrate clinical terminology like LOINC and SNOMED CT, something HL7 v3 can only provide with limited support (assuming the future of Australian Pathology goes the way of v3).
# Alan OKeefe 2011-02-22 15:28
I've worked in senior development and management positions in 2 out of the 3 large providers you mentioned and your article hit painfully close to home for both of this environments.
The only issue you didn't cover is that even in the same discipline, it is almost impossible to get agreement between scientists across a national organisation on the single best way to perform even routine tests, (don't even talk about the more clinically obscure stuff).
So IT end up being the referee between two groups of experts on a subject they aren't professionally qualified to understand, let alone arbitrate.
# Brian Collins 2011-02-23 19:20
Alan makes a good point – domain knowledge seems to be more critical to success in developing LIMS than it is in other healthcare IT areas, and the complexity of the business model, coupled with a layer of pretty diverse medical knowledge, makes for a pretty long and steep learning curve for new initiates. It’s interesting that, of all the healthcare IT disciplines, pathology is the only one that Robert’s current vendor abandoned – they still have a presence in all the others. Good requirements analysis is the obvious simplistic solution, but people who can walk both sides of the client/develope r divide with enough background knowledge to ask intelligent questions are very thin on the ground!

I understand Robert’s point about software development being a “degraded science” but I don’t totally agree that you have to just “accept the present reality”. Being a past LIMS architect, I have some sympathy with the vendors – LIMS are incredibly complex systems and testing them thoroughly is a nightmare. However, I believe there is a role for automated unit and integration testing here that established vendors are probably still not acknowledging. The complexity of the systems is such that even the most experienced developer often finds himself making changes with his fingers crossed, more in hope than expectation that he hasn’t broken something apparently totally unrelated. I believe that a test-driven development methodology, and the comprehensive automated unit and integration test suites that grow out of it, would go a long way towards allowing vendors (and corporate IT departments) to ship, if not bullet-proof code, then at least something that is less prone to failure with the catastrophic consequences that can entail. Unfortunately, automated unit testing is often difficult to retrofit to legacy systems but, if I was in the market for a new LIMS, evidence of a comprehensive test-driven software development methodology would be high on my list of wants from a new vendor. Without it, I think you’re doomed to repeat history.
# Chris Quin 2011-03-03 12:06
I understand the problems that occur but I think they tend to be a product of legacy systems and vendors not evolving as modern computer development techniques have. I also have a degree in Computer Science and have experience programming in c++, java, c#(and other .net languages), javascript, php and a variety of other programming and scripting languages. I totally agree with Brians comments above.

Most of the systems I deal with in our healthcare environment started life 20 - 30 years ago before I was born or when I was still a child and complexity has grown exponentially as good, bad or obsolete programming solutions and practices have been built on top of the last. Sometimes you just need to start over with the requirements that have long been known from previous experience and remove the unnecessary complexity that exists and I think that is where things are headed eventually, especially as a new generation of computer specialists enter the field this will become inevitable. I find even the way of thinking about the laboratory and computational concepts contained within these systems is usually outdated and complex. Unfortunately the incentive is not there to simplify components within existing legacy software if the vendor has already captured a market, why spend extra money to ultimately get less money from your client? it makes sense.

I tend to disagree with the internal software point of view and is contrary to what we have seen if long term internal projects are funded long term like you would a vendor product. You get what the business requires at and it tends to be at lower cost and more reliable. The argument I have always come across is generally supportability but it becomes apparent in many situations that even the support you pay for from a vendor is not really support.

I totally agree that standards whether nationally or regionally is a must and building a diverse laboratory IT platform with this in mind is completely plausible, however I have not seen a system that has been designed to future proof itself in regard to standards and this needs to be done for long term use in healthcare.

So what is the solution? Maybe its time to start a new Open Laboratory Platform based on a community development model and modern laboratory and programming concepts?
# Yvonne Sherlock 2011-03-13 08:37
"Robert has hit the nail on the head with this article. Having been on both the vendor and client side, I know that every manager in Pathology IT is dealing with the same challenges and frustrations. Pathology IT is not being fully utilised and is always undervalued by senior management, seen as a cost not a resource. Given better funding and more focused Executive Management, the high quality of Pathology IT staff would promote further progress for the entire industry, and better value for their organisations, offering the true competetive edge most management are seeking. " 18 days ago
# Trevor 2011-03-25 10:02
When the new LIS is installed, will Mr Flanagan be able to present all patients' data, from legacy and new databases, in an accessible format?
# Rob Sands 2011-03-25 20:12
I think you are being a bit tough on Pathology IT, it has been one bright spot in Health IT. Over the last 25 years there has been remarkable development in LIS capability and sophistication, so much so that it has enabled a handful of pathology organisations to grow to the stage that they now monopolise the market. This downside of this success has been that there are now very few laboratories left in the market for a LIS, so this makes it difficult to support a flourishing LIS industry in Australia.

But if you really want to get a headache, try implementing clinical systems in the acute hospital setting. There have been many grand schemes, many millions of taxpayer dollars have been sunk , but precious little has been achieved!




# Byron Phillips 2011-04-15 19:39
It seems at iSOFT we are guilty of keeping well hidden what we have in the area of a modern fully localised LIS and as such I can’t help make comment regarding the lack of modern systems in Australia.

I read Roberts article with great interest and fully respect the challenges involved. I was encouraged by Roberts desire to be able to select a new solution based on the best of US or European product and yet with local presence as that’s exactly what we have sought to achieve with the ANZ Market Entry of our German LabCentre solution.

LabCentre runs around 300 hospital Labs in Europe and in conjunction with state government lab stakeholders we have completed development (in Australia) of a sophisticated AP module and the configuration (not development) of Australian Billing requirements.

iSOFT is not new to LIS and needed a replacement lab system for our legacy systems in NZ and we thought very carefully before bringing LabCentre to ANZ. For many of the reasons outlined in comments above we were convinced the solution could provide both technical and business (efficiency) differentiation to those systems on the ground in ANZ. Local lab managers visiting our customers in Europe commented on the significantly lower staff numbers and attributed some of this to the work flow enablement found in the foundation of LabCentre.

Those Australian lab managers that have seen the product and our new localisation developments have confirmed our belief that LabCentre has what it takes to provide ANZ an alternative solution for the next couple of decades of lab systems.

We fully respect however, the solution is part of the challenge and the doing is another. We are part way through our first LabCentre implementation in the region and have full confidence the solution is worthy of consideration for anyone about to make long term LIS reinvestment.

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.