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 in the 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.
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.
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 DevOps 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:
- Architectural introduction
- Common architectural elements
- Example iDaaS architecture
- Example HL7 and FHIR integration architecture
- Example iDaaS knowledge and insight architecture
Catch up on any articles you missed by following one of the links above.
Next in this series, taking a look at an example iDaaS architecture for the intelligent data as a service solution.
Published on System Code Geeks with permission by Eric Schabell, partner at our SCG program. See the original article here: Intelligent data as a service (iDaaS) – Common architectural elements Opinions expressed by System Code Geeks contributors are their own. |
