# Interoperability Discovery Checklist

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.

Updated: 2026-09-08

## When to use

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?

Response: ____________________

### Current friction and evidence

Describe the observed failure, manual step, or delay. Link to approved evidence without copying patient information.

Response: ____________________

### Scope and exclusions

List supported sites, source systems, destinations, data domains, and explicit non-goals.

Response: ____________________

### Accountable owners

Name the product decision owner, clinical or operational approver, partner contact, and technical lead.

Response: ____________________

### 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.

Response: ____________________

### Identifiers and semantics

Define patient and encounter identifiers, terminology, required fields, matching ownership, mapping rules, and rejection behavior.

Response: ____________________

### Authentication and access

Record the agreed authentication flow, scopes, credential owner, rotation process, and environment separation. Store secrets only in approved systems.

Response: ____________________

### Delivery behavior

Agree on acknowledgments, timeout handling, bounded retries, duplicate detection or idempotency, ordering, reconciliation, and error ownership.

Response: ____________________

### 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.

Response: ____________________

### Decision and rationale

Record the selected option, user value, reuse potential, support cost, dependencies, and why alternatives were rejected.

Response: ____________________

### Exception boundary

If an exception is accepted, name its owner, affected customers, support implications, review date, and retirement condition.

Response: ____________________

### Delivery dependencies

List partner access, test data, mapping approval, staffing, security review, and milestone owners.

Response: ____________________

### 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 [ ].

Response: ____________________

### Measurement record

Metric [ ]; definition and denominator [ ]; baseline [ ]; baseline window [ ]; target [ ]; result [ ]; result window [ ]; source [ ]; owner [ ].

Response: ____________________

### Support and release handoff

Identify launch gate, rollback or containment owner, reconciliation procedure, support coverage, and first post-live review.

Response: ____________________

### 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.

Portfolio: https://jasonpagliaro.com/work-samples/interoperability-discovery-checklist