The Evolution of Radiology Reporting: Embracing FHIRcast for Seamless Integration

Interoperability is at the heart of our vision for the future of radiology. Rad AI Reporting leverages standards like HL7, FHIR, and FHIRcast to enhance radiology workflows.

HL7 (Health Level Seven International) is a set of international standards for the transfer of clinical and administrative data between software applications used by various healthcare providers.

Within HL7, FHIR (Fast Healthcare Interoperability Resources) is a standard describing data formats and elements (known as "resources") and an application programming interface (API) for exchanging electronic health records. FHIR aims to simplify implementation without sacrificing information integrity, providing a modern, web-based approach to healthcare interoperability.

FHIRcast builds on FHIR's foundational principles of interoperability and modern web technologies. FHIRcast is an open standard for synchronizing healthcare applications in real-time. It allows applications to communicate and share context, enabling them to stay in sync while the user works across multiple applications.

While many vendors have worked with HL7 and FHIR, not many have worked with FHIRcast just yet. We’ll go over what FHIRcast is, what problems it solves, and how Rad AI uses FHIRcast to push the boundaries of what’s possible in radiology reporting.

To start, let’s take a look at the strengths and weaknesses of FHIR.

What problems are solved by FHIR?

Common Data Model

FHIR provides a standardized and consistent data model known as "resources". Each resource represents a specific aspect of healthcare, such as patients, observations, imaging studies, and procedures. By using these standardized resources, FHIR ensures that different systems can understand and use the data in the same way. FHIR resources are format-agnostic, but commonly implemented using JSON.

Resources used by Rad AI Reporting include, Diagnostic Report, Patient, ImagingStudy, ServiceRequest, and Observation.

Common Access Patterns

FHIR defines a RESTful API as part of its specification. Implementations of this RESTful API specification are often referred to as “FHIR servers”. These FHIR servers provide well-defined endpoints for retrieving FHIR resources, publishing updates to FHIR resources, etc.

Improvements Over HL7

The complexity of HL7 can be a barrier to adoption and effective implementation. The HL7 standards have steep learning curves and often require extensive customization, which can be time-consuming and expensive. FHIR is designed to be simpler and more intuitive. Its modular structure allows developers to use only the parts they need, reducing complexity and making it easier to implement.

Furthermore, conceptual differences from HL7 make FHIR easier to work with. HL7 messages are transactional in nature. To get the up-to-date content for a set of resources, a system needs to read the HL7 resources in order and apply those transactions one at a time to the underlying resources. This essentially forces systems to re-implement their own data store to get the full resource content.

FHIR breaks those constraints by providing a stateful interface instead of a transactional interface. When you request an ImagingStudy resource, you get the full up-to-date state of that resource. Underlying transactions (i.e. creating resources, updating resources, deleting resources) are handled by the FHIR server.

What problems are NOT solved by FHIR?

While FHIR addresses many challenges in healthcare data interoperability, there are certain problems that it does not fully solve, particularly related to real-time data sharing and synchronization across multiple systems.

Real-Time Sharing of Resources

FHIR does not inherently provide mechanisms for real-time notifications or updates when a resource changes in one system. This means that changes to a resource in one system are not automatically propagated to other systems.

Without a built-in method for real-time notifications, systems need to implement their own mechanisms to share updates, which can lead to inconsistencies and delays in data synchronization.

Real-Time Sharing of Context

FHIR does not provide native support for maintaining shared context across different systems. For example, if I open an ImagingStudy in my PACS, my Reporting app should open to the same ImagingStudy.

This lack of shared context can lead to workflow inefficiencies and discrepancies, as different systems may not be synchronized. In scenarios where multiple applications need to work together seamlessly, this can be a significant limitation.

Existing Solutions that FHIRcast Replaces

For real-time sharing of resources and context, healthcare systems often resort to bespoke data-sharing processes. One common approach is the "file-drop" method, which involves writing files to disk and monitoring those files for updates.

Let’s take a look at an example. We’ll assume a Radiologist is using a PACS and the Rad AI Reporting app, with their PACS acting as the “driver” application.

1. A user initiates an action in their PACS, such as opening an imaging study.
2. The PACS pulls the accession number from the imaging study and writes this information to an XML file.
   • This XML file is saved in a pre-defined directory that other systems have access to.
   • That XML file may look like:‍

<ImagingStudy>

           <AccessionNumber>123456</AccessionNumber>

</ImagingStudy>

The Rad AI Reporting app watches for changes to that XML file. When a file change occurs, Rad AI Reporting reads the XML file, extracts the accession number, and fetches the corresponding ImagingStudy resource from the FHIR server.

Problems with the File-Drop Method

• Latency: There can be delays between when the PACS writes the XML file and when other systems detect and process the change.
• Scalability: This method does not scale well, especially in environments with multiple systems needing to stay in sync.
• Standardization: This method lacks standardization, leading to inconsistencies in how different systems implement and interpret the XML files.
• File-system access: All applications must have file-system access to watch and read from files. This introduces complexities for healthcare applications that are built as web apps, as web apps don’t have access to the file-system.

What is FHIRcast?

FHIRcast is a standard developed to provide real-time synchronization and context sharing between healthcare applications. It builds on the foundations of FHIR resources, but focuses specifically on ensuring that multiple applications remain synchronized in real-time as users interact with them.

FHIRcast requires a centralized system to manage real-time synchronization and context sharing. This system is referred to as a “FHIRcast hub”.

Here’s how FHIRcast works:

1. Subscription setup: Applications subscribe to a FHIRcast hub for specific events. This is typically done during application startup.
2. Event triggering: When a user interacts with an application (e.g., opens a patient record or an imaging study), the application sends an event to the FHIRcast hub.
3. Real-time notification: The FHIRcast hub immediately broadcasts this event to all subscribed applications via WebSockets, ensuring they are notified in real-time.
4. Context synchronization: Subscribed applications receive the event notification and adjust their context accordingly. For example, if an imaging study is opened in one application, other applications might display related patient information or open the same study.

Example Use Case - Imaging Study Synchronization

1. A radiologist opens an imaging study in their PACS.
2. The PACS sends an event to the FHIRcast hub, indicating that the ImagingStudy FHIR resource has been opened.
3. The FHIRcast hub broadcasts this event to all subscribed applications, including the Rad AI Reporting application.
4. The Rad AI Reporting application receives the notification and automatically opens the same ImagingStudy, ready for the radiologist to dictate their findings into a new report.

Benefits of FHIRcast

• Standards based: By providing a standard interface, all applications can share data and context seamlessly.
• Centralized access control: FHIRcast provides built-in mechanisms for authentication and authorization, ensuring that only authorized applications can subscribe to and receive updates.
• Robust error handling: FHIRcast offers robust mechanisms for error handling and retry logic within the WebSocket protocol, ensuring reliable communication. If an application falls out-of-sync, FHIRcast provides mechanisms to get back in-sync with the current context.

Potential Drawbacks of FHIRcast

• Complexity of implementation: Implementing FHIRcast requires integrating with a FHIRcast hub and ensuring that all participating applications can communicate with it. While third-party libraries may perform some of the heavy-lifting here, integrating older or legacy systems that do not support modern web technologies like WebSockets or do not adhere to FHIR standards can be difficult.
• Single point of failure: The FHIRcast hub acts as a central point for managing events and notifications. If the hub experiences downtime or failures, the entire real-time synchronization mechanism can be disrupted.

Furthermore, the FHIRcast specification is relatively young. The initial 1.0 release only came out in 2019, and the specification is still evolving alongside the FHIR specification.

Despite these potential drawbacks, Rad AI Reporting has embraced FHIRcast as the go-to mechanism to integrate with other healthcare applications.

How Rad AI Reporting Uses FHIRcast for Integrations

Rad AI Reporting is one application among many that serve radiologists in their day-to-day workflows. We need the ability to integrate with PACS, EMRs, and any other healthcare applications radiologists use.

To solve this problem, Rad AI Reporting leans heavily on FHIRcast for vendor integrations. There are a wide-range of events we listen for and publish, and we have thorough documentation on these events and the workflows they relate to within the Rad AI Reporting application.

There’s a bit of a “chicken and egg” problem with FHIRcast. Because it’s relatively new, not many vendors have committed to integrating it into their products yet. Because there aren’t many vendors with FHIRcast enabled, it’s hard to justify building it into an existing product. Rad AI Reporting is pushing the healthcare ecosystem forward here. We’re actively building out our FHIRcast system and working with vendors to build out their FHIRcast integrations as we roll out to new customers.

We’ve also seen a lot of interest from new tools in the healthcare ecosystem. These are newer applications that want to integrate with vendors but don’t necessarily have the resources or experience to build custom integrations. For these applications, FHIRcast is a modern, low-barrier way to start integrating with other applications.

Another way Rad AI Reporting has built out FHIRcast integrations is through “hackathons”. These are events many individuals and companies attend to push the industry forward in regards to healthcare application interoperability. Recently, Rad AI Reporting has participated in two of these events.

IHE Connectathon - Trieste, 2024

IHE Connectathons provide a detailed implementation and testing process to enable the adoption of standards-based interoperability by vendors and users of healthcare information systems. During a Connectathon systems exchange information with corresponding systems in a structured and supervised peer-to-peer testing environment, performing transactions required for the roles (IHE actors) they have selected to perform in carefully defined interoperability use cases (IHE profiles).

Rad AI partnered with Agfa for this IHE Connectathon. We tested Rad AI Reporting’s FHIRcast capabilities with Agfa HealthCare Enterprise Imaging. For our integration, Agfa would have the “driver” application, and Rad AI would have the “driven” application. This meant that Agfa would set the current context via FHIRcast events like DiagnosticReport-open, and Rad AI Reporting would update resources via FHIRcast events like DiagnosticReport-update.

Partnering with Agfa at the IHE Connectathon was a massive success. Both teams were able to pass all tests, becoming the first vendors to pass all Integrated Reporting Application tests. Some of the workflows we were able to demonstrate include Interruptions Without Losing Progress and Sharing Measurements from PACS. By using FHIRcast, these types of integrations are now open to all other vendors, making integration with Rad AI Reporting seamless and simple.

Interrupted Without Losing Progress

This demo shows how a radiologist could:

1. Start working on a report (the “original report”).
2. Get interrupted and start on another report (the “interrupting report”).
3. Sign and send off the interrupting report.
4. Switch back to the original report without losing progress.

Below, Agfa demonstrates the “Suspend/Resume” IRA Profile

Sharing Measurements from PACS

This demo shows how a radiologist could:

1. Make structured measurements in their PACS.
2. Use those structured measurements in the report.

Below, Agfa demonstrates the “Content Creator” IRA Profile by sending measurements from their PACS to Reporting

Note that FHIR resources inserted into the report as “measurements” are stored as-is. You can see this in the image below, we’re storing ObservationComponent and ImagingSelection resources.

SIIM Hackathon - 2024

The Society for Imaging Informatics in Medicine (SIIM) is a global advisor and thought leader in imaging informatics, focusing on enterprise imaging, artificial intelligence, cybersecurity, infrastructure, and standards.

SIIM Hackathon Project Showcase. Martin’s project, “Integrated Reporting and Conferencing with FHIRcast” is the first project in the showcase

Rad AI Reporting did not officially participate in the event; however, we played a supportive role by assisting one of the participants, Martin Bellehumeur, with the integration of FHIRcast into his hackathon project. This collaborative effort highlights our commitment to advancing interoperability and supporting the broader healthcare community, even outside of direct event participation. Martin’s project was an integration between Open Health Imaging Foundation (OHIF) and Rad AI Reporting. The idea was to enable “FHIRcast Conferencing”, allowing conference leaders to share context and drive the applications for conference attendees through the use of FHIRcast.

The project showcases some of the deep integrations Rad AI Reporting can have with other vendors. Some of the workflows enabled by this integration include:

• Opening an imaging study in OHIF will create or open that report in Rad AI Reporting.
• Sending measurements taken from OHIF to Rad AI Reporting, and adding those measurements into the report.
• Selecting a measurement in Rad AI Reporting sharing that selection with OHIF, bringing that measurement into context.

Congratulations to Martin for his project’s 5th place win in the SIIM Hackathon!

Why Standards Matter

Modern healthcare technology standards like FHIR and FHIRcast are crucial for enhancing interoperability and communication between disparate healthcare systems. By providing a common framework for data exchange and real-time synchronization, these standards enable seamless sharing of patient information across various applications and platforms. This connectivity ensures that healthcare providers have timely access to comprehensive patient data, which facilitates more informed decision-making, reduces the risk of errors, and streamlines workflows. Ultimately, the adoption of standards like FHIR and FHIRcast leads to more coordinated and efficient patient care.