7 posts tagged with "self-host"

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

Claims data is a uniquely rich source of financial and clinical data important to many healthcare workflows. The EDI 837 Health Care Claim transaction is one of the oldest forms of electronic data exchange, stemming from being defined as a required data transmission specification by HIPAA.

Today, we are showcasing Flexpa which connects applications to claims data via direct patient consent and a modern FHIR API powered by Medplum.

How does it work?​

Flexpa aggregates and standardizes Patient Access APIs created by payers as required by CMS-9115-F. First, patients authenticate and consent to a data-sharing request from an application.

Then, Flexpa extracts, transforms, and loads payer responses into a normalized FHIR dataset. Flexpa stores data in a temporary FHIR server cache during the period for which a patient has granted access.

Finally, applications receive a patient-specific authorization response which can be used to retrieve data from a FHIR API provided by Flexpa – powered by Medplum.

What problems does Flexpa solve?​

Payer FHIR servers offer an extremely variable API experience and implementing against 200+ of them is painful. Using Medplum as a data cache for their own FHIR API allows for a uniform developer experience on top of the underlying network access. Flexpa allows developers to use claims data to deliver risk factor adjustment scoring to value-based care providers, help patients navigate care, join clinical trials, negotiate bills, and more.

How does Flexpa use Medplum?​

Flexpa takes advantage of several important features of Medplum’s FHIR implementation:

• Self-hosting
• Multi-tenant through Projects
• Update as Create
• Client assigned IDs
• Batch transactions
• Medplum App
• FHIR Operations such as $validate, $everything and $expunge

Medplum’s open source implementation provides Flexpa with the ability to contribute back to the project when improvements or changes are required. Additionally, Medplum’s technology choices and stack align perfectly with Flexpa’s making working with Medplum easy for Flexpa’s development team.

Related Resources​

• Flexpa website
• Flexpa Blog
• CMS FHIR compliance documentation

Develo has built a full-featured EHR and customer relationship management (CRM) for pediatrics, encompassing core scheduling, clinical, and billing workflows along with family engagement capabilities.

(5 minute demo)

Outpatient pediatrics is uniquely family-centered, longitudinal care-driven, and high volume, with distinct well child check-ups and payor mix that is different from other specialties. Accordingly, the Develo product is beautifully designed with much attention to the nuances that matter to their core independent pediatric practices market.

(A beautiful pediatric growth chart)

Develo has built a full stack solution with key innovations around automating family engagement, reducing administrative tasks, and AI-assisted documentation.

(Intuitive patient intake)

They rapidly release new capabilities and take a comprehensive, end-to-end approach to build a full operating system for pediatrics, rather than just optimizing a narrow set of provider workflows.

(Scheduling orders)

Develo EHR is FHIR native and built on Medplum using the following features:

• Self-hosting: Develo hosts Medplum in their own AWS.
• Multi-tenant: Develo customers have separate datastores using Medplum projects.

This application is an example of a software company, using Medplum to build a custom EHR that delights pediatricians, patients, and families alike. Some screen shots of the applications are shown below.

(Even the billing experience shows attention to detail)

NASA's TRISH team (Translational Research Institute for Space Health) recently issued an RFP for a healthcare tech platform designed for monitoring spaceflight participant health metrics during space missions. TRISH is a virtual consortium focused on applied research to ensure astronaut health during space exploration.

As avid space enthusiasts, and NASA Space Camp alumni, we were eager to apply.

Medplum submitted a proposal. We were invited to present to the TRISH team in June!

We're now anxiously awaiting the results.

Adapting to Space Challenges​

A notable challenge in the RFP was the solution's ability to operate in a low power environment. To address this:

Medplum on Raspberry Pi​

We successfully set up the entire Medplum tech stack on a Raspberry Pi 4 (8gb edition). Due to Medplum's open source nature and its reliance only on widely-used open source dependencies, this transition was quite smooth. For those curious, here's the Raspberry Pi 4 model we used.

Raspberry Pi OS Selection​

A necessary adjustment was using the 64-bit edition of the Raspberry Pi OS because 32-bit Postgres isn’t widely supported or available as a Debian package. Following that, the Medplum installation mirrored the process on any other Linux server, as detailed in our Ubuntu installation guide.

Monitoring Power Consumption​

With everything up and running, it became pertinent to gauge the power consumption. Using the SURAIELEC Watt Meter, we observed that when Medplum operates idly, the power consumption hovers around 1-1.5 watts.

UI Development​

Once power constraints were addressed, we used the Medplum React components to assemble a mock dashboard showcasing health metrics of Artemis mission astronauts, monitoring vital signs and other crucial health parameters. We also included the spacecraft's intrinsic metrics, such as cabin temperature, pressure, oxygen levels, CO2 concentrations, and radiation readings.

Conclusion​

This exercise provided a practical demonstration of Medplum’s adaptability and versatility, underscored by the strength of open source tools. We believe the exercise emphasizes Medplum's flexibility and readiness for diverse challenges.

Today, we received a thoughtful email from an engineering leader who installed Medplum for the first time:

Cody,

Medplum looks like really cool and I'd like to play with for a digital health company I am helping out.

When I tried to install it I got the following problems:

npm WARN deprecated trim@0.0.1: Use String.prototype.trim() instead
npm WARN deprecated stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
npm WARN deprecated sourcemap-codec@1.4.8: Please use @jridgewell/sourcemap-codec instead
npm WARN deprecated @npmcli/move-file@2.0.1: This functionality has been moved to @npmcli/fs
npm WARN deprecated rollup-plugin-terser@7.0.2: This package has been deprecated and is no longer maintained. Please use @rollup/plugin-terser

added 3083 packages, and audited 3134 packages in 1m

410 packages are looking for funding
run `npm fund` for details

22 vulnerabilities (9 moderate, 13 high)

To address issues that do not require attention, run:
npm audit fix

Some issues need review, and may require choosing
a different dependency.

Run `npm audit` for details.

Have you updated any of these? Please let me know what to do.

Our Response​

This is a great question!

By engineering policy, we upgrade dependencies at minimum once per month. In practice, we upgrade dependencies roughly once per week. We are strong believers in staying current, and providing Medplum developers the best version of all tools.

Our last dependencies upgrade was just yesterday, where we upgraded all direct dependencies to latest stable/release versions: https://github.com/medplum/medplum/pull/1789

The dependencies listed in your email are transitive / indirect dependencies. You can use the "npm list" command to see the dependency tree for any given package.

• trim and stable are installed indirectly for Docusaurus (by Meta)
• sourcemap-codec and rollup-plugin-terser are installed indirectly for Workbox (by Google)
• @npmcli/move-file is installed indirectly for npm-check-updates (ironically, the tool that we use to upgrade dependencies)

The dependency warnings, and the output of npm audit in general, is sadly quite flawed. People much smarter than me have written at length about this. For example, I recommend this essay by Dan Abramov, lead engineer on React at Meta, titled npm audit: Broken by Design.

We continue to take dependency management very seriously, and use automation where possible:

• GitHub Dependabot integration is enabled with continuous monitoring and alerts to the Medplum engineering team
• CodeQL scans every PR
• SonarCloud scans every PR
• Snyk scans every Docker image

I'd be happy to discuss further if you have any questions, or if you have any suggestions on how we can do better. Join our Discord!

This guide is for customers who are self-hosting Medplum, and this post assumes that your installation was complete and successful. We will refer to your base installation as $domainName, and this refers to the domain on which the Medplum app is running, for example on hosted Medplum the domain is app.medplum.com.

Now that the initial installation is complete, it's essential to verify that your environment is functioning correctly. In this article, we'll walk you through the necessary steps to ensure your Medplum installation is working.

The initial user created after you set up your account is referred to in this article as a super admin.

Change Default Password​

The first step after installation is to change the default password for your super admin account. Using the default password poses a security risk, as it's easily accessible to unauthorized users. To change the default password, log in to your instance of the Medplum App using the default credentials provided and navigate to the "Security" settings on the left sidebar ($domainName/security will be the URL). Update your password with a strong, unique combination of letters, numbers, and special characters.

Note your password and logout by clicking on the Sign Out item on the top right menu.

Create a Medplum Project​

A Medplum Project serves as a container for your FHIR resources.

To create a new project, follow these steps:

• Navigate to the "Register" page in your Medplum app at $domainName/register.
• Fill out your name and email and create a password.
• Click the "Create account" button.
• Provide a name and description for your project.
• Click "Save" to create the project.

You will create a new (blank) Medplum project and be logged in.

Invite a New User to the Project​

Now that you are logged into your new project. Inviting a new user to your project is a great way to confirm that your email notifications are set up and install is working. To send an invitation:

• Click on the Admin -> Project item on your left navigation panel or visit $domainName/admin/project.
• Go to the "Users" tab within the project.
• Click the "Invite new user" link.
• Enter the user's email address, name and (optional) Access Policy. e. Click "Invite."

The new user should receive an email invitation to join the project. This process confirms that your system emails are functioning correctly.

You can see a visual on these steps here.

Create a FHIR Patient Resource​

To test the core functionality of your Medplum installation, create a FHIR Patient resource within your project:

• Navigate to the "Patient Resources" page in your project on the left nav bar or by going to $domainName/Patient.
• Click "New" on top, or navigate to $domainName/Patient/new.
• Fill in the required fields for the patient.
• Click "Save" to create the FHIR Patient resource.

Create, Deploy, and Execute a Medplum Bot​

"features": [
  "bots"
]

To confirm that AWS Lambda is correctly configured, create, deploy, and execute a Medplum Bot:

• Go to the "Bots" tab in your project in the Admin -> Project section or navigate to this url $domainName/admin/bots.
• Click "Create new bot" and provide the necessary details.
• Click "Create Bot" to create the bot.
• Navigate to the Bot on the $domainName/Bot page, click on the editor and save the boiler plate code.
• Deploy the bot by clicking "Deploy" in the editor window.
• Once the bot is deployed, click "Execute" to run it.

If the bot executes successfully, AWS Lambda is correctly configured in your environment.

Check Log Files​

Inspecting log files is crucial for identifying any errors or issues in your Medplum installation. Locate the log files in AWS Cloudwatch and confirm that you see AuditEvent resources appearing in the logs.

After following these steps, you can be confident that your Medplum environment is up and running. Remember to periodically check for updates and patches to ensure your system remains secure and efficient.

Data privacy, locality, governance and compliance are huge issues in healthcare, and that's why we at Medplum support self-hosting. For those running on AWS, we use Aurora RDS, which supports auto-scaling. A common question we get is - how big is my database going to be?

Say for example, you have 1M active patients annually - how does that translate to database size?

Unfortunately, there is no straightforward answer to that question, but the right way to think about it is to make a FHIR resource count estimate, per patient, annually. Applications with a lot of messaging and observation data are generally more resource intensive, while those that have visit notes and prescriptions are generally less resource intensive.

Here's an example of a resource projection.

Average History Length (column 5) refers to the number of times the resource is edited, as changes are tracked, historical data will increase storage size.

To calculate the total storage, we use an "overhead factor" (representing metadata, indexes, etc) of 10%. The following formula shows how to estimate column 6 - Total Storage

totalStorage = resourceCount * patientTotal * avgSize * avgHistoryLength / (1024 * 1024) * (1 + overheadFactor)

In this example, summing the Total Storage column, you get an estimated total of 308.4 GB of data per year.

Hopefully, this lightweight exercise can help you and your organization get a sense of your database needs today and over time.

Related Resources​

• AWS Aurora Pricing
• AWS Aurora Instance Class Summary
• Medplum Self-hosting guide
• Self-hosting change log on Github