Title – NwHIN CAQH/CORE X12
support Discussion
Date June 23 2014
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
payload(CAQH Core envelope/metadata + 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
5
• 824 Application Acknowledgement?? (still open discussions on this to utilize 278 response or
824 or both)
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
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
–
10
AOR analysis and development
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.
• RESPONSE : 6/23/2014 - 278 will use Deferred mode only. CMS may need
synchronous for other X12 transactions. The question is still open on whether the
sender would know ahead of time.
• 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?
• <<Snippet from NwHIN service spec>>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.
11
• RESPONSE : 6/23/2014– You could have more than 3 notifications too for deferred
transactions.
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?
– RESPONSE : 6/23/2014– 278 will be in Deferred mode only. Need further
discussion on WSDLs and detail related to response.
• Assertion Type to include NPI Provider Name – this is not
defined in the NwHIN Authorization Framework spec. or
the underlying OASIS/XSPA profile.
– RESPONSE: 6/23/2014 - NPI Provider Name not needed for now. CMS business
team will follow-up
• Digital signatures and AOR requirements for future
phases
12
• Follow-up on sending multiple documents.
Open Questions and Discussion items
• See wiki page open questions related to WSDLshttps://connectopensource.atlassian.net/wiki/display/CONNECTWIKI/CO
NN-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?
RESPONSE: 6/23/2014 Specifications were created by CMS team. Walter/Swati and
QSSI team to look at the discrepancies identified on the wiki page created by CONNECT
team and help with getting responses. Critical for development.
BatchReceiptConfirmation, CoreEnvelopeError, 999, TA1 are all generated at adapters.
Gateway concerned with SOAP faults that need to be generated and in scope at the
gateway
• Digital signatures and AOR requirements for future phases
• Specification related dependencies
13
Next steps
14