\"We are a facilitator and expediter of linking disparate PACS systems and extending value.\" Lindsy Strait, CTO, Healthcare and Life Sciences, Sun Microsystems.
Despite government initiatives and encouragement for the U.S. healthcare industry to build a national electronic health record (EHR), the competitive nature of the U.S. healthcare system creates many obstacles, such as noninteroperability and software implementation costs, which have hindered progress.
Studies indicate that potential annual net savings from a full implementation of a national EHR system could add up to $77.8 billion. Despite the potential pay out, the initial capital investment would require $156 billion over five years. With estimates that only 15 percent of physicians in the U.S. today use EHRs, the market has reacted with only moderate interest in these long-term gains.
One of the most significant barrier to a unified EHR is healthcare software that is not interoperable-friendly. Although programs such as Integrating the Healthcare Enterprise (IHE) advocate interoperablity among proprietary IT solutions and reinforce adoption of DICOM and HL7 standards among proprietary systems, the cost of interfacing these systems creates an additional cost barrier.
To overcome these obstacles, the industry will have to take alternative routes. According to some experts, open source software may pave that new path and eventually become the dominant model for developing healthcare software.
The way it works is that open source code is freely available — revenue is generated through services such as implementation and support rather than licensing. Therefore, the cost for customers is minimal. Also, because no single vendor owns the software, users have more options. In addition, access to source code enables a region to adapt the software to its specific needs, facilitating the adoption of a standardized EHR. Plus, it comes with clout — large IT companies such as IBM, Hewlett Packard and Sun Microsystems support the open source models.
To find out if open source could in fact form the backbone of healthcare’s IT infrastructure, Imaging Technology News (ITN) went directly to the source in an interview with Lindsy Strait, chief technology officer, Healthcare and Life Sciences, Sun Microsystems.
ITN: Do you work directly with hospitals for imaging and implementing EMRs?
Lindsy Strait: Yes, we do. In many hospitals such as Mass General, Brigham and Women’s, UCLA, many of the informatics teams have helped deliver applications, and some of the vendor solutions we have today were birthed there. So hospitals and healthcare informatics vendors and researchers are all just as much a client to Sun as any big DI vendor or any PACS supplier. They are all of our clients and our technology serves them all.
ITN: Integrating disparate systems is a problem with imaging because there are information silos. How is Sun facilitating the need to transfer large volume data sets?
LS: Number one, at a certain level, the PACS problem space is not much different from any other problem space where you have large binary objects. Images are just large objects that need to be intelligently moved around. What they do is tag images and image subsets and have built applications to manage the distribution of these objects, whether I am sending it to a device or to a machine that is going to do something to it or to some viewer for someone to look at. Because Sun has the ability to run virtually unchanged on all of the different operating systems and proprietary systems with our Java technology, and in many modalities we can provide optimal solutions, all of the big PACS vendors are customers of ours. They use our hardware and, in most cases, they use our Java software to write PACS applications that they use to distribute those images.
So Siemens, Philips, GE and Kodak are all going to have very elegant PACS applications that they have invested a great deal of time and effort and money in that are task specific to their equipment, their viewers and their distribution scenarios. There are very specific high-resolution radiology department needs that a PACS systems serves. Now, if they were to decide that they would want to loosen access control and make it more accessible to other applications in a Java environment, they could. There are no technical reasons why you can’t.
So what Sun does to encourage more sharing is allow our applications run on all of the different hardware platforms and environments and provide agility and interoperability. We work with the vendors and, in some cases, do some task-specific hardware operating devices specific for them. So we can help clients do everything, number one, to have excellence in their internal applications, and should they decide to open them up and make them more easily accessible, we have all kinds of technologies that support that kind of heterogeneous interoperability. We are a facilitator and expediter of linking disparate PACS systems and extending value.
ITN: How can Sun facilitate interoperability through open source coding?
LS: Sun pioneered open code availability in many ways with Solaris and with Java. So for us to open source our operating system, for example, no one has ever fully done that before, and for us to pollinate the world with open source means we are really excited about increasing adoption and utilization and advancing the state of the science.
Instead of keeping our source code secret and proprietary, and only licensing run time, we said hey, if you’re a really smart programmer, and you really get Java, we’ll give it to you. We’ll let you look at the source code. In fact we would love you to improve that source code. The only requirement is if you make changes, you have to give it back to us and you have to share it with the world. And then, we get paid when you take it into production or decide you want to subscribe world-class maintenance and support. So we don’t actually sell them the code or access to it. What we give you is a subscription license for support and maintenance; and no one else does that right now.
What proprietary vendors try to do is mark up their source code run times. So they take the run time, license it to you, and never ever let you see the source code. Other vendors may not be able to stand the scrutiny of open source, especially when they already have vast security problems. And then they will charge you maintenance on top of the run time licensing. So they license run time and they get maintenance. Sun said forget that. Let’s share our source code, let you use it, let you extend it, let you create solutions with it, and we will help you. When you go to market, you’re making a living off of it, and then use us for support and maintenance — what a great partnership.
ITN: Is there a potential security liability?
LS: I believe there are not a lot of truly deep technical issues behind that stance. Unix, for example, has been open source for a long time and lots of people have taken the open source Unix and have built whole companies out of supporting it and maintaining it. Even today it is one of the most secure operating systems. It is much less breached or hacked than some of the other operating systems. In fact, if it is open source, there is a larger body of computer scientists looking at that source code. Or if there is a breach or a weakness, it is going to surface much earlier. So, in fact, I believe open source makes even more secure systems. I think the idea of keeping it secret to a very small group, you’re asking for trouble. So I think in an open source community they are going to be even more secure than less secure. Also, you have to experience the open source community to understand it — there is a passion for quality that pervades the people involved.
ITN: What are the biggest challenges in healthcare for implementing
the EHR?
LS: There are literally hundreds of electronic health records out there in the market. The things that need to be overcome now are particularly in diagnostic imaging and integrating those images at the point of care.
Number one, there are hundreds of slices and digital subsets in a typical CT or MRI scan study. An oncologist or surgeon or radiologist or orthopedist is probably interested in a certain subset of that overall group and at a specific resolution. In the course of a disease state you may do many sets of images, but ideally there are only a few of them that are really pertinent to a care decision. One of the big obstacles is getting that relevance nailed down, making sure you get the right subset of the right images, at the right time, at the right place to the right viewer. So there is authorization, there is role-based access, there is security, there is audit, there is tagging, there are relevance issues and context issues.
The hurdles and barriers are not technical, they are cultural and policy-related, and they are provision related. We do this in other verticals technically; we can do it here. We know how to meta-tag data, we know how to do relevance, we know how to make sure you get the right data at the right time to the person for the right reason and the right place and you audit trail all of that. I mean banking has done these for decades, and banking is right on the tip to moving to image-based checks for example. They have a very similar source of solution.
I think the electronic medical records will have DICOM for those who want images with higher resolution or JPEG 2000 for example if you don’t need that level of resolution. If you can make the DI fit into your data and access model for that EMR, its meta-model, room for tagging these images, room for relevance tags, role-based authorization, then you can easily embrace moving those images in and out of your care management package, or your problem-oriented package or your physician-oriented package, or your time oriented package.
There are all kinds of ways that you can pull images and make them relevant to your EMR. Some of the EMRs do that, and on the flip side some of the PACS vendors now are buying EMR companies and they are going to come out with their own electronic medical record solutions that have PACS deeply imbedded there for the diagnostic image management. And as we move into biosurveillance, and more genetic-based medicine and pathology-based and more CT-, MRI-, PET/CT-based care, and as we get more image-guided surgeries, like needle biopsies, it just gets more prevalent, and even more tightly integrated medical records applications for care management and image management will evolve.
Right now, they are all in their separate domain spaces, but I see that overlap and convergence starting to occur, especially in the PACS world where the big vendors have bought all of these systems. So we are going to see generations of them with tightly integrated DI. The EMRs that don’t have them will have to have standards that will allow you to embrace them. You will have the option of buying it directly from your PACS vendor who will give you an EMR that will have it, or you will have companies like Sun that can give you the plug-and-play capability across those domains. We are giving it to the vendors internally. They can use it to build their own systems. We’re giving it to their trading partners so they can do plug-and-play. We’re even giving it to the end-user so they can pick the best-of-breed solution for their particular need as opposed to having to go to one monolithic vendor to get everything. Sun really deals more with partners, and PACS vendors are our partners, or we can give the tools to the open source community to build new apps. Sun doesn’t pick one over the other — we facilitate agility.