In a recent note (see: New Healthcare Delivery Models & Technologies That Will Affect the Clinical Labs), I raised the possibility of the evolution of lab networks in connection with my prediction that IT will become an increasing important competitive factor for national reference labs and hospital lab outreach programs. I want to provide some additional information here about what I mean by the term lab network.
There is a long history of reference labs and lab outreach programs providing basic connectivity to their client hospital labs. Such connectivity frequently consists of test ordering from the hospital lab and test reporting back to it. I envision much tighter LIS integration between these types of organizations in the future, forming lab networks. Here are four examples of specimen allocation and reporting scenarios that could become commonplace in the future:
- For a test performed only in the reference lab, a patient specimen would be labeled and bar-coded only once at the collection point and then automatically and quickly routed to the reference lab for testing.
- Some genomic and proteomic specimens will undergo initial processing in the hospital laboratory and will then be routed to the reference lab for final processing and final report generation.
- Some patient specimens will be aliquotted in the hospital lab with some of the aliquots retained in the local lab for testing and others transported to the reference lab.
- Draft reports of genomic and proteomic tests will be generated in the reference lab and then completed in the hospital lab after review of a patient's clinical record.
A major barrier to the development of such lab networks has been the fact that the reference labs and clients hospital labs are frequently supported by different and thus incompatible LISs. Although it has been technically possible to develop interfaces between such systems, the cost of such projects is often so large as to be deemed impractical. Also lurking in the background has been the specter that the contract between the reference and hospital lab could be canceled abruptly, making any substantial IT investment risky.
I have published a number of previous notes about the federated architecture with which heterogeneous LISs could communicate without a large investment in complex and expensive HL7 interfaces. The federated architecture is closely related to a service-oriented architecture (SOA), which is defined in the Wikipedia in the following way (boldface emphasis mine):
Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. SOA separates functions into distinct units (services), which can be distributed over a network and can be combined and reused to create business applications.
Interestingly enough, Intel has just announced an SOA initiative for healthcare (see: Intel Announced Intel SOA Expressway for Healthcare). Here is an excerpt from the announcement:
The product will allow healthcare providers to connect with one another so that each can provide better care while benefiting from reduced integration costs. Until now, the sharing of patient information among healthcare network participants has been hindered by the steep costs and complexities of proprietary data and integration services. Based on Service Oriented Architecture (SOA), Intel SOA Expressway for Healthcare offers a solution to this problem by providing a way to translate, process and connect any data format across a healthcare network.
Given the clout of the Intel marketing juggernaut, I believe that the federated/SOA computer model will greater gain credibility in the healthcare market and provide impetus for novel inter-laboratory IT relationships such as the lab network described above.
Hmm.. whilst SOA as an integration paradigm is certainly on the increase (it has its obvious benefits) one should realize that regardless of the systems integration paradigm one has to standardize the format of the medical content which is passed as part of a service call. So whether one uses a HL7 model in combination with a messaging paradigm (a solution you call an expensive one) or a model (which could also be HL7) in a SOA paradigm - one wull still have to agree upon a shared model for the data that is shared between applications.
As such there is no difference between SOA or a messaging paradigm: if you have software solutions from multiple vendors, they'll have to agree upon a common data and service model, and the end user will have to pay for the functionality. I see no reason why SOA should less expensive than traditional messaging interfaces. After all - it's the exact same problem, with just a slightly different technological solution. The problem is however not a technological one - it is agreeing upon a standard workflow, and agreeing upon a common data model.
-René
Posted by: René Spronk | April 25, 2008 at 04:48 AM