Composability is the ability of different components or systems to be combined and work together seamlessly. This allows developers to build on existing open source software to create new applications and solutions that meet their specific needs.

As a software engineer, when a system you are using supports enables composability you have this visceral feeling that you are moving fast, and you feel powerful. Ideally, you also feel a sense of confidence and safety, that the application you are building is going to work as expected.

Composability is so important to us here at Medplum that we have used the three biggest tools in our toolbox to enable it for healthcare applications and those are:

• Standards
• Open source software
• API-First design

Standards​

The needs of a healthcare organization are in constant flux. Some days the patient experience is top of mind, other days the provider workflow needs work, and yet other days the needs of payors or partners is crucial.

However, in a organization with active patient flow, upgrading tooling and technology to address needs can be a challenge.

Providers have a stack that looks something like this - with a mix of commercially available tools working together with home grown software. There is often a lively discussion on which tools to pick for which purpose. The diagram below shows (as an example) applications that are written in house as purple, and the ones that are bought in grey - but there are many possible configurations.

In practice, a stack might look like the following, with different SaaS, on-premise, or other tools working together to enable a service. Sometimes teams within a company coalesce around a tool, and an information silo within an organization can form. We have even seen some groups where it is a person's job to move data from one tool to another.

After many years of doing implementations like these, and getting these systems to work together, we at Medplum have formed a strong opinion on how to get your stack to evolve to meet your needs and we want to emphasize one word: standards.

Getting your application to implement the functionality you need will be so much easier if you have a standards based approach. An example of a standards enabled stack might look:

Here are 5 specific ways standards can help your stack evolve.

Open Source Software​

Open source is critical in enabling composability, and that is one of the top reasons why developers love it so much. When developing an application, it is common to get unexpected behavior and get stuck. Sometimes something that sounds so simple, like the way a regex is parsed or the way a dates are compared can cause chaos in or completely block an implementation.

Open source, providing line by line access can greatly speed debugging, and can help users get past blockers that would have caused enormous delays in the past. Similarly, understanding with specificity how something is implemented is critical to extending it.

At Medplum, we care a great deal about having our open source enable composability. Well organized and tested code, solid abstractions, with great issue management is what we strive for.

API First Design​

Many, many applications have an API, but only allow limited functions to be accessed via the API. This limits the composability of said systems substantially because by definition some of the functions must be done manually in the app.

In healthcare, the most common pattern where you see the limitations of existing platforms is workflow. For example, there is a sophisticated workflow app with data capture, business logic and validation that triggers notifications. Inevitably, when the workflow needs to be amended and many organizations work around this by having humans do data entry and processing, or make an alternate datastore and copy and manipulate the data. This feels slow, is costly and error prone.

At Medplum we take great care to make nearly everything available via well-documented API. As needs change, if the workflow abstractions (data, users, business logic, notifications) are in place they can be altered to evolve with the changing needs of healthcare.

In Conclusion​

We aim to enable extreme composability for healthcare apps - and we use standards, open source and API-first design to do it. We welcome your feedback via issues or discussions.

What is ONC Certification?​

The Office of the National Coordinator for Health Information Technology (ONC) certification is a program that ensures that electronic health records (EHRs) meet certain standards for interoperability and security. It is designed to help healthcare providers adopt and use EHRs more effectively, and to promote the widespread adoption of EHRs as a means of improving the quality and efficiency of healthcare. To be certified, an EHR must meet a set of standards and criteria that have been developed by the ONC in collaboration with other organizations and stakeholders in the healthcare industry. These standards cover a range of areas, including the exchange of health information(g10), patient access to their own health data (also g10), and the protection of sensitive health information(d1,d13,g12). By achieving ONC certification, EHRs can demonstrate that they meet these standards and are ready for use in a wide variety of healthcare settings.

From a technical perspective - the most important thing to understand about the certification is that it requires FHIR API access - for patients and practitioners.

The Benefits of Certification​

The benefits of certification vary by the type of provider. The following are very tangible benefits to getting certified.

• For those with a large CMS (Medicare, Medicaid) population, getting reimbursement at the optimal rate will require certification.
• Supporting CMS Queries will streamline contracting with payors (other than CMS), who want insight into "quality metrics" and technical touch points.

Beyond the above there, certified systems do gain a benefit in contracting and partnerships because partners know they have a streamlined interface to exchange data.

The Certification Process​

The certification process has is driven by examination, there are certification vendors, e.g. Drummond, who proctor vendors through a walk-through of developer products according to a specific script.

Some of the criteria, for example g10 have standardized test harness, like Inferno or Cypress, that verifies that APIs are working as expected.

This video shows an example of the Inferno tool in practice. The proctored exam will have developers walk through the test session like this one, and the output will be verified by the proctor.

Running the Inferno test harness as shown in the video will be meat of what goes on during the certification examination for that g10 criteria.

The Developer Perspective​

For developers, it is important to understand that there are two types of criteria.

• Self attested criteria: these will not be tested by the examiner, instead organizations will have to self-attest that the functionality is available and provide some documentation.
• Live tested criteria: these will be tested by an examiner, in accordance with the scripts.

You do not need to certify for all criteria at once, you can batch them up and pursue subsets.

Prepare for frequent requirements changes. The regulations and requirements do change frequently, with amendments coming out each year. If you are on point to deliver a system with a certain compliance profile, you can expect to need to adapt to the changing regulations and requirements.

There are "spot" solutions for many specific functionality types, for example ePrescribe, custom reporting or vaccine registry transmission, which can be composed together to support many configurations.

However, at the core of your system, we recommend a highly programmable, well-documented. FHIR enabled infrastructure like Medplum as a base. This will give you the infrastructure needed to orchestrate the ever-changing suite of tools needed to comply with the required regs.

Medplum is a YC Company​

Hello from Medplum!

Medplum is an API-first Electronic Health Record - that’s open source, and today we are announcing that we are part of the YC S22 batch.

This announcement is extra special for us because this fall marks 10 years of YC for our team. Almost a decade ago, we were the founding team of MedXT (W13 acquired by Box) and I spent 2021 as a Visiting Group Partner for the W21 and S21 batches.

Why are we back in YC?

• Medical apps are notoriously hard to build and maintain, largely due to all the stakeholders involved and the byzantine incentive system.
• We were inspired by trailblazing open source YC companies Gitlab, PostHog, Airbyte and many others who solve similar complex problems in other domains.
• We believe the open source model will be especially impactful for healthcare.

Medplum makes it fast and easy to build white label medical apps that look good and are compliant and integration-ready day one.

• Read our docs
• Browse the code
• Try our sample app, with source code

Reshma, Cody and Rahul

When working with customers to set up their apps and workflow we commonly get this request:

We need to track this extra data, but there is no field for it in the FHIR object. What should we do?

FHIR Extensions are a relatively simple way to track extra fields associated with a FHIR objects, and Medplum supports versioning and API access for the extensions, just like we do for all FHIR objects.

Here is the FHIR Extentions official guide.

Design your Extension​

As with any data modeling problem, design of your extension is the hardest part. Most implementations use (1) a top-level extension with the full URL of their institution and then (2) create many sub-extensions with specific values that you want to track.

Let's start with an example: Consider a (fictional) healthcare provider "My Teleradiology Practice" that serves hospitals and clinics throughout the United States with the website www.myteleradiologypractice.com.

Continuing in this example, let's say that My Teleradiology Practice serves several hospitals nationwide, each represented as Organization FHIR objects.

My Teleradiology Practice has contracted with these hospitals and has an annual minimum and annual maximum number of studies they will perform for those hospitals and want to store that data in Medplum, associated with the relevant FHIR objects.

Set up URL(s)​

To get started, My Teleradiology Practice sets up a URL that serves as the top level extension for these organizational details. This URL can have publicly available content or authenticated conent. Example url (there is no content here, it's just an example):

www.myteleradiologypractice.com/organization-details

Write the data as appropriate using the API​

With the URL(s) in place, you can now use them to build the extension. Like the example shown below:

{
  "resourceType": "Organization",
  "name": "City Hospital",
  "extension": [
    {
      "url": "https://www.myteleradiologypractice.com/organization-details",
      "extension": [
        {
          "url": "annualMaximum",
          "valueInteger": 1000
        },
        {
          "url": "annualMinimum",
          "valueInteger": 50
        }
      ]
    }
  ]
}

Now this Organization JSON Object, representing a specific organization, also has the annual maximums and annual minimums tracked along with the core data.

View data in the Medplum Console App​

As with any data in Medplum, FHIR objects with extensions will have data versioning and audit history. If you browse to the JSON representation of the object in the console you can browse the values, and of course access them via the API.

As always, we can help you construct your extension to fit your needs. Contact us at info@medplum.com.

We at Medplum are pleased to share the news that we have recently completed our System and Organization Controls (SOC) 2 Type I audit.

Industry-Standard Accreditation​

The SOC 2 audit is one the highest recognized standards of information security compliance in the world. It was developed by the American Institute of CPAs (AICPA) to allow a third-party auditor to validate a service company’s internal controls with respect to information security. Our SOC 2 Audited Report, which can be obtained upon request, is the auditor’s opinion on how our organization’s security controls meet the SOC 2 criteria.

We obtained our audited SOC 2 Report by partnering with Secureframe and Prescient Assurance who respectively helped us prepare for and review our internal controls including policies, procedures, and infrastructure regarding data security, firewall configurations, change management, logical access, backup management, business continuity and disaster recovery, security incident response, and other critical areas of our business.

Thanks to a company-wide effort here at Medplum, and with the help of our partners, we successfully achieved SOC 2 compliance and received an Auditor’s Report, which we are happy to share with you to demonstrate to you that our policies, procedures, and infrastructure meet or exceed the SOC 2 criteria. A summary of our practices can be found in our security summary.

We go above and beyond the minimum requirements for SOC 2 by integrating our critical infrastructure to monitor compliance to the SOC 2 framework 24/7/354, not just during the audit window.

The successful completion of our SOC 2 Report is one of many ways that we have planned to earn and retain our customer's trust. SOC 2 is just one aspect of our growing security program. We are committed to continually improving our information security program and retaining an annual SOC 2 audit to ensure we keep supporting our customers’ needs.

At Medplum we know that customizable forms are critical for any healthcare app. Is it even a healthcare app without tons of forms?

To serve that need, we have created a Form builder similar to common tools like SurveyMonkey or Google Forms but based on the FHIR Questionnaires.

FHIR Questionnaires are very powerful and are widely used in healthcare systems. Medplum can help you author questionnaires or import them from other systems and manipulate them programmatically to get the workflow and data capture you desire.

Here is a 2 minute video introducing the product.

Here's how to get FHIR Questionnaires set up​

0. This tutorial assumes you have registered for an account. If you have not, you can do so here.
1. You can create new questionnaires using the Questionnaire Tool on Medplum. (Here are all Questionnaires in your account.)
2. You can use the Builder to add questions that have different types, and they can be common types like strings or integers, or they can be FHIR objects like Organizations or Patients
3. Each questionnaire has one or more Subjects, which will link the Questionnaire in the tool to the Subject data type. For example if the Subject is a Patient, then the Questionnaire can be found in the Apps tab on the Patient object (see video to get a visual).
4. Once the Form is filled out a QuestionnaireResponse will be created with all the appropriate data.
5. This is an advanced topic which will be covered in another tutorial, but you can use Bots to create new FHIR objects and execute an advanced workflows.
6. Questionnaires can be embedded in applications such as your webapp, this is also an advanced topic for another time but if you want to get started building app start here

Open Source Questionnaires​

There are tons of standard questionnaires available online, and some institutions have proprietary ones that are tailored for a use case, or in some cases even validated experimentally.

Some institutions publish their questionnaires - for example:

• MDCalc publishes a large number of questionnaires like PHQ9
• Ages and Stages publishes widely used pediatric screening tools.

Having a well managed and documented Questionnaire set with version tracking and attribution can be a huge asset for an organization and we encourage everyone to think of it as such.

Synthetic FHIR data is increasingly popular for people who are building healthcare apps. It's useful for testing, prototyping, partnerships, sales and more. In the implementations we see here at Medplum, more than half use synthetic data in some form or another!

Synthetic FHIR data is just what it sounds like. It's realistic patient data but it's completely synthetic, and can be shared and used for testing. It's useful to think of synthetic data as a "population" or set of records that correspond to a group of fictional patients.

At Medplum, some of our customers use a project called Synthea to generate this data. Here is some sample data, that shows what the tool generates as raw FHIR Objects. Below are instructions on how to generate some sample data and load it into your Medplum account.

1. Setup Java 1.8+

   1. Try to run java from a Terminal: java -version
   2. Verify that you have Java 1.8+ installed, if not download and install.

2. Download Synthea

   1. Go to Synthea Releases Page
   2. Download the latest synthea-with-dependencies.jar
   3. Move the jar file to it's own directory

3. Run Synthea

   1. Open a Terminal and navigate to your recently downloaded synthea jar.
   2. Run: java -jar synthea-with-dependencies.jar
   3. This will create a folder called output
   4. In the folder output/fhir, there will be 3 new files - one representing a hospital, one representing a practitioner, and the third representing a patient.

4. Import the data

   1. Go to Medplum Batch Create Page
   2. Copy the contents of the files one at a time, in the correct order
      1. hospitalInformation first
      2. practitionerInformation second
      3. patient last
   3. Once you have imported the data, you can go to the Patients page to browse the data you created.

Let us know if you need assistance with your data sets - we would be happy to help.

You can use Medplum as a tool to help you learn FHIR quickly.

Fast Healthcare Interoperability Resources (FHIR) specification is a data standard for healthcare that defines how information can be exchanged between systems. (Read more about what FHIR is and it's philosophy and history here)

Major healthcare platforms such as Epic and Cerner, as well as big tech - Apple, Google, etc. support FHIR in various capacities, making it increasingly popular.

FHIR is very powerful and expressive, but that can make it hard to understand. It can feel intimidating, even for those with a healthcare background and a lot of domain expertise.

Medplum is designed to help you implement FHIR, of course, but also to help you learn FHIR. The app is built on a JAM stack (Javascript, APIs and Markup), and the API calls are... FHIR API calls!

Using Chrome Developer tools can see directly which calls are made to render the page and quickly get a feel for FHIR and how to write your own app. Here's a brief video tutorial:

To try for yourself:

0. Pre-requisite, you have set up your Medplum account and created at least one patient instructions here and are using Google Chrome.
1. Open the Medplum App and navigate to the Patient page.
2. Open up Chrome Developer Tools and navigate to the Network tab and refresh the page instructions here.

Use the tool to help you construct the objects and searches that you need to build your application. Good luck, and let us know what you build!

Developer infrastructure and tools for healthcare apps​

Healthcare applications are famous for being complex, rigid and hideous, and we on the Medplum team have seen many up close and witnessed the problems firsthand. It's easy to dismiss the hideous phenomenon as lazy app developers or poor product management, but in reality, it's not that straightforward.

Delivering healthcare is very complicated - lives are at stake and tools and treatments are constantly evolving. Additionally, incentives and business models for patient care complex and heavily regulated. Any app built for healthcare by default serves many stakeholders.

Medplum approaches this complex environment from the developer perspective. We believe that a toolset that abstracts data, identity management, user interface and reporting will allow healthcare apps can be built quickly, and more importantly flexibly - i.e. they won't need to be re-written when new stakeholders are introduced. That's what we are building.

Our open source model is critical to building extensible, flexible apps. In healthcare, it is extremely common for vendors to lock in data. In the US - interoperability is regulated for this reason. Storing data natively in FHIR, and showing exactly how it is done, we believe, will prevent the rot that is so common in the industry.

Thank you for taking the time to check out Medplum. Please try it. We welcome your feedback.

Medplum Repo

Open an Issue