Blog from October, 2019

Discussion on the last point from October 18th:

1. Current requirement for the use of Direct addresses:
   • The From address in the initial request SHALL be used by the recipient to send back an accept or decline
2. Add the following
   • When the recipient sends an Accept response back to the initiator, the From address MAY be different from the To address on the initial request.
   • If the initiator receives an Accept response with a From address which is different from the To address used on the initial request, it SHALL process the response properly based on the patient and referral identifiers in the metadata. Any further transactions from the initiator to the recipient can use either the new From address or the original To address as the destination.
   • If an Accept response is sent back to the initiator with a From address that is different from the To address on the initial request, the recipient SHALL be able to process any further transactions from the initiator on either of these two addresses.

1. Reviewed the sequence diagram showing multiple requests, multiples accepts, a declines, confirmation, and cancel.
   1. When the list of possible facilities is made, or when the selection of the particular facility is made, the specification will note that the patient (or a delegate) will be provided with the required quality information per the latest CMS rule.
2. Discussion on what "closing the loop" means, and whether we need to be explicit about it
   1. The "administrative" process of transferring is complete with the physical discharge. In the 360X SNF use case, this will be represented as the Discharge Transaction, which will contain
      1. a C-CDA document representing the reconciled medication list, relevant clinical information, and assessments.
      2. An HL7 v2 message indicating a Complete status.
   2. The "clinical" process may continue after the the physical discharge - diagnostic results, final discharge summary, and other clinical information, which still needs to be properly communicated to the SNF. Several points came up in the discussion:
      1. Post-transfer communications SHOULD take advantage of the unique patient ID provided by the hospital as part of the request. Using the referral ID is not appropriate. The SNF SHOULD properly update the patient chart with the additional clinical information.
      2. The completed Discharge Summary SHALL be sent to the SNF. (Note: this is not a 360X-specific transaction, it is part of communicating the Discharge Summary to the patient/delegate and the patient's care team) 
   3. A lot of communications between the hospital and the SNF happen in the hours before and after the actual transfer, and this information is essential for the quality of the transfer.
      1. These communications do not represent a particular change of state of the transfer, and are therefore not a part of the 360X SNF Use case.
      2. One possible way to address this communication need could be a companion Implementation Guide that profiles the HL7 FHIR Questionnaire and QuestionnaireResponse resources
   4. A patient-centric discharge process, where the patient (or their delegate) is kept properly informed of their condition and necessary next steps, is a more general problem than the 360X SNF use case.
      1. A well executed discharge process has a great impact on the transfer
      2. The 360X SNF use case can indicate the places in the descriptions of the various transactions where the patient/delegate needs to be made aware of the appropriate information.
3. Question: is there any guidance on the Direct address to be used in the response?

Short call:

Ongoing work on IHE specification updates

360X testing

• 10/17 testing will be smaller scale
• 11/5 and 11/7 as scheduled
• Tentatively, 11/19 and 11/20 will be the next testing session, to be confirmed at the next call

Discussion of possible options in addition to current 360X LTAC transactions:

• There are similarities between the workflow steps for LTAC transfers, and request for extra-clinical services.
• The scope and need for clinical data is vastly different, the distinction between HIPAA and non-HIPAA partners needs to be taken into account
• BSeR has already defined content for extra-clinical referrals as FHIR resources
• A fully FHIR-based solution requires wide adoption of an underlying infrastructure, which will not be present for a while (e.g. Argonaut FHIR Subscription IG is in development, earliest publication date is beginning of 2021 )
• A possible mixed approach was discussed, consisting of
  • push HL7v2 messages for the Request and Confirmation steps, and
  • RESTful FHIR reads and updates to get appropriate clinical data (for the SNF case, a C-CDA as the content of a DocumentReference resource; for the BSeR case, the appropriate Observation Resources).
• The conclusion was that this was an interesting idea, but at this point the effort should be on completing the 360X based approach for NSF transfers.

Question about the Cancel transaction, when it is used to indicate that the facility was not chosen: do we follow the Cancel Request/Cancel Confirmation pattern described in 360X? Conclusion: No, this has a specific meaning, not to be confused with a Cancellation request. Will need to make sure this case is easily distinguishable from a generic 360X Cancel.