INTEGRATION & INTEROPERABILITY
Integration Architecture Review
A bounded review of one healthcare integration workflow: its dependencies, failure paths, and the decisions needed before modernization. Led by Ian Booker, with prior integration engineering experience at Rush and data architecture experience at Lurie Children’s Hospital.
WHEN THIS HELPS
Interfaces are difficult to change, dependencies are poorly understood, or an upcoming migration needs a defensible starting point. The review helps your team agree what to address first.
One agreed workflow and its connected systems, reviewed through stakeholder discussions and sanitized architecture and interface evidence.
The decision: what should be stabilized, redesigned, or migrated first?
ILLUSTRATIVE REVIEW EXCERPT
Fictional scenario. Not a client case study. All systems, evidence references, findings, and responsibilities below are invented to demonstrate the work product. No production outcome or measured improvement is claimed. This excerpt is not the complete contracted review.
A fictional outpatient organization plans to replace its interface engine. Before choosing a migration sequence, it needs to understand how appointment updates reach its scheduling application and reporting feed.
Review boundary: One appointment-update workflow, its two consumers, and the exception process. Other interfaces, patient care decisions, and production changes are outside this example.
Engine failures enter an exception queue for operator review. In this assumed design, downstream application failures have no documented reconciliation path.
F01 / ESTABLISH COMPLETION
Fictional evidence E1: The sample flow diagram ends at the consumer connection and omits application processing status.
Inference: The diagram cannot establish whether an appointment change was applied. This is a documentation gap, not proof of message loss.
Verify: Trace approved synthetic updates from source through application state and reporting. Record failure and rejection behavior.
F02 / DEFINE SAFE RECOVERY
Fictional evidence E2: A sample runbook says “resend the message” without duplicate or ordering rules.
Inference: Safe replay is not demonstrated. Do not assume either consumer handles duplicates safely.
Verify: In a non-production environment, test duplicate and out-of-order updates with each consumer owner. Document expected state and rejection handling.
F03 / ASSIGN THE EXCEPTION
Fictional evidence E3: A sample responsibility list names the engine operator but omits the application-side escalation owner.
Inference: Recovery ownership is unclear; response performance has not been measured.
Verify: Agree an escalation path and rehearse a synthetic failure with engine, application, and reporting owners.
03 / SAMPLE ARCHITECTURE DECISION · ADR-001
Status: Proposed within this fictional scenario; subject to evidence and stakeholder review.
Proposed choice: Option B for this example. Keep the migration decision conditional on verified consumer behavior, an agreed exception procedure, and a recoverable cutover plan.
Reconsider if: An imminent platform deadline changes the trade-off, the existing platform cannot support the required checks, or the synthetic tests reveal incompatible consumer behavior. A changed recommendation needs an explicit risk decision.
Proposed owner: Integration lead with application and reporting owners.
Completion evidence: An agreed flow map identifying update types, each consumer, and the point at which processing is considered complete.
Proposed owner: Integration engineer and consumer owners.
Completion evidence: Recorded synthetic test results for normal processing, duplicates, ordering, and rejection; unresolved cases documented.
Proposed owner: Operations lead and named application responders.
Completion evidence: A practiced escalation and recovery procedure with responsibility for each handoff.
Proposed owner: Architecture sponsor and change owner.
Completion evidence: A decision record with dependencies, acceptance conditions, and rollback criteria. No production change is performed by this illustrative review.
What this excerpt demonstrates: the connection between an evidence gap, a verification task, an architecture decision, and a delivery sequence. It does not demonstrate a client result.
HOW THE REVIEW WORKS
Work starts with a written scope, fee, inputs, and delivery date. The scope follows your workflow and decision; the sample above does not prescribe a universal solution.
Discuss a project or contractUseful inputs: A workflow description, existing diagrams, known pain points, relevant interface documentation, and access to the people who own the connected systems.
Not included by default: Production changes, emergency incident response, a complete interface inventory, migration execution, or ongoing operations. A broader delivery need can be scoped separately.
Initial reviews use sanitized evidence. System access and implementation are agreed separately. Do not send patient information, credentials, or confidential documents through the inquiry link.
START A CONVERSATION
Share the work, the team, and the timing. Ian welcomes relevant senior architecture opportunities and focused consulting inquiries.
Please leave out patient data, credentials, and confidential documents. Supporting material can be arranged afterward.
Describe the integration, platform, or architecture challenge and the support you need.
Integration Architecture Review
Discuss a project or contractOpens your email app with a project outline.
Or use the inquiry formFor consulting, scope, fee, inputs, and timing are agreed before work starts.
C2C/1099 preferred. Suitable W2 roles considered.
Send the role, organization, location, engagement type, and expected rate or salary range.
Discuss an architecture roleOpens your email app with an opportunity outline.
Or use the inquiry form