Illustrative Work Sample

Interoperability Discovery Checklist

A reusable brief that connects the user workflow, integration contract, operating constraints, and product decision before delivery begins.

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 customer or partner requests a new connection, a workflow change, or a migration. Complete it with product, implementation, engineering, and the receiving workflow owner.

Decision This Supports

Approve discovery completion only when the problem, contract assumptions, acceptance evidence, and unresolved dependency owners are explicit. Record whether to build a reusable capability, allow a bounded exception, investigate further, or defer.

1. Establish the workflow and problem

Start with the clinical or operational job to be done so the connection does not become the definition of success.

User and workflow: Who performs which task, in which care setting, and what happens before and after the exchange?
Current friction and evidence: Describe the observed failure, manual step, or delay. Link to approved evidence without copying patient information.
Scope and exclusions: List supported sites, source systems, destinations, data domains, and explicit non-goals.
Accountable owners: Name the product decision owner, clinical or operational approver, partner contact, and technical lead.

Review Checks

Affected users agree on the problem and intended workflow.
Every unresolved clinical or data-integrity assumption has an owner and due date.

2. Define the integration contract

Record the actual partner capabilities rather than treating a standard name as a complete contract.

Connectivity and version: Record transport, endpoints, HL7 message types and version or FHIR version, profiles, implementation guide, and supported operations.
Identifiers and semantics: Define patient and encounter identifiers, terminology, required fields, matching ownership, mapping rules, and rejection behavior.
Authentication and access: Record the agreed authentication flow, scopes, credential owner, rotation process, and environment separation. Store secrets only in approved systems.
Delivery behavior: Agree on acknowledgments, timeout handling, bounded retries, duplicate detection or idempotency, ordering, reconciliation, and error ownership.

Review Checks

HL7 acknowledgment modes and application acceptance are agreed with the partner.
FHIR capability and profile assumptions are verified against the specific endpoint.
Synthetic test cases cover malformed, duplicate, missing, and out-of-order data.

3. Make the product tradeoff

Separate customer urgency from the value and cost of making the capability reusable.

Options considered: Compare a shared platform capability, a partner-specific exception, an operational workaround, and deferral where relevant.
Decision and rationale: Record the selected option, user value, reuse potential, support cost, dependencies, and why alternatives were rejected.
Exception boundary: If an exception is accepted, name its owner, affected customers, support implications, review date, and retirement condition.
Delivery dependencies: List partner access, test data, mapping approval, staffing, security review, and milestone owners.

Review Checks

Decision owner accepts the tradeoff and remaining risk.
The launch date is conditional on evidence, with blocked dependencies visible.

4. Define success and readiness

Make acceptance observable in the intended workflow and measurable after release.

Acceptance scenario: Given [workflow state], when [event], then [observable outcome]; evidence location [ ]; approver [ ].
Measurement record: Metric [ ]; definition and denominator [ ]; baseline [ ]; baseline window [ ]; target [ ]; result [ ]; result window [ ]; source [ ]; owner [ ].
Support and release handoff: Identify launch gate, rollback or containment owner, reconciliation procedure, support coverage, and first post-live review.

Review Checks

Intended users validate the receiving workflow, not only transport success.
Unresolved risks have an explicit go, no-go, or conditional decision.

Synthetic Worked Example

Synthetic scenario: a fictional ambulatory partner requests a custom result-routing rule while a second partner needs a similar capability.

Illustrative decision: investigate a shared configurable rule before approving two custom mappings. Keep partner-specific terminology mapping explicitly scoped.

Required evidence: approved routing scenarios, identifier and terminology mapping, negative and duplicate test cases, receiving-workflow validation, and a named exception owner. Baseline, target, and result remain blank until measured.