FHIR Telehealth Platform

The challenge

Clinicians needed the full clinical record — appointments, conditions, medications, imaging, care plans — in one place, with AI help that answers from the patient in front of them.

What we built· with the Bracket Mind team

• Complete FHIR R4 clinical records on Azure Health Data Services — appointments, conditions, medications, observations, notes and care plans in one place
• A Claude clinical assistant on AWS Bedrock, grounded in the open patient's record: six FHIR resource types embedded into Pinecone, chunked, and re-embedded in the background as the record changes
• AI-assisted drafting of clinical notes, conditions, medications, orders and care plans
• DICOM imaging end to end — a DICOMweb client for Azure's DICOM service, upload and validation, studies that open in an OHIF-based viewer, and expiring share links that can be revoked, with each opening recorded
• Apple Health exports imported into FHIR — clinical records, ECG, XML and CDA — tracked in phases so an interrupted upload resumes instead of starting over
• Patient-data access through one security service: role checks, CareTeam and Consent validation, and an audit log of who opened which record

How it fits together

Which engineering decisions shaped it?

1. 01Clinical records are stored as FHIR R4 resources, not in our own tables

   Instead of

   A custom relational schema for clinical data, mapped to FHIR only when records are exchanged

   Why

   FHIR is HL7's standard for exchanging health records, so the platform's data is already in that shape, on a BAA-eligible managed service (Azure Health Data Services). The app's own database keeps operational state, such as sync tracking, import jobs and role assignments.

2. 02The assistant answers from the open patient's record

   Instead of

   A general medical chatbot, or one search across every patient's records

   Why

   Clinicians wanted AI help that answers from the patient in front of them. Retrieval is filtered to the open patient's record, so the context Claude works from is that patient's conditions, medications, observations and notes, re-embedded in the background as the record changes.

3. 03The AI index follows FHIR, not our own save events

   Instead of

   Re-embedding a record only when our app saves it

   Why

   FHIR is the source of truth, and other apps can create, change or delete records without going through ours. A background job picks up resources changed since its last run, and a reconciler compares FHIR with the sync log to add missing records, remove deleted ones and refresh stale ones.

4. 04Apple Health imports save checkpoints and resume

   Instead of

   Restarting a failed import from the beginning, as the first version did

   Why

   A crash late in a large import used to mean downloading, parsing and posting everything again: 40 minutes lost on a 40-minute import. Each import now records its phase and a checkpoint (sizes, counts and dates, never patient data), so an interrupted one picks up where it stopped.

Our founder's part

Haseeb Attaullah: Lead engineer on the platform's FHIR back end — the FHIR R4 integration, the first version of the clinical assistant, DICOM imaging and share links, and the Apple Health import; led the move to .NET 10.