Intelligent Data as a Service (iDaaS) - Example Data Architecture

In our previous article from this series we talked about the logical common architectural elements found in an intelligent data as a service (iDaaS) solution 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. It continued by laying out the process of how we approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.

Having completed our discussions on the common architectural elements, it's now time to look at a specific example. This article walks you through an example data integration scenario showing how expanding the previously discussed elements provides an example for healthcare data integration scenarios.

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.

iDaaS integration

This first look is of the overall data integration architecture for iDaaS with the details filled in that were discussed as logical elements previously. Starting on the left side of the diagram, the entry point for the actors you can expect for this use case. It's representing the edge devices and the actors, that are submitting requests and receiving responses. These users are representing patients, vendors, suppliers, and clinical personnel. The administrators is representing the clinical personnel tasked with managing the various healthcare processes.

All requests enter through the API management element, used to secure and authenticate access to internal services and applications. The first collection of elements encountered is labeled as iDaaS Connect, where we find all the various integration services for specific communication channels. These are but a few of the options available, some being very generic such as iDaaS connect third party, but others are more specific to specialised healthcare standards; iDaaS connect HL7, iDaaS connect EDI, iDaaS connect FHIR, iDaaS connect Blue Button, and iDaaS connect ePrescribe. Each of these individual elements are integration services that handle both the message standards and transformation needed between systems and those standards.

The iDaaS Connect services will register events and receive event notification from the iDaaS connect events. This is a central hub that ensures all events can be registered, managed, and notifications sent when needed to the appropriate elements in the iDaaS architecture.

Events will often trigger elements of the iDaaS DREAM collection to take action, through the iDaaS event builder which captures business automation activities and the iDaaS intelligent data router. This data router is capable of managing where specific data needs to be sent, both inbound to sources and outbound to application or service destinations. It's assisted by the iDaaS connect data distribution element which ensures integration with all manner of data sources which might be in local or remote locations such as a public cloud. There are all manner of possible, and optional, external services that a healthcare organisation might integrate from third-party or externally hosted services such as reporting services, security, analytics, monitoring & logging, external API management, big data, and other partner data services.

Finally, the iDaaS architecture provides both conformance and insights into the knowledge being managed by the offered solutions. The iDaaS knowledge insight element manages 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. An essential requirement 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.

Next up, a look at the architectural solution with a focus on the data view.

iDaaS integration (data)

Data connectivity through the iDaaS architecture provides a different look at the architecture and gives us insights into how one of the most valuable assets of a healthcare organisation is being processed.

It should be seen as the architecture is intended, as a guide and not a definitive must-do-it-this-way statement on how the data is being routed through as actors are engaging with the systems, applications, and services in this architecture.

Note that many of the data flows only one direction while it's fairly obvious it's going to flow both ways. We've chosen to note that in the flows that do not disrupt the clarity of the architecture diagram, and chose not to indicate where the intent is to show processing and flows for clarity from actors to systems on the backend.

It's left to the reader to explore these data diagrams and feel free to send comments our way.

What's next

This was just a short overview of an example data integration architecture for the intelligent data as a service architecture.

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