MAIE — medical availability integration engine
An integration engine that receives medical-availability slots from clinics in three different formats — native JSON, FHIR R4 bundles and HL7 SIU — normalises them, resolves the identifiers, and lands them in the booking system for the CRDS.
The challenge
Clinics and provider systems all publish physician availability differently: some
send our native JSON, some send FHIR R4 bundles, and hospital systems send
HL7 SIU scheduling messages. Every one of those had to end up as a clean
DISPONIBILITE record in the booking database for the CRDS — with the right
internal keys, without duplicates, and with a clear answer back to the sender
when something didn’t validate.
Approach
Role separation — each tool does what it’s best at:
- Node.js / Express / TypeScript owns the HTTP entry point, API-key auth, rate limiting, JSON and FHIR R4 parsing (message and batch bundles), the business logic and persistence.
- Mirth Connect owns HL7 SIU parsing only — a dedicated internal channel extracts the SCH / AIG / AIL segments and hands back the same normalised object.
One internal contract — every parser produces the same AvailabilityDTO, so
the rest of the pipeline never cares about the input format.
- Resolver — translates external identifiers (physician licence number, facility MSSS code) to internal FileMaker foreign keys, cache-first with Redis and a fuzzy name fallback, so lookups stay under ~50 ms.
- Mapper + de-duplication — builds the
DISPONIBILITErecord and rejects a slot that already exists (by provider UUID, or date + time + physician + facility). - Persistence via the FileMaker Data API, with structured
LOG_IMPORTlogging and HTTP201 / 207 / 422so callers know exactly what happened, slot by slot.
FHIR profile — six resources (MessageHeader, Slot, Schedule, Practitioner,
Organization, PractitionerRole); message bundles (≤ 50 slots) answered
synchronously in ≤ 2 s, batch bundles up to 500 slots processed
asynchronously with a batch id.
Result
Providers integrate against one endpoint regardless of their format; real-time changes (a cancellation, a few new slots) get an immediate answer, while a physician’s whole weekly grid can be pushed in a single batch. The FHIR layer can evolve without touching the systems around it.
Add live volumes (slots/day, providers connected) and the go-live date via the admin panel.
Want an outcome like this?
One endpoint that any provider can send to, whatever their format, with identifier resolution, de-duplication and per-slot error reporting.
Book a callFHIR R4 Bundle Generator for Healthcare Systems