Medplum is a community, and advocacy for standards and open source implementations are core to our mission. I’m writing today to share Medplum’s support for Stanford Biodesign OpenCareHub’s proposal for ARPA-H PARADIGM.

There are three things that make this proposal noteworthy.

• ARPA-H PARADIGM is a government initiative, whose mission to improve access to healthcare in rural communities
• OpenCareHub will open source their implementation
• The initiative is led by an interdisciplinary (clinical/technical) team out of Stanford Biodesign, Dr. Oliver Aalami and Dr. Paul Schmiedmayer

We would like to encourage those in the Medplum community to reach out if you need a letter of support for your engagement with government agencies like ARPA-H, NIH, CMS, FDA and more. Contact us at hello@medplum.com.

We wrote a letter of support for the OpenCareHub team. Good luck!

Chamber Cardio, a technology-enabled cardiology solution, helps enable and empower cardiologists and practices in their transition to value-based care. With our cloud-based technology platform, we offer a suite of tools designed specifically for cardiovascular care. These tools provide real-time insights, analytics and care coordination tools focused on improving outcomes for patients with chronic cardiovascular conditions.

Chamber’s products serve as a compliment to a cardiology practice’s existing Electronic Health Records (EHR) and Practice Management Systems offering many powerful features, such as quality measure and care gap assessment, customizable population-level patient dashboards and hospital encounter notifications, clinical pathway workflows (including guideline-directed medication support), automated risk assessments and care team collaboration through secure messaging and task management.

To reduce engineering lift and accelerate development, the clinical and operational front-end for internal care team management was built using the Retool Enterprise Platform self-hosted in Chamber’s AWS cloud environment integrated directly with Medplum for the backend data storage and web services layer.

Problem​

In the early stages of product development, the Chamber team, with limited time and technical resources, sought out creative solutions to help accelerate product delivery without sacrificing the quality or capabilities in scope for our MVP milestones. We initially prioritized the development of our core data integration pipeline (including EHR, ADT feeds, claims, etc.) and a foundation for internal tooling to properly support clinical and operational workflows.

The complexity of internal care coordination and practice management requirements, including integrated clinical guidelines, medication titration support, disease-specific risk assessments, and quality measure reporting, elevated the challenge. We also had to manage and normalize diverse datasets and terminology standards. As a seed-funded startup with just two software engineers, finding the right mix of custom-built and off-the-shelf solutions was critical to building a strong, secure foundation for the product, capable of supporting future growth.

Solution​

Chamber decided to tackle the challenge of managing key data workflows and operational tooling by leveraging Retool as the backbone for our internal platform. Retool's platform, known for its comprehensive frontend components and ease of data integration, enabled Chamber's team to effortlessly link our FHIR datastore, supported by Medplum, with clinical and scheduling information. This approach allowed for a development of a wide range of care management and operational applications with minimal custom development.

The Retool client, deployed in AWS, connects to Medplum directly, using both API protocols (REST and GraphQL). This configuration provided a flexible and robust environment for Chamber’s internal requirements, and, given the compliance offering (SOC 2, HIPAA, ONC, etc) from Medplum built into the platform, our team could devote more resources to developing a reliable data pipeline and a high-quality user experience for our external clinician-facing products, ensuring the foundation was set for future scale and complexity.

Challenges Faced​

Several challenges emerged during the early development process:

• Normalizing Clinical Terminologies: One of the first obstacles was creating a system to accurately map and normalize clinical terminologies from various data sources into Chamber’s FHIR datastore. The solution was a blend of API integrations for standard coding systems, utilization of public crosswalk datasets, and leveraging Medplum for critical terminology metadata and mapping logic. This multilayered approach ensured a seamless, standardized coding solution.
• Generating Realistic Synthetic Patient Data: To refine complex workflows, Chamber turned to Synthea™, generating synthetic patient data that mimics real-world medical histories (e.g. hospital encounters, office visits, prescriptions, lab values, etc). This synthetic data allowed our team to simulate scenarios specific to chronic cardiovascular diseases, refining the system’s use of FHIR resources and Medplum integration. The insights gained were pivotal in developing analytics dashboards, risk assessment algorithms, and medication management features.
• Concept Mapping and Categorization: Effective query support and decision-making required a sophisticated grouping and categorization of clinical concepts. By integrating with leading coding system APIs and the NLM VSAC repository through Retool, Chamber was able to categorize and code clinical concepts efficiently, laying the groundwork for robust data queries and decision support tools.
• Maximizing Retool Built-in Capabilities: While Retool provided a strong foundation for data integration, Chamber encountered limitations with more complex and nuanced FHIR data use cases. To overcome these, the team incorporated FHIR-based libraries as global functions using BonFHIR, enhancing Retool’s capabilities while adhering to healthcare standards.

Medplum Features​

Medplum, offered several key features that were useful in the development of the Chamber Cardio platform:

• Authentication: Ensuring secure access and access controls for data and system functionality that works well with Retool.
• Subscriptions: Used to automate critical updates when changes are made to FHIR resources, helping to maintain quality and contingency across all data elements.
• API and SDK: Offering robust application programming interfaces and software development kit for seamless integration.
• Compliance: Meeting healthcare regulations and standards, an essential aspect of any medical software solution.

Retool Features​

Chamber took advantage of a wide array of Retool’s platform capabilities for both prototyping and developing solutions for internal tools and care coordination workflows:

• Component Library: comprehensive set of highly customizable, scalable and responsive frontend components
• Data Source Integration: REST and GraphQL APIs, AWS Lambda, S3 Resources
• Javascript Transformers: reusable functions and local data storage used to manipulate data returned from queries and access anywhere in the app
• Event handling: triggering queries and components on successful and failing query responses and manual data refresh control
• Environments & Version Control: Ease of configuration for multi-environment deployment with dedicated data sources and version-based release support
• Self-Hosted Deployment: To maintain healthcare compliance, Chamber’s Retool instance is deployed fully within our AWS cloud infrastructure

Conclusion​

Chamber Cardio’s initiative underscores the effectiveness of combining cutting-edge technologies—Retool’s frontend versatility, Medplum’s backend strength, and BonFHIR’s supplementary libraries and tooling —to craft a cardiology care platform that stands out for its comprehensive data integration and workflow management offering. This collaboration resulted in a product and technology foundation for enhanced care coordination, streamlined decision-making processes, and a supportive pathway for cardiology practices transitioning to value-based care and exemplifies how strategic tool selection and technology partners can enable meaningful advancements in healthcare innovation and delivery.

References​

• Chamber Cardio Blog Post on Modernizing Cardiology Care

Claims data is a uniquely rich source of financial and clinical data important to many healthcare workflows. The EDI 837 Health Care Claim transaction is one of the oldest forms of electronic data exchange, stemming from being defined as a required data transmission specification by HIPAA.

Today, we are showcasing Flexpa which connects applications to claims data via direct patient consent and a modern FHIR API powered by Medplum.

How does it work?​

Flexpa aggregates and standardizes Patient Access APIs created by payers as required by CMS-9115-F. First, patients authenticate and consent to a data-sharing request from an application.

Then, Flexpa extracts, transforms, and loads payer responses into a normalized FHIR dataset. Flexpa stores data in a temporary FHIR server cache during the period for which a patient has granted access.

Finally, applications receive a patient-specific authorization response which can be used to retrieve data from a FHIR API provided by Flexpa – powered by Medplum.

What problems does Flexpa solve?​

Payer FHIR servers offer an extremely variable API experience and implementing against 200+ of them is painful. Using Medplum as a data cache for their own FHIR API allows for a uniform developer experience on top of the underlying network access. Flexpa allows developers to use claims data to deliver risk factor adjustment scoring to value-based care providers, help patients navigate care, join clinical trials, negotiate bills, and more.

How does Flexpa use Medplum?​

Flexpa takes advantage of several important features of Medplum’s FHIR implementation:

• Self-hosting
• Multi-tenant through Projects
• Update as Create
• Client assigned IDs
• Batch transactions
• Medplum App
• FHIR Operations such as $validate, $everything and $expunge

Medplum’s open source implementation provides Flexpa with the ability to contribute back to the project when improvements or changes are required. Additionally, Medplum’s technology choices and stack align perfectly with Flexpa’s making working with Medplum easy for Flexpa’s development team.

Related Resources​

• Flexpa website
• Flexpa Blog
• CMS FHIR compliance documentation

Develo has built a full-featured EHR and customer relationship management (CRM) for pediatrics, encompassing core scheduling, clinical, and billing workflows along with family engagement capabilities.

(5 minute demo)

Outpatient pediatrics is uniquely family-centered, longitudinal care-driven, and high volume, with distinct well child check-ups and payor mix that is different from other specialties. Accordingly, the Develo product is beautifully designed with much attention to the nuances that matter to their core independent pediatric practices market.

(A beautiful pediatric growth chart)

Develo has built a full stack solution with key innovations around automating family engagement, reducing administrative tasks, and AI-assisted documentation.

(Intuitive patient intake)

They rapidly release new capabilities and take a comprehensive, end-to-end approach to build a full operating system for pediatrics, rather than just optimizing a narrow set of provider workflows.

(Scheduling orders)

Develo EHR is FHIR native and built on Medplum using the following features:

• Self-hosting: Develo hosts Medplum in their own AWS.
• Multi-tenant: Develo customers have separate datastores using Medplum projects.

This application is an example of a software company, using Medplum to build a custom EHR that delights pediatricians, patients, and families alike. Some screen shots of the applications are shown below.

(Even the billing experience shows attention to detail)

As we close out 2023, 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.

✅ Added many wonderful customers, and several have written case studies about how they use Medplum.

✅ ONC Certified in March

✅ 99.999% uptime

✅ Launched integrations with many popular platforms like Labcorp and Epic

✅ Enhanced our connectivity with on premise systems with the Medplum agent

✅ Released support for FHIRcast

✅ Doubled the size of our team

✅ Added to our Youtube Channel and Discord Community

✅ Enhanced our our Roadmap

Thank you, dear reader, for being part of our community. See you on Discord.

Medplum’s Open-Source FHIRcast Hub Enables Rad AI Omni Reporting's Interactive Measurements​

Radiology is a bellwether for innovations in Healthcare IT due to the time-sensitive and data-intensive workflow. Naturally, radiology applications lead the way in adopting real-time functionality like FHIRcast, a WebSockets-based protocol that enables development of highly interactive applications.

Today, we are showcasing the Rad AI Omni Reporting platform, with FHIRcast support through Medplum’s open source FHIRcast hub.

How does it work?​

Let’s consider an example: a radiologist makes a tumor measurement from a PACS workstation; that measurement can be sent in real-time to the FHIRcast hub as an event. The event is then forwarded to the radiologist’s report editor, where a context-aware description is automatically filled in describing the tumor findings, all without the radiologist ever needing to touch another application or do dictation.

Why open source?​

Proprietary notification systems are a walled garden, and make it difficult or impossible to build highly ergonomic applications. An open-source FHIRcast hub is a foundational community asset, as developers and vendors can focus on building integrations rather than the plumbing. Open source provides a lot of flexibility for prototyping, testing and integrations across organizations.

Why FHIR?​

Integration is a thorny problem in healthcare overall, and the adoption of standards has been a key tool in allowing system interoperability. Specifically for FHIRcast, a reference implementation that partners can prototype against and use without restriction will increase quality and speed of integration.

Rad AI interactive reporting enabled by FHIRcast​

Rad AI Omni Reporting uses the Integrated Reporting Application (IRA) spec and Medplum’s open source FHIRcast hub to enable the rich, interactive application seen in the video.

Rad AI is excited to use open source FHIRcast for context syncing and data passing with our imaging and worklist partners. Having an open-source, standards-based FHIRcast hub lowers the barrier of entry for products to work together.

John Paulett Director of Engineering, Rad AI

About Rad AI​

Rad AI is the fastest-growing radiologist-led AI company. The company was recently listed on the CB Insights’ Digital Health 50 as one of the top privately-owned companies using digital technology to transform healthcare, Digital Health 150 as one of the most innovative digital health startups, and AI 100 as one of the world’s 100 most promising private AI companies. Rad AI won AuntMinnie’s “Best New Radiology Software” in 2023 for Omni Reporting and “Best New Radiology Vendor” in 2021. In 2022, Black Book ranked Rad AI #1 in Mean KPI score on its survey of 50 emerging solutions challenging the healthcare technology status quo.

Founded in 2018 by the youngest radiologist in U.S. history, Rad AI has seen rapid adoption of its AI platform and is already in use at 8 of the ten largest private radiology practices in the U.S. Rad AI uses state-of-the-art machine learning to streamline repetitive tasks for radiologists and automate workflow for health systems, which yields substantial time savings, alleviates burnout, and creates more time to focus on patient care.

Related Reading​

• IRA Specification
• Omni Reporting Press Release
• Medplum FHIRcast

Digital health companies are at the forefront of revolutionizing patient experience by combining quality care, at lower costs, and at national scale. Typically, they target a specific healthcare niche, concentrating on top-notch execution. Their ultimate goal? To merge an exceptional patient experience with smooth operations behind the scenes.

When operations are executed right, patients have a seamless experience - everything Just Works ^TM. At Medplum, we've worked with many excellent digital health implementations, and there are four foundational elements that make their operations truly stand out:

1. Well-defined Service Menu
2. Top of License Care
3. Fifty-state Workflow
4. Asynchronous / Hybrid Care Models

To implement these elements, companies need IT infrastructure that can be tailored to their service niche.

Traditional EHRs weren't built for this - rather, they were built to serve a broad healthcare domain at a smaller scale, typically within the four walls of a single site.

Well-Defined Service Menu​

Successful digital health operations start with a crystal-clear understanding of their clinical service menu. From an IT standpoint, this means defining your codes:

• ICD-10 and CPT codes for services
• LOINC codes for diagnostics
• RXNorm codes for medications

A well-defined scope not only sets the stage for streamlined integration and billing, but also paves the way for a superior clinical experience. Instead of using one-size-fits-all EHRs, developers can build dedicated interfaces for physicians, highlighting only the necessary data for that specific care context.

The result? Reduced data entry, no physician burnout, and easier clinician recruitment. That's why Medplum provides a truly headless platform - to empower developers to create purpose-built physician experiences.

Top of License Care​

Delivering high quality care at reasonable cost means that everyone is working at the "top of their license". MDs and NPs focus diagnosing, prescribing, and designing care plans; care coordinators handle administrative inquiries.

To implement this model at scale, operations teams need to develop a clear ontology of clinical tasks and roles that mirrors their care model, and manage them in a unified task system. The challenge is ensuring tasks are automatically directed to the professional, while still being able to escalate when needed.

Many traditional EHRs make offer a fixed clinical workflow, or offer limited configurability. Most of them cater to MDs, but don't account for care coordinators, customer success representatives, fulfillment teams, and the host of other roles that make up the digital health care workforce.

Platforms like Medplum offer a layer of programmability on top of the FHIR Task model, which allows developers to implement the precise clinical workflow model. Tasks can be organized into queues and assigned based on credentials and availability. And by integrating these automations (i.e. Bots) into the software development lifecycle, operations teams can test workflow changes before deploying and release with confidence.

For a deeper dive, check out our guide on Task-based workflows.

Fifty-State Workflow​

One of the game-changing innovations of digital health was the ability to serve patients across all 50 states. But this evolution brought with it a significant challenge: managing physician licensure and credentials nationwide.

Operations teams need to make sure that enough physicians with the correct licenses are staffed to serve their patient population. They need to account for differing physician specialties, regulatory restrictions, and vacations across service lines.

The key to managing this complexity is having the right data model. How can you manage physician coverage if you don't even know which licenses they have? Traditional EHRs fall short here, as they presume a single-site deployment.

Leveraging the FHIR standard, platforms like Medplum offer the building blocks for tracking physician credentials, specialties, and care teams. For more insights, take a look at our guides on provider organizations, credentials, and payor networks.

Asynchronous Care​

The rise of telehealth, catalyzed by the pandemic, was the first step in unlocking the potential of digital care. But digital health is more than just video calls. Not every patient concern needs to be handled face-to-face.

Allowing physicians to deliver care asynchronously allows them to scale themselves more effectively. It also opens up a number of different interaction media for patients: SMS, video message, in-app chat, etc.

While many traditional EHRs have chat functionality, their visit-centric model makes them ill-suited to async-first care. What is considered a "visit" in the age of day-long text chains?

Platforms like Medplum present the tools to craft your care delivery, even if it adopts a partially or completely asynchronous model. Our guide on asynchronous encounters provides an example of how you can build your async care model from FHIR primitives.

The Digital Health Operations Playbook​

1. Define your Service Menu: For each clinical service line, clearly outline the relevant CPT, ICD-10, RxNorm, and LOINC codes. Focus on the essential data entry requirements from patients and physicians and prioritize data-entry efficiency.

2. Diagram your Operations: Map out the clinical tasks required, identify the roles responsible for each task, and determine data access restrictions for each role. A visual representation, such as a flow-chart, of your end-to-end clinical operations can be immensely beneficial.

3. Map out your Provider Organization: Have a keen understanding of the availability and qualifications of each provider to ensure availability and access to care.

4. Define the Encounter Model: In the digital age, redefining the patient encounter is crucial. Understand the mediums, methods, and tools at your disposal and craft a model that best serves your patients and practitioners alike.

Remember, in the rapidly evolving world of digital health, operations are more than just a behind-the-scenes affair. It's the backbone that defines patient experience and sets the stage for a future of healthcare that is efficient, effective, and truly global.

Those who have experienced the wait and shuffle of a specialist referral will appreciate the thoughtful and futuristic approach of the team at Titan Intake.

(5 minute demo)

Problem​

Continuity of care is broken because practices rely on fax and paper referral workflows to send patients to specialists. It is unrealistic to expect practices to change their systems, but patients need referrals and practices want to process them faster and capture all of the incoming clinical data without manual data entry.

Solution​

Titan provides a novel solution that leverages large language models (LLMs) to normalize unstructured referral data to FHIR, and gives practitioners and staff a button to synchronize data to their EHR (Cerner and others) via FHIR API. This saves manual work by staff and helps patients track the status of their referral. To lighten provider load, the Titan Intake app automatically synchronizes FHIR data to enable faster and more complete chart prepping.

In addition, as part of the intake process, Titan’s Natural Language Processing (NLP) engine detects and predicts the presence of Hierarchical Classification Codes and Elixhauser Comorbities to help both health systems and payors measure and receive reimbursement for the health of their patient populations. These are added to the FHIR Resources as CodableConcepts.

Medplum Solutions Used​

• Enterprise Master Patient Index (EMPI) - As part of their EMPI implementation Titan checks and deduplicates patients, to prevent the fear of hospital IT - that an integration will introduce duplicates into their system and disturb their reporting and workflow.
• Interoperability Service - From their web application, Titan triggers data synchronization into many downstream EHRs like Cerner, NextGen and others. This uses the Medplum integration engine a natively multi-tenant system that is very scalable and they serve many providers on the same technical stack.

Here is the full list of Medplum Solutions.

Challenges Faced​

• Extracting data from documents/PDFs and structuring the data as FHIR is a very difficult technical problem. The team employs use of LLMs and modern artificial intelligence techniques to structure and tag the data with code systems.

• Due to the nature of referrals, with a single patient being sent to many different institutions, duplicate Patient resources immediately become an issue. The team built a FHIR native Enterprise Master Patient Index and deduplication pipeline to support this use case.

• Synchronizing to many downstream EHRs, like Cerner and Epic on an event driven basis is difficult because each EHR has slightly different conventions and requirements to accept data.

Medplum Features Used​

• Bots and Automation - to enable the event driven connections between applications and EHRs
• FHIR Datastore - to store the data and manage the identities and deduplication
• Self Hosting - super admin features, and the ability to to manage tenants enables multi-institution access and connections

Related Reading​

• EMPI Implementation video
• Patient Deduplication Architectures
• Deduplication reference implementation code
• Case Study: Codex and the Power of the (g)(10)
• CodableConcepts in FHIR

One of the most frequent questions we get from our users is whether they should use Medplum's REST or GraphQL APIs. Both have a FHIR specification, but they offer different tradeoffs for different use cases.

In this post, we'll discuss these tradeoffs and provide some guidance on how you can choose which API is right for you.

GraphQL​

GraphQL has surged in popularity in recent years. You can try out FHIR graphql queries on your medplum project using our graphiql sandbox.

In the context of FHIR, one of GraphQL's strongest features is the ability to quickly retrieve multiple linked resources. While the REST API allows similar functionality using the _include and _revinclude search parameters, GraphQL offers a more natural syntax for querying bundles of resources that reference each other.

{
  Patient(id: "patient-id") {
    name {
      given
      family
    }
    address {
      line
      city
      state
      postalCode
    }
    # Get all DiagnosticReports related to this patient
    DiagnosticReportList(_reference: patient) {
      performer {
        reference
      }
      code {
        text
      }
      # Get all Observation resources
      # referenced by DiagnosticReport.result
      result {
        resource {
          ... on Observation {
            status
            code {
              text
            }
            valueQuantity {
              value
              unit
            }
          }
        }
      }
    }
  }
}

In addition, GraphQL also offers very fine grained control for developers to select the exact fields returned in a query, which can reduce your app's network traffic. Unlike the REST API, GraphQL lets you select specific fields, even in deeply nested elements, and provides additional filtering functionality through FHIR Path list filters. This is helpful in applications where bandwidth is at a premium, such as in mobile applications.

{
  Patient(id: "patient-id") {
    name {
      given
      family
    }
    address {
      line
      city
      state
      postalCode
    }
    # Filter the `telecom` field to only contain phone numbers
    telecom(system: "phone") {
      value
    }
  }
}

As with REST batch requests, GraphQL queries and mutations support the retrieval and modification of multiple resources in a single query, respectively.

{
  # Retrieve all Patients
  patients: PatientList(name: "Eve", address_city: "Philadelphia") {
    resourceType
    id
    name {
      family
      given
    }
    address {
      line
      city
      state
      postalCode
    }
  }
  # Retrieve all Medications
  medications: MedicationList {
    code {
      text
    }
  }
}

However, GraphQL does have some limitations. The FHIR GraphQL specification is under active development, but some parts have not yet reached maturity. For instance, its search specification isn't as detailed as its REST counterpart, though the _filter search parameter is available in both APIs. And FHIR GraphQL does not yet have a specification for PATCH operations, which limits its ability to make field-level updates to a resource.

Lastly, because shape of a GraphQL query's return value depends on the query itself, it's harder to use typescript type definitions from @medplum/fhirtypes to handle return values. Instead, users must defined custom types that match the shape of their query.

REST​

The FHIR REST API is the most common way to interact with FHIR-based systems on the market, and enjoys a broad base of support. While REST is an older technology, the FHIR REST API offers a few advantages.

First off, REST offers a relatively richer search specification out of the box, with support for search modifiers, iterated includes, and search result counts .

Moreover, REST supports HTTP PATCH operations, which allows clients to perform targeted, field-level resource updates. This capability is especially useful in high-concurrency environments, where many clients could be editing different parts of the same field.

// This call assigns the Task to the current user
// IF AND ONLY IF the the task has not been modified on the server
await medplum.patchResource('Task', task.id, [
  { op: 'test', path: '/meta/versionId', value: task.meta?.versionId },
  { op: 'replace', path: '/status', value: 'accepted' },
  { op: 'replace', path: '/owner', value: createReference(currentUser) },
]);

And while GraphQL mutations do allow writing multiple resources at once, using FHIR batch requests via the REST API offers more advanced batch writing functionality. The ifNoneExist element can be used to perform a search before creating a resource to prevent duplicate resource creation. Additionally, you can create collection of linked resources that reference each other using the urn:uuid syntax.

{
  resourceType: 'Bundle',
  type: 'batch',
  entry: [
    {
      fullUrl: 'urn:uuid:42316ff8-2714-4680-9980-f37a6d1a71bc',
      request: {
        method: 'POST',
        url: 'Practitioner',
        ifNoneExist: 'identifier=https://example.com|' + identifier,
      },
      resource: {
        resourceType: 'Practitioner',
        identifier: [{ system: 'https://example.com', value: identifier }],
      },
    },
    {
      request: { method: 'POST', url: 'ServiceRequest' },
      resource: {
        resourceType: 'ServiceRequest',
        status: 'active',
        intent: 'order',
        subject: createReference(patient),
        code: { coding: [{ system: 'http://loinc.org', code: '12345-6' }] },
        requester: { reference: 'urn:uuid:42316ff8-2714-4680-9980-f37a6d1a71bc' },
      },
    },
  ],
}

Lastly, there are additional APIs that are only available from REST, such as the resource history API, which returns a Bundle of all historical versions of a resource.

However, while REST has more powerful write and search functionality, it has some limitations on reads. You can use the special _elements search parameter to limit which fields in a resource are returned, but this can only be used to filter top-level fields. You cannot specify filter out nested subfields of a complex element.

Additionally, when requesting linked resources using _include and _revinclude with a FHIR search, the REST API will return a flat Bundle of resources. You will have to implement some additional logic in your client to connect linked resources with their base resource, where as GraphQL nests linked resources within their root resource.

Which One Should I Choose?​

So which should you choose? Your choice between REST and GraphQL will largely hinge on your specific use-case. Here are three potential paths to consider:

Both (recommended): For those not committed to a specific toolset, blending the best of both worlds is our recommended strategy. GraphQL is great for reading linked resources, and REST offers advanced write, batch, and history management functionality. Using the Medplum Client makes it easy to shift between these two query modalities, and it's what we used when building the Medplum App.

REST API: Using REST is our recommendation if your tasks involve complex searches or filters. Similarly, if you are performing queries that delve into resource history or necessitate targeted updates using PATCH, REST is the way to go. Lastly, REST is the de-facto standard when interacting with multiple FHIR systems.

GraphQL Only: This route may appeal to you if you have invested in building on top of GraphQL tooling such as Apollo. Additionally, if your operations are predominantly read-heavy and bandwidth is at a premium, GraphQL can give you fine-grained control over what is sent over the network.

The decision between REST and GraphQL isn't black and white, and each API offers its own tradeoffs. Medplum aims to offer developers the widest set of options so that they can hone in on the optimal tool for their needs.

As a long time YC community member (10+ years) and former Visiting Group Partner, I'm always excited by the great companies that release each Demo Day. For me, it's like the Superbowl 🏈.

Read our coverage on YC S23 Open Source Meetup and Medplum's YC Launch

YC Alumni Demo Day was this Saturday September 2, and I thought the presentations were particularly good. Here's some exciting nuggets we saw in the presentations in the Healthcare and Life Sciences category.

• Mantle Bio - Snowflake for Biotech - enormous data sets, complex algorithms, and a workforce filled with PhDs who have a lot of domain expertise but little exposure to data engineering make this a fertile area. Great to see an MIT team here as well.
• Flex - Stripe for HSA/FSA - accepting payments period in healthcare and HSA/FSA in particular requires so many special agreements and there is a ton of float out there. I could see specialized medical services being built around these balances. A team with strong infra chops and big tech background is great to see here too.
• Decoda - AI medical claims creation. Just Google CPT 99205 (outpatient evaluation and management of new patient) documentation and you'll see why it would be great to have AI do this.
• Shasta Health - AI Platform for physical therapists. Patients need PT before and after surgery and treatment in so many cases for health reasons and for payers. Having an AI guided workflow here seems so useful.
• Ohmic Biosiciences - Genetically engineering plants for alternative to roundup. Clear win to getting this to work! A team out of UCB, and reading their launch brought to mind the movie Interstellar.
• Olio Labs - Therapeutics for tough diseases. There's a lot of great properties of targeting tough diseases. Details are long, but a Startup and FDA article may be of interest.
• Flair health - Shopify for holistic primary care. It's just a matter of time before there is a huge direct-to-consumer health company the likes of the biggest companies in America, that's the opportunity.
• Feanix Biotech - genetic testing for animal (cow) breeding. Clear win getting this to work as well! Launch highlights a team at the intersection of big tech and agriculture.
• Health Harbor - Gen AI to "call insurance" for clinics. The phone, like fax, is a major channel for information exchange. I could see one angle where they payers also put a bot on the other side of the line.
• Obento Health - Patient engagement for private practice. Patient engagement at the right level is a perennial challenge at all levels. If it's cracked it is a big deal.
• Andromeda Surgical - autonomous surgical robots. Love the ambition and it would be a breakthrough as trained surgeons are so scarce. Clearly a team savvy about Startups and the FDA.
• Medisearch - trustworthy medical search. Healthcare is all about trust! Trust is the difference between gold and garbage in this industry. A trusted search engine has immense obvious value. A very technical team working on this.
• Sohar Health - AI driven clearinghouse for behavioral health. Access to behavioral health is a huge issue at the societal level. Godspeed.
• Sensible Biotech - mRNA synthesis for therapeutics and vaccines. We all know how powerful mRNA is. Exciting. Related: FDA Orientation for Startups.
• Wattson Health - Software for managing Rx and automate manual workflow. Healthcare + automation, love it. The quality monitoring benefit seems like a big deal as well. Demo gif tells a good story to those (like us at Medplum) in the industry.
• Healthtech 1 - Automating repetitive healthcare processes. After fighting our way through interop and "standard" interfaces, we at Medplum know how powerful and compelling RPA can be for practitioners. This is a case in point in solving a burning pain point for practitioners.
• Synaptic - AI powered training for doctors Well organized, high quality medical knowledge is a sleeper category. UpToDate is the Craigslist of this category and am excited about the future. Also cool to see an interdisciplinary MD + big tech team at work on this.
• Simbie - AI powered practice in a box for NPs in women's health. I could see myself as a customer of one of their customers.
• Cleancard - cancer screening as easy as pregnancy test. Clearly valuable and loved their launch. We at Medplum serve several at-home test providers as customers and at home diagnostics resonate a ton with patients. Related: How to start a Biotech on a budget,
• Nanograb - AI-generated binders for targeted drug delivery. Nothing close to an expert in this space, but am enthusiastic about the descriptive name of this company, and like that they have a neat domain. 70% of drug trials fail because the "grab" doesn't work (poor targeting).
• MICSI - Higher resolution MRI with faster scan times. MRI (and ultrasound) are really valuable tools, and see many wonderful applications of this technology. MICSI stands for microstructure imaging, and I could see this technology being able to read the mind.
• Certainly Health - Book doctors and avoid surprise bills. How much (and when) are two frequent unknowns in healthcare. Great to see a technocratic approach here from a technical team.
• Stellar Sleep - clinic for chronic insomnia. Great use case for a specialized provider, as insomnia really affects quality of life and the standard advice from GP is to reduce coffee intake, neglecting frequent related issues like anxiety, hormonal issues and more.
• Empirical Health - proactive primary care, scaled with AI. I love the name and the premise. Also, so exciting to see a team with a deep understanding of precision,recall and value based care in this space.
• Eden Care - Digital health insurance for employers in Africa. Not an expert, but we see a good amount of Medplum community activity in Africa, and am bullish about the opportunity in region.

A huge congrats to YC S23 on your Demo Day!