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.

For more details about our solutions or to discuss a specific requirement

x

Interested in similar content?