4 posts tagged with "self-host"

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