8 posts tagged with "case-study"

Chamber Cardio, a technology-enabled cardiology solution, helps enable and empower cardiologists and practices in their transition to value-based care. With our cloud-based technology platform, we offer a suite of tools designed specifically for cardiovascular care. These tools provide real-time insights, analytics and care coordination tools focused on improving outcomes for patients with chronic cardiovascular conditions.

Chamber’s products serve as a compliment to a cardiology practice’s existing Electronic Health Records (EHR) and Practice Management Systems offering many powerful features, such as quality measure and care gap assessment, customizable population-level patient dashboards and hospital encounter notifications, clinical pathway workflows (including guideline-directed medication support), automated risk assessments and care team collaboration through secure messaging and task management.

To reduce engineering lift and accelerate development, the clinical and operational front-end for internal care team management was built using the Retool Enterprise Platform self-hosted in Chamber’s AWS cloud environment integrated directly with Medplum for the backend data storage and web services layer.

Problem​

In the early stages of product development, the Chamber team, with limited time and technical resources, sought out creative solutions to help accelerate product delivery without sacrificing the quality or capabilities in scope for our MVP milestones. We initially prioritized the development of our core data integration pipeline (including EHR, ADT feeds, claims, etc.) and a foundation for internal tooling to properly support clinical and operational workflows.

The complexity of internal care coordination and practice management requirements, including integrated clinical guidelines, medication titration support, disease-specific risk assessments, and quality measure reporting, elevated the challenge. We also had to manage and normalize diverse datasets and terminology standards. As a seed-funded startup with just two software engineers, finding the right mix of custom-built and off-the-shelf solutions was critical to building a strong, secure foundation for the product, capable of supporting future growth.

Solution​

Chamber decided to tackle the challenge of managing key data workflows and operational tooling by leveraging Retool as the backbone for our internal platform. Retool's platform, known for its comprehensive frontend components and ease of data integration, enabled Chamber's team to effortlessly link our FHIR datastore, supported by Medplum, with clinical and scheduling information. This approach allowed for a development of a wide range of care management and operational applications with minimal custom development.

The Retool client, deployed in AWS, connects to Medplum directly, using both API protocols (REST and GraphQL). This configuration provided a flexible and robust environment for Chamber’s internal requirements, and, given the compliance offering (SOC 2, HIPAA, ONC, etc) from Medplum built into the platform, our team could devote more resources to developing a reliable data pipeline and a high-quality user experience for our external clinician-facing products, ensuring the foundation was set for future scale and complexity.

Challenges Faced​

Several challenges emerged during the early development process:

• Normalizing Clinical Terminologies: One of the first obstacles was creating a system to accurately map and normalize clinical terminologies from various data sources into Chamber’s FHIR datastore. The solution was a blend of API integrations for standard coding systems, utilization of public crosswalk datasets, and leveraging Medplum for critical terminology metadata and mapping logic. This multilayered approach ensured a seamless, standardized coding solution.
• Generating Realistic Synthetic Patient Data: To refine complex workflows, Chamber turned to Synthea™, generating synthetic patient data that mimics real-world medical histories (e.g. hospital encounters, office visits, prescriptions, lab values, etc). This synthetic data allowed our team to simulate scenarios specific to chronic cardiovascular diseases, refining the system’s use of FHIR resources and Medplum integration. The insights gained were pivotal in developing analytics dashboards, risk assessment algorithms, and medication management features.
• Concept Mapping and Categorization: Effective query support and decision-making required a sophisticated grouping and categorization of clinical concepts. By integrating with leading coding system APIs and the NLM VSAC repository through Retool, Chamber was able to categorize and code clinical concepts efficiently, laying the groundwork for robust data queries and decision support tools.
• Maximizing Retool Built-in Capabilities: While Retool provided a strong foundation for data integration, Chamber encountered limitations with more complex and nuanced FHIR data use cases. To overcome these, the team incorporated FHIR-based libraries as global functions using BonFHIR, enhancing Retool’s capabilities while adhering to healthcare standards.

Medplum Features​

Medplum, offered several key features that were useful in the development of the Chamber Cardio platform:

• Authentication: Ensuring secure access and access controls for data and system functionality that works well with Retool.
• Subscriptions: Used to automate critical updates when changes are made to FHIR resources, helping to maintain quality and contingency across all data elements.
• API and SDK: Offering robust application programming interfaces and software development kit for seamless integration.
• Compliance: Meeting healthcare regulations and standards, an essential aspect of any medical software solution.

Retool Features​

Chamber took advantage of a wide array of Retool’s platform capabilities for both prototyping and developing solutions for internal tools and care coordination workflows:

• Component Library: comprehensive set of highly customizable, scalable and responsive frontend components
• Data Source Integration: REST and GraphQL APIs, AWS Lambda, S3 Resources
• Javascript Transformers: reusable functions and local data storage used to manipulate data returned from queries and access anywhere in the app
• Event handling: triggering queries and components on successful and failing query responses and manual data refresh control
• Environments & Version Control: Ease of configuration for multi-environment deployment with dedicated data sources and version-based release support
• Self-Hosted Deployment: To maintain healthcare compliance, Chamber’s Retool instance is deployed fully within our AWS cloud infrastructure

Conclusion​

Chamber Cardio’s initiative underscores the effectiveness of combining cutting-edge technologies—Retool’s frontend versatility, Medplum’s backend strength, and BonFHIR’s supplementary libraries and tooling —to craft a cardiology care platform that stands out for its comprehensive data integration and workflow management offering. This collaboration resulted in a product and technology foundation for enhanced care coordination, streamlined decision-making processes, and a supportive pathway for cardiology practices transitioning to value-based care and exemplifies how strategic tool selection and technology partners can enable meaningful advancements in healthcare innovation and delivery.

References​

• Chamber Cardio Blog Post on Modernizing Cardiology Care

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.

Today, we are showcasing the Rad AI Omni Reporting platform, with FHIRcast support through Medplum’s open source FHIRcast hub.

How does it work?​

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.

Why open source?​

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.

Why FHIR?​

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 interactive reporting enabled by FHIRcast​

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.

John Paulett Director of Engineering, Rad AI

About Rad AI​

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.

Related Reading​

• IRA Specification
• Omni Reporting Press Release
• Medplum FHIRcast

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.

(5 minute demo)

Problem​

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.

Solution​

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.

Medplum Solutions Used​

• 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.

Here is the full list of Medplum Solutions.

Challenges Faced​

• 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.

Medplum Features Used​

• Bots and Automation - to enable the event driven connections between applications and EHRs
• FHIR Datastore - to store the data and manage the identities and deduplication
• Self Hosting - super admin features, and the ability to to manage tenants enables multi-institution access and connections

Related Reading​

• EMPI Implementation video
• Patient Deduplication Architectures
• Deduplication reference implementation code
• Case Study: Codex and the Power of the (g)(10)
• CodableConcepts in FHIR

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.

Setting Up Vanya with Medplum's FHIR Server​

If you've decided to give Vanya a try, here's what you need to know to get it running with Medplum's FHIR server:

FHIR Base URL​

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".

Authentication​

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:

Using Vanya​

Once you've set up these parameters, you can start using Vanya to browse through different types of FHIR data on the Medplum server.

Wrapping Up​

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!

(2 minute demo)

Introduction​

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.

Medplum Solutions Used​

• 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.

Challenges Faced​

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.

Why Medplum?​

Medplum stood out for the following reasons:

• 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.

Features Used​

The following Medplum features were used to build this product.

• Integrations - notably Medplum's integration framework and tools made it easy to integrate BigQuery and LLMs.
• Google Authentication and External authentication - Summer Health uses multiple identity providers for practitioners and patients respectively.
• Access policies - Patients are children, so parametrized access policies support parent and caregiver access.
• Subscriptions - integrations to data warehousing and other applications are powered by event driven notifications
• FHIR Datastore, specifically family relationships and GraphQL allow for medical records that incorporate sibling and family member context
• Charting and Task Management - encounter documentation and tasks are featured in the application and major drivers of the workflow.
• Bulk FHIR API to support reporting and interoperability with other systems.

Related Resources​

• Summer Health Website
• Analyze FHIR in Bigquery
• Open AI Blog features Summer Health
• Real Gen AI Use Cases in Healthcare talk by Matthew Woo on YouTube.

(2 minute demo)

Introduction​

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.

Medplum Solutions Used​

In this project, EnSage utilized two Medplum solutions.

1. Custom EHR: A health record application specifically tailored for EnSage practitioners. This provides healthcare professionals with vital data at their fingertips.
2. 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.

Challenges Faced​

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.

They completed their initial build in 16 weeks.

Why Medplum?​

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.

Features Used​

EnSage leveraged a suite of Medplum features to create a comprehensive and efficient solution:

1. 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.
2. Authentication: Multiple authentication providers were utilized, with the EnSage team using Google Authentication, while referring physician identities were managed in an Auth0 tenant.
3. 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.
4. Subscriptions: In this implementation, in response to questionnaires, subscriptions are triggered, setting off automated workflows like notifications, data synchronization and more.
5. Scheduling: Integration between Acuity and FHIR Schedule provided a robust solution for managing appointments and optimizing healthcare service delivery.
6. Charting: A system for documenting encounters, including details like CPT and diagnosis codes, was created. This facilitated a comprehensive and precise record-keeping process.
7. Billing and Revenue Cycle: An automated integration with Candid Health enabled Medicare (CMS) billing for providers on the platform.
8. 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.

Click to enlarge

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.

Related Resources​

• Implementation partner: AlleyCorp Nord
• Tech leads: Julien Blin, Florencia Herra Vega
• BonFHIR Toolkit is featured in this application
• Download Case Study as PDF

Introduction​

Ro, is an innovator in direct-to-patient healthcare services, provides patient centric healthcare services nationwide.

Medplum Solutions Used​

1. Lab Network - sending lab orders and receiving diagnostic reports across lab sites
2. Provider Portal and FHIR API - allow data access with controls, to practitioners and applications

Challenges Faced​

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.

Related Materials​

• How It Works from the patient perspective
• Press Release

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.

Challenging the Status Quo​

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.

Using Medplum​

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.

Interview with Codex Engineering​

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.

How It Works​

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 = new MedplumClient({
  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');

Related Resources​

• Medplum SDK Constructor
• Medplum SDK startLogin