Building a Foundation for Service Oriented Architecture
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.
The same can be said for IT systems in an enterprise. Excellent IT systems can be a competitive advantage, and it's difficult to purchase them out-of-the-box. Most successful organizations have great enterprise architecture to take them to the next level. Simply implementing a single integrated system won't necessarily meet the growing demand of a business. SOA can help you achieve your vision, and take you beyond what single vendors can offer. The question is how to solve the integration problem and bring all the discrete applications into a single homogeneous enterprise fabric.
WHY SOA MATTERS IN HEALTHCARE
Service-oriented architecture is not another piece of technology. It's a design methodology for systems and application integration. A deployed SOA-based architecture will provide a loosely integrated suite of services that can be used within multiple business domains. If you already design each business function and process as a pluggable modular system, then you are already doing some form of service orientation. A perfect service oriented organization will have variety of best of breed applications performing a core or granular service and using it to create a complex or simple service.
Although there are software tools available from vendors, such as ESB, BPM to SOA that can make things more automated, the reality is, service oriented business processes and architecture can be established without using any of these tools. Of course, a service bus and BPM will take your organization to the next level in SOA maturity. The advance of Web service technologies and SOA promises to have far-reaching effects on both internal and external applications. Web services using extensible markup language (XML), simple object access protocol (SOAP) and JavaScript Notation (JSON) allow applications to talk to each other seamlessly in a more native manner. Matured service design can lead to efficient automated business process management.
LAYING THE FOUNDATION FOR SOA
No organization can become service oriented overnight. It requires both careful planning and bringing discrete vendors together. In addition, your application integration team and architects play a vital role.
Vendors are extremely critical to the success of your SOA implementation. Once you have an architectural blueprint of SOA and a roadmap customized for your organization, you can start defining standards and asking vendors to comply with those standards. Eventually you will have a set of applications meeting those standards; and at this point, you may want to take advantage of the software tools available, such as ESB or BPM, to take the automation process to the next level.
Your application and integration team will come up with a list of services (some of them might be Web service). In a typical hospital, you may find some of the following services: admission; discharge; charges; room service; resource locator; orders; results; notification; and hand-off. The list can be long. The point is, all those methods done via HL-7 can be converted to services. Each of these services can be made up of more granular services.
The power of SOA is in reusing these granular services to create complex services and business processes. If you have unified communication in place, the architecture can extend to create communication enabled business processes. IT should consider agile and iterative processes for SOA where each iteration will produce a set of services-complex services would start building in later revisions.
While deploying Web service healthcare, organizations should invest a good portion of time in security architecture. Traditionally, security mechanisms are not very well suited for Web services, or sometime they can hinder usage of web services. Web services based on the XML, SOAP, and related open standards, and deployed in SOA, allow data and applications to interact without human intervention through dynamic and ad hoc connections.
Web services technology can be implemented in a wide variety of architectures, can co-exist with other technologies and software design approaches, and can be adopted in an evolutionary manner without requiring major transformations to legacy applications and databases.
Other industries, such as banking and finance, have gone a long way in SOA adaption, compared to healthcare IT, which has been slow in adopting it. This is probably due to lack of leadership from healthcare vendors. As vendors are now jumping on the SOA bandwagon, this should provide an excellent opportunity for CIOs and CTOs to prepare the roadmap for the application backbone for a future SOA platform.
Ajay Kandelwal is manager of enterprise architecture, Children's Hospital Los Angeles. Healthcare Informatics 2011 February;28(2):73-75
