Medplum’s Open-Source FHIRcast Hub Enables Rad AI Omni Reporting's Interactive Measurements
Radiology is a bellwether for innovations in Healthcare IT due to the time-sensitive and data-intensive workflow. Naturally, radiology applications lead the way in adopting real-time functionality like FHIRcast, a WebSockets-based protocol that enables development of highly interactive applications.
Let’s consider an example: a radiologist makes a tumor measurement from a PACS workstation; that measurement can be sent in real-time to the FHIRcast hub as an event. The event is then forwarded to the radiologist’s report editor, where a context-aware description is automatically filled in describing the tumor findings, all without the radiologist ever needing to touch another application or do dictation.
Proprietary notification systems are a walled garden, and make it difficult or impossible to build highly ergonomic applications. An open-source FHIRcast hub is a foundational community asset, as developers and vendors can focus on building integrations rather than the plumbing. Open source provides a lot of flexibility for prototyping, testing and integrations across organizations.
Integration is a thorny problem in healthcare overall, and the adoption of standards has been a key tool in allowing system interoperability. Specifically for FHIRcast, a reference implementation that partners can prototype against and use without restriction will increase quality and speed of integration.
Rad AI Omni Reporting uses the Integrated Reporting Application (IRA) spec and Medplum’s open source FHIRcast hub to enable the rich, interactive application seen in the video.
Rad AI is excited to use open source FHIRcast for context syncing and data passing with our imaging and worklist partners. Having an open-source, standards-based FHIRcast hub lowers the barrier of entry for products to work together.
Rad AI is the fastest-growing radiologist-led AI company. The company was recently listed on the CB Insights’ Digital Health 50 as one of the top privately-owned companies using digital technology to transform healthcare, Digital Health 150 as one of the most innovative digital health startups, and AI 100 as one of the world’s 100 most promising private AI companies. Rad AI won AuntMinnie’s “Best New Radiology Software” in 2023 for Omni Reporting and “Best New Radiology Vendor” in 2021. In 2022, Black Book ranked Rad AI #1 in Mean KPI score on its survey of 50 emerging solutions challenging the healthcare technology status quo.
Founded in 2018 by the youngest radiologist in U.S. history, Rad AI has seen rapid adoption of its AI platform and is already in use at 8 of the ten largest private radiology practices in the U.S. Rad AI uses state-of-the-art machine learning to streamline repetitive tasks for radiologists and automate workflow for health systems, which yields substantial time savings, alleviates burnout, and creates more time to focus on patient care.
Those who have experienced the wait and shuffle of a specialist referral will appreciate the thoughtful and futuristic approach of the team at Titan Intake.
Continuity of care is broken because practices rely on fax and paper referral workflows to send patients to specialists. It is unrealistic to expect practices to change their systems, but patients need referrals and practices want to process them faster and capture all of the incoming clinical data without manual data entry.
Titan provides a novel solution that leverages large language models (LLMs) to normalize unstructured referral data to FHIR, and gives practitioners and staff a button to synchronize data to their EHR (Cerner and others) via FHIR API. This saves manual work by staff and helps patients track the status of their referral. To lighten provider load, the Titan Intake app automatically synchronizes FHIR data to enable faster and more complete chart prepping.
In addition, as part of the intake process, Titan’s Natural Language Processing (NLP) engine detects and predicts the presence of Hierarchical Classification Codes and Elixhauser Comorbities to help both health systems and payors measure and receive reimbursement for the health of their patient populations. These are added to the FHIR Resources as CodableConcepts.
Enterprise Master Patient Index (EMPI) - As part of their EMPI implementation Titan checks and deduplicates patients, to prevent the fear of hospital IT - that an integration will introduce duplicates into their system and disturb their reporting and workflow.
Interoperability Service - From their web application, Titan triggers data synchronization into many downstream EHRs like Cerner, NextGen and others. This uses the Medplum integration engine a natively multi-tenant system that is very scalable and they serve many providers on the same technical stack.
Extracting data from documents/PDFs and structuring the data as FHIR is a very difficult technical problem. The team employs use of LLMs and modern artificial intelligence techniques to structure and tag the data with code systems.
Due to the nature of referrals, with a single patient being sent to many different institutions, duplicate Patient resources immediately become an issue. The team built a FHIR native Enterprise Master Patient Index and deduplication pipeline to support this use case.
Synchronizing to many downstream EHRs, like Cerner and Epic on an event driven basis is difficult because each EHR has slightly different conventions and requirements to accept data.
Darren Devitt, a respected FHIR expert, has recently released an alpha version of a new tool called Vanya. Similar to how Postman functions for API requests, Vanya is designed specifically for browsing data on FHIR servers.
I've taken some time to test Vanya with Medplum's FHIR server, and I want to share the setup process, some tricks I've found useful, and a brief overview of my experience.
You'll need to input the FHIR base URL, not just the server base URL. Remember to include the "fhir/R4" path. For example, when using the Medplum Staging server, I used the full URL "https://api.staging.medplum.com/fhir/R4".
Vanya requires authentication as an HTTP header. For my testing, I used a "Basic" auth header created using the client ID and client secret.
You can use a tool such as DebugBear to generate a Basic auth header from a client ID and client secret.
Or, if you prefer, you can use the OAuth2 client_credentials flow with the client ID and client secret to get an access token. See our guide on Client Credentials for step-by-step instructions.
Once you have a Basic auth token or a Bearer token, add it to the Vanya HTTP headers:
Vanya is still in its alpha stage, and there's a lot to look forward to as it continues to develop. However, even now, it offers a useful tool for browsing FHIR data. I'll be keeping an eye on the tool's progress, and I'll share any important updates here.
Give Vanya a try and let us know about your experience. If you have any questions or need help with the setup, please join our Discord!
Summer Health is an innovator in direct-to-patient pediatrics, with a focus on messaging and mobile access for parents via SMS. Their fast growing practice is available nationwide and is known for excellent patient engagement.
Custom EHR - The Summer Health custom EHR allows providers to respond to patient messages, enables task management and automation, and has AI-assisted encounter documentation.
Patient Portal - The patient experience includes the ability to reach pediatricians via messaging, and to view information across web and mobile devices.
FHIR API - with all data being natively stored as FHIR, enabling synchronization through a FHIR API to Google BigQuery allows robust analytics and visibility into operations.
The unique nature of the Summer Health offering necessitated custom software development, specifically:
Messaging-based workflows are convenient for users, but require aggregation, careful data extraction and synthesis to be actionable for providers.
Pediatrics requires complex access control patterns because patients are children and multiple caregivers are creating and accessing data on their behalf.
Timeliness and tasking are crucial and providers and staff respond in a timely manner to patient inquiries.
Mobile access with single sign on for clinicians who primarily administer care through mobile devices. This was a key pain point with other solutions.
Complete control over the user experience, reducing burden for the providers.
Identity management and access control allows caregivers to access records.
Unlimited and flexible integrations, and ability to build them as needed without restriction, including streamlined incorporation of cutting edge technologies like LLMs.
The team completed their initial build in 16 weeks.
EnSage, is an innovator in healthcare management, improves outcomes for elderly populations in value-based care (VBC) organizations. Their service automates the acquisition of patient data from multiple sources and performs data-driven risk-scoring on each patient. The risk scores then aid the care team in scheduling check ups for the highest risk patients first. It also facilitates sharing these risk profiles with their Primary Care Providers, enabling high fidelity care coordination across institutions.
In this project, EnSage utilized two Medplum solutions.
Custom EHR: A health record application specifically tailored for EnSage practitioners. This provides healthcare professionals with vital data at their fingertips.
Provider Portal and FHIR API: An application for referring physicians to access and contribute to the integrated care management, but ensures they only have access (via API or app) to patients under their care.
EnSage overcame significant technical challenges in this project, including the need to aggregate data from a wide array of sources such as claims data, CMS datasets, and more. Additionally, they required a bespoke workflow that incorporated case management across multiple organizations that necessitated sophisticated access controls.
Medplum stood out due to its out-of-the-box auth service that supports cross-organization access. Its ability to build high-fidelity custom integrations quickly also proved invaluable in overcoming the challenges of collecting and synchronizing data from multiple sources.
The FHIR data model also proved valuable, as a well documented data model supported by EHRs aligned stakeholders quickly.
These factors allowed EnSage to focus on what was most important: their risk scoring algorithms and the clinician experience.
EnSage leveraged a suite of Medplum features to create a comprehensive and efficient solution:
Authorization: by leveraging Medplum sophisticated access control system, the EnSage team was able to expose the Medplum FHIR API directly to client applications and external partners, without the need to encapsulate it behind a gateway / proxy.
FHIR Datastore: All data is stored in FHIR format and is accessible via the FHIR API. This provides a standardized approach to storing and accessing health information.
Subscriptions: In this implementation, in response to questionnaires, subscriptions are triggered, setting off automated workflows like notifications, data synchronization and more.
Scheduling: Integration between Acuity and FHIR Schedule provided a robust solution for managing appointments and optimizing healthcare service delivery.
Charting: A system for documenting encounters, including details like CPT and diagnosis codes, was created. This facilitated a comprehensive and precise record-keeping process.
Open source: The development team used Typescript for the entire stack. The Medplum open source code, issue tracking and community features helped streamline development and speed learning.
Below is an architecture diagram showing how the different components fit together.
In conclusion, Medplum was instrumental in providing the tools and support needed to address the complex challenges faced by EnSage. The result is an efficient, patient-centered system that ensures proactive care for elderly populations in value-based care settings.
Ro, and their diagnostics arm Kit.com enable a sophisticated nationwide diagnostics service, that includes touch points across clinical teams, shipping and logistics, laboratory sites and customer success.
The workflow requires tight coordination and real-time synchronization between many systems and applications.
Codex Health enables health systems manage their patient populations with effective remote patient monitoring (RPM) programs for diabetes, cardiovascular diseases and more.
Their offering has a patient facing experience, a provider experience and EHR integrations with Epic, Cerner and others.
They read and write data from EHRs, and collect data from medical devices like CGM, scales and blood pressure monitors.
Historically, services like Codex would have had to connect to EHRs using some combination of system integrators or HL7 V2 over VPN connections which is painful, brittle and costly.
With the roll out of the Standardized API for Patient and Population Services (g)(10) by major EHR platforms like Epic and Cerner they are able to connect to multiple health systems via REST based FHIR APIs, without third party aggregators or VPN Connections.
(Above) The "old" way of connecting an application to an EHR
(Above) The new (g)(10) based way of connecting an application to an EHR
This standardized interface allows Codex to provide RPM programs with no setup cost.
The (g)(10) API is very powerful, as it has build in support for access controls using SMART-on-FHIR oAuth Scopes, enabling:
Provider Access - allowing Codex physicians and staff to access demographic data, diagnostic reports and notes for patients under their care.
Patient Access - patients can auth in the Codex application and read and write their own data to their record, without need for IT approval.
This scalable approach allows the Codex team to focus on their service, and not on integrations.
Codex uses Medplum as part of their software development cycle, because Medplum is an open source implementation of the (g)(10), and so from a developer perspective is the same as Epic, Cerner or others, but with robust tooling and configurable permissions. This streamlines the Codex's teams software development lifecycle and their testing across platforms and products.
This standardized interface driven approach allows them to deliver their two solutions:
Foresight - an analytics and case management web application for clinicians, that helps them view and manage their patients care
Allie - a patient facing application that runs on iOS and Android that allows patients to view their care plans and take action.
Below is a brief interview with the Codex engineering leadership Zane Silver and Yury Staravoitau, about their EHR integrations the transcript is edited for clarity.
Video - 7 mins 51 seconds
Background (Zane): Let me just give you quick refresher of what we're doing here at Codex.
So we're building a remote patient monitoring platform a software solution as well as professional service on top of that. So we sell directly to healthcare providers or DMEs durable medical equipment manufacturers. And they can use our platform to monitor patients remotely if any diseases we connect over Bluetooth.
We have native (iOS, Android) applications, connects over Bluetooth to various blood glucose meters scales, blood pressure monitors. We also do cloud connections for like Dexcom and Freestyle Libre and other CGM devices. A clinician, either at a hospital system or a doctor or technician, might use our platform to be able to monitor or they can out outsource that to us.
We have a licensed disease educators for heart failure, diabetes that we can monitor the patients for them as well. Our internal educators use the same product that we also sell as a platform to the healthcare providers. We integrate directly with EHR systems for those hospital systems, either being able to read or write results back.
So sometimes blood glucose meter results are required in the EHR system, so we do that. We use Medplum as a testing ground and staging ground to make sure that we can properly read and write as well as be able to pull new types of resources records from the healthcare provider themselves.
At this point, a dozen to, well, half a dozen different types of EHR systems: Meditech, Hilo, Epic, Cerner, and others.
We use a multi-tenant system. And so each multi-tenant itself will have its own set of EHRs that's integrated and they're totally isolated across tenants. We are testing connectivity and correctness and being able to pull in those records there.
EHR systems quickly either throttle or crash. So we, we pull in batches and we kind of basically do periodic syncs and then try to do writes in real time.
Question (Reshma): How does it work end to end?
Yury: A patient, selects Medplum as healthcare provider login using the account. And authentication that we put that in the background request EHR system to, to grab some data for this user and update our database, get the refresh token, and on a daily basis, we request some updates using this user by ID for example.
Zane: We integrate with EHR systems, right? Yeah. So we wanna be able to test against EHR systems. And because Medplum is an EHR system with also write access, we can test whether or not we can write records and be able to see that as well as manually write records outside of our application.
Make sure we were able to read those as well. You can't do that unless you're actually doing it on a real EHR system. And we can, but not all of our customers have partnerships where they actually allow us to be able to test on their production systems.
We're remote patient monitoring, so we get (FHIR) Observations (from the customer EHR).
The big part it's missing in terms of the spec is just callbacks and being able to get asynchronous updates.
So moving from an event based versus a pull based system. The pull based system is like much more scalable operationally for us. So we don't have any kind of third party dependencies.
I think for the most part they (providers) prefer it because there's fewer integration points. They turn on the endpoint and give us, our credentials and they're just ready to go. We don't have to, you know, do any back doors connecting directly to their databases or anything like that.
So observations came as from our applications that can be connected to via some devices or, for example, we have dramatic error device that I testing for my blood, blood glucose. Or it can be from EHR system.
I'm happy to talk or, you know, feel free to put us, you know, connect us to anyone you feel like I might be interested in and we're happy to also help out and share any of our learnings and thoughts too.
Question: Can you do a day in the life for me about when you're talking to the provider and you're engaging their IT to get this kind of access, what the process looks like?
Yeah, it's more of a, I would say like a long engaged relationship in terms of actually getting like the direct access to write and read from systems to system.
Obviously, with ONC and data blocking, we can connect with the provider on our own. We don't coordinate with them to do that in terms of just getting patient consent to read their (FHIR) resources. So that's easy if we do that on our own. And then it just takes a little bit of time and talk to the right stakeholders.
The healthcare provider side, find out who the IT team is, get the right people in there and make sure we go through their security reviews. At that point, basically there's, each of the major healthcare providers have their own app portal. So we create an app portal on there. We usually end up giving the healthcare provider what our app ID is, whether it's, you know, app Orchard on Epic.
Cerner has their own developer portal too. Give that to them and then basically they download the app into their system. I don't have any visibility into what that looks like. There says admins do that. And it's usually like a, it takes about 24 hours for that to happen for them to pull it in and then we get their endpoint and it just seems to work for us on that side.
Reshma: So you download their app, but like they're not using the traditional SMART-on-FHIR kind of app machinery. It's more that. You're now eligible to get the credentials that you need to connect server to server?
Zane: That is true. Yeah. We, we can use it in terms of if SMART-on-FHIR to be able to do our launch and they do have to have, you know, download the app there.
But the (Codex) app type is different. So instead of it's a clinician facing app, which is system facing app. So they, the app store kind of on their part, they (provider) have the dropdown that they choose how they want to install it, and it gets installed in their system.
Seems, seems great and it's a lot more scalable in terms of how you can write your application once.
And you don't have to have a custom footprint or like dedicated boxes or instances for each provider.
Our integration costs are very low, so we don't really even, we don't charge in a new integration or onboarding fees or anything like that for a new customer.
Question (Reshma): Are you continuing to roll it out or working on more of the depth scenarios within systems?
I think it's more of just getting more breadth with more provider systems on there. You know, even just this morning we tested Hilo and Meditech, which are two different EHR systems and just getting verified all those seems to work out of the box quite well, which is nice.
Question (Reshma): So anyone with a (g)(10) right? A (g)(10) FHIR implementation?
Zane: Yep.
Reshma: Awesome. It's a great story. It's a great, great story and all the FHIR enthusiasts would be excited.
Medplum Client Typescript SDK can be used to connect to the EHR in multiple modes, such as Patient access, oAuth and Basic Auth.
For example use the MedplumClient to connect to another FHIR server from a Bot or other application that has the Medplum client as follows (client credentials).
// External EHR Url and credentials const externalEhrBaseUrl ='https://ehr.externalprovider.org/FHIRProxy/api/FHIR/DSTU2/'; const externalClientId ='<client_id>'; const externalClientSecret ='<client_secret>'; // Construct client ant authenticate const externalEhrClient =newMedplumClient({ baseUrl: externalEhrBaseUrl, }); await externalEhrClient.startLogin(externalClientId, externalClientSecret); // Work with the client as needed, for example search await externalEhrClient.searchResources('Patient?identifier:contains=999-47-5984');
