What is Service Oriented Architecture (SOA)? Thanks to wonderful marketing programs, courtesy of both software consultants and vendors, you may already know what it is. In fact, you might know a little too much-vendors create buzzwords to package “old” products into “new” concepts, which often leads to confusion regarding SOA and its associated terms, such as, Web services, enterprise service bus (ESB), and business process management (BPM). It's not surprising that you may be asking yourself some fundamental questions: How can SOA affect patient care? Can SOA improve the state of technology in a healthcare organization? How are other industries adapting SOA? And, should you start working on SOA before your boss hears about it at a Gartner Conference? If you are asking these questions, rest assured, you're not alone.
CORE FUNCTIONS AND GRANULARITY
Every business consists of numerous core business functions. Here at Children's Hospital Los Angeles (CHLA), just a few of our core business functions include admissions, claims processing, and discharge. These business functions themselves are made up of granular functions; for example, the admissions function is comprised of bed availability, bed assignment, and floor notification.
For years, software engineers considered it to be good practice to make each individual function modular, so these functions could be reused. In our admission process, for example, a floor notification function can be used for admissions as well as for other high-level core functions.
THERE IS NO SINGLE INTEGRATED HEALTHCARE RESOURCE PLANNING APPLICATION AVAILABLE IN THE MARKET TODAY THAT CAN SATISFY THE NEEDS OF ALL DEPARTMENTS.
This can be done easily when all these features and functions exist in a single software program; however, that's not the case in hospitals, which means that manual steps are required to complete the admissions workflow. And, if your organization uses multiple software vendors for admissions, bed assignment, and insurance verification, for example, then the problem is exacerbated.
EAI, or so-called application integration engines, solved some of these problems, while at the same time introducing different concerns into the system. These systems become strained when more data is flowing through the integration backbone in forms of HL-7 messages, and data is being duplicated all over the enterprise network. This strain can leave the system less secure, and may require additional IT resources to manage and maintain these discrete data sources. There have been previous attempts to solve this unique problem by seamlessly connecting distributed applications using technologies like common object request broker architecture (CORBA) and and distributed component object model (DCOM), but none of these technologies have turned out to be a panacea.
A single integrated healthcare application suite has always been a dream of many organizations. The truth is there is no single integrated Healthcare Resource Planning (HRP) application available in the market today that can satisfy the needs of all departments. Currently, IT executives have been pushing departments to use integrated EMRs from a single vendor, and trying to steer them away from a best of breed strategy. This strategy doesn't serve the business purpose adequately and often creates discontent among departmental users.
The important point to remember is a single vendor strategy is no replacement for sound architecture and integration planning. You can have a world-class, well-integrated system if you have the design and vision of what you want. Here's a simple analogy to help drive the point home (pardon the pun). All parts of a well-designed car, like BMW, don't have to be manufactured in one factory. While individual components can be manufactured throughout the world, ultimately it's the design of the overall car and its assembly that makes the difference. BMW uses the best and most economical manufacturers across the globe to produce its engineering marvel.