Kno2 Direct payloads need receiver ingestion contracts

Delivery, interpretation, and use are separate states

The direct answer is to define a receiving contract for each Direct message type. Kno2 documents a route that can carry structured and unstructured payloads, including PDFs, C-CDA, HL7 v2, and FHIR JSON. The envelope can reach an address while the attachment remains unreadable to the receiving application, is associated with the wrong chart, contains unsupported versioned content, or needs a human review before clinical use. One “delivered” status should not silently become “ingested,” “reconciled,” or “acted upon.”

A practical contract identifies sender and receiver organizations, permitted purpose, Direct address, message and attachment identifiers, content type, profile or implementation guide where relevant, patient matching rules, destination queue, responsible role, validation rules, acknowledgment type, retry policy, error handling, retention, and escalation. Keep the original envelope and payload alongside transformations and chart entries. A downstream C-CDA summary, HL7 event, or PDF referral may need materially different handling even when all three use the same transport.

Make payload semantics testable at the receiver

For structured content, test whether the receiving system accepts the exact version, vocabulary, identifiers, time zones, provenance, null values, and extensions it will see in production. For a document, test whether patient and author identity, encounter context, page completeness, and attachments survive routing. For a PDF, a viewer may display the file while discrete medication, allergy, or result reconciliation remains a manual step. For a FHIR JSON resource carried as a file, transport does not imply that a FHIR server accepted a transaction or that an implementation guide was met.

A send-side receipt, transport acknowledgment, application acceptance, clinical reconciliation, and action completion should each have a time, identifier, actor, and error state. Replays and retries should use stable message identity and duplicate controls, especially after a receiver outage or demographic correction. When content conflicts with the existing chart, the receiving team should see the discrepancy and source rather than overwrite the old record.

Test the promise with mismatched payloads

A buyer test should send a supported C-CDA, a PDF with multiple attachments, an HL7 v2 message, and a FHIR JSON payload through the documented Kno2 route to the actual receiver. Include a patient identity ambiguity, an unsupported code, a duplicate retry, and a delayed acknowledgement. Capture the source message, delivery status, validation results, receiving queue, chart or work-item output, human disposition, and any response to the sender. This reveals which steps Kno2 performs, which the recipient performs, and which remain local policy.

Kno2’s page supports its attributed connectivity positioning and payload examples; it does not prove interoperability with every EHR, recipient endpoint, clinical workflow, exchange purpose, or content standard. A contract should allocate responsibility for address management, mapping, parsing, patient matching, exception work, support, and quality measurement. The fact that one connector handles multiple formats does not erase those boundaries.

Evidence boundary and next watch

This is an independent analysis of Kno2’s official Direct page as reviewed September 21, 2026. We did not send a message, inspect a customer configuration, observe a recipient workflow, or validate conformance, privacy authorization, clinical safety, or outcome. Direct’s transport model and the provider’s product claims are distinct from the recipient’s implementation and governance.

Watch for dated Kno2 documentation that specifies supported payload versions, acknowledgments, errors, and route availability. Buyers should update test cases and receiving contracts only for documented, demonstrated behavior and should retain earlier results for historical messages. The durable decision is whether the receiving organization can prove each state after secure delivery.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.