Designing for Doctors: A FHIR-Driven Approach to Patient Management That Clinicians Actually Use

Poornachandra Vivekanenda

Poornachandra Vivekanenda

Co-Founder and Product

What if your EHR could work with physicians, not against them? We reimagined patient management by pairing FHIR’s flexibility with intuitive UI. Built vendor-neutral from day one, it integrates effortlessly with any FHIR-compatible service, eliminating lock-in while giving doctors the simplicity they crave.

We are designing tools so seamless, physicians forget they’re using ‘tech’ and focus on what matters: care

#

Registration is the first touchpoint for a patient in the hospital, and so it is important to provide a quick and convenient experience. This would also improve patient flow or throughput.

We begin the Patient Registration workflow with a simple patient registration form. The search field on top allows searching for existing patients using UHID or phone number. If the patient exists, then details are filled in automatically and the receptionist is prompted to start a visit.

The patient is created by making a POST request to create a new FHIR Patient resource like below

{
  "id": "eddd292f-dfd4-4cf7-aa15-3838323645b9",
  "resourceType": "Patient",
  "meta": {
    "versionId": "eb5a1d92-a98f-4aa3-8e1c-ed1bd804116a",
    "lastUpdated": "2024-11-19T10:48:03.649Z"
  },
  "address": [
    {
      "text": "1 Polly Drummond Shopping Center ",
      "postalCode": "19711"
    }
  ],
  "birthDate": "1999-11-03",
  "gender": "male",
  "identifier": [
    {
      "system": "https://medblocks.com/fhir/aarthy_uid",
      "value": "AHMB003"
    }
  ],
  "name": [
    {
      "text": "Poornachandra Vivekananda"
    }
  ],
 "photo": [
    {
      "contentType": "image/jpeg",
      "url": "data:image/<image>””
}]
}

If the patient does not exist, the form can be used to register a new patient. All details except name, gender and age are optional. A picture of the patient can be easily captured using a web camera.

After registration, the next step is to create a visit. Each visit in FHIR corresponds to the Encounter resource where a visit is created with the Location where the encounter happens, Practitioner who is the care physician and Patient. The Encounter resource also allows us to track the time the patient waits at each location.

We use Encounter FHIR resource to tag the patient and start the visit

{
  "id": "f62c470c-d2a1-4038-9ecd-630d54d25ca0",
  "resourceType": "Encounter",
  "meta": {
    "versionId": "cbca8d41-e0d1-4783-97d9-fea4169734ae",
    "lastUpdated": "2025-01-21T16:03:30.497Z"
  },
  "status": "in-progress",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "AMB",
    "display": "Ambulatory"
  },
  "subject": {
    "type": "Patient",
    "reference": "Patient/eddd292f-dfd4-4cf7-aa15-3838323645b9"
  },
  "participant": [
    {
      "individual": {
        "display": "Dr. John Doe",
        "type": "Practitioner",
        "reference": "Practitioner/1427b07a-32ee-460b-aa84-3bbd9ae54261"
      }
    }
  ],
  "period": {
    "start": "2024-11-04T10:07:22.233Z"
  },
  "location": [
    {
      "location": {
        "reference": "Location/a1cd52d5-5d90-4e37-a971-8b94eda2de55",
        "display": "Doctors Chamber"
      }
    }
  ]
}

When deciding what goes on the Encounter details screen we were told that in previous software workflows, once registration is complete that context is lost. To avoid this, we included a small banner on top summarizing the patient's details.

You might have noticed that we store a few details in our FHIR resource a little differently than recommended. Let us explore the decisions we made. There are a few nuances involved here, particularly with respect to storing addresses, names and images of patients. Lets explore them below:

  1. The FHIR Address specification includes multiple elements to individually store various parts of an address.

We decided against storing address details in separate fields for two reasons:

  • Our use case didn’t require accessing individual parts of an address, and it would make processing harder later on. So, we store the address in its entirety as text and record only the postalCode separately.

  • Names can be stored by using different elements for family name, given name, prefix and suffix. When we built our FHIR server we had these fields included based on the specification. Names are stored in one single text field with the salutation such as “Mr” / “Mrs” / “Baby of” stored separately as a prefix.

  1. In the FHIR Patient resource, images are stored as a generic Attachment. This is possible in two ways - upload the image elsewhere and store the URL, or store the image directly as a base64 encoded value. We chose the latter option as it was simpler.

#

The next view we designed were Patient Lists, these are used to track patient visits and view patient details among other use cases.

FHIR’s Encounter resource can help hospitals track patient visits according to two key details:

  1. Physical location (e.g., ER, ward, clinic) updated by staff as patients move
  2. Primary physician assigned by the receptionist when the visit starts

By organizing this data in FHIR, hospitals can generate real-time patient lists filtered by location, doctor, or visit status (e.g., "in-progress" or "completed"). This ensures care teams always see who is where and under whose responsibility.

This is what most practitioners see when they use our platform.

Sometimes physicians want to create ad hoc lists during the day to track patients of interest to them for later discussions. This means that we need to be able to tag patients when a doctor chooses them. We wanted this type of list to resemble the existing lists to reduce the cognitive overload of clinicians.

#

We wanted the method of creating lists to be super simple and intuitive. On clicking the plus icon on the top a menu opens up with options on the type of list that needs to be created.

There are two types of lists that can be created:

  1. Static lists - these are custom lists into which patients are added manually - for example “patients with special diets” or “patients for feedback collection”
  2. FHIR lists - these are standard patient visit lists with details such as care physician, location and type of visit. FHIR list creation requires a name and a FHIR query to apply to the encounter resource

Now let’s look at the workflows for interacting with these lists.

#

All the data for FHIR lists comes from querying FHIR resources such as Patient and Encounter, so there is no manual way to add patients to a FHIR list.

A doctor can use the ‘Transfer’ option to move the patient between lists for location or care physician based on requirement.

Using the transfer function modifies the location or the participant field in the Encounter FHIR resource by using a PUT request with the modified resource.

Lets look at some examples of common use cases for FHIR based lists:

  1. Visualizing encounters currently in-progress The parameter for the FHIR query when created then becomes
status=in-progress
  1. Visualizing encounters that are at a particular location
status=in-progress&location=7e4f8312-1519-49be-a948-7a879c9374f1

Where the location value corresponds to the Location ID

  1. Show a list of all visits today
period={{today}}

We also support a list of custom variables in all queries to add more relevant context to the queries.

The queries get added as a query as a part of the POST Bundle Request

{
  "resourceType": "Bundle",
  "type": "batch",
  "entry": [
    {
      "request": {
        "method": "GET",
        "url": "Encounter?status=in-progress”
      }
    }
  ]
}

#

We implemented Custom Lists to allow practitioners to create lists as need arose without it being bound to the FHIR paradigm. The workflow for each custom list was planned out in detail to keep the experience as close as possible to the existing FHIR lists.

The first workflow for adding a patient to a list involved the following steps - Click the three dots next to the visit -> Choose ‘Add or remove patient’ -> Check the lists you want patients to be added to -> Click on save

This was deployed at all our sites. In a feedback session we were told that adding patients to the list involved too many clicks. So we decided that selecting a list in the menu should automatically save without an additional click.

This approach worked, however the practitioners received no feedback on whether the patient was truly added to the list. To help with that we added direct feedback when the checkbox was selected.

Our initial goal was to build a UI that doctors like to use without strain and use FHIR underneath so that it can use any FHIR compatible service when necessary without vendor lock-in. This meant that at each step of the workflow, we considered the design and doctor-friendliness of each screen, along with how it would map to and interact with FHIR Resources. Spending time on patient registration, visit creation and patient lists tackles some of the most important aspects of patient management in the hospital - reducing provider effort and improving experience.

Through careful consideration, the outcome we achieved is a flexible system that aligns with hospital processes, demonstrating how vendor-neutral APIs and user-centered design collectively enhance care delivery.

If you find what we are working on interesting and want to work together, click here

Save lives with digital healthcare innovation
© 2024 Mediblocks. All rights reserved.