In our previous article from this series we talked about the example iDaaS data architecture specifically integration for HL7 and FHIR healthcare standards.
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 exploration of an HL7 and FHIR integration architecture, we'll walk you through a more specific example. This scenario is showing a proven and scalable architecture for integrating data insights into your healthcare solutions.
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.
In the previous article, details were given for a specific integration architecture for iDaaS that focused on HL7 and FHIR healthcare standards. In this example the focus moves to gathering knowledge about the iDaaS solutions and ensure that compliancy and conformance is met.
This diagram also simplifies the iDaaS Connect collection by reducing it to a single FHIR connect microservices element working with message transformation microservices element.
With that in mind, let's starting on the left side of the diagram where the entry point for actors in this architecture can be found. They're representing the edge devices as well as the users 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 the single integration service for FHIR communication channels as discussed in the previously.
After all of the standards integration and eventual message transformation activities, iDaaS Connect services register events (and receive event notification from) the iDaaS connect events. This is a central hub that ensures all events are registered, managed, and notifications are sent 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, we reach the focus of this example.
This 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. Access is shown for the compliancy officer or similar user for maintaining, monitoring, and reporting on compliancy data.
Next up, a look at the architectural solution with a focus on the data view.
iDaaS insights (data)
Data insights through the iDaaS insights architecture provides a different look at the architecture and gives us insights into how our healthcare solutions are performing.
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.
This was just a short overview of an example data insights 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 data architecture
- Example HL7 and FHIR integration
- Example data insights
Catch up on any articles you missed by following one of the links above.
This completes the series and we hope you enjoyed this tour of the intelligent data as a service architecture.