Getting Comfortable Together

• Thanks for joining—what's your role and main responsibility for integration and interoperability in your organization? Options: CIO/CTO, VP/Director of Integration, Interoperability Director, Integration Architect, Clinical Informaticist, IT Operations / NOC, Other
• Who else on your team should we involve so we can get accurate technical and governance answers quickly?
• What is the single most important outcome you need this integration initiative to deliver in the next 6–12 months?
• How urgent is this initiative—when would you like to see measurable progress or a pilot live? Options: Immediately (weeks), 1–3 months, 3–6 months, 6–12 months, No fixed timeline
• Have you previously evaluated or used any integration engines or interoperability platforms? If yes, which ones and what was the deciding factor to keep or move away?

Are You Quietly Resolving Fires Instead of Preventing Them?

• What happens inside your organization when a critical lab or radiology message fails on a Monday morning—who notices first and what breaks downstream?
• How often do you see interface failures that require manual intervention or rework? Options: Multiple times daily, Daily, Weekly, Monthly, Rarely
• Which failure types occur most often in your estate? Options: Message parsing/format errors, Mapping/transform bugs, Connectivity/timeouts, Downstream system rejects, Duplicate or missing messages, Security/authentication failures, Performance/latency issues, Other
• Describe your typical detection and resolution flow—who gets alerted, how long before it’s noticed, and who performs the fix?
• When these failures happen, what are the real-world consequences for clinicians, revenue cycle, or regulatory exposure? Can you share a recent example?

How Many Interfaces Are Holding Your Breath?

• If someone asked you to inventory every active interface and trading partner in 24 hours, could you produce an accurate list that matches production? Options: Yes, No, Partially — rough inventory, Not sure
• Approximately how many active interfaces and unique trading partners do you currently manage? Options: <50, 50–199, 200–499, 500–999, 1000+
• Which standards and protocols are present in your estate today? Options: HL7 v2, FHIR (R4/R4B), CDA, X12, DICOM, SOAP/XML, REST/JSON, Custom flat files, Other
• How many of your interfaces rely on pre-built connectors vs custom point-to-point integrations? Options: Mostly pre-built connectors, Mostly custom point-to-point, About half and half, Don’t know
• Which source or destination systems create the most volume or the most headaches for you? Options: Epic, Cerner/Oracle, Meditech, Allscripts, Sunquest, LabCorp/Reference Labs, Payer systems, Public health registries, Other
• What are the most complex mapping or routing scenarios you face (for example: multiple code sets, payer-specific transforms, conditional fan-out)?

Who Really Owns the Problem When Things Break?

• When an interface creates a patient-safety risk, who in your organization makes the operational call—and does that person have clear remit and authority?
• Which internal teams are involved across design, build, testing, and ongoing support? Options: Integration/Interface team, Clinical informatics, IT Operations / NOC, Security/Compliance, Application owners (EHR/Lab), Vendor/3rd-party support, Business analysts, DevOps / Platform
• How satisfied are you with cross-team collaboration for incident response and root-cause investigations? Options: Very satisfied, Somewhat satisfied, Neutral, Somewhat dissatisfied, Very dissatisfied
• Do you have formal escalation paths, runbooks, and a single-source-of-truth that assigns ownership for each interface? Options: Fully documented and practiced, Partially documented, Informal only, No formal process
• Who signs off on go/no-go for production cutovers and what are the non-negotiable criteria they require?
• How does your team emotionally respond to repeat incidents—does it erode trust in tooling, create burnout, or motivate process change?

What Would 'Regulatory-Proof' Look Like?

• If an auditor or regulator asked for evidence of ONC information blocking compliance or TEFCA readiness tomorrow, could you confidently provide the required artifacts? Options: Yes — ready today, Partially ready, No, Not sure what would be required
• Which regulatory priorities worry you most right now? Options: ONC information blocking, TEFCA participation, Payer-to-payer data exchange, Public health reporting (CDC/state), HIPAA breach reporting, State-specific interoperability rules, Other
• What kinds of reports, logs, or dashboards do you currently produce to demonstrate compliance and how automated are they? Options: Audit logs (message-level), Interface success/failure dashboards, Message provenance & lineage, Consent and access logs, Ad-hoc manual reports, No standard reports
• How comfortable are you delivering message-level evidence and attestation within regulatory timelines? Options: Very comfortable, Somewhat comfortable, Unsure, Not comfortable
• Are there specific audits, attestations, or deadlines coming up we should build our plan around? Please include dates where possible.

If We Could Rebuild One Interface From Scratch, Which Would It Be?

• Imagine one interface worked flawlessly every time— which one would free the most capacity or reduce the most clinical or financial risk?
• What measurable targets would make that interface a clear success? Select all that apply. Options: Throughput (messages/sec) target, End-to-end latency target, Error rate threshold (errors per 10k msgs), MTTR (mean time to repair) goal, Availability / uptime SLA (%), Auditable message provenance
• For mapping and transform ownership, what model do you prefer? Options: We own mapping logic, Vendor/Host owns mapping, Shared ownership (we review), Depends on interface complexity
• How do you prefer to validate mapping accuracy and end-to-end behavior? Options: Sample-based testing, Full-system replay, Parallel/dual-write run, Synthetic test data, Automated contract tests, Combination
• What would your acceptance criteria and sign-off steps look like for a pilot or initial cutover?
• After go-live, what monitoring, alerting, and reporting cadence would make you feel confident the interface is stable? Options: Real-time alerts + daily summary, Real-time only, Daily reports, Weekly executive summary, Custom SLA-based notifications

What Would It Take to Commit—Money, Trust, or Proof?

• What would make you say 'yes' to a new integration platform right now: price, a live demo with your data, a short pilot, or references from peers? Options: Competitive price, Live demo with our data, Time-boxed pilot/PoC, Peer customer references, Contractual SLAs & penalties, Regulatory attestations
• Which procurement, legal, or security reviews typically slow deals down in your organization? Options: Annual budget cycles, Security / pen test reviews, Legal/contract negotiation, Privacy / BAA reviews, Executive sponsor availability, Procurement policies
• What budget range would you consider for an initial pilot or PoC for a critical interface? Options: <$50k, $50k–$150k, $150k–$500k, $500k–$1M, >$1M, Unsure
• Who needs to be convinced and sign off for this to move forward (roles/titles)?
• How long is your typical procurement cycle for new infrastructure or platform software? Options: <1 month, 1–3 months, 3–6 months, 6–12 months, >12 months

Little Things That Break Big Plans

• What's the smallest, most recurring missing item—credentials, firewall rule, test dataset—that has delayed your go-lives in the past?
• Which environments, accounts, and access controls must be in place before we can begin integration testing? Options: Development, Test/QA, Staging (prod-like), Production mirrors, VPN access, IP allowlists/firewall rules, Service accounts / API keys, SAML/mTLS setup
• Do you have anonymized or synthetic test data available for safe end-to-end testing, or will we need to create it? Options: Anonymized production extracts available, Synthetic datasets available, Need vendor to generate, Mixed (some available), Not sure
• What network/security constraints (e.g., IP allowlist, mTLS, SAML, strict firewall windows) typically cause delays that we should plan for?
• What rollback, emergency cutover, and runbook controls do you insist on before any production change?
• Who will be our operational point-of-contact for scheduling cutovers, approving maintenance windows, and declaring rollbacks?

• Solution Experience - Pre‑Work Alignment
• End‑to‑End Workflow Validation (Hands‑On Lab)
• Error Injection & Recovery Workshop
• Compliance Evidence & Reporting Walkthrough
• Validation Summary & Acceptance Decision

• Verify audit trails and data provenance satisfy the customer's internal and external audit requirements.
• Review Prioritized Failure Modes
• Prove that the platform automates recovery for common failures or provides clear operator guidance when manual action is required.
• Validate that monitoring and alerts surface the right information to resolve issues within agreed SLAs.
• Produce runbook updates and automation tasks to close operational gaps found during injection.
• Create/update runbooks and on‑call playbooks based on observed recovery steps.
• Implement automations (e.g., replay script, mapping fallback) for high‑frequency failure modes.
• Adjust monitoring thresholds and notification routing to reduce noise and improve actionability.
• Log any compliance or data integrity issues discovered for remediation planning.
• Map Requirements to System Outputs
• Produce a demonstrable compliance packet that maps to the customer's regulatory obligations.
• Introductions & Objectives
• Agree a remediation plan for any identified compliance gaps with owners and dates.
• Seller to deliver the sample compliance packet (audit logs, lineage, reporting) for customer review.
• Customer compliance team to validate artifacts against internal checklist and return gap list.
• Implement agreed configuration changes to retention, masking, or consent enforcement.
• Review Test Results & Metrics
• Obtain an explicit go/no‑go decision or a prioritized remediation plan with timelines and owners.
• Ensure all stakeholders understand residual risks and the path to closure for any open items.
• Hand off validated artifacts, runbooks, and acceptance evidence to Deployment for readiness activities.
• Publish a consolidated validation report with test evidence and acceptance status.
• If remediation required, create a prioritized backlog with owners, SLAs, and retest dates.
• Transition accepted artifacts and operational runbooks to the Deployment group and schedule pre‑deployment checks.
• Produce a single crisp current state sentence that will be used as the diagnostic anchor for all demonstrations.
• Document explicit consequences (cost, risk, downtime) tied to the current state.
• Agree the future state outcome that the experience must prove and the exact workflows/data to exercise.
• Secure necessary access, sanitized sample data, and an executable schedule for live validation.
• Customer to deliver representative message samples, recent failure logs, and a list of endpoints by [date].
• Seller to prepare a tailored test harness and mapping baseline for the chosen workflows.
• Assign technical contacts and test accounts with required permissions and network access.
• Document the agreed one‑sentence current state, consequence, and future state in the meeting notes.
• Re‑state Problem, Consequence, Future State
• Demonstrate that end‑to‑end mappings and routing resolve the documented failure modes for the prioritized workflows.
• Produce measurable performance data (throughput/latency) tied to acceptance criteria.
• Verify that error handling paths produce actionable alerts, retries, and audit artifacts required for compliance.
• Obtain explicit customer validation at each checkpoint that the observed behavior aligns with their expectations.
• Seller to export and share run artifacts (message traces, transformation logs, audit reports) for each scenario.
• Customer to review artifacts and annotate any mismatches or unexpected behaviors.
• If defects found, log tickets with severity and target remediation owner and timeline.
• Schedule re‑run dates for any scenario that failed to meet acceptance criteria.
• Write the One‑Sentence Current State
• Generate Sample Audit & Exchange Reports
• Triage Unresolved Issues & Risk Register
• Inject Connection & Endpoint Failures
• Scenario 1: Critical Workflow Run (e.g., Lab Results -> Ordering Provider)
• Quantify the Consequence
• Validate Data Lineage, Consent & Masking
• Inject Message Corruption & Mapping Edge Cases
• Acceptance Criteria Review
• Scenario 2: Secondary Workflow Run (e.g., ADT -> HIE / Payer Exchange)
• Observe Error Handling During Runs
• Gap Review & Remediation Plan
• Observe Monitoring, Alerts & Operator Flow
• Decision & Next Steps
• Define The Future State (One Sentence)
• Measure Performance & SLAs
• Confirm Automated Remediation & Escalation
• Confirm Workflows, Interfaces & Data Samples
• Confirm Audit‑Ready Process
• Pre‑work Checklist & Timeline

• Build HL7v2 interface and message mappings
• Deploy FHIR R4 API endpoints and resources
• Configure X12 translation (837/835/270/271)
• Deploy pre-built EHR connector
• Deploy pre-built lab system connector
• Implement message routing and orchestration flows
• Configure real-time monitoring and alerting
• Implement automated error handling and retry workflows
• Map and transform CDA to FHIR documents
• Provision FHIR API gateway and OAuth2 security
• Execute interface integration testing and validation
• Perform go-live cutover and production support

Build HL7v2 interface and message mappings

• Do you require one or more HL7v2 interfaces to be built or updated for this engagement? Options: Yes, No
• Which HL7v2 message types must be supported? Options: ADT, ORM, ORU, MDM, SIU, ACK, Other
• What are expected daily and peak message volumes for HL7v2 traffic? Options: Less than 1,000/day, 1,000–10,000/day, 10,000–100,000/day, More than 100,000/day
• Which systems will be the primary senders and receivers for HL7v2 messages (system names and environments)?
• Who will own detailed segment/field mapping definitions and sign-off? Options: Customer, Vendor (we), Shared (customer + vendor)
• Do you use custom Z-segments or site-specific HL7 extensions that require mapping? Options: Yes, No
• What acceptance criteria should we use to validate HL7v2 mappings (e.g., sample messages transformed, percent match, error rate)?

Deploy FHIR R4 API endpoints and resources

• Do you need FHIR R4 API endpoints provisioned and configured? Options: Yes, No
• Which FHIR resource types must be exposed or stored? Options: Patient, Observation, Encounter, DiagnosticReport, Condition, Claim, ExplanationOfBenefit, Practitioner, Other
• What operations are required on these resources? Options: Read, Search, Create, Update, Delete, Subscribe
• What is the expected API throughput (requests per second) and acceptable latency SLA? Options: <10 RPS, 10–50 RPS, 50–200 RPS, >200 RPS
• Will you provide FHIR profiles/implementation guides or should standard DSTU2/R4 profiles be used? Options: Customer provides IGs/profiles, Use standard R4 profiles, Vendor to propose profiles, Other
• Are there specific compliance or certification requirements (e.g., ONC API attestation, TEFCA readiness)? Options: Yes, No
• Who will be responsible for mapping source data to FHIR resources? Options: Customer, Vendor (we), Shared

Configure X12 translation (837/835/270/271)

• Do you require X12 translation for any transaction sets (837/835/270/271)? Options: Yes, No
• Which transaction sets are in scope? Options: 837 (Professional), 837 (Institutional), 835, 270/271, Other
• How many trading partners will you onboard for X12 exchanges initially? Options: 1–5, 6–20, 21–50, 50+
• Do any trading partners require testing/certification in a payer/test harness environment? Options: Yes, No, Not sure
• Who owns X12 mapping and validation rules? Options: Customer, Vendor (we), Shared
• Are there envelope/ISA/GS values, acknowledgements (TA1, 999) or EDI control requirements we should plan for? Options: Yes, No
• What acceptance criteria confirm X12 translation success (e.g., test scripts, partner ACKs, % pass rate)?

Deploy pre-built EHR connector

• Do you want us to deploy our pre-built connector for your EHR? Options: Yes, No
• Which EHR product and version are you using? Options: Epic, Cerner/Oracle, Meditech, Allscripts, Athena, Other
• Which connector modes are required? Options: Inbound (receive), Outbound (send), Bidirectional
• What authentication method does the EHR support for the connector (API keys, OAuth2, mTLS, other)? Options: API Key, OAuth2/SMART, mTLS, Username/Password, Other
• Is development/test access to the EHR environment available for connector configuration and testing? Options: Yes, No
• Will the connector require any customization beyond the pre-built adapter (e.g., custom fields, workflows)? Options: Yes, No
• What criteria constitute successful connector deployment (e.g., sample flows, end-to-end test cases, uptime)?

Deploy pre-built lab system connector

• Do you need a pre-built lab system connector deployed? Options: Yes, No
• Which lab system(s) and versions are in scope? Options: Sunquest, Orchestra/Orchard, LabCorp/Quest interfaces, Other
• Which message types must the lab connector support (orders, results, accessioning, ORU)? Options: Orders, Results (ORU), Accessioning, Other
• Is mapping to LOINC or other terminology required for lab results? Options: Yes, No
• What is the expected daily lab message volume and peak windows? Options: <500/day, 500–5,000/day, 5,000–50,000/day, >50,000/day
• Are there special order/result workflows (stat orders, batching) that the connector must handle? Options: Yes, No
• What acceptance tests will validate the lab connector (e.g., sample ORU verification, LOINC mapping checks)?

Implement message routing and orchestration flows

• Do you require configurable routing and orchestration flows for message processing? Options: Yes, No
• What routing rules are needed (by message type, facility, patient ID, payer, custom header)?
• Should orchestration include conditional logic (e.g., enrichment, branching, parallel calls)? Options: Yes, No
• Are there transactional or ordering guarantees required (exactly-once, at-least-once, idempotency)? Options: Exactly-once, At-least-once, Idempotent processing required, Not required
• Do you require durable state/long-running workflows (e.g., wait for multiple messages before continuing)? Options: Yes, No
• Who will maintain orchestration logic after handover? Options: Customer, Vendor (we), Shared
• What operational acceptance criteria for routing/orchestration should we validate (e.g., end-to-end latency, success rate)?

Configure real-time monitoring and alerting

• Do you want real-time monitoring and alerting configured for these interfaces? Options: Yes, No
• Which events should trigger alerts? Options: Message failures, Connector down, Throughput drop, Latency spike, Security events, Custom
• What alert threshold or SLA values should we enforce (e.g., >1% message error, latency >500ms)?
• What notification channels should be used for alerts? Options: Email, PagerDuty/On-call, Slack/Microsoft Teams, Syslog/SIEM, SNMP
• What metric retention and dashboarding window do you require (e.g., 30/90/365 days)? Options: 30 days, 90 days, 365 days, Other
• Do you require role-based dashboards for different teams (SRE, Integration Ops, Security)? Options: Yes, No
• What acceptance criteria confirm monitoring is operational (alert test, dashboard accuracy, alert delivery)?

Implement automated error handling and retry workflows

• Should the platform automatically retry transient failures? Options: Yes, No
• Which error classes should be retried automatically? Options: Network/timeouts, Remote system busy/429, Temporary schema mismatch, Authentication failures, Other
• Which retry policies do you prefer? Options: Exponential backoff, Fixed interval, Immediate retry then DLQ, Custom
• What should happen on exhausted retries (dead-letter, notify, manual queue)? Options: Dead-letter queue, Notify on-call, Create incident/ticket, Other
• Do you want automated remediation steps for common errors (e.g., auto-resubmit after fix)? Options: Yes, No
• What measurable acceptance criteria define successful error automation (e.g., % auto-resolved within X hours)?

Map and transform CDA to FHIR documents

• Do you require transformation of CDA (C-CDA) documents into FHIR resources? Options: Yes, No
• Which CDA document types are in scope (e.g., Continuity of Care, Discharge Summary, Progress Note)? Options: C-CDA CCD/US Core, Discharge Summary, Progress Note, Other
• Which FHIR resources should the CDA map to (e.g., Composition, DocumentReference, Observation, DiagnosticReport)? Options: Composition, DocumentReference, Observation, DiagnosticReport, Other
• Is terminology mapping required (LOINC, SNOMED CT, ICD), and will you provide mapping tables? Options: Yes - provide mappings, Yes - vendor to map, No terminology mapping needed
• Are XSLT or transformation templates already available, or will they need to be authored? Options: Templates available, Templates need to be authored, Partially available

• Statement of Work (SOW)
• Master Services Agreement (MSA)
• Business Associate Agreement (BAA)
• Data Processing & Compliance Addendum
• Commercial Terms & Pricing Attachment
• Service Level Agreement (SLA) & Performance Targets
• Acceptance & Go/No-Go Criteria
• Implementation Schedule & Milestone Sign-off
• Operational Readiness & Governance Plan
• Support & Escalation Matrix
• Change Control & Change Order Process
• Third-Party Connectors & Dependency Acknowledgment
• Rollback, Recovery & Incident Response Agreement
• Termination, Data Handover & Exit Plan
• Security & Audit Rights Addendum

• Success Review & Formal Acceptance
• Operational Handoff & Steady‑State Runbook
• Post‑Go‑Live Hypercare Retrospective (30‑day)
• Continuous Improvement & Enhancement Planning
• Governance, Compliance & Quarterly Escalation Review

• Define the governance path for approving and deploying future enhancements.
• Hypercare Summary Snapshot
• Validate that major incidents have remediation plans and timelines for permanent fixes.
• Agree on whether hypercare is complete, or document extension scope and duration.
• Capture lessons learned to update runbooks, monitoring, and design standards.
• Create and assign tickets for all permanent fixes with priorities, owners, and verification criteria.
• Update runbook and monitoring thresholds based on lessons learned and distribute to ops teams.
• Schedule any necessary follow‑up verification tests and a 90‑day stability review.
• Collect Enhancement Requests
• Establish a prioritized backlog with clear owners, timelines, and acceptance criteria for the next 90 days.
• Align on release cadence and resource commitments to deliver high‑priority items.
• Introductions & Objectives
• Create backlog items in the shared tracking tool with priority scores, owners, and acceptance criteria.
• Publish the planned release calendar and assign engineering and operations owners.
• Initiate intake process for urgent regulatory changes with expedited approval steps.
• SLA & KPI Performance Review
• Confirm SLA compliance status and agree remediation for any shortfalls.
• Ensure regulatory obligations are tracked, resourced, and on schedule.
• Maintain alignment between operations, product roadmap, and governance owners.
• Update the SLA performance dashboard and distribute to governance stakeholders.
• Assign owners and deadlines for regulatory actions and high‑severity escalations.
• Publish governance minutes with RACI updates and schedule the next quarterly review.
• Obtain customer decision to accept the solution or document a time‑boxed remediation plan.
• Confirm that each success signal has measurable evidence and a named owner for any open items.
• Produce a clear acceptance artifact (signed checklist or recorded decision) and next steps.
• Publish acceptance checklist with linked evidence artifacts and obtain customer sign-off.
• Create remediation tracker for any open items with owners, severity, target completion, and verification steps.
• Schedule a re‑review date (if acceptance deferred) or transition meeting into steady‑state ops.
• Runbook Walkthrough
• Transfer ownership of the runbook and confirm that customer ops has read/write access to necessary tools.
• Agree monitoring thresholds and the exact alerting flow into customer on‑call and ITSM systems.
• Document escalation owners and ensure security/access controls meet the customer's governance requirements.
• Publish final runbook to the shared repository and notify all ops stakeholders.
• Provision dashboard access and configure alert integrations into customer paging/ITSM systems.
• Record and distribute the on‑call roster and escalation contact list; confirm rotation start dates.
• Open High‑Severity Escalations
• Impact vs Effort Prioritization
• One‑Sentence Current State
• Monitoring, Alerts & Dashboards
• Major Incident RCA Summaries
• Evidence Review: Success Signals
• Regulatory & Compliance Update
• Operational Pain Points & Customer Feedback
• Define Acceptance Criteria & Success Signals
• Escalation Paths & On‑Call Roster
• Customer Validation Demos
• Change Control & Maintenance Window Agreement
• Architecture & Technical Debt Review
• Release Cadence & Resource Allocation
• Permanent Fixes vs Workarounds
• Governance Actions & Next Quarter Goals
• Open Issues & Risk Register
• Hypercare Close Decision & Next Steps
• Access, Roles & Security Controls
• Governance & Approval Workflow
• Acceptance Decision & Next Steps