How to evaluate an ABDM/FHIR reference implementation

A reproducible claim identifies the FHIR release, package name, package version, validator version, and the date the target was reviewed. “FHIR compatible” alone is too broad to test.

MedicalRecords.in currently targets FHIR R4 4.0.1 and the published NRCeS package ndhm.in#6.5.0. The repository labels newer preview material separately instead of silently changing the target.[1][2]

A fixture should be safe to share, stable enough to reproduce, and representative enough to expose profile and reference errors. It should not contain a disguised production record.

The MedicalRecords.in manifest declares exactly six supported synthetic document examples: HealthDocumentRecord, OPConsultRecord, PrescriptionRecord, DiagnosticReportRecord, DischargeSummaryRecord, and ImmunizationRecord. Each fixture has its own expected profile, terminology result, official-validator result, and narrow offline MIME deferral allowlist. The prescription fixture uses text-only synthetic medication and dosage placeholders with no clinical instruction. The diagnostic-report fixture is a document envelope around a synthetic PDF and contains no DiagnosticReport, Observation, measurement, result, or interpretation. The discharge-summary fixture contains a synthetic completed inpatient encounter and empty attachment, with no diagnosis, medication, procedure, investigation, care plan, instruction, or other clinical assertion. The immunization fixture is an empty document envelope with no Immunization, ImmunizationRecommendation, vaccine, dose, administration date, lot, manufacturer, eligibility, or schedule.[3][7][8][9]

The validation command, validator artifact digest, implementation package, terminology mode, and OperationOutcome should be inspectable. A passing internal JSON-schema test does not replace profile validation.

A green fixture proves only that the named example passed the named validator and package. It does not prove ABDM certification, production connectivity, workflow correctness, clinical safety, or legal compliance.

For implementation commit 8628210, public CI retained separate OperationOutcome, validation-summary, and terminology-summary files for all six declared fixtures. Every fixture reports profile-structure-pass with zero blocking issues and terminology-pass with both invalid controls rejected.[4][5]

Interoperability is one control in a larger product. Review identity, consent, source access, corrections, deletion, audit, clinical release, incident response, and the difference between machine-created and clinician-reviewed content.

A credible design partnership begins with a narrow engineering and governance evaluation. Production data, certification language, and clinical workflow expansion should remain out of scope until their evidence gates are met.