Intelligent Data as a Service (iDaaS) - Common Architectural Elements

In the previous article from this series we introduced an architecture around intelligent data as a service (iDaaS) for the healthcare industry.

The process was laid out how we approached the use case and how portfolio solutions are the base for researching a generic architecture.

The only thing left to cover was the order in which you'll be led through the details.

This article starts the real journey at the very top, with a generic architecture from which we'll discuss the common architectural elements one by one.

Architecture review

As mentioned before, the architectural details covered here are based on real solutions using open source technologies. The example scenario presented here is a generic common architecture that was uncovered while researching those solutions. It's our intent to provide guidance and not deep technical details.

This section covers the visual representations as presented, but it's expected that they'll be evolving based on future research. There are many ways to represent each element in this architecture, but we've chosen a format that we hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.

Now let's take a look at the details in this architecture and outline the solution.

From specific to generic

Before diving into the common elements, it might be nice to understand that this is not a catch all for every possible solution. It's a collection of identified elements that we've uncovered in multiple customer implementations. These elements presented here are then the generic common architectural elements that we've identified and collected into the generic architecture.

It's our intent to provide an architecture for guidance and not deep technical details. You're smart enough to figure out wiring integration points in your own architectures. You're capable of slotting in the technologies and components you've committed to in the past where applicable. It's our job here to describe the architectural generic components and outline a few specific cases with visual diagrams so that you're able to make the right decisions from the start of your own projects.

Another challenge has been how to visually represent the architecture. There are many ways to represent each element, but we've chosen some icons, text and colours that we hope are going to make it all easy to absorb.

Now let's take a quick tour of the generic architecture and outline the common elements uncovered in our research.

Edge services

Starting on the left side of the diagram, which is by no means a geographical necessity, there are two elements that represent external edge services that are integrated with the core elements of this architecture.

The first are edge devices,  covering basically everything that is used in the field from clinical personnel, patients, to partnering vendors. These can be anything from sensor devices to mobile units such as phones or tablets, but certainly not limited to just these. It's a grouping to identify functionality on the edge of this use case.

The second is a catch all for data collection and consumption called external data sources, a broad element containing all of the remote devices. For example, a heart monitoring machine capturing diagnostic information from a heart patient at home.

iDaaS core

These elements are core to the iDaaS solution and are deployed on a container platform to indicate the cloud-ready nature of this architecture.

Starting on the top right and working down from left to right, the first element is iDaaS knowledge insight. This represents the management applications that provide analytics and insights into the data available across the live platform. This can be setup to provide near-realtime gathering and reporting as organisational need require.

This architecture relies on event streaming to react and respond to events within the iDaaS solution, making the iDaaS connect events element central to the solution. This is the element designed for collecting data streams and messages, making it all available to applications and services as subscribers, and pushing notifications as needed to interested parties when certain events happen.

Core to any data architecture has to be integration. The iDaaS connect element represents the collection of both integration services and data integration services that are essential to bringing data, messages, and systems throughout a healthcare organisation together in a seamless fashion.

The iDaaS connect data distribution element is a solution where routing of data to the desired destination happens. This can be incoming data being routed to the correct data store, or out bound data being routed to the right service, application, or end user.

One of the most essential requirements for any healthcare organisation is to maintain compliancy to national laws, data privacy, and other transitional requirements. The iDaaS knowledge conformance element is a set of applications and tools that allow for any organisation to automate compliancy and regulation adherence using rule systems customised to their own local needs. This is a very flexible element that can be designed to ensure that compliancy audit requirements are constantly met.

While data distribution can be a simple way to ensure data ends up in the right location, often there is a need for a more intelligent near real-time adjustment to the route data needs to take. Using the iDaaS intelligent data router allows for rule based intelligent routing based on message content, data origin, data destinations, or any other metric required to determine routing.

For any healthcare organisation one can expect that there are some complexer processes that might require partially automated processing or even human interaction such as the four eyes principle. An element shown here as the iDaaS event builder is meant for capturing all the process automation needs for any healthcare organisation. It's easy to integrate with data, events, services, applications, and provides a treasure trove of processing metrics to help tune your organisations activities for patients and clinical staff.

Finally, there is a need to provide access to internal services through generic application programming interfaces, or API's. The API management element provides all the needed functionality to help expose and connect with services, applications, and more.

External services

External services host an array of potential tools, systems, or third-party applications that are used in healthcare organisations.

Every organisation has reporting services, either internal or external. These can be Software as a Service (SaaS) tools or just hosted tooling that is external to the organisation.

There are any number of big data solutions and tools that can be found in healthcare architectures, often external to the organisation as they are working on very, very large data sets.

Monitoring & logging tools are in abundance together with analytics these also can be hosted externally applications, tooling, or interfaces to be integrated into a healthcare architecture.

Many organisations are engaged with other partner data services and need to be able to interact in a timely fashion when sharing or pulling from these data sources.

All of the above external services have a need to provide consistent access, which is done using an external API management element shown here that can be a SaaS offering or just hosted externally to the organisation.

Finally, both security and any D evOps infrastructure or tooling can be hosted externally and needs to be integrated into the delivery processes for healthcare organisations that make use of them.

What's next

This was just a short overview of the common generic elements that make up our architecture for the intelligent data as a service architecture. 

An overview of this series on intelligent data as a service architecture: