In previous articles, we’ve explored the advantages of integrating systems in healthcare and the main healthcare standards. Now, let’s describe the ideal scenario for integrating our application, which leads us to Service-Oriented Architecture (SOA).

In this article, we’ll discuss SOA, its purpose, role in applications, relationship with web services, and more. We’ll cover where to start SOA integration the benefits of adopting this strategy based on evidence and our experience.

Before defining SOA, it’s important to understand the problem that led to its creation. This takes us to the “spaghetti architecture,” or point-to-point integration, a genuine anti-pattern.

Point-to-Point integration and its problems #

For many years, there has been a need to integrate applications in healthcare systems amid rapid technological evolution. Those of us who’ve been in the field for a while know the challenges of doing things hastily.

The problem is that these needs have been addressed sporadically, focusing on short-term cost savings and immediate goals, without a strategic or future vision.

Each communication in the integration was point-to-point, implemented through embedded applications, database connections, FTP files, etc., leading to tightly coupled systems. Each system used its semantics or misused standards in communications.

After some time of adopting this “strategy,” systems become trapped in “spaghetti architecture.” This can be quantified by calculating the total number of point-to-point connections based on the number of integrated systems.

For example:

• 2 systems: 1 connection.
• 3 systems: 3 connections.
• 4 systems: 6 connections.
• 5 systems: 10 connections.
• …
• 50 systems: 1225 connections.
• 100 systems: 4950 connections.

C = (N * (N - 1)) / 2
Where:
- N: number of systems
- C: number of point-to-point connections.

Clearly, integrating even a few systems makes it nearly impossible to replace, add, or update systems.

SOA to the rescue #

Facing this undesirable scenario, we might ask:

Wouldn’t it be ideal to centralize all this redundant information flow in a way that allows systems to be decoupled from each other?

Wouldn’t it be preferable to have generalized business processes represented on a service catalog, rather than specific needs and functional requirements for each application?

Wouldn’t it be beneficial for integrated systems to correctly use the same messaging and semantic standards?

Wouldn’t it be wise to adopt a common strategy that allows natural technological evolution of information systems, and the replacement, addition, and updating of integrated systems without incurring exorbitant costs?

You can find the answers to these questions and more in the next section on what SOA is, its benefits, and the roles our application can play in this architecture.

What is SOA? #

SOA stands for Service-Oriented Architecture. There are many definitions of SOA online, depending on who adopts it, how, and where.

Some tech providers see SOA as a technology architecture centered around an Enterprise Service Bus, others relate it to web services or a set of applications for system integration. The term has been attributed almost everything.

However, SOA is not a technology or software/hardware architecture in itself, nor even a concept. We align with those who think that SOA is a strategy focused on business processes that lead to a service catalog. Web services are part of the recommended technological solution for its implementation, though not mandatory.

As technology providers specialized in system integration, we discuss SOA from the perspective of integrated applications. From our viewpoint, there’s a huge difference between integrating an application within SOA and without it. Hence, we always advise organizations to commit to an SOA strategy. It’s a long-term investment that’s truly worthwhile.

Other interesting links include:

• SOA on Wikipedia.
• SOA on arcitura.com.
• A successful SOA case in Spain: Andalusian Health Service (SAS) (in Spanish).

What roles can our application play in SOA? #

In SOA, there’s a catalog of services. Examples of these services are:

• admitting a patient,
• discharging,
• merging medical records,
• reporting lab results, radiological studies, medical prescriptions,
• etc.

Although each healthcare system has its catalog, there’s a basic set of common services usually implemented.

To integrate our application with SOA, we need to determine which services we want to consume and which we can produce (or provide). Our application should declare itself as a consumer of some services and a producer (or provider) of others.

Our application as a service consumer #

To integrate our application, we need patient information and medical records. Basic services, generally produced by the Hospital information Systems (HIS), allow us to keep an updated patient census for our application.

The most common services are:

• creating a new patient,
• modifying patient demographic data,
• and merging patients.

Less common but sometimes implemented are deleting a patient and undoing a patient merge.

If we need information from other systems, like LIS or RIS,, we simply declare ourselves consumers of their services. This must be justified to the organization for needing this additional information.

One of the great advantages of SOA is the weak coupling of systems. If one of these systems changes in the future, the new one only needs to implement the same services, and we, as consumers, would not be affected. We must also be aware that our system can be replaced by another. This is unthinkable with the point-to-point integration strategy.

Our application as a service producer #

If the information our application provides fits into a service in the catalog, we can declare ourselves producers (or providers) of that service.

If our application produces useful information that doesn’t fit any service in the catalog, we need to negotiate with the organization for its inclusion.

In any case, the key is that all specification and analysis tasks are done directly with the organization, regardless of the applications we share information with.

So far, we’ve discussed the problem of point-to-point integration or “spaghetti architecture”, introduced the term SOA, and examined some ideas to consider if we want to integrate within SOA. To conclude this article, we will look at the relationship between SOA, web services, and healthcare standards, and finally, we’ll summarize the advantages of adopting an SOA strategy.

SOA, healthcare interoperability standards and web services #

This section completes our article on SOA. Previously, we’ve introduced SOA, starting from the problem of “spaghetti architecture” or point-to-point integration. Now we know that in SOA there’s a catalog of services we can consume or produce (or provide).

Let’s see the relationship between these services, web services, and healthcare interoperability standards. We’ll conclude by summarizing all the advantages (and more!) of adopting an SOA strategy.

It’s important not to confuse SOA services with web services; they are entirely different. This widespread belief mistakenly links web services closely to SOA.

Web services, a prevalent technology today, arose from the need to exchange data between applications developed in different programming languages and executed on different platforms. They use a set of protocols familiar to us, like HTTP, FTP, SMTP, SOAP (not to be confused with SOA!), or REST, and can be described using an API or WSDL.

Web services are interesting for SOA because they can be described (using a WSDL or the API documentation), this establish a contract between parties to produce or consume a service. In summary, it is highly recommended using web services for implementing SOA services, but they are not the only option. SOA as a strategy should be above all technologies and implementations.

What Role Do Healthcare Standards Play in SOA? #

Regardless of how services are implemented in SOA, the clinical information exchanged must be based on healthcare standards.

Example with the Patient Census

Continuing the previous section’s example, to maintain the patient census in a healthcare system using an SOA strategy, web services for implementation, and HL7 messaging, we would need to:

1. Identify the services in the catalog we want to consume.
2. Publish a web service for each of these services.
3. Process the received HL7 messaging.

The organization must decide which types of HL7 messages to use to implement its services. Typical implementations include:

• ADT^A28 for creating a new patient,
• ADT^A08 for modifying a patient,
• ADT^A40 for merging patients,
• ADT^A23 for deleting a patient,
• ADT^A37 for undoing a patient merge,
• and ADT^A47 for changing a patient’s list of identifiers.

Within these implementations, the organization must also decide which controlled vocabularies to use for semantics (SNOMED-CT, ICD-11, LOINC, etc.).

In short, if we want to integrate our application into SOA, we must use implementations based on healthcare interoperability standards established by the organization.

Advantages of adopting a SOA strategy #

We’ve already highlighted many benefits of following a Service Oriented Architecture (SOA) strategy. Let’s summarize them and add a few more:

Flexibility and scalability #

Weak coupling between integrated systems makes it easy to replace, add, and update them. This means that these changes will not affect our integrations.

No dependency on technologies #

Using technologies like web services allows for the exchange of information between applications, regardless of the technologies and platforms they use.

Concentrated services #

The use of a service catalog imposed by the organization centralizes all the business processes of the system. This avoids redundant analysis of the specific functional requirements of each application.

Centralized routing and uniform security treatment #

All communications between endpoints are centralized. This makes it possible to exchange information between applications without having to perform specification and analysis tasks directly with them. All the necessary management to integrate our application is done through the organization, which also allows for a uniform approach to security.

Composition of services based on simpler ones #

The organization should define a level of granularity large enough to cover a complete business process, yet small enough to meet specific needs that may exist in applications. This allows for the creation of more general services from simpler ones if required by our application.

Use of healthcare standards #

All integrated systems must use the healthcare interoperability standards imposed by the organization to produce (or provide) or consume services from the catalog.

And of course, cost reduction #

All these advantages make adopting this strategy a very good investment for all parties involved. It will undoubtedly reduce significant costs in the medium to long term and allow the system to continue growing and evolving naturally.

With this, we conclude our article on SOA: we started with the problem of “spaghetti architecture” or point-to-point integration, explained what SOA is, and finally discussed its relationship with web services and the advantages it offers.