Title – NwHIN CAQH/CORE X12 support Discussion Date June

Understanding of Scope As a CONNECT adopter using the CONNECT gateway(CMS), I would like the gateway to support CAQH CORE X12 Document Submission service transactions within the NwHIN specifications framework so that I can exchange health data with my trading partners that support CAQH Core compliant transactions with X12 payload 2

Phase 1 – Current understanding of Gateway Requirements Ability to send NwHIN CAQH CORE X12 Document Submission transactions with X12 payload Ability to receive NwHIN CAQH CORE X12 Document Submission transactions with X12 payload Ability to support both synchronous and deferred modes of transaction for X12 document submission Support the transactions in pass-through mode at the gateway. Support error reporting for exceptions generated at the gateway via SOAP faults 3

Phase 1 - Interface Requirements at gateway Support NwHIN interface and endpoints for NwHIN CAQH Core X12 service Support Entity interface and endpoints for NwHIN CAQH Core X12 service Support Adapter interface and endpoints for NwHIN CAQH Core X12 service Create reference adapters for CAQH X12 service – Adapters would be NoOp implementation which returns a successful Acknowledgement as response message. –Sample non-production reference adapters 4

Phase 1 – Current assumptions for gateway X12 payload type will have no impacts on the synchronous or deferred pattern as defined in the NwHIN CAQH Core X12 DS specification Scope does not include any translation or X12 creation or conversion at the gateway. The assumption is that X12 payload generated by the CMS adapters will be wrapped within the NwHIN framework specifications by the gateway. –Priority 1 – 278 Health Care Review and Response related payloads generated by the adapter layer 278 Request BatchReceiptConfirmation - deferred only? CoreEnvelopeError TA1 Interchange Acknowledgement 999 Implementation Acknowledgement 824 Application Acknowledgement?? 278 Response 5

Phase 1 Error handling discussion– gateway vs adapter 6

NwHIN CAQH CORE X12 Synchronous workflow 7

NwHIN CAQH CORE X12 Deferred workflow 8

WSDL and sample messages Based on NwHIN X12 Specification 1.0, we have identified the NwHIN interface with required operations is listed below: –Real time Transaction: X12 Document Submission Synchronous messaging. –Batch Transaction: X12 Asynchronous messaging. X12 Document Submission Request X12 Document Submission Response An Entity interface to generate the request message will be provided for the edge clients. An Nwhin Inbound/Outbound interface to communication with agencies in NwHIN network. A light weight reference Adapter returning an Acknowledgement are part of the CONNECT Gateway. 9

Testing Plan (To be discussed) 10

Current understanding of Phases Phase 1 –Synchronous and Deferred mode for NwHIN CAQH Core DS transactions at the gateway –Pass-through mode of gateway. Future phases –Policy check –Auditing –Event logging – AOR analysis and development 11

Open Questions and Discussion items - Specifications Would the sender know ahead of time the mode that it wants to support - Synchronous or Deferred? We are trying to understand how different the X12 modes are in comparison to the NwHIN Deferred workflows. In the NwHIN Deferred paradigm the Synchronous and Deferred were separate endpoints, so you would need to target a separate endpoint if you wanted to do a Deferred transaction. Will you have two notifications i.e., deferred responses for the same deferred request one for delivery, other for pickup etc.? For all X12 transactions? – >In the message interaction diagram below, each request and corresponding response (e.g., 1 and 1a) is a CAQH CORE Generic Batch. The combination of three Generic Batch message interactions shown below is equivalent to IHE’s Deferred Document Submission interaction. 12

Open Questions and Discussion items In a Synchronous mode, how will the two notifications paradigm work? Or is it not possible ? What is the workflow for 278 work in real-time /synchronous mode? What are expected responses to a 278 request? Will the CoreEnvelope element be the same for every response type in the case of synchronous mode ie. CoreEnvelopeRealTimeResponse? Assertion Type to include NPI Provider Name – this is not defined in the NwHIN Authorization Framework spec. or the underlying OASIS/XSPA profile. Digital signatures and AOR requirements for future phases Follow-up on sending multiple documents. 13

Open Questions and Discussion items See wiki page open questions related to WSDLs- CTWIKI/CONN CTWIKI/CONN-1167 –For batch transactions – need to clearly understand the Core Envelope element type for all deferred requests and responses for 278. –Can you respond to a 999 with a TA1 or vice versa or will it only be a BatchReceiptConfirmation or CoreEnvelopeError? –Can you respond to a 999 with a 999 or TA1 with a TA1 or will it only be a BatchReceiptConfirmation or CoreEnvelopeError? Digital signatures and AOR requirements for future phases Specification related dependencies 14

Next steps 15