Clinical data + deterministic findings
FHIR clinical data retrieved through the application API is shown before the rule-engine output. The workflow can explicitly persist the deterministic results back to the synthetic HealthLake datastore.
← All projects
01 / HEALTHCARE / INTEROPERABILITY
FHIR Medication Safety Intelligence
Connect standards-based healthcare data with deterministic medication-safety analysis and grounded AI explanation.
End-to-end cloud prototype · explicit FHIR write-back
View public GitHub repository →Overview
Interoperability with explicit safety layers.
A FHIR-native medication-safety prototype that retrieves synthetic clinical data from AWS HealthLake, runs deterministic drug-drug, drug-lab, and missing-data rules, and only then asks AI to explain the resulting findings. The application keeps clinical data, deterministic findings/data gaps, and AI explanation visibly separate.
The problem
Medication safety depends on medication, laboratory, and clinical-note context that is often spread across systems. A standards-based FHIR boundary makes that context reusable while the rule engine preserves traceability and the explanation layer stays downstream of the facts.
My contribution
Designed the FHIR resource model, repository abstraction, synthetic scenarios, deterministic safety workflow, HealthLake integration, cloud API path, guarded explanation layer, and explicit write-back of DetectedIssue and RiskAssessment resources.
Architecture
Read → analyze → explain → persist.
FHIR R4 dataSynthetic patients, meds, labs, notes
AWS HealthLakeFHIR clinical repository
Cloud APIAPI Gateway + Lambda / FastAPI
Safety engineDrug-drug, drug-lab, data-gap rules
AI explanationGuarded explanation of established findings
FHIR write-backExplicit DetectedIssue + RiskAssessment persistence
Analysis and explanation are read-only. FHIR write-back is a separate, explicit persist action so the application does not silently modify clinical data.
Application walkthrough
Clinical context stays separate from interpretation.
The interface makes the architecture visible: Layer 1 clinical data, Layer 2 deterministic findings and data gaps, then Layer 3 grounded AI explanation.
Findings + data gaps + grounded explanation
Drug-lab and drug-drug findings retain their own evidence and severity. Data gaps are separate, and AI can explain only the findings and supporting context supplied to it.
Key capabilities
- FHIR-native repository: the same application logic can operate over local test data or AWS HealthLake.
- Deterministic safety engine: drug-drug, drug-lab, and missing-data rules decide the result before AI runs.
- Explicit write-back: persisted DetectedIssue and RiskAssessment resources are a deliberate action, separate from analyze/explain.
- Grounded AI: explanations are guard-checked and cannot create findings or alter severity.
Representative patient: Lisa Demo
The displayed scenario produces a HIGH drug-lab finding for lisinopril with elevated potassium and a MODERATE drug-drug finding for lisinopril with ibuprofen. The same workflow can surface missing-data conditions rather than estimating values.
10 scenariosGolden synthetic patient cases exercise findings, gaps, and negative cases
HealthLake liveClinical retrieval is verified against the deployed AWS FHIR datastore
FHIR write-backDetectedIssue and RiskAssessment persistence is implemented and explicit
Synthetic demonstration only; not intended for patient care.