Proposal: Integrate OpenEMR FHIR API with Azure Health Data Services (AHDS)

[matthansen0]

Proposal: Integrate OpenEMR FHIR API with Azure Health Data Services (AHDS)

Summary

Add a new integration connector that enables pushing/selectively synchronizing FHIR R4 resources from this OpenEMR deployment to Azure Health Data Services (FHIR). The goal is a small POC (Patient + Observation) and an integration pattern that can be extended for production use.

Background

• This deployment uses the official OpenEMR container (openemr/openemr:7.0.2), which includes a native FHIR R4 API (base path: /apis/<site>/fhir, capability statement at /apis/default/fhir/metadata).
• The repo currently includes cloud deployment artifacts (VM/compose), but no Azure-specific FHIR connector code.
• The OpenEMR image contains code and services for FHIR (FHIR controllers and services) and supports SMART/OIDC and bulk $export.

Proposal

Implement a connector service that:

1. Authenticates to OpenEMR FHIR (using a registered API client / OIDC client credentials or an authorized user token);
2. Reads/transforms FHIR resources from OpenEMR (Patient, Observation, Encounter, MedicationRequest, etc.);
3. Authenticates to AHDS (Azure AD: managed identity or service principal);
4. Pushes resources to AHDS FHIR endpoints (or uses AHDS bulk-import if suitable for bulk data loads);
5. Logs/audits all activity and exposes metrics for monitoring and retries on transient failures.

Recommended implementation choices for POC

• Connectors: Azure Function (HTTP-triggered / timer) or containerized microservice (Node/Python/C#). Azure Function is easiest for a short POC.
• Auth:
  • To OpenEMR: register a confidential client in OpenEMR (client credentials flow) or use a test access token (short-term) for POC.
  • To AHDS: use an Azure AD app registration + client secret or use a managed identity (recommended for production) to obtain a bearer token for the AHDS FHIR endpoint.
• Data transfer options:
  • Pull small dataset via FHIR REST (GET /Patient, GET /Observation) and POST/PUT to AHDS.
  • For larger datasets, use OpenEMR $export bulk NDJSON and use AHDS import (or staged blob + import) if AHDS supports the chosen import mechanism.

POC Plan (steps)

1. Provision an AHDS (FHIR) instance in a dev subscription or use an existing test instance.
2. Spin up this repo's stack locally on a dev host (docker-compose in all-in-one/docker-compose.yml) and enable FHIR in OpenEMR Admin -> Globals -> Connectors.
3. Add an OpenEMR API client for the POC (or use an admin token) and verify GET /apis/default/fhir/metadata returns the CapabilityStatement.
4. Create an Azure AD app (or use managed identity) and configure permission to write to AHDS.
5. Implement a small connector (Azure Function) that:
   • obtains token for OpenEMR and AHDS,
   • reads a Patient by id (or small list) from OpenEMR FHIR,
   • POSTs/PUTs the Patient resource to AHDS FHIR endpoint,
   • repeats for an Observation.
6. Validate the resources in AHDS and confirm resource integrity and provenance.

Acceptance criteria (POC)

• A single patient and associated observation created in AHDS via the connector.
• Successful authentication flows (OpenEMR OIDC and Azure AD) documented and reproducible.
• Basic logging and retry logic implemented.

Security & compliance notes

• PHI handling must comply with applicable regulations (TLS, RBAC, audit logs, minimal retention of PHI in transit,
  secure secrets storage for client credentials).
• For production, prefer managed identity and least-privilege roles for AHDS access.

Estimated effort

• POC (Patient + Observation): 1 engineer, 1–2 weeks.
• Production-grade integration (terminology mapping, de-dupe, reconciliation, monitoring): 1–3 engineers, 1–3 months.

Next actions / decision items

• Approve POC and provide a dev Azure subscription with permissions to create AHDS or confirm use of an existing instance.
• Decide preferred deployment model for the connector (Azure Function vs container).

---

If this sounds good I can open this issue and (optionally) start a PR with a connector scaffold (Azure Function template) and a short runbook for the POC.