White Paper

WHITE PAPER

12/2015

Connected Health Reference Architecture

By Nuwan Bandara
Associate Director/Solutions Architect, WSO2

1. Introduction

In a typical healthcare situation, a person would fall ill, go to the nearest hospital and register as an out-door patient and receive the required treatment. In some cases, the patient would need to take some tests and these activities would be recorded. The healthcare part would probably culminate in the patient being examined by a doctor, given some advice and being prescribed the appropriate medication. However, this event does not end there, because there are other entities that connect back to the person, such as linking up to a financial institution to pay bills, and communication with a workplace if the illness is contagious, and leveraging benefits of an insurance scheme, etc. Therefore, in a healthcare scenario, there are many connected parties and systems that need to be active at the same time. For instance, a recent survey in the US stated that a connected ecosystem could potentially generate $850 million to $1 billion a year in health system efficiencies through increased clinical productivity and reductions in patient transfers, duplicate lab activities, etc. Another study showed that 84% of primary care clinicians share their patients' clinical data across their own organization and use it to help improve their clinical care protocols.

2. Why Does The Healthcare Industry Need to be Connected?

Connected health as a concept refers to providing healthcare in a collaborative manner where information technology will aim to connect disparate systems, devices, and stakeholders. This will bring together the different entities to create a connected health ecosystem, thus making this service efficient and effective for users. It will also enable healthcare institutions to achieve the following long-terms goals:

  • Providing the best possible service through accurate and timely information sources
  • Decrease latencies in connected services
  • Reduce manual executions to reduce human errors (i.e data entry, etc.)
  • Provide high availability of medical information
  • Gain intelligence via information sharing
  • Big data analytics for healthcare research

3. Key Drivers in a Healthcare System

There are many drivers of a connected healthcare system that need to come together to create a connected ecosystem. This can be a challenge given the different functions of each of these drivers as it doesn't just count medical institutes, but all related parties and entities.

Government

A government needs to ensure that the necessary infrastructure is in place for the wellbeing of the country's population and this applies to the healthcare systems as well. For all of this to work seamlessly, the government would prefer to have a single entity that's connected so they don’t need to refer to different disparate systems.

Citizens

In this scenario, the citizens could either be the patient, families of the patient, or the caregivers. These people would need to get the best possible health care in the most efficient manner, i.e. receive immediate medical attention and also be guaranteed that the information provided would be treated as confidential.

Healthcare Organizations

These would include the main healthcare institutions as well as sub institutions that support these organizations in various ways. Each of these would have different systems storing different types of data. If these institutions shared some of this data, they would be able to create synergies and leverage each other's capabilities and thus benefit from being connected.

Insurance Organizations

In most countries, citizens are required to obtain a health insurance to receive healthcare facilities, which means there needs to be a clear link between the health care and insurance organizations. There also should be some degree of confidentiality that restricts sharing of certain irrelevant, yet sensitive information to the insurance organizations. However, the insurance company would need to know certain accurate data to evaluate various opportunities available.

World Healthcare Institutions

Just like how a country would be interested in providing its citizens a good healthcare solution, world healthcare institutions are responsible for creating different standards and ensuring these are applied and followed across the globe. A connected health ecosystem would help facilitate the implementation of these standards.

Research Entities/Universities

Such institutions are instrumental in finding new forms of treatment and new ways to alleviate certain problems. This is two-fold because this would be part of the research in itself and also access to a plethora of data that’s already available. Again, if such data is available to these institutions and vice versa, it would automatically be beneficial to both sides, especially to those who would use these services.

The real challenge here is that if a healthcare business is to remain competitive it needs to make sure it's providing accurate information based on connected data that’s obtained in a very efficient manner. There should also not be any latency issues between these sources either with no delays in aggregated information. The faster and more transparent the process, the better the service provided.

4. Connected Health Reference Architecture - An Overview

From a business architecture perspective, these entities should be connected in a seamless manner, i.e. an integrated healthcare system or the healthcare cloud as illustrated in Figure 1, in order to achieve the benefits of a connected health ecosystem. This will also be the same amalgamated cloud or system cloud that would be accessed from other non-medical entities that would need to interact both for this system to work as well as for the other systems to work.

figure1-connected-health-reference-architecture-01

Figure 1

From a technical perspective, to get the above business architecture in place several technical entities will need to come together. These segregations on the operational aspects on bringing these entities together would form the building blocks of a connected health ecosystem.

4.1 Interoperability

The technological landscape is such that there are many different devices used in the healthcare industry. These devices would typically take various measurements, would be recorded in different formats, might use different protocols, and there would be different applications, services, etc. To achieve efficiency, you need to have a central place where all of these devices and services and workflows are linked so the readings and measurements emitted from these are transformed and then used by the services or workflows. The initial step towards being connected would be to provide a medium that promotes interoperability, such as a bus architecture in a healthcare information system. This would actually do the required transformations in a generic manner and also stop each system from trying to solve the same problem over and over again.

4.2 Data storage and transformation

Data generally resides in multiple locations in different formats. In order to access data, you would need to be able to pull data from different places. In a real isolated healthcare system, there might be a case where the same data is actually stored in multiple systems in different formats; therefore, there’s a significant amount of redundancy. This would also affect accuracy because an event may require data to be stored and updated in these multiple locations. There would also be instances where some of this data would need to be consolidated, thereby creating the need for data consolidation or even data aggregation.

4.3 Data federation and mediation

In addition to the healthcare service bus to which the services, workflows, and various cloud services were connected, there would be a data bus which would source the data from disparate systems. The data bus would link up to many of these data sources, carry out the necessary consolidation and federation, and provide a unified data model to the healthcare service bus. Various services, applications, and cloud services will be accessed in this unified data model (Figure 2).

figure2-connected-health-reference-architecture

Figure 2

4.4 Data accessibility and integrity

The next step would be to focus on confidentiality and security of the data that’s been unified. When data can be accessed and put into a system, it needs to be secured and also have some degree of integrity. This calls for checks such as who's accessing the data, from where the data is being accessed, who created the actual data, etc.

4.5 Security - Identity and entitlement

In terms of identity and entitlement, the various entitlement policies that should be put into place to provide authorization to access this data can be implemented. This provides data governance and entitlement and needs to manage the policies for data governance. It would provide access controls for data access, and the ability to grant or revoke permissions, e.g. if there are different types of data that would be stored, this data will not be readily accessible to everyone in that institution. Only certain doctors for instance would be able to see the very confidential details of a person’s health record. The identity and entitlement bus can be used to provide the technology to introduce these controls as illustrated in Figure 3. When certain requests come into accessing this data it can ascertain if the request is authentic.

figure3-connected-health-reference-architecture

Figure 3

4.6 Events generation

If you consider a typical use-case scenario, there would be several activities that occur when a person is admitted to hospital (admission, discharge, transfers, scheduling surgeries, patient care, lab activity, etc.). Each of these actions would generate an event that would be fired into the various systems. Apart from these, there are certain alerts and events that would be generated through the system itself based on, for example, a checkup that needs to be done routinely or some alerts that would be generated due to some analysis that’s done on a series of reports for a particular patient.

Another example that would come into play here is the insurance scheme management systems; whenever a patient is admitted and an event gets fired into the system, the insurance claim management systems would be activated and that would in turn fire different types of events that would need to fulfill the insurance part of the scenario.

Furthermore, if there is some sort of an epidemic in a particular area, there would be different alerts for disease control or vaccination. The administration of the hospital too, like inventory management, equipment maintenance, etc., would lead to different types of events that are generated in the healthcare system. All of these events would need some sort of processing and analyzing because action would need to be taken based on certain rules.

4.7 Complex health event processing

The final block of the connected health architecture is complex health event processing. As illustrated in Figure 4, the various devices and systems would start pushing events into a queue. All these events would be directed to the bus and then would either be pushed into an event store or an event queue. If they are pushed into an event store, they would be analyzed in a batch-like manner and the results would be used to generate dashboards. If they are pushed into an event queue and a complex event processor, then based on the rules that have been defined, certain action items would be triggered. For example, emails can be fired, or alerts would be sent out, or even another event might go into the system and cause more processing. These events in turn need to be processed in a particular manner using certain rules and some of these rules might actually come in from external systems for which a bridge to the healthcare cloud may be needed as well.

figure4-connected-health-reference-architecture

Figure 4

A combination of all the above components will give you a healthcare ecosystem as depicted in Figure 5.

figure5-connected-health-reference-architecture

Figure 5

4.8 Deployment aspects

In a typical scenario, a person would go to the nearest hospital in an emergency situation because that institution will be fully geared to meet such requirements. Similarly, like the institutions being available, the systems that are needed to run those institutions also need to be highly available. Moreover, these systems need to be able to deal with high loads during peak times, such as crisis situations, hence availability and scalability become an inherent part of the healthcare ecosystem. You need to consider having a disaster recovery management system as well; so putting all of this together, this points towards a healthcare PaaS where elastic scaling on demand is available. The minimum high availability setup is enabled at the beginning, then in a crisis situation where the loads goes up, there would be more nodes serving the different data and services requests. These would be deployed across different availability zones and regions to ensure continuity in the event of a break down.

5. How WSO2 Fits Into the Connected Health Reference Architecture

WSO2 provides a complete product stack that fits well into this reference architecture model. It is a very powerful platform that can be used to build a connected healthcare ecosystem. If you consider WSO2’s product stack, as illustrated in Figure 6, WSO2 Data Services Server can be used as your data bus to carry out data federation among disparate systems. WSO2 Application Server and WSO2 Business Process Server would fit in where the different services and workflows need to be hosted. WSO2 Identity Server can serve as your identity bus providing identity and entitle management services; this product is capable of doing federated authentication which would be a necessity in a scenario where you need to bring together many disparate systems and different user bases. WSO2 Enterprise Service Bus is more or less at the heart of this architecture providing the interoperability aspect and would be responsible for doing all the transformations, mediations, routing, etc. It would also be able to expose certain services and be able to talk via adaptors to different cloud services and provide APIs that can be used by external parties. WSO2 API Manager can be used to ensure these APIs are secured and are well managed in terms of throttling, scoping, and versioning. WSO2 Message Broker can be used for data and event queue and WSO2’s mobile device manager, which is based on the company’s mobility device framework, can be used to register all these devices. WSO2 Data Services Server and WSO2 Business Activity Monitor can be used for the big data analytics part, and WSO2 User Engagement Server for dashboards.

Figure 6: Building and deploying microservices as containers

Figure 6

6. Conclusion

A connected healthcare ecosystem to brings together disparate systems that can work together in an interoperable manner. It would also enable a variety of devices and applications to seamlessly link up to these systems. Data federation and mediation systems would address the need of bringing the disparate systems to a virtually unified system; data governance and entitlement would ensure data and services are secure and will not be exposed to any risks; complex event processing and batch event processing can be added for dashboards and notifications to provide timely information. Technology can transform healthcare delivery and address many inefficiencies especially in the area of workflow management, chronic disease management, and non-medical parties that are key components in the overall connected health ecosystems. Thus, a connected healthcare system enables healthcare institutions to streamline its operations, thereby providing a faster and more efficient service.

x

Interested in similar content?