Increasingly, healthcare organisations are looking towards healthcare IT to help drive efficiencies and improve care quality. However, they need to sort out the common misconceptions regarding SOA before adopting it in their organisations.
Healthcare organisations face many challenges today. Though each organisation has its own specific obstacles, a quick review of industry literature quickly highlights that there are many common problems: How do we manage with the budget we have? How can we do a better job of treating our patients and improving care quality? How can we prevent medical errors? How can our EHR investment be successful where others have been unsuccessful? Which product or products are best for us? How do we make all this technology work in our organisation?
Globally, populations are both growing and ageing, creating pressure on the healthcare organisations that manage and treat them, a problem further exacerbated by significant shortages of skilled healthcare staff. Result is the burgeoning needs and limited budgets, where many organisations are looking to healthcare IT for answers on how to do more with less.
Before we can entertain a reasonable discussion about either Healthcare IT architecture or Service-Oriented Architecture (SOA), we must first begin with the business principles and rationale behind making such investments. This stems from the business functions we enable, the objectives we are trying to achieve and the outcomes we hope to achieve as a result of our IT investment. We must first have a foundation, and architecture to provide that
foundation.
Understanding Architecture
It all seems too easy to cobble together some requirements, pick a product and be done with it. The downside is that this model is proven time and time again to fail, and for a variety of reasons:
• No single vendor is best-of-breed at everything
• Legacy systems do (and will continue to) exist
• Organisational boundaries are constantly changing, driving the need to adapt.
When making IT investments within an organisation, we must not only consider the needs of the users, but the needs of the organisation itself as a business entity. What are our drivers? Who are we looking to benefit (clinician, patient, organisation)? What returns do we hope to get on this investment? (Improved outcomes? Streamlined workflow? More accurate reporting?)
Enterprise Architecture (EA) is the key discipline and building block to help align business needs to IT investment. In brief, EA models our understanding of the business, captures business requirements, relates those requirements to IT investment and demonstrates accountability of that investment back to the business. The result is a blueprint that frames how technology components, products, processes and policies all come together to support the needs of the Enterprise.
How does this work ‘in the real world’? Let’s take an EHR example. Suppose, one specific EHR vendor-offering appears ideally suited to our business need. It provides the clinicians with the information quality and fidelity they want. It has a user interface that is easy to understand, multilingual and supports the modalities (desktop, tablet PC, mobile phone) that interest us. Seemingly, this would be a good investment were it not for considerations around the architecture.
Further investigation reveals that this ‘ideal’ product that is unable to integrate with our existing laboratories (both government and commercial) is unable to ingest data from our existing registration system. It is unable to support our planned personal health record. Quite simply, the product doesn’t fit within the context of our organisation.
How do we know this? We know this because an Enterprise Architecture documents a bigger picture, formalising where we are and where we plan to go, giving us the raw data and insight to make informed decisions. Though there are dozens of EA frameworks and methodologies, most accepted approaches share the following dimensions. These dimensions are comprehensive and distinct, but interrelated as the context of one view affects the others.
Business View: Describes the purpose, functions and organisational considerations of the business. This view would capture the core functions provided by the organisation, its policies, drivers and so on. For example, Emergency department, laboratory, financial management; objectives such as reduced wait times, improved patient safety.
Information View: Identifies the information of interest and pertinent information standards / terminologies, such as what might be captured in forms or stored in systems (administrative data, registration information, medical record information, patient demographics etc.).
Systems View: Discusses the applications, software, messaging, software services and standards that comprise the IT landscape within our organisation. It would include commercial packages, such as our EHR and speciality / subspeciality systems, integration engines, workflow packages etc.
Technology View: Identifies the underlying infrastructure components upon which systems will be built, such as the physical network, hardware platform, key software in the technology stack (operating system, Java / .NET etc.).
So, what about SOA?
If Enterprise Architecture is what helps in making informed decisions about IT purchases, why care about service-oriented architecture? What is it? How does SOA relate to EA? More importantly, why would a business person care about SOA? There is a common misconception in the industry that SOA is a technology—the embodiment of a solution that is offered through a variety of vendor products that will solve all our problems.
Just as its moniker, SOA is an approach, a philosophy, a method for integrating a broad spectrum of tools, processes and people for business to realise its objectives through adherence to a set of core tenets. SOA is fundamentally based on the services that an organisation provides and is thus owned by the business and not the IT shop.
One of the pre-eminent SOA organisations—the SOA Consortium articulates its purpose to “Promote and enable business agility via Service Oriented Architecture which allows businesses to compete, innovate and thrive.” Their focus is to help change the public perception, particularly from business executives that SOA is an IT integration platform when it is more appropriately considered a business agility tool.
How does this relate to healthcare then? Quite simply, healthcare organisations are making significant investments without an architecture. The result is that they have little or no confidence that their purchases will integrate, adapt and evolve to support changing business needs. SOA provides a framework for thinking about healthcare IT that naturally aligns to the needs of healthcare organisations, improving alignment, traceability, and ultimately consistency with good EA practices.
Healthcare is service-oriented
Very often, care delivery is conducted not by one individual, but by a care team, each member of which has specific capabilities and responsibilities. They collectively engage and collaborate to meet the needs of a given patient. For instance, a care team may comprise many specialists: cardiologists, radiologists, physiologists, nurses, nutritionists and so on. Each member of the team provides a unique expertise and performs specific functions. The team is collectively governed by an authority with an overall responsibility for the care delivery, which orchestrates its operation and coordinates its activities.
SOA embodies many of these principles
Services themselves are not expected to do everything, as they require collaboration with others. A given service has well defined role and responsibility, based on a commonality of function and capability. They require coordination among multiple parts to work effectively, and work together within the context of some governance with responsibility for orchestrating workflow among them.
Authority is the underpinning of a successful SOA
To adopt SOA in an organisation, we must align our business processes, our policies, our systems and the role that those systems perform within our organisation. It is not enough to purchase a new demographics system that supports a web services / XML interface. The new software does not make that system authoritative, especially if we do not have plans to “turn off” the legacy system that also contains demographics information.
The key difference lies in the policies and expectations of the new system. Consider, instead, deploying our new demographics system with a policy: As of January 1, all demographics-of-record will be stored in the new system, and all Enterprise systems will look to it as their source for demographic information. The difference may be subtle, but is profound. This new system, coupled with the above-stated policy is now moving toward service-orientation. The demographics service is the authoritative source for this information within the enterprise (e.g. well-defined scope, responsibility, authority).
SOA is not about technology
Web-services implementations and XML do not make the organisation SOA-enabled, as both can be used to build point-to-point solutions as easily as SOA-based ones. While it is true that many SOA solutions do in fact leverage technologies such as XML, SOAP and Web-Services, the technologies themselves do not fulfill the objectives of SOA. It is how those technologies are applied within the context of a total solution that makes something SOA-based or not.
Get the core tenets right
There are hundreds of industry publications and articles highlighting key qualities needed to realise effective SOA implementations. These qualities—a clearly defined scope, formal interface specifications, loose-coupling (e.g. minimal direct dependencies on other services)—ultimately benefit the autonomy and composability of services. Some of the tenets that drive this flexibility include:
Abstraction: Supports the ‘hiding’ of underlying implementation details, enabling and preserving the described loose-coupling of SOA components.
Autonomy: Provides independent, self-contained function of a service that is not controlled or inhibited by other services.
Composability : The ability to bring together autonomous services in potentially dynamic or unforeseen ways allows SOA to grow to support complexities of business needs.
Discoverability : The ability to identify and leverage services as assets, resulting in improved Return-On-Investment (ROI) and ability to bring online and leverage new capabilities as they become available.
Why is this important? Services are not systems. They are capabilities with singularity of purpose that need to collaborate with other services in support of business needs. With services being defined and scoped autonomously, but with the capability to ‘orchestrate’ workflow among the parts, SOA-based solutions are more adaptable and flexible than alternative approaches.
Moving to SOA
Health organisations need to keep in mind several aspects of SOA before adopting it. Many have jumped onto the technology bandwagon thinking that by installing a Enterprise Service Bus, moving interfaces to web services, you have SOA. The migration to SOA is a carefully architected process that needs to balance business and technology domains concurrently. SOA is as much an organisational and cultural change as it is technical. SOA cannot be seen as the quick fix to the complexity that has accumulated over the history of the legacy landscape in healthcare.
Adopt a maturity-model approach
By adopting this approach, organisations can carefully plan the maturity of their transformation. Industry maturity models typically follow a similar pattern of incremental improvement across domains (architecture, technology, information, governance, business process etc.) It is critical to adopt a balanced approach, particularly in a SOA environment, and avoid the tendency to become too focussed in one domain at the expense of another. This is a long journey spanning several years and requires commitment, flexibility and governance in order to be successful.
Standards matter
Healthcare is a collaborative effort, involving participants from across a broad spectrum of people, organisations, and systems that support them. Even if your organisation were to architect, deploy and operate a SOA-based system absolutely perfectly, there are factors beyond your control. Vendors change their offerings and technical direction. Health systems interact with new organisations and business partners. Technologies change and are replaced.
Standards form a basis to mitigate these challenges. Even if we institute a SOA-service to manage patient identities (e.g. a Patient ID Service), what assurances do we have that our business partners will be able to interact with it?
It is for these reasons that efforts such as the Healthcare Services Specification Project (HSSP) exist. This effort is a collaboration involving primarily Health Level Seven (HL7) and the Object Management Group (OMG) to develop health industry SOA standards. These specifications establish an industry position on the scope of healthcare SOA services, their responsibilities and bindings for their implementation using specific technologies (such as web services). Efforts such as these promote interoperability among organisations while still providing autonomy to vendors and organisations to realise SOA in the way that best fits their needs.
Act locally
The mainstream ‘business as usual’ approach toward buying products and leaving healthcare institutions to force products that do not fit well or integrate effectively. This approach is not sustainable, particularly as increasing reliance and investments are made in healthcare IT.
The decisions you make within your own institution have broad industry impact, as vendors won’t supply what isn’t being demanded. The onus is on each of us to move the industry in the direction that meets our needs. That means placing requirements such as standards-based interfaces and open architectures into our purchasing, sending a clear message to industry of our needs. Irrespective of which technology path and architecture you choose, you have to recognise that there is no way to reach your destination if it is not defined clearly.
AUTHOR BIO
Ken Rubin is a Senior Healthcare Architect with EDS, is focussed on informatics, EA and EHR interoperability, and has supported the (US) Veterans Health Administration and the (UK) National Programme for IT. Rubin chairs committees for the OMG, HL7, Open Health Tools and the Healthcare Services Specification Project (HSSP).
Martin J Holzworth is an internationally experienced Enterprise Architect with expertise across healthcare, financial services, telecommunications, and government sectors with an outstanding track record of success. Holzworth has worked with numerous clients in Australia, Asia and USA and is currently working with a large government healthcare provider in Australia.
Acknowledgement: The views in this article reflect the personal opinions of the authors and are not intended to be an endorsement by EDS, Health Level Seven, the Healthcare Services Specification Project or the Object Management Group.
