MITRE Open Health Solutions is a leader in healthcare open source and are the makers of Inferno, Synthea and more - which are tools we use all the time here.

Medplum gave a talk at MITRE last fall, that was recently released, and this post contains an annotated transcript and clips, as well as some updates as the talk was last fall, shortly after Medplum's public launch. Transcript has been lightly edited for clarity.

Medplum Intro and Team Story​

5 minutes

Intro by Mick O'Hanlon

Welcome to today's OHS Tech Talk. Today we are very lucky to be joined by Reshma Khilnani, who will be giving a talk titled Medplum FHIR Native Web Apps. Reshma is the CEO at Medplum, which is an open source toolkit for building FHIR native web apps. Reshma has an experience as a Visiting Partner at Y Combinator and as a two-time founder in healthcare. She is also an alumna at Meta, Microsoft, Box and BS and MEng course six at MIT. Reshma will cover the opportunity and challenges in developing apps that use FHIR as their data model. She'll also discuss Medplum business model and how they hope to make a living off of open source.

Today's material will include demos and Medplum getting started tutorial.

Reshma Khilnani

So what is Medplum? Medplum is a open source toolkit to build FHIR native web applications. At the highest level, that's what it is. Before we dive two into the details with a little story about our founding team.

So these are our founders. We myself, Cody, and Rahul, notably you'll notice we have a crossover career. I myself have done venture capital, I was early-ish on the team at Facebook. Cody has a career from Microsoft and he was at One Medical as well on the provider side and, Rahul at Palantir and Applied Intuition, these are enterprise and very machine learning centric organizations and so we're bringing that experience with us to this.

And I'm going to run through the following agenda.

1. First of all, I'll tell a little bit about our story.
2. Second pain points from our history of building medical applications.
3. I'll go through Medplum's approach and how we're thinking about solving the problems that we have experienced in our career.
4. I'll talk about open source and why we decided to make a commercial open source company and how we think about the opportunity on that front.
5. Then I'll do some, some demos and we can do Q&A.

Like I mentioned with regards to our team, you know, our endeavor in building Medplum is informed by our experience. First of all, in big tech. Microsoft and Meta (Facebook) and getting a sense of professional software engineering in that environment and that type of infrastructure and quality control. Also, the way web applications are developed at that scale was really informed by our careers in big tech.

This same team built another startup. It was called MedXT, which was a RIS/PACS that was our first endeavor. That was a long time ago. That company was founded in 2012 and was acquired by Box. And then we've also had the opportunity, I myself have worked with a lot of startups. In a time working in venture capital and over the course of my career, and had a chance to work with entrepreneurs who are building applications for the first time, many in healthcare.

We have some experiences in enterprise as MedXT was acquired by Box and we worked with large enterprise customers to implement their healthcare and life sciences workflows. And Cody was a senior director of engineering at One Medical, which is a primary care company that was acquired by Amazon and has a lot of they were real leaders in providing this primary care experience that's accessible and friendly. There were a lot of learnings from building the infrastructure for that company. I was a Visiting Group Partner at Y Combinator, and notable in there I had opportunity to work with a lot of commercial open source companies and learn a lot about why they make sense and how they can help in delivering software in a new way by helping people develop their applications. So that's where we're coming from.

Our experience is also informed by building many applications that are in the healthcare context, I'll include a LIS/LIMS, RIS/PACS, custom EHRs, patient portals, all as examples of medical applications.

Healthcare Developer Pain Points​

5 minutes

We experience the following pain points. I think there first we'll call it the terrible choice, so I'll go into this in a bit of detail, but basically while developing your application, you have to make some trade-offs and it's, it's possible to leave with the impression that, you know, you don't have any good choices.

So integrations and workflow in healthcare are very difficult, harder, I believe, than other sectors like FinTech to build and maintain. So this is a common problem. And the regulated environment is part of it. The vendor mix is part of it, but in general, this is just an extremely challenging aspect of developing healthcare.

Third. And I'm very interested to hear from this team in particular on this front is poor data quality is rampant. Duplication issues, you can't compare records that exist in different institutions. There's lots of subtle issues with the data that make it hard to trust and if you're writing an application and you want it to have good quality data, for example, to report HEDIS or something like that, this is often an enormous lift for developers.

So this is a, it's a big problem. And fourth, which I think is related to the first three, is that talent is very scarce. If, you know, it's tempting to think of software engineers as a monolith and there's a labor pool. But really healthcare has its own domain specific nature, and the intersection of those who are software engineers and who are trained in the specifics of the domain is rare.

And in order to build an application, you often have a lot of people who are not trained in healthcare I'm often find myself in the position of telling them to please just use FHIR instead of, create a new patient table create table, patient, patient ID equals X, you know this is a common pattern.

And then the nature of the workforce. Having so many people who are working in the domain who do not have healthcare experience just has a shape to it that's challenging to work with. So those, those are the high level on the pain points. So first let me talk about the terrible choice.

Basically consider, say you're company like One Medical, you're a provider. You have a terrible choice. You can build a great tailored experience, but roll all of your own infrastructure or you can use off the shelf products and fight with experience. So this is a common choice that people have to make and it's easy to be frustrated with this choice.

If you want your great tailored experience, think about how much work you have to do to build up your certifications, interop and workflows. But if you use the off the shelf product, it's very rigid, so you're stuffing data where it's not meant to be, or you're doing unnatural things to get your system to behave the way you want.

This is a common experience that people have been having with developing these apps for years. And what's notable to me is that other domains have made more, let, for example, FinTech or insurance technology have a better story in this regard than I've seen in healthcare. And that is part of the opportunity that they don't have in those other domains the same terrible choice in the same way that we see in healthcare.

Healthcare is harder. Developer productivity and velocity is slower. And sometimes talented engineers choose to work in other sectors. So this is a, this is a pain point and things that we thought about hard when we decided to start Medplum.

So that leads me to the next part, which is our approach, how we've thought about at least chipping away at some of these problems. And I mean, the problems are very hard. I will never want to give people the impression that they will be overcome instantly. But, Medplum is a first step towards addressing some of these problems that we see day to day.

System Overview​

3 minutes

And the approach is simple. The API is the product. Tery headless product that is interop-ready and features that are designed to be programmed.

Here's an overview of the system: the core Medplum application, then this is an open source application, is right here in purple and this is a source code that you can get on. Internet. It has a data store, FHIR data store, and a FHIR Rest API. And so that's a big part of it.

We've invested heavily in the TypeScript SDK. And most of our customers and people who are developing on the platform, they're really here. They're writing a white label application on a custom domain, so it's like my healthcareapp.com, and they're embedding our SDK. Now, what's notable about this developer paradigm is that.

Right here, this gray box that's running their website is a static JavaScript file. This has no backend and it's meant to be very easy for back to our, the discussion on the labor and labor shortage for somebody who is you know, has a light education in healthcare or they're from a different domain, but they know how to develop apps to help them get productive very quickly.

And they don't have to think about the complexities of the data model, and the auth and all that stuff. They can just focus on the experience that they really care about that's important to them. Notably is that integrations are very important to any healthcare application.

And we think of, integrations are the product so that this is crucial. And we have our infrastructure here called bots. You can think of these as like lambdas, you know for example, if you create a new patient, You can invoke one of these lambdas to synchronize that data to a legacy EHR, either via FHIR, HL7.

We support a bunch of data types and we have a streamlined developer kit so that, again one of these developers who don't have a lot of history or training in the domain can be very productive very quickly using this technique. So, and these, we provide the environment, which in which to develop these, and then all the tooling so that you can run them.

So there's really no DevOps from the perspective of the developer. They're just writing their code and hooking it up. And this is a big productivity win. And people bring their own code here. We have some partners who have written their own integrations and we also provide some built-in integrations.

So that's part of the customer experience. We also have access policies and identity, literacy in general on FHIR and SMART-on-FHIR is growing, and we're part of the message there helping people understand how to use these tools and the scopes and the auth part of what we provide as well.

And we just have a built-in implementation as well as allowing people to bring their own auth if that's what they want as a developer. And then subscriptions, you can think of these as webhooks, you know allow event driven applications to be built, and I'll show some examples of those in the demo.

Traditional Healthcare Applications​

1 minute

So this is, this is the Medplum overview. And I'll just like compare and contrast that with traditional software healthcare software, which is like a full stack SaaS application that exposes some interfaces. In this model, it's hard to program a system like this. The developer experiences is poor.

Systems that we've built like this tend to be brittle and slow, and introp is an afterthought. So we, want to think about how to do this a bit differently from the traditional way. We believe that, assume we are, go back to this view. Like all of the applications, like a LIS/LIMS or a custom EHR or patient facing apps, EDC can all be built in this simplified way.

And it could be an effective developer model to get more productivity, leverage, better interop, and just reduce the investment overall and have better tooling and story. So that's kind of the thinking. So I'll summarize it here. So our approach, you know, interoperability is the product not an afterthought.

So the, I'll emphasize that. It's very common to have a SaaS app with an API software as a service, by the way, app with an API to support interop. That generally is not the same as having a headless and dev tools centric focus, and we really live that difference. The programability of the system is what we focus on and You'll notice that our ui, they, they look very bare bones because we're really focused on the programability.

Developer Experience and Open Source​

4 minutes

And we hope for a lot of attention to detail on the developer experience. We consider testing and test-driven development, CI/CD and documentation as products. And there are things that we deliver and part of our offering and of course our open source. Open source has a lot of interesting characteristics that are unexpected.

I'll put an example here. We see people, our customers searching our repo all the time. How do I search for resources? Oh, here's an example. And they're just searching in the code for examples for how to implement their own applications and workflow. And it's, a way to help people do a complex implementation without having to build the full stack SaaS app and then hand it to them.

So that's, that's the thinking. And we didn't, we didn't make this up like GitLab, Hashicorp, Vercel, Supabase. These are examples of companies who are doing this in other domains. So GitLab does DevOps and Hashicorp also is on, on the infrastructure side, infrastructure as code. And they're, really focusing on the developer as being their advocate and their own audience that they're trying to reach.

So I'll talk a bit about open source and how we think about it. So why open source? That's question. We believe we know that open source enables developer productivity and velocity.

If you are composing complicated systems to implement an application that's very functional, that has to do a lot of things and support lots of features enable to do that effectively. Open source is just a great tool. It's a way for an individual contributor to make a lot of progress without being gummed up with a lot of meetings and compliance and access issues. It's way for devs to also learn about how to do an implementation and a way to build trust.

So once, assuming a developer is our audience and people who we think about as users of the product, we want them to trust it. We want them to think about how to solve their problems, using us as a reference. So that's the thinking. And again, we didn't, make this up, GitLab, Hashicorp, Vercel, Supabase. They, really have a lot of mindshare on this, in other domains.

We are early in our open source life, so I'm really excited for the chance to meet you all and to have your, your thoughts and feedback and engagement as part of this community. But we, you know, we publicly launched in September around 190 GitHub stars, if that's a metric that people care about. We're, just getting started 13 contributors and around 80 in in our discord, and we just released our v1. So we're like you know, in the stage of having, we do have some definitely implementations on the platform and are working to move past the early adopters in this coming year and have some more established players.

Updated stats as of April 14, 2023 - 622 Github Stars, 25 Contributors, 261 in Discord

Business Model​

1 minute

So, That's where we are so far and our business model. So we're really focused on hosting and we have our hosted product app.medplum.com where you can sign up, start building your application, and it provides that backend that you know is fully working and easy to. And if you're a developer who wants to get started quickly, then it's a great option.

Then, you know, usually what we think of how we think about deployments is that you kind of decouple them into two parts. So one is the developers, Who want to build the app and they, build their applications the mostly front end applications or integrations. And then once they've made a significant amount of progress, the organization that they're a part of can make a decision.

Do we wanna go self-hosted and, install in our own environment or do we want to use the cloud offering? So we have invested in, SOC II Type 2 certification, HIPAA compliance, and ONC certification. So we're going to really show our work on the compliance side as a way to have people think about using the hosted option.

And again, this is a model that is, is modeled after GitLab and their very successful at doing this in the DevOps world.

Demos​

10 minutes

So first of all, I'm gonna demo the following things.

1. So first the admin console for developers
2. Next, a sample patient portal
3. A sample custom EHR
4. I'll show our storybook, which is our react components
5. Demo of our documentation because as I mentioned documentation is a big part of the product.

I think as a developer developing in this space, the number of times I had to contact someone to even get a copy of the docs makes me irritated. So first of all, admin console. So this is our admin console. You can see here it's app.medplum.com, and this is a, developer-centric view of your FHIR data.

We have a list of the resources here on the side and you can just browse your resources. As I'm talking to the folks who work on Synthea, this is largely Synthea Data and. You can add your fields to your list can filter.

And the reason this is potentially interesting is that people are using this in the following way. They are actually learning how to program FHIR This. They go to their work list and they look at their dev tools here and let's see, fetch, they're like copy as curl. So they're learning how to construct their FHIR queries.

And other things this way. It's a great tool for teaching and it's a great way to explore your data. And I'll go into that in a sec. So here's my Synthea data. You can see this is, you know, it's not super beautiful, but it's very functional from a developer perspective. You can see all the linked resources that are linked to this patient.

You can, if you do the same, inspect and copy as curl. You can view the queries to query all the resources related to the patient. Let's see. These are all FHIR objects, so you can, you know, look at 'em, browse 'em, and then this is generated from the FHIR spec. So this is just a very good debugging tool where you can see all the fields.

Great. You can touch them up if you need to. This is common when doing a deployment. Just add your identifiers, for example, or change address. If you don't yet have an app that's fully functioning, you can see the history started by Synthea. And blame. So if you're running a deployment, it's very often that you wanna be, who changed this data. So this is a great tool for that. JSON representation. And then there's this concept of apps basically if you have. Questionnaires that are linked to this, to the patient object, then you can just link them here. They are automatically linked here. So that's a example. So yeah, that this is, this is the admin console.

It's very powerful. It helps. The developer have like an on-ramp into FHIR that you know, for a novice developer it can be pretty intimidating. For this crew, I'll show the batch upload like. I, I think one of the top search items on our website is Synthea. People generate their Synthea, or use Synthea from files from GitHub and just upload them here or paste them as JSON here and then, use that to quick start and prototype their application.

I would invite all of you all who, if you're making demos or you want to have a little environment to share with people, That would be, you know, we would love to have you use the free offering. That would be great. And we'd really like that. We support all of the resources. We just have like some, this account just has these ones configured, but you can change your user profile to have the quick links that you want.

And there's a lot of administrative tools to, to help you get started. One thing I'll note here. Is that there's this concept of bots that we talked about. So if you have a bot, this is basically like it's code, that executes. For example, in this example if a patient fills out a questionnaire and you have a questionnaire response and you want to like compute some in this case, this is the SDOH, I think social determinants of health.

Then you can use, build out your scoring function and if you want to write it as an observation, you can implement a lightweight workflow here. This is just a very common thing and the bots have, you know, different flavors. There's integration bots synchronizing to insurance, you know this is what a lot of the developers on the platform are.

I'll go briefly into the questionnaire as well, because a lot of developers, they are focused on the patient experience or the provider experience, but the, they're setting up their questionnaires and stuff in the admin tool and this is a, Google forms type experience for your FHIR questionnaire.

So here's the builder can, wow, this one's really big add item. You can change, the display can change go through a bunch of different. Editing and it's, this is just, a way to build it. It just ends up being, your FHIR questionnaire object and you have the history and the, and the blame, et cetera, just like the other resources.

And then you can preview what it will look like. And this is not very impressive in and of itself, except that this, you can, you can use. Form and embed it in your application. So that's, the real use case. And people are tagging them with their various ontologies.

I don't have a good one here right now, but like, you know, where, where did this form come from? What ontologies is it tagged with? That's very useful generally for getting your, your workflow to work, right. I. Okay. Let's see. So once you have all of these like resources in place your questionnaires, your integrations, and you can start building a more powerful app.

So I'll show you kind of in context. So this is foomedical.com. All this is also an open source application. If you go to foomedical.com and just look at the footer, you can get to the documentation and stuff and you can log in. It's a sample. It's not a real healthcare practice, but you can have like a very cool patient portal that looks white label.

That's all FHIR native. And these are FHIR resources. I'll show you some examples here. Here's the lab result. Medications. It's a medication object. Vaccinations, vitals, blood pressure. This is based off of Synthea Data by the way, but and kind of body temperature. You can add measurements if you want.

And this is the core data model. All, the data for this is living on app.medplum.com. Foomedical is a static JavaScript site. It's a streamlined developer experience for a novice. Care plans, checklist. There's a lot of discussion in the community on how to, represent care plans and I'm curious on this team's perspective as well, but also get care, you know this is just a FHIR schedule with slots.

Questionnaires, but these are composing all of the things that you've set up in your app, in your admin console into an experience that's sensible for the users. And it has, you know a lot of other, FHIR resources. I think this example uses like 40 or 50 different type of resources in order to get this experience.

But it absolutely can be supported. We have a alpha version of the Foo Medical provider as well, which is like a very simple EHR. I won't go to this in depth, but you can, you can kind of see very similarly. This is the, questionnaire object, which. Is actually comes, you know, that we saw previously here in the admin console.

So, and this is just a FHIR questionnaire object, so this is kind of helps people administer their practice in a more effective way. Let's see. So patient portal, sample custom EHR. I want to save time for questions, so I'm just gonna blitz through the rest of these. But we have our storybook here online, which is just our React components.

These React components. Map generally to FHIR objects or FHIR data types. I'll, I'm showing like the diagnostic report display here because one of our claims to fame is that one of our customers has built a LIS/LIMS, which has been certified by CLIA/CAP, on top of Medplum. And they use this diagnostic report display, which the CAP inspector has looked at, and you can see the code.

This is just a, you know, diagnostic report we have if you search in our, our repos for this, you can see the object. So it's, it's got a lot of tools to help, you know, smooth the onboarding for the, for the users and for the developers. And then finally, the storybook, I think is one of the top things that developers are looking at in order to help build their applications more effectively.

Finally, I'll move on to the documentation. So we invest a lot in our docs and we absolutely, we want feedback. So if anybody is just looks at the docs, they find something they don't. File a GitHub issue. We're happy to talk about it. It's the subject matter for, and the subject matter is very dense.

So like, it's a, it is a tough job to really document it in a way that makes sense for users, but we are working on it. One thing I'll point out here is that we have sophisticated search. As very popular. And so like, oh, how do I invite a user? Okay, great. Or, you know, I want to look at observation.

And documentation is all in GitHub, so if you ever wanted to contribute to, to documentation, write some tutorials we would absolutely welcome that. And this is part of our open source project, so again, can just go there. Great. And I think you know, we have our, our core repo and would have our, our lots of tooling and build associated with it.

Let me see if I can find, okay, so one thing I will note here is we have like a pretty sophisticated build system, which is all publicly available and it has code scanning and actually probably the best way to see it and I'm also interested to talk to this group about is we have our build of course, Which includes a lot of code coverage and, and important things like that, code analysis.

And if there was like testing tools made. By MITRE and other groups that could be incorporated into a build. We think that that would be really high value. For example, like just be able to test your conformance or ontologies or terminology. The, all of those things would be just very helpful and we hope to you know, bend your ear on it or have the opportunity to at some point.

Medplum will be at HIMSS on April 17-19, 2023 participating in the HIMSS23 Cancer Care: Treating the Whole Person Demonstration hosted by the CDC in McCormick Place, North Building Hall B, Booth 7649.

Let's connect in person, please fill out this form and we will reach out to set up a time/place to meet.

We also welcome you to join our HIMSS related Discord channel.

HIMSS Materials​

(Updated April 21, 2023)

Thanks to all of those who visited the showcase and here are some more supporting materials.

• CDC Medmorph Reference Implementation repository on Github
• Interop Showcase Handout

When the video is available, we will link to it here.

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

We are excited to hear about the release of Fast Healthcare Interoperability Resources (FHIR) R5, the latest version of the healthcare data interoperability standard. This new version builds on the previous versions of FHIR and incorporates new features and improvements to further support healthcare data exchange and interoperability.

FHIR R5 includes enhancements to the FHIR specification, including additional resources, improved support for clinical workflows, and improved alignment with other healthcare data standards. The new version also includes updates to the FHIR conformance framework, which helps ensure that FHIR implementations are interoperable with each other.

In the future, we will upgrade our service to support FHIR R5 side by side with R4. This includes ensuring that our solutions comply with the latest FHIR R5 specifications and testing our products for interoperability with other FHIR R5-compliant systems.

We will do this while maintaining our support for FHIR R4 - which most of our customers rely on today. We will use our Bot framework, TypeScript SDK and validation tools to help our customers implement the version of the spec that best suits their business needs.

We are excited about the potential of FHIR R5 to improve interoperability and enable better healthcare outcomes for patients. We continue to closely monitor industry adoption and compliance requirements and will strive to provide our customers with the most up-to-date solutions to meet their interoperability needs.

Thank you for your continued support, and we look forward to sharing more updates with you soon. If you are interested in updates related to FHIR R5, please reach out at hello@medplum.com.

Related Reading​

• FHIR Forums Announcement

Patient deduplication is a tough problem, and there are many approaches to implementing a deduplication program. We provide this guide and sample code as a resource to teams who want to run a continuous deduplication program that is powered by automation and highly auditable.

There are three elements that we see playing a big role in deduplication:

1. New patients evaluated for duplication at time of creation (event driven)
2. Disciplined maintenance of identifiers from different systems
3. Maintaining your de-duplication policy as code

Here is a 5 minute tutorial video on deduplication that summarizes the content of this post.

Event Driven Deduplication​

In Medplum, by hooking a Subscription to the Patient resource, you can subscribe to the creation of new Patient. This is powerful because it allows you to check each new patient against the existing patient base and flag duplicates in real time.

We suggest making a Bot that listens for new patients and every time a new patient is created evaluation whether they can be merged with an existing patient, creating a duplication risk score or flagging for manual review.

A sample (skeleton) deduplication bot can be found in the Medplum Demo Bot repository.

Maintaining Identifiers​

Many systems issue patient identifiers, like payors (e.g. United Healthcare), pharmacy and medication systems (e.g. DoseSpot) and even payment providers like Stripe. FHIR support maintaining multiple identifiers from different systems. If you maintain records with patient identifiers from different systems, this can be the basis for detecting duplicates with high accuracy.

The sample deduplication bot test shows a patient with multiple identifiers for reference.

Policy as Code​

The stakes are high for deduplication. A false merge can cause treatment errors, incorrect data disclosure and more. Having an auditable policy as code, test coverage, source control and a system with robust audit history is an excellent tool for having that high fidelity deduplication process that is required for great patient care.

Resources​

• Patient deduplication sample Bot
• Patient deduplication Bot tests
• Bot Execution via Subscription
• FHIR Multiple Identifiers documentation
• Patient resource in Medplum App

Great workflow apps are core for us at Medplum, and we provide tools to build highly ergonomic asynchronous task tracking systems providers. Some examples of task management apps in the medical context are apps that:

• Review and approve lab reports
• Approve or reject medication refill requests
• Instantiate custom care plans for a patient

Medical systems in general and FHIR in specific have robust workflow resources to create, track and implement workflows. Tasks and ServiceRequests are the most common workflow resources for asynchronous work.

Setting up Queues or Worklists​

The core or a workflow app is a queue or sometimes called a worklist. This is exactly what it sounds like - a list of tracking tasks that represent the work to be done and it's current status. The FHIR Tasks as a group are often used to represent a queue. Tasks can be created programmatically, or via Questionnaire and Bot.

When populating the Task resource, it can be useful to populate the following fields:

• Task.focus - this is what the task is about, for example you can link it to a DiagnosticReport, MedicationRequest or CarePlan
• Task.businessStatus - this can be used for custom workflow, where you can set your own statuses that fit your workflow
• Task.code - this can be useful to cue the Task specific user interface (below), example might be "Lab Review"
• Task.executionPeriod - this can be useful for productivity tracking
• Task.for - this is usually a link to the Patient

Once you have created some Tasks you can view Tasks in the Medplum App.

Once you have confirmed that tasks are formed the way you want them to be, you can embed a search control in your Task tracking application, there are examples in the sample application.

Like in the Medplum App, it is recommended that you have one page in your app that supports permalinking to a specific task search as it is useful for collaboration, integrating into chat apps and other common workflow tooling scenarios.

Task specific User interface​

For each task, you will want to show a user interface that gives the user some context on how to resolve or take action on that task. This is very workflow dependent so customizability is important. You can see a video (70 seconds) on this topic here.

The exact components of the Task specific user interface are often driven by Task.focus or Task.code.

Dashboards​

Turnaround times and productivity tracking are crucial for observing the health of your task-based workflow. Assuming you populate the timestamps correctly in the resources, it is straightforward to calculate how many work hours a certain task takes, or the turnaround time.

Here is an example of a timestamp calculation:

• Turnaround Time for a Task: Task.executionPeriod.end - Task.authoredTime
• Work hours for a task: Task.executionPeriod.end - Task.executionPeriod.start

Using these calculations, it is straightforward to make a dashboard that gives a very clear picture into the status and health of your queues. In this example below, each of the graphs is a representation of a Task search, with results bucketed by turnaround time or by work hours.

Related Resources​

• Sample Task App Github repository
• Task center stage video
• Task Resource Documentation
• Tasks in the Medplum App

We're hiring! Check out the new Careers page.

Medplum was founded by industry veterans, experienced founders with a clear vision of how to tackle healthcare's biggest challenges. We are committed to maintaining a tight team of elite engineers. Medplum is open source and building in public. We use modern tools and follow industry best practices.

If that sounds interesting, please email careers@medplum.com with your resume and a short introduction. We're excited to meet you.

As we close out 2022, the Medplum team would love to thank our customers and community for joining us on this journey.

We wanted to highlight a few memorable moments and reflect on all that happened during the year. It was a lot of fun, and huge thank you to the team who pushed so hard to make all these things happen.

✅ Open sourced our repository

✅ Achieved SOC2 Type 2 and HIPAA certification

✅ First Enterprise customer went live!

✅ Launched our Youtube Channel and Discord Community

✅ Had our YC S22 Demo Day

✅ Launched our sample patient portal Foo Medical, video, source code

✅ CLIA/CAP Certified

✅ Launched on Hacker News

✅ 500+ Github Stars

✅ Published our Roadmap

Instead of going on about what the new year has to hold, I'll share a peek into the future in the most Medplum way possible - i.e. in excruciating technical detail. Please enjoy and feedback always welcome.