Embracing modern event-driven architecture is key in handling the healthcare industry’s vast data growth, which accounts for about 30% of global data. This approach, especially pivotal for FHIR servers processing real-time data, enhances system resilience, scalability, and interoperability.
The use of event-driven architecture in healthcare can help developers create decoupled, scalable, and fault-tolerant systems. That’s why at the inception of the Kodjin, our team chose the event-driven approach for our FHIR server architecture.
For a detailed comparison between Kodjin and other FHIR interoperability solutions, refer to our Kodjin vs. HAPI article, which provides insights into the advantages of Kodjin’s event-driven design.
In this article, we will delve into the benefits and implementation of this type of architecture in healthcare.
What is event-driven architecture in FHIR?
Event-driven architecture (EDA) is a decoupled architectural design based on asynchronous communication between event producers and consumers. The detection, transmission, and processing of FHIR events are the core structure of the event-driven approach.
This differs from the traditional request-driven model, where a system has to wait for a reply before moving on to the next task.
What is an event?
An event is defined as an important action or change in the state that occurs in the system. Events in the context of EDA shouldn’t be confused with event notifications, which are messages sent by the system to communicate to another part of the system that an event has happened.
Events are delivered in near real time, so consumers can respond immediately to events as they occur. Producers are decoupled from consumers—a producer doesn’t know which consumers are listening. Consumers are also decoupled from each other, and every consumer sees all of the events.
In the FHIR server architecture, a source of an event can be resource changes such as creating, editing, or deleting a resource. Once FHIR events occur, they are stored in event records.
How does an event-driven FHIR server architecture work?
A typical event-driven architecture for an FHIR server design consists of event producers, event brokers, and event consumers:
- Event producers detect events and notify event brokers about the occurrence. Event producers do not know the consumer of the event.
- Event brokers are responsible for determining which event consumer receives which event. They asynchronously filter and route the events to consumers. The broker is not necessary, especially if there’s only a single event producer and a single event consumer who communicate directly.
- Event consumers listen to events and process them once informed.
Illustrated, this process will look as such:
Event-driven FHIR architecture models
There are two models on which event-driven FHIR architectures can be built:
Publish/subscribe model: In this architectural pattern, event producers, referred to as publishers, send event messages when an event is published to event consumers, referred to as subscribers. After an event is received, it cannot be replayed, and new subscribers do not see it. When a dedicated broker sits between the publisher and subscribers, it receives all the publishers’ events and notifies those who have registered interest in receiving them.
Event streaming model: In addition to brokers routing events, they are also recorded in a log called an event stream. Event consumers don’t subscribe to an event stream. Instead, they can read from any part of the stream and can join it anytime.
How we built an event-driven FHIR server architecture
To better demonstrate how an event-driven pattern can work in the context of FHIR, we will use a Kodjin FHIR server as an example. Our team developed Kodjin with the idea of building a high-performance and agile FHIR server that would be able to support national-level projects.
Based on our technical expertise and previous experience developing national healthcare systems for high-load processing, we decided to build Kodjin on microservices with asynchronous, non-blocking event-driven interactions whenever possible.
In our FHIR server architecture, we used Debezium for MongoDB, Apache Kafka, Elasticsearch, and Clickhouse connectors.
Debezium is used by Kodjin as a change data capture (CDC) controller. It’s built on top of Apache Kafka and provides Kafka connectors that monitor the database and pick up any changes. As the data in the source MongoDB database changes, this results in Kafka event streams that are then streamed through connectors into the Elasticsearch search engine and ClickHouse history storage. This process is illustrated in the image below.
In Kodjin, events are used internally for several purposes:
- Search index update: the change in data is affecting the Elasticsearch search index.
- History database update: the version of data is stored in the ClickHouse history DB.
- Subscriptions: a subscription consumer checks whether a change in data falls into some FHIR subscription. If yes, a notification is sent identifying the subscription.
Patient $everything and FHIR bulk: denormalized data is written into collections, so when the request is made, it is collected faster from denormalized data.
5 Benefits of Event-Driven FHIR Server Architecture
Now that we know how the event-driven approach works, let’s look at the many benefits of event-driven architecture.
1. Asynchronous
Event-based architectures are asynchronous without blocking. This means that resources can be freely allocated to the next task once their workload is complete. Events can be queued, which takes off the load from the producers.
2. Loose coupling
Services are interconnected in a way that requires the least dependency. In the event-driven architecture, services run independently of each other and thus can be deployed, updated, or tested more easily.
Scalability
Since the services are decoupled, they can be scaled individually without impacting other services. This lowers the risk of compromising system integrity and makes scaling more cost-efficient.
Recovery support
In the event-driven architecture, events are logged and can be replayed to prevent data loss and identify the cause of a failed event.
Responsiveness
With an asynchronous approach in event-driven architecture, requests don’t need to wait for a response and are processed as soon as possible, resulting in a lightning-fast response time.
The advantages of event-driven architecture are notably impactful in today’s fast-paced digital environment. This approach offers remarkable scalability and responsiveness due to its asynchronous processing capabilities. The loose coupling of services and components ensures greater flexibility and ease in system maintenance. Additionally, the real-time processing of events facilitates immediate response to dynamic conditions, making event-driven architecture a preferred choice for complex, high-volume applications across numerous industries.
Challenges of Implementing Event-Driven Architecture in Healthcare
Implementing event-driven architecture (EDA) in healthcare presents unique challenges, particularly due to the complex and sensitive nature of healthcare data and systems. Here’s an overview of these challenges, intertwined with the potential of event-driven architecture patterns to address them:
1. Complex Event Processing
Healthcare systems often have complex workflows and require processing a large volume of events. This complexity can be overwhelming, especially when transitioning from traditional, linear architectures. To manage this, patterns like CQRS (Command Query Responsibility Segregation) and Event Sourcing can be employed, allowing for better handling and segregation of data manipulation and data querying responsibilities.
2. Data Security and Privacy
Given the sensitive nature of healthcare data, ensuring security and privacy is paramount. In an event-driven system, where data is constantly in motion, implementing robust security protocols becomes challenging. Using secure event channels and encryption patterns can help safeguard data transmission.
3. Integration with Legacy Systems
Healthcare is known for its reliance on legacy systems. Integrating these with a modern event-driven framework can be daunting. Adapter and Bridge patterns can facilitate this integration, allowing older systems to communicate with new event-driven architectures without extensive reengineering.
4. Scalability and Performance
Healthcare systems must scale effectively to handle varying loads, especially during critical situations like health crises. Scalability patterns in event-driven architecture, like Sharding or Load Leveling, can help distribute workload efficiently across the system.
5. Reliability and Fault Tolerance
In healthcare, system failures can have serious consequences. Ensuring high reliability and fault tolerance in an event-driven setup is crucial. Implementing patterns like Circuit Breaker or Bulkhead can help isolate failures and maintain system stability.
6. Real-time Data Processing
Healthcare often requires real-time data analysis for prompt decision-making. Event-driven architectures excel at this, but setting up a system that can process and analyze data in real-time is challenging. Utilizing Stream Processing and Complex Event Processing patterns can aid in achieving real-time data analytics.
7. Decomposing Monolithic Systems into Microservices
Transitioning from a monolithic system to a microservices-based, event-driven architecture is a significant challenge in healthcare. Patterns like Decompose by Business Capability can guide the segmentation of monolithic systems into more manageable, independent microservices.
8. Asynchronous Communication Complexity
Managing the asynchronous nature of EDA can be difficult, especially in ensuring data consistency and order. Applying patterns like Saga can help manage long-running, distributed transactions and maintain consistency across microservices.
9. Monitoring and Debugging
Monitoring an event-driven system with numerous independent components is complex. Implementing distributed tracing and log aggregation patterns can make monitoring more manageable and aid in debugging.
In conclusion, while event-driven architecture offers numerous benefits for healthcare systems, including improved scalability, real-time data processing, and flexibility, it comes with its own set of challenges. These challenges can be effectively managed by applying appropriate architectural patterns and strategies tailored to the specific needs of healthcare environments.
Conclusion
An event-driven FHIR architecture benefits healthcare organizations to better adapt to changes and make faster, well-informed decisions by providing a near real-time system response. Using the event-driven approach, you can build resilient FHIR architectures with increased agility and scalability.
The Kodjin team is open to cooperation and consultation. Get in touch with us to request a demo of the Kodjin FHIR server to see how you can leverage the event-driven approach for your FHIR project.
FAQ
Is there a difference between FHIR architecture and event-driven architecture?
Yes, FHIR is a standard for exchanging healthcare data. It structures data into resources and data elements to be used within healthcare information systems. FHIR architecture is based on a RESTful web services approach, meaning data is accessed using HTTP methods such as GET, POST, PUT, and DELETE. FHIR resources can be exchanged between healthcare systems, making it easier to share patient data between different healthcare providers.
On the other hand, event-driven architecture (EDA) is an architectural pattern that focuses on events as the primary means of communication between different components of a system. In an EDA, components communicate by producing and consuming events. Events can represent things like changes in data, user interactions, or system events. An EDA allows for loosely coupled systems that can scale and evolve more easily than tightly coupled systems.
While FHIR and EDA can both be used in healthcare systems, they serve different purposes. FHIR is a standard for exchanging healthcare information, while EDA is an architectural pattern for designing systems that communicate through events. But as we have discussed in the article, FHIR resources can be used as event triggers to communicate events in an event-driven architecture.
Why choose an event-driven architecture for FHIR servers?
An event-driven architecture can improve healthcare interoperability by enabling real-time data processing and response to changes in the environment. It also allows for better scalability and flexibility in FHIR server design.
What are some benefits of using event-driven architecture for FHIR servers?
The benefits of using event-driven architecture for FHIR servers include improved scalability, flexibility, and real-time data processing. It also enables more efficient and cost-effective data integration and interoperability between different healthcare systems.
How can event-driven architecture be implemented for FHIR servers?
Event-driven architecture can be implemented for FHIR servers through the use of message brokers, event-driven frameworks, and other tools that enable communication between system components through events. It also requires careful consideration of FHIR data models and messaging protocols.
