DEV Community: Paul Aderoju

Setting Up a Managed FHIR Server on AWS Using AWS HealthLake

Paul Aderoju — Sun, 08 Mar 2026 14:19:48 +0000

Introduction

Setting up a FHIR server from scratch is no small feat. The traditional route means provisioning backend infrastructure, configuring a database, building a CI/CD pipeline, managing server patches, and locking down networking with subnets, security groups, and ACLs — and that's before you've written a single line of application code.

AWS HealthLake cuts through all of that. It's a fully managed, HIPAA-eligible service that gives you a production-grade FHIR R4 repository without the operational overhead. In this guide, you'll learn how to spin one up, connect to it, and start working with real patient data using Postman — then see how to wire it into a live application.

Why HealthLake?

Fully managed FHIR R4 infrastructure — no servers to patch or scale
HIPAA-eligible with built-in encryption and access controls
Sub-millisecond latency at petabyte scale
SMART on FHIR support for standards-based authentication and authorization
Automatic export to Apache Iceberg for SQL-on-FHIR analytics
Built-in NLP to extract clinical context from unstructured medical text

Part 1: Provisioning Your HealthLake Data Store

Step 1 — Navigate to AWS HealthLake

Log in to your AWS Management Console and use the search bar at the top to search for HealthLake. Click on the AWS HealthLake result to open the service dashboard.

Step 2 — Open the Data Stores Panel

On the HealthLake landing page, click View Data Stores (or Create Data Store if you're starting fresh). This is your central hub for managing FHIR repositories.

Step 3 — Create a New Data Store

Click Create Data Store and fill in the configuration:

Data Store Name: Give it a meaningful name, e.g. my-fhir-app
Format: Select FHIR R4. This is the data schema all your FHIR resources will conform to.
Preload Sample Data (Optional): If you'd like to explore the service with synthetic patient data right away, enable this. The data is generated by Synthea — a realistic but fictional patient population. Note: enabling this adds 10–20 minutes to initialization time.

Step 4 — Configure Encryption

Under Data Store encryption, you have two options:

AWS Owned Key (Default): AWS manages the key on your behalf. This is the quickest option and appropriate for most use cases.
Customer Managed Key (Advanced): Bring your own AWS KMS key if your compliance requirements demand it. This gives you full key lifecycle control.

Tip: For most development and production workloads, the AWS-owned key is sufficient. Use a customer-managed key only if your security policy requires explicit key rotation or audit trails.

Step 5 — Add Tags (Optional)

Tags are key-value metadata labels, useful for cost allocation, access policies, and resource organization — for example Environment: production or Team: clinical-apps. Skip this for quick experiments.

Step 6 — Create and Wait

Click Create Data Store. Provisioning typically takes between 10 and 30 minutes. The status will show as Creating during this time.

Note: HealthLake is spinning up dedicated infrastructure for your FHIR repository. You can stay on the Data Stores page and refresh periodically to check progress.

Step 7 — Copy Your Endpoint

Once the status changes to Active, open the data store details. You'll see:

Data Store ID
ARN (Amazon Resource Name)
Endpoint — this is the FHIR base URL you'll use for all API calls

Copy the endpoint. It will look something like this:

https://healthlake.us-east-1.amazonaws.com/datastore/<YOUR_DATASTORE_ID>/r4/

Part 2: Testing Your FHIR Endpoint with Postman

Before wiring HealthLake into your application, it's good practice to validate the endpoint manually. Postman is ideal for this — it supports AWS Signature V4 authentication out of the box, which HealthLake requires.

Authentication: AWS Signature V4

HealthLake uses IAM-based authentication. Every request must be signed using AWS Signature V4. In Postman, this is handled automatically once configured.

Open the Authorization tab in your Postman request and set the following:

Field	Value
Auth Type	AWS Signature
AccessKey	Your IAM Access Key ID
SecretKey	Your IAM Secret Access Key
AWS Region	`us-east-1` (or your deployment region)
Service Name	`healthlake`

IAM: Make sure the IAM identity you're using has the AmazonHealthLakeFullAccess policy attached, or at minimum the healthlake:CreateResource and healthlake:ReadResource actions scoped to your data store's ARN.

Creating a Patient Resource (POST)

Set up your Postman request as follows:

Method: POST
URL: https://healthlake.us-east-1.amazonaws.com/datastore/<YOUR_DATASTORE_ID>/r4/Patient
Headers: Content-Type: application/json
Body: Raw JSON

{
  "resourceType": "Patient",
  "id": "example-patient-1",
  "name": [{
    "use": "official",
    "family": "Doe",
    "given": ["John"]
  }],
  "gender": "male",
  "birthDate": "1990-05-15",
  "telecom": [{
    "system": "phone",
    "value": "+2348012345678",
    "use": "mobile"
  }],
  "address": [{
    "city": "Lagos",
    "country": "Nigeria"
  }]
}

Hit Send. A successful response returns HTTP 201 Created with the full resource body, including a server-generated UUID as the resource ID and a meta.lastUpdated timestamp — confirming your record was persisted.

Reading a Patient Resource (GET)

To retrieve the patient you just created, use the resource ID from the 201 response:

GET .../r4/Patient/<RESOURCE_ID>

You can also search across all patients using query parameters:

# Search by family name
GET .../r4/Patient?family=Doe

# Search by birthdate
GET .../r4/Patient?birthdate=1990-05-15

# Get all patients (paginated)
GET .../r4/Patient

Updating a Patient Resource (PUT)

To update an existing patient, use a PUT request with the full updated resource body:

PUT .../r4/Patient/<RESOURCE_ID>

HealthLake performs a full replace — not a partial update. For partial updates, use the PATCH method with a FHIR Patch document.

Deleting a Resource (DELETE)

DELETE .../r4/Patient/<RESOURCE_ID>

Note: HealthLake soft-deletes resources by default — they're marked as deleted but remain in the audit trail. This supports HIPAA compliance requirements around data retention and auditability.

Part 3: Using HealthLake in a Live Application

Now that you've confirmed the endpoint works, let's integrate HealthLake into a real application. We'll use Node.js with the AWS SDK v3, which handles Signature V4 signing automatically.

Setup: Install Dependencies

npm install @aws-sdk/client-healthlake
npm install @aws-sdk/signature-v4
npm install axios
npm install @aws-sdk/credential-provider-node

Initializing the AWS HTTP Client with SigV4 Signing

Rather than using the HealthLake SDK client (which has limited FHIR-specific support), the recommended approach is to sign requests manually using the AWS HTTP signing library, then use any HTTP client to call the endpoint directly.

const { SignatureV4 } = require('@aws-sdk/signature-v4');
const { defaultProvider } = require('@aws-sdk/credential-provider-node');
const { Sha256 } = require('@aws-crypto/sha256-js');
const axios = require('axios');

const REGION = 'us-east-1';
const DATASTORE_ID = process.env.HEALTHLAKE_DATASTORE_ID;
const BASE_URL = `https://healthlake.${REGION}.amazonaws.com/datastore/${DATASTORE_ID}/r4`;

async function signedRequest(method, path, body = null) {
  const credentials = await defaultProvider()();
  const signer = new SignatureV4({
    credentials,
    region: REGION,
    service: 'healthlake',
    sha256: Sha256
  });

  const url = new URL(`${BASE_URL}${path}`);
  const request = {
    method,
    hostname: url.hostname,
    path: url.pathname + url.search,
    headers: {
      host: url.hostname,
      'content-type': 'application/json',
    },
    body: body ? JSON.stringify(body) : undefined
  };

  const signed = await signer.sign(request);
  return axios({
    method,
    url: url.toString(),
    headers: signed.headers,
    data: body
  });
}

Creating a Patient from Your App

async function createPatient(patientData) {
  const response = await signedRequest('POST', '/Patient', patientData);
  console.log('Created patient:', response.data.id);
  return response.data;
}

// Usage
createPatient({
  resourceType: 'Patient',
  name: [{ use: 'official', family: 'Adeyemi', given: ['Amara'] }],
  gender: 'female',
  birthDate: '1988-03-22',
  address: [{ city: 'Abuja', country: 'Nigeria' }]
});

Searching for Patients

async function searchPatients(params) {
  const query = new URLSearchParams(params).toString();
  const response = await signedRequest('GET', `/Patient?${query}`);
  const bundle = response.data;
  console.log(`Found ${bundle.total} patients`);
  return bundle.entry?.map(e => e.resource) ?? [];
}

// Search by name
const patients = await searchPatients({ family: 'Adeyemi' });

Environment Configuration

Store your configuration in environment variables — never hardcode credentials:

# .env
AWS_REGION=us-east-1
AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
HEALTHLAKE_DATASTORE_ID=your_datastore_id

Security: In production, use IAM roles attached to your EC2/ECS/Lambda instance instead of static credentials. This avoids storing secrets entirely and is the AWS-recommended approach.

Production Best Practices

IAM Least Privilege

Create a dedicated IAM role for your application with only the HealthLake permissions it needs. Avoid attaching broad policies like AdministratorAccess.

Error Handling

HealthLake returns standard FHIR OperationOutcome resources on errors. Parse these to surface meaningful messages to your logs:

try {
  const result = await signedRequest('POST', '/Patient', patient);
} catch (err) {
  if (err.response?.data?.resourceType === 'OperationOutcome') {
    const issues = err.response.data.issue;
    issues.forEach(i => console.error(`[${i.severity}] ${i.diagnostics}`));
  }
}

SMART on FHIR for Multi-Tenant Apps

If you're building a patient-facing or clinician-facing application that needs OAuth2-based access control, HealthLake supports SMART on FHIR. This lets you scope access tokens to specific patients, resource types, and operations — a key requirement for EHR integrations.

Wrapping Up

AWS HealthLake removes the infrastructure complexity from FHIR development. Instead of managing servers, databases, and networking, you can focus on building healthcare applications that matter.

Here's a recap of what you've covered:

Provisioned a fully managed FHIR R4 data store on AWS HealthLake
Configured AWS Signature V4 authentication in Postman
Created, read, updated, and deleted FHIR Patient resources via REST
Integrated the HealthLake endpoint into a Node.js application
Applied security and production best practices

From here, you can explore other FHIR resource types — Observation, Encounter, Condition, MedicationRequest — and start building out a full clinical data platform, all without a single server to manage.

Understanding FHIR Data Types

Paul Aderoju — Tue, 16 Dec 2025 21:29:37 +0000

FHIR (Fast Healthcare Interoperability Resources) has revolutionized how healthcare data is exchanged between systems. Over the last decade, it has evolved from a nascent standard into the global language of health informatics.

The power of FHIR lies in its Resource-Based Model, which breaks down complex medical records into modular, reusable building blocks like Patient, Observation, and Medication. By leveraging a RESTful API architecture and modern data formats like JSON, FHIR ensures that health data is not just portable, but developer-friendly.

However, to truly master FHIR, you must understand the "DNA" of these resources: Data Types.

The 5 Categories of FHIR Data Types

Every resource is a collection of elements, and every element is defined by a data type. These are categorized into five distinct layers:

Category	Description	Examples
1. Base Types	The abstract foundation. Every FHIR type inherits from the Base class.	`Base`, `Element`
2. Primitive Types	Single elements representing a single value (strings, numbers, dates).	`boolean`, `string`, `dateTime`
3. General Purpose	Complex, reusable clusters representing common healthcare concepts.	`HumanName`, `Address`, `Quantity`
4. Metadata Types	Types used to define "data about the data" for searching and cataloging.	`ContactDetail`, `UsageContext`
5. Special Purpose	Specialized structures for specific technical usage within the spec.	`Reference`, `Extension`, `Narrative`

Why Data Types Matter

Understanding these types is critical because FHIR is strictly typed. If a system expects a Quantity (which includes a value and a unit) and you send a simple integer, the exchange will fail. By mastering these categories, you ensure that your healthcare applications are not only interoperable but also robust and compliant with global standards.

Case Study: The Patient Resource

Let's look at a sample Patient resource to see these types in action.

{
  "resourceType": "Patient",
  "id": "example-patient-001",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2024-12-16T10:30:00Z",
    "profile": ["http://hl7.org/fhir/StructureDefinition/Patient"]
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">John Doe, Male, DOB: 1990-05-15</div>"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
      "valueAddress": {
        "city": "Lagos",
        "country": "Nigeria"
      }
    }
  ],
  "identifier": [
    {
      "use": "official",
      "system": "http://hospital.example.org/patients",
      "value": "MRN-123456"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "family": "Doe",
      "given": ["John", "Michael"]
    }
  ],
  "gender": "male",
  "birthDate": "1990-05-15",
  "_birthDate": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/patient-birthTime",
        "valueDateTime": "1990-05-15T14:30:00+01:00"
      }
    ]
  }
}

Let's Dive into the Data Types

1. Primitive Types (Simple Values)

String: A sequence of Unicode characters (Max 1MB).
Boolean: Strict true or false.
Code: A string from a controlled vocabulary (e.g., gender: "male").
DateTime vs. Instant: * DateTime: For human events (can be partial, like just a year).
- Instant: A precise UTC timestamp for system events (e.g., lastUpdated).
Uri/Url/Canonical: Used for naming systems, external links, and referencing other profiles.

2. Complex Types (Composite Structures)

Identifier: Used for MRNs, SSNs, or Driver’s Licenses. It pairs a system (the namespace) with a value.
HumanName: Handles the complexity of global naming (prefixes, suffixes, multiple given names).
CodeableConcept: The powerhouse of FHIR. It allows you to send a code from a system (like LOINC or SNOMED) along with the original text description.
Period: A simple range with a start and an optional end.

3. Special Purpose Types

Extension: FHIR's primary growth mechanism. Since no standard can cover every clinical edge case, extensions allow you to add custom data (like birthPlace) while remaining compliant.
Narrative (text): Provides a human-readable XHTML summary so that even if a system doesn't "understand" the structured data, a clinician can still read the record.

Key Takeaways for Developers

Type Reusability: Notice how Period is used for names, identifiers, and addresses. Once you learn the structure of a Period, you know it everywhere.
The Underscore Pattern: If you see an element like _birthDate, it means an Extension is being applied to a Primitive type.
Strict Cardinality: Pay attention to arrays []. Many FHIR elements (like name or identifier) allow multiple entries to handle real-world complexity.

The beauty of FHIR's type system is that once you learn these ~30 datatypes, you can understand ANY FHIR resource. Whether you are looking at a Patient, an Observation, or a MedicationRequest, they are all built from these same consistent blocks.

Building a FHIR-Enabled Patient Portal with Next.js 16 (Step-by-Step Guide)

Paul Aderoju — Tue, 02 Dec 2025 11:58:58 +0000

In my previous article, I introduced FHIR (Fast Healthcare Interoperability Resources)—the modern, API-first standard that is transforming how developers interact with healthcare data. FHIR is not just another healthcare protocol; it is a REST-driven ecosystem that uses JSON, structured resources, and predictable endpoints.

This modern approach allows developers to build healthcare applications using familiar web technologies while maintaining strict healthcare data standards.

Today, we’ll take a practical deep dive into FHIR by building a real-world project: a FHIR-enabled patient portal.

We’ll use:

Next.js 16 (App Router)
TypeScript
HAPI FHIR Public Test Server (R4)
REST-based FHIR APIs
FHIR Patient & Practitioner resources

By the end of this tutorial, you will be able to:

Understand FHIR resource structures
Call real FHIR APIs
Search, paginate, and view Patient and Practitioner data
Build a reusable service layer
Display structured healthcare data using modern web UI
Work with FHIR Bundles, metadata, and search parameters

🔗 GitHub Repository (Full Project Source Code)

You can explore or clone the complete project here:

https://github.com/PaulBoye-py/fhir-tutorials

1. What We’re Building

We will build a simple yet realistic patient portal with:

Patient Search
Patient List Page
Patient Detail Page
Practitioner Search
Practitioner Detail Page
Pagination via FHIR _count and _offset
Clean service layer with reusable API logic
Structured healthcare UI

This structure mirrors real-world EHR interfaces and is an ideal foundation for:

Telemedicine apps
EHR integration layers
Health dashboards
Clinical note systems
Medical analytics apps

2. Understanding FHIR Resources

2.1 What Is a FHIR Resource?

A FHIR Resource is the core building block of the FHIR standard.

Every piece of healthcare information—patients, practitioners, encounters, medications, observations—is represented as a resource.

Characteristics of FHIR resources:

Modular
JSON or XML format
REST-accessible
Self-describing
Extensible
Standardized

Almost all resources share:

{
  "resourceType": "Patient",
  "id": "123",
  "meta": { ... }
}

FHIR is RESTful:

GET /Patient/123
POST /Patient
PUT /Patient/123
DELETE /Patient/123

Search is simple:

/Patient?name=John
/Patient?phone=08012345678
/Practitioner?identifier=12345

2.2 Understanding the FHIR Patient Resource

FHIR defines the Patient resource as:

“Demographics and administrative information about an individual receiving care.”

Key fields:

Field	Description
`identifier`	MRN, NIN, hospital numbers
`active`	Indicates if record is active
`name`	Array of names (given, family, prefixes)
`telecom`	Phones and emails
`gender`	male, female, other, unknown
`birthDate`	Date of birth
`address`	Multiple structured addresses
`contact`	Next of kin / guardian
`photo`	Patient picture
`managingOrganization`	Linked facility

Why arrays?

Healthcare data is complex. A patient can have:

Multiple names (maiden name, legal name)
Multiple phones (home, work, mobile)
Multiple addresses

Patient JSON Example

{
  "resourceType": "Patient",
  "id": "123",
  "active": true,
  "name": [
    {
      "family": "Doe",
      "given": ["John"],
      "use": "official"
    }
  ],
  "telecom": [
    {
      "system": "phone",
      "value": "08012345678"
    }
  ],
  "gender": "male",
  "birthDate": "1990-01-01"
}

2.3 Understanding the FHIR Practitioner Resource

A Practitioner represents the person providing care.

Key fields:

identifier — license number, certifications
name — same structure as Patient
telecom
address
qualification — degrees, certifications
active

Practitioner vs PractitionerRole

Resource	Meaning
Practitioner	The actual person (identity, demographics)
PractitionerRole	Their job role, specialty, and organization

A practitioner can have many roles — e.g., Consultant Surgeon at Hospital A, Visiting Specialist at Clinic B.

3. Setting Up the Next.js Project

Run:

npx create-next-app@latest fhir-patient-portal
cd fhir-patient-portal
npm install axios

Create .env.local:

NEXT_PUBLIC_FHIR_BASE_URL=https://hapi.fhir.org/baseR4

4. Building the FHIR Service Layer

We separate API logic from UI logic.

Create:

services/
  patientService.ts
  practitionerService.ts

4.1 Patient Service

import axios from 'axios';

const baseUrl = `${process.env.NEXT_PUBLIC_FHIR_BASE_URL}/Patient`;

const fhirApi = axios.create({ baseURL: baseUrl, headers: {
    'Cache-Control' : 'no-cache',
} });

const isPhoneNumber = (searchTerm: string) => {
  if (parseInt(searchTerm)) {
    return true
  }
  return false
}

const getAll = async (page: number, searchTerm: string | undefined) => {
  let searchParams: {
    phone?: string | undefined,
    name?: string | undefined,
  } = {};

  if (searchTerm) {
    if (isPhoneNumber(searchTerm)) {
      searchParams.phone = searchTerm;
    } else {
      searchParams.name = searchTerm;
    }
  }

  try {
    // First request: Get total count
    const countResponse = await fhirApi.get('', { 
      params: {
        _summary: 'count',
        ...searchParams,
      }
    });

    const totalCount = countResponse.data?.total || 0;

    // Second request: Get actual patient data
    const dataResponse = await fhirApi.get('', { 
      params: {
        _count: 15,
        _offset: (page - 1) * 15, // Convert 1-based page to 0-based offset
        ...searchParams,
      }
    });

    if (dataResponse.headers['content-type']?.includes('application/fhir+json')) {
      console.log('FHIR Response:', dataResponse.data);
      console.log('Total Count:', totalCount);

      // Merge the total count into the data response
      return {
        ...dataResponse.data,
        total: totalCount,
      };
    } else {
      console.error('Unexpected response format:', dataResponse.data);
      return null;
    }
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error fetching patients:', message);
    throw error;
  }
};

const getPatient = async (id : any) => {
  try {
    const response = await fhirApi.get(`/${id}`);
    return response.data; // return the patient data from the response
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error fetching patient:', message);
  }
};

const updatePatient = async (id: any, updatedPatient: object) => {
  try {
    const response = await fhirApi.put(`/${id}`, updatedPatient);
    return response.data; // Return the updated patient data
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error updating patient:', message);
    throw error;
  }
};

const createNew = async (patientData: object) => {
  try {
    const response = await fhirApi.post('', patientData); 
    return response.data; // Return the created patient data
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error creating patient:', message);
    throw error;
  }
};

// Correct export statement
const patientService = {
    getAll,
    getPatient,
    updatePatient,
    createNew,
  };

  export default patientService;

4.2 Practitioner Service

import axios from 'axios';
import { Practitioner, Bundle } from '@/types/fhir';

const baseUrl = `${process.env.NEXT_PUBLIC_FHIR_BASE_URL}/Practitioner`;

const fhirApi = axios.create({
  baseURL: baseUrl,
  headers: {
    'Cache-Control': 'no-cache',
    'Accept': 'application/fhir+json',
  },
});

const isPhoneNumber = (searchTerm: string) => {
  return /^\d+$/.test(searchTerm);
};

const getAll = async (page: number, searchTerm: string | undefined) => {
  let searchParams: {
    phone?: string | undefined,
    name?: string | undefined,
  } = {};

  if (searchTerm) {
    if (isPhoneNumber(searchTerm)) {
      searchParams.phone = searchTerm;
    } else {
      searchParams.name = searchTerm;
    }
  }

  try {
    // First request: Get total count
    const countResponse = await fhirApi.get('', { 
      params: {
        _summary: 'count',
        ...searchParams,
      }
    });

    const totalCount = countResponse.data?.total || 0;

    // Second request: Get actual patient data
    const dataResponse = await fhirApi.get('', { 
      params: {
        _count: 15,
        _offset: (page - 1) * 15, // Convert 1-based page to 0-based offset
        ...searchParams,
      }
    });

    if (dataResponse.headers['content-type']?.includes('application/fhir+json')) {
      console.log('FHIR Response:', dataResponse.data);
      console.log('Total Count:', totalCount);

      // Merge the total count into the data response
      return {
        ...dataResponse.data,
        total: totalCount,
      };
    } else {
      console.error('Unexpected response format:', dataResponse.data);
      return null;
    }
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error fetching practitioners:', message);
    throw error;
  }
};

const getPractitioner = async (id: string): Promise<Practitioner | null> => {
  try {
    const response = await fhirApi.get<Practitioner>(`/${id}`);
    return response.data;
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error fetching practitioner:', message);
    throw error;
  }
};

const updatePractitioner = async (id: string, updatedPractitioner: Practitioner): Promise<Practitioner | null> => {
  try {
    const response = await fhirApi.put<Practitioner>(`/${id}`, updatedPractitioner);
    return response.data;
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error updating practitioner:', message);
    throw error;
  }
};

const createNew = async (practitionerData: Practitioner): Promise<Practitioner | null> => {
  try {
    const response = await fhirApi.post<Practitioner>('', practitionerData);
    return response.data;
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error('Error creating practitioner:', message);
    throw error;
  }
};

const practitionerService = {
  getAll,
  getPractitioner,
  updatePractitioner,
  createNew,
};

export default practitionerService;

5. Building the Patient Search Page

File: app/patients/page.tsx

This page:

Accepts a search input
Displays results
Uses pagination
Links to patient detail pages

Snippet:

{data?.entry?.map((e) => {
  const p = e.resource;
  return (
    <Link href={`/patients/${p.id}`} key={p.id}>
      <div>
        {p.name?.[0]?.given?.join(" ")} {p.name?.[0]?.family}
      </div>
    </Link>
  );
})}

6. Patient Detail Page

File: app/patients/[id]/page.tsx

Shows:

Name
Gender
Birth date
Contact
Identifiers
Addresses

{/* Demographics Section */}
          <div className="bg-white rounded-lg border border-gray-200 p-4 md:p-6 shadow-sm">
            <h2 className="text-lg md:text-xl font-semibold mb-4 pb-2 border-b border-gray-200 text-gray-900">
              Demographics
            </h2>
            <div className="grid sm:grid-cols-2 gap-4">
              <div>
                <div className="text-sm font-medium text-gray-500 mb-1">Gender</div>
                <div className="text-gray-900 capitalize">{patient.gender || 'Unknown'}</div>
              </div>
              <div>
                <div className="text-sm font-medium text-gray-500 mb-1">Birth Date</div>
                <div className="text-gray-900">{formatDate(patient.birthDate)}</div>
              </div>
              {patient.maritalStatus && (
                <div>
                  <div className="text-sm font-medium text-gray-500 mb-1">Marital Status</div>
                  <div className="text-gray-900">
                    {patient.maritalStatus.text || patient.maritalStatus.coding?.[0]?.display || 'N/A'}
                  </div>
                </div>
              )}
            </div>
          </div>

7. Practitioner Search Page

Same structure as patient search but with additional fields:

Qualifications
Specialties
Practice locations

8. Practitioner Detail Page

Display:

Full name
Contact
Gender
Qualifications
Practice addresses

Example FHIR qualification:

{
  "qualification": [
    {
      "code": { "text": "MBBS" },
      "period": { "start": "2012-01-01" }
    }
  ]
}

9. Layout & Navigation

Add a simple navigation bar:

<nav className="p-4 border-b flex gap-4">
  <Link href="/patients">Patients</Link>
  <Link href="/practitioners">Practitioners</Link>
</nav>

10. Understanding FHIR Bundles

FHIR search returns a Bundle:

{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 150,
  "entry": [...]
}

Fields:

Field	Meaning
`total`	Total matches
`entry`	Actual resources
`link`	Pagination links

11. Testing With HAPI FHIR Server

Examples:

/Patient?_count=10
/Patient?name=smith
/Practitioner?phone=0803...

Limitations:

Data resets
Some resources incomplete
Occasional slowness

12. Best Practices

Validate resourceType
Handle optional fields
Use TypeScript models
Cache data when possible
You can use SMART on FHIR to add a layer of authentication
Avoid excessive API calls. You'll get rate-limited if this happens.

Useful Links

FHIR R4 Spec → https://build.fhir.org
HAPI FHIR → https://hapi.fhir.org
Full Project Source Code: https://github.com/PaulBoye-py/fhir-tutorials
Live Deployment: https://fhir-tutorials.vercel.app

13. Conclusion

In this article, we built a functional patient portal powered by FHIR and Next.js—with real-time access to Patient and Practitioner data.

You learned:

How FHIR structures healthcare data
How to build reusable services in Next.js
How to fetch and display Patient and Practitioner data
How to handle FHIR Bundles and pagination
How to implement dynamic routes and detail pages

FHIR is a powerful standard, and this project is just the beginning.
You can easily expand this into a complete EHR frontend or a telemedicine dashboard.

If you build something with this tutorial, I’d love to see it—tag me here and on LinkedIn or share your implementation!

Healthcare Data Interoperability and FHIR: A Developer's Guide

Paul Aderoju — Mon, 17 Nov 2025 17:46:40 +0000

Healthcare technology is experiencing a revolution, and at its core is a challenge that affects millions of patients daily: getting different systems to talk to each other. In this article, I will explain what healthcare data interoperability is, and how FHIR is changing the game.

What is Healthcare Data Interoperability?

Healthcare data interoperability is the ability of different healthcare information systems, applications, and devices to exchange, access, and use patient data seamlessly—regardless of the vendor or platform. You can think of it as creating a common language that allows your doctor's EHR (Electronic Health Record) system, the hospital's imaging system, your pharmacy's software, and even your fitness tracker to share information accurately and securely.

There are typically four levels of interoperability:

Foundational: Basic data exchange between systems;
Structural: Data format and syntax standards (like using XML or JSON);
Semantic: Shared understanding of data meaning (what does "blood pressure" mean across systems?);
Organizational: Governance, policies, and workflows that enable data sharing.

Why Is Healthcare Data Interoperability Critical?

The lack of interoperability has real-world consequences:

1. Patient Safety

When a patient visits a new specialist, that doctor needs complete medical history. Without interoperability, crucial information about allergies, current medications, or past procedures might be missing, potentially leading to dangerous drug interactions or duplicate tests.

2. Care Coordination

Imagine a diabetic patient who sees an endocrinologist, a primary care physician, and a nutritionist. Without data sharing, each provider works with incomplete information, leading to fragmented care and poor outcomes.

3. Cost Reduction

Healthcare systems worldwide lose billions of dollars annually due to duplicate tests, administrative inefficiencies, and medical errors—many stemming from poor interoperability. When systems can share data automatically, it eliminates redundant work.

4. Patient Empowerment

Patients should own their health data. Interoperability enables individuals to access their complete medical records, share them with providers of their choice, and use health apps that provide personalized insights.

5. Research and Public Health

During the COVID-19 pandemic, the ability to aggregate and analyze health data quickly became critical. Interoperability enables population health monitoring, disease outbreak tracking, and clinical research at scale.

Healthcare Data Standards

Before FHIR became prominent, several standards attempted to solve interoperability:

HL7 v2

Introduced in the 1980s, HL7 Version 2 is still widely used for messaging between hospital systems. It uses a pipe-delimited format that's efficient but challenging to parse and implement. Each organization often creates custom variations, leading to "interoperability" that requires significant customization.

MSH|^~\&|SendingApp|SendingFac|ReceivingApp|ReceivingFac|20240101120000||ADT^A01|MSG123|P|2.5
PID|1||12345^^^Hospital^MRN||Doe^John^A||19800101|M|||123 Main St^^Boston^MA^02101

HL7 v3 and CDA

HL7 Version 3 attempted to create a more rigorous, model-driven standard, while Clinical Document Architecture (CDA) focused on structured clinical documents. Both use XML extensively and are highly detailed—sometimes too detailed—making implementation complex and heavyweight.

DICOM

The Digital Imaging and Communications in Medicine (DICOM) standard is the gold standard for medical imaging. It handles everything from CT scans to ultrasounds but is specialized for imaging data rather than general healthcare information.

X12

Used primarily for administrative and financial healthcare transactions like insurance claims, eligibility verification, and remittance advice.

What Makes FHIR Unique?

Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") is a next-generation standard developed by HL7 that takes a radically different approach:

1. RESTful API Architecture

FHIR embraces modern web standards. It's built on REST APIs using HTTP verbs (GET, POST, PUT, DELETE) that any web developer immediately understands. No special healthcare protocol knowledge required to get started.

// Get a patient's data
GET https://fhir.example.com/Patient/123

// Search for observations
GET https://fhir.example.com/Observation?patient=123&code=55284-4

2. Resource-Based Model

FHIR breaks health data into modular, reusable "resources" like Patient, Observation, Medication, Encounter, etc. Each resource has a clear structure and can be used independently or linked together. This modularity means you only implement what you need.

{
  "resourceType": "Patient",
  "id": "123",
  "name": [{
    "use": "official",
    "family": "Doe",
    "given": ["John", "A"]
  }],
  "birthDate": "1980-01-01",
  "gender": "male"
}

3. Modern Data Formats

FHIR supports both JSON and XML, but JSON is the primary format—making it instantly accessible to modern developers. No more wrestling with complex XML schemas.

4. Extensibility

FHIR allows extensions for use cases not covered by the base standard. Healthcare organizations can add custom fields while maintaining core compatibility, solving the customization problem that plagued HL7 v2.

5. Implementation Guides

FHIR uses "Implementation Guides" (IGs) that provide specific profiles for particular use cases—like US Core for American healthcare, or specific guides for pediatrics, genomics, or clinical research. This balances flexibility with standardization.

6. Built for the Web

FHIR was designed for mobile apps, cloud platforms, and web services from day one. It fits naturally into modern development workflows with OAuth2 for security, SMART on FHIR for app authorization, and standard HTTP for transport.

7. Developer-Friendly

FHIR has extensive documentation, open-source tools, public test servers, and an active community. You can prototype a FHIR application in hours, not months.

Real-World Use Case Scenarios

Use Case 1: Patient Health Records Access

Scenario: A patient wants to view their lab results, medications, and visit summaries through a mobile app.

FHIR Solution: Using SMART on FHIR, the app authenticates the patient via OAuth2, then queries the EHR system:

GET /Patient/{id} - Patient demographics
GET /Observation?patient={id}&category=laboratory - Lab results
GET /MedicationRequest?patient={id} - Current prescriptions
GET /Encounter?patient={id} - Visit history

The app presents unified data from multiple sources in a user-friendly interface.

Use Case 2: Care Coordination Between Providers

Scenario: A primary care physician refers a patient to a cardiologist. The cardiologist needs access to relevant patient history.

FHIR Solution:

The physician's system creates a DocumentReference resource containing a care summary
The cardiologist's system queries for Condition, Observation, and MedicationStatement resources
Both systems exchange data via secure FHIR APIs, ensuring the cardiologist has complete context before the first appointment

Use Case 3: Clinical Decision Support

Scenario: A hospital wants to implement real-time alerts for drug interactions when physicians prescribe medications.

FHIR Solution:

The EHR system sends current MedicationRequest and Patient resources to a CDS Hooks service
The service analyzes the data and returns alerts as OperationOutcome resources
Physicians receive actionable warnings integrated directly into their workflow

Use Case 4: Population Health Analytics

Scenario: A health system wants to identify diabetic patients due for annual retinal screenings.

FHIR Solution:

Query for Patient resources with Condition of diabetes
Retrieve associated Observation resources for most recent HbA1c levels
Check Procedure resources for retinal screening history
Generate outreach lists for patients overdue for screening

Use Case 5: Remote Patient Monitoring

Scenario: Monitor post-surgery patients' vital signs at home using connected devices.

FHIR Solution:

Home devices (blood pressure cuffs, pulse oximeters) push Observation resources to a FHIR server
Clinical staff query Observation?patient={id}&date=gt{timestamp} to view recent vitals
Automated alerts trigger when values exceed thresholds, creating Task resources for clinician follow-up

Getting Started with FHIR Development

If you're ready to build with FHIR, here's your starting point:

Explore the Specification: Visit hl7.org/fhir for comprehensive documentation
Use Test Servers: HAPI FHIR and SMART Health IT provide public test servers for experimentation
Leverage Libraries: HAPI FHIR (Java), FHIR.js (JavaScript), fhir.resources (Python) to simplify development
Follow Implementation Guides: Start with US Core or your region's national standard
Join the Community: Participate in FHIR Zulip chat and HL7 working groups

For developers, FHIR opens exciting opportunities to build applications that genuinely improve patient care, streamline workflows, and unlock the potential of healthcare data. Whether you're creating patient portals, clinical decision support tools, or population health analytics platforms, FHIR provides the foundation for interoperable, impactful healthcare solutions.

Have you worked with FHIR or healthcare interoperability? What challenges did you face? Share your experiences in the comments below!

Hosting a WordPress Website on AWS

Paul Aderoju — Sun, 20 Aug 2023 16:34:01 +0000

Hi.

In this tutorial, we are going to learn how to host a WordPress website on AWS.

Requirements

An AWS Account;
An active domain name.

STEP 1: Create an AWS EC2 Instance

In Your AWS Management Console, Search for EC2 in the search bar, and click on the first option that appears. Then click on the Launch Instance button.

Fill out the fields like this:
Give your EC2 instance a name and select the Ubuntu AMI.

Select the t2.micro(free tier) instance type and create a keypair or use an already existing one.

Create a new security group, and allow SSH, HTTPS and HTTP traffic from the Internet.

Configure your storage. 8GB is enough for this project. Launch your instance.

Allocate an Elastic IP and Associate it with your instance. An Elastic IP doesn't change unless you explicitly release it, making it useful for scenarios where you need a consistent IP address for your resource even if the resource is stopped and started.

STEP 2: SSH into your EC2 Instance

Securely login to your EC2 Instance. You can do that using a SSH Client or EC2 Instant Connect.

STEP 3: Update and Upgrade the local package index on your system

Run the command:

sudo apt update -y
sudo apt upgrade -y

STEP 4: Install Apache2, PHP, MySQL

Run the command:

sudo apt install apache2 -y
sudo apt install apache2 -y
sudo apt install mysql-server -y

STEP 5: Change Mysql authentication plugin to a mysql native password

sudo mysql -u root

Change authentication plugin

ALTER USER 'root'@localhost IDENTIFIED WITH mysql_native_password BY 'Testpassword@123';

Create a seperate user other than root

CREATE USER 'wp_user'@localhost IDENTIFIED BY 'Testpassword@123';

Create a Database for Wordpress. We'll call this database wp.
```
CREATE DATABASE wp;
```
Assign all priviledges on the newly cretaed DB to the wp_user user;
```
GRANT ALL PRIVILEGES ON wp.* TO 'wp_user'@localhost;
```

Exit MySQL by pressing Ctrl + d

STEP 6: Download and Unzip Wordpress

cd to the /tmp directory
```
cd /tmp
```

Download wordpress

wget https://wordpress.org/latest.tar.gz

Unzip Wordpress. This will create a new folder called wordpress.
```
tar -xvf latest.tar.gz 
```
Move wordpress folder to document root of Apache2
```
sudo mv wordpress/ /var/www/html/
```

STEP 7: Create a `wp-config.php file` from wordpress GUI

In the browser, go to http://{ip_address}/wordpress

Fill out the form with the information we used to create MySQL earlier, and submit:

    DATABASE Name: wp
    Usename: wp_user
    password: Testpassword@123
    DATABASE host: localhost
    table prefix: wp_

It will throw an error saying Unable to write to wp-config.php file. Follow theses instructions to correct error.

Go to the /var/www/html/wordpress directory:
```
cd /var/www/html/wordpress
```
Create a wp-config.php file and copy instructions from earlier error.
```
sudo vi wp-config.php
```
Reload the browser and run installation.
Fill the form on the next page.

Go back to http://{ip_address}/wordpress and see the wordpress sites working

STEP 8: Modifying the Apache `000-default.conf` file

Go to Apache2 config folder
```
cd /etc/apache2/sites-available/
```
Open up sudo 000-default.conf file
```
sudo vi 000-default.conf 
```

Change DocumentRoot /var/www/html/ to:

 DocumentRoot /var/www/html/wordpress

Add:

Alias '/wordpress/' '/var/www/html/wordpress/'

Restart apache2

sudo systemctl restart apache2

STEP 9: Configuring your domain

Create an A Type DNS record. Copy your ip address from your ec2 and paste it to the new A type, set TTL to 60.

Add ServerName and ServerAlias to 000-default.conf file

ServerName paulboye.live
ServerAlias www.paulboye.live

Restart apache2

sudo systemctl restart apache2

WordPress Address (URL): http://{your-domain-name}
Site Address (URL): http://{your-domain-name}

Click on Save Changes

Notice that the url of your wordpress site will have changed.

STEP 10: Install SSL Certificate

Install CertBot

sudo apt install certbot python3-certbot-apache -y

Run Certbot and Follow prompts

sudo certbot --apache