In our previous article from this series we talked about the example iDaaS data architecture which outlines at a higher abstraction level the solution for any healthcare organisation.
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 example data integration architecture, we’ll walk you through a more specific example. This scenario is showing a proven and scalable architecture for integrating HL7 and FHIR solutions into your healthcare organisation.
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 HL7 and FHIR integration
In the previous article, details were given for a general overview of the data integration architecture for iDaaS. In this example the goal is not focus more on the collection of iDaaS Connect integration services and how they are specifically architected to integrate HL7 and FHIR systems in a healthcare organisation.
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 all the various integration services for specific communication channels as discussed in the previous article.
Specific to this example, the figure narrows the scope of iDaaS Connect to just those required for HL7 and FHIR integration scenarios. Two elements are shown and each one is a specific collection of microservices implementing their respective communication standards. The HL7 connect microservices element provides connectivity to systems and organisations that have adopted this specific healthcare standard. A FHIR connect microservices element does the same for that healthcare standard. Backing both of these elements is a message transformation microservices element. This is used to ensure messages are in the formats needed for the eventual backend events that need to take place when they come into the architecture, or translated back out to the right standard for the end point consumer.
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, the iDaaS generic architecture provides both conformance and insights into the knowledge being managed by the offered solutions. For simplicity these elements were left out of this specific architecture diagram.
Next up, a look at the architectural solution with a focus on the data view.
iDaaS HL7 and FHIR integration (data)
Data connectivity through the iDaaS connect HL7 and FHIR integration 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 HL7 and FHIR integration 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.
Next in this series, taking a look at a more specific architectural example of iDaaS data insights that can be mapped to your own intelligent data as a service solutions.
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) – Example HL7 and FHIR integration Opinions expressed by System Code Geeks contributors are their own. |
