Illustrative Work Sample

Hybrid HL7 and FHIR Delivery Playbook

A shared delivery sequence for legacy interfaces and API exchange, with explicit contracts, test evidence, and ongoing ownership for each path.

Illustrative template created for this portfolio. Contains no client data and is not a historical project deliverable. Example scenarios are synthetic; blank measurement fields are for future use.

Download editable template (.md)Back to Skills + Artifacts

When to Use It

A program introduces FHIR or API exchange alongside existing HL7 interfaces. Use one set of decision gates while documenting each connection’s actual technical behavior.

Decision This Supports

Choose coexistence, phased migration, or replacement based on workflow coverage and operational evidence. Advance a connection only when its contract, validation, reconciliation, and support ownership are ready.

1. Inventory the coexistence model

Identify where legacy and modern paths overlap before introducing conflicting writes or duplicate workflow events.

Workflow inventory: For each workflow, record source, destination, business owner, current connection, planned connection, and systems that remain in service.
Source of truth: Record ownership of identifiers, terminology mapping, updates, corrections, and conflict resolution for each data domain.
Migration choice: Coexist, migrate in phases, or replace [ ]; rationale [ ]; excluded workflows [ ]; review trigger [ ].
Dependency map: Record partner release windows, vendor capabilities, endpoint availability, security decisions, and owners.

Review Checks

No data domain has two undefined write authorities.
Installed-base support responsibilities remain assigned during transition.

2. Agree on separate technical contracts

Use consistent ownership and review without assuming HL7 messaging and FHIR exchange have equivalent semantics.

HL7 contract: Record version, message and trigger types, transport, mapping, acknowledgment mode, timeout, retry, duplicate detection, ordering, and reconciliation.
FHIR or API contract: Record version, profiles, supported resources and operations, search parameters, pagination, validation expectations, and error responses.
Authorization contract: Record supported OAuth flow, SMART context if applicable, scopes, token lifetime assumptions, service identity, and rotation owner.
Failure contract: Define permanent versus retriable errors, retry limits, quarantine or exception workflow, replay authorization, and incident escalation.

Review Checks

Partner documentation and endpoint capabilities agree with the proposed contract.
A transport acknowledgment or successful HTTP response is not used alone as proof of correct downstream workflow.
Retry and replay paths protect against unintended duplicate effects.

3. Run common evidence gates

Compare readiness through the same evidence categories while retaining protocol-specific test cases.

Test record: Scenario [ ]; expected receiving-workflow behavior [ ]; protocol [ ]; evidence [ ]; actual result [ ]; defect owner [ ]; approver [ ].
Coverage: Include successful exchange, invalid or missing data, corrections, duplicates, delayed or out-of-order events, unavailable endpoints, expired credentials, and reconciliation.
Representative volume: Agreed operating profile [ ]; test environment limitations [ ]; backlog recovery expectations [ ]; observed evidence [ ].
User acceptance: Receiving user [ ]; workflow validation steps [ ]; acceptance evidence [ ]; unresolved gap [ ].

Review Checks

Engineering, QA, and the receiving workflow owner review failures and limitations together.
Uncovered behavior is recorded as a risk, not silently counted as a pass.

4. Release, observe, and decide the next phase

Make the decision to expand or retire a connection dependent on stable observed behavior.

Release sequence: Cohort [ ]; launch owner [ ]; decision gates [ ]; containment or rollback path [ ]; communication plan [ ].
Operational ownership: Alert source [ ]; support owner [ ]; engineering escalation [ ]; reconciliation cadence [ ]; coverage window [ ].
Measurement record: Metric [ ]; definition and denominator [ ]; baseline [ ]; target [ ]; result [ ]; observation window [ ]; source [ ]; owner [ ].
Expansion or retirement decision: Evidence reviewed [ ]; remaining legacy dependency [ ]; decision [ ]; approver [ ]; next review date [ ].

Review Checks

A legacy path is retired only after affected workflow coverage and remaining dependencies are accepted.
Post-live findings become named product or operational follow-up work.

Synthetic Worked Example

Synthetic scenario: a fictional specialty network keeps HL7 results while introducing FHIR reads for a separate application workflow.

Illustrative decision: coexist initially. Assign ownership per workflow, verify the endpoint’s FHIR profile and authorization behavior, and keep the existing results support path staffed.

Required evidence: clear data authority, scenario-level receiving-workflow checks, failure and credential-expiry tests, reconciliation results, and an explicit review before expansion. No migration benefit or performance result is assumed.