Interfaces — the most expensive repetitive work an implementer does
Being wrong here costs an afternoon, never a patient — which is exactly why these two are safe to build now.
ITEM 6PlannedNo patient data
Explains why an HL7 message was rejected
Reads a rejected interface message and its error code, and explains in plain language what is likely wrong and where to look — without ever touching the message itself.
Synthetic example walkthrough
Who
Marcus Webb (synthetic example), an implementation engineer debugging a lab interface on his third clinic this month.
Situation
The interface engine logged “OBX-5 malformed” with no further context, and re-reading raw HL7 by hand costs an afternoon.
Blue shows
“The result value in segment OBX-5 is text (‘Pending’) where a numeric result was expected — this usually means the sending lab system sent a placeholder before the result was final.”
They do
Marcus checks the sending system’s configuration, confirms the diagnosis, and fixes the mapping himself — Blue never touches the interface.
Design mockup · not built Shown inside blueHealthcare's real shell (top bar, left rail, product tokens) with synthetic data, composed from the platform's own components — not a live feature, and not a real screenshot of a shipped screen.
What it never does
Never resends, modifies, or reprocesses the rejected message.
Never fixes the interface mapping itself — only explains what a person should check.
ITEM 7PlannedNo patient data
Proposes an interface field mapping
Proposes a mapping between two systems’ interface fields, admitted only once a person has run it against a golden pair of real sample messages and it passes.
Synthetic example walkthrough
Who
Marcus Webb (synthetic example) again, setting up an admissions feed for a new partner hospital.
Situation
The partner’s ADT message carries a custom, undocumented segment.
Blue shows
A proposed mapping — “ZPD-3 → patient.preferred_language, matching 47 of 50 sample messages” — alongside a deterministic test run comparing the mapping’s output to the expected result on those samples.
They do
Marcus runs the test, sees 47 of 50 pass, inspects the 3 failures, and accepts the mapping only once every case passes or a documented exception covers it.
Design mockup · not built Shown inside blueHealthcare's real shell (top bar, left rail, product tokens) with synthetic data, composed from the platform's own components — not a live feature, and not a real screenshot of a shipped screen.
What it never does
Never ships a mapping that has not been run against a golden pair of sample messages.
Never marks its own test as passing — the deterministic test runner decides that.
