6 posts tagged with "fhir-datastore"

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

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.

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

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

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.