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. Surescripts or 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.

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.