Blog

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.

The ISA proposal was submitted, and can be seen at https://www.healthit.gov/isa/sites/isa/files/2019-09/2019_ISA_Comments_Approval_Final%20Submitted_2.pdf

Discussions on preparations for the HIMSS Interoperability Showcase Demo

Review of outstanding specification work

Details on the ISA proposal (due September 23rd):

The list of standards for each of the three sub-sections:

• Closed Loop Referral to Specialist:

  • CDA R2

  • C-CDA 2.1 - in production, highly used

  • 360X - pilot stage

• Referral from Acute Care to SNF
  

  • CDA R2

  • C-CDA 2.1 - in production, highly used

  • 360X - Long term care transfers, request for comments stage

• Closed Loop Referral to Extra-Clinical Services

  • FHIR R4 Observation

  • FHIR R4 ServiceRequest

  • FHIR R4 Task

  • FHIR R4 Messaging

  • BSeR Implementation Guide

The proposal will be distributed on the mailing list, and a sign-up sheet will let participants provide individual or organizational support.

Discussion on updates for the Interoperability Standards Advisory (ISA):

• Currently 360X is under
  • Section II: Content/Structure Standards and Implementation Specifications
    • Summary Care Record
      • Support a Transition of Care or Referral to Another Healthcare Provider
• We need a better presentation. We will propose the following:
  • Under section II create a new sub-section, called "Care coordination for referrals"
  • Within that, list three sub-sections:

    • Closed Loop Referral to Specialist

    • Referral from Acute Care to SNF

    • Closed Loop Referral to Extra-Clinical Services

Discussion on proper handling of clinical data after a decline

• The 360X Implementation guide doesn't say anything, but in demos it is emphasized that after a decline the clinical information is removed from the recipient's system
• The IG doesn't specify anything on that, because it is specific to different situations. If the patient had not been seen by the recipient before the request, then it is up to local or jurisdictional policies what to do with the clinical data. The ability to purge data in this case is a system feature, but no general requirement can be made
• There are cases when it is against  local or jurisdictional policies to purge the clinical data after a decline. In the case of SNFs, the information is needed to justify the decline in the case of an audit.
• Probably needs clarification/short discussion in the IG.

Question about where the reason for cancel is located - it is in ORC-16

A request for sample 360X messages

How does pre-authorization work happen in LTAC transfers? Medicare vs. non-Medicare patients

• Transfer pre-authorization
  • pre-authorization not needed for Medicare patients
  • Most insurance companies have contracts with LTAC facilities, and these transfers do not need pre-auth
  • Only transfers to non-contracted facilities may need pre-authorization
• Medication pre-authorization
  • Medicare patients - since LTAC falls under Medicare Part A, there is no-need for pre-authorizations. Medication treatments are covered under PDPM rules. Note: if the transfer is not to LTAC. but for assisted living, then medications may fall under Medicare part D, and pre-auth may be necessary.
  • Non-medicare patients - private insurance rules vary, pre-authorization may be needed. Sending the coverage information is therefore important, and a clean medication list is critical,
• Based on the above, communicating pre-authorization numbers as part of the request and transfer process is not considered of immediate importance

Initial dates for testing sessions:

• October 17 (and if needed, use the regular call time on the 18th)
• November 5th and November 7th

Report from the ONC Interoperability Forum demo:

• Demo went very well, we got postivie feedback
• Dr. Terry O'Malley: "You guys rock!"
• Many thanks to Dr. Miller and Brett Andriesen for organizing the demo, and to the team from eClinicalWorks, Epic, Medallies, Netsmart, and Qvera for the hard work.
• We made it to Twitter:
   

  Error rendering macro 'widget'

  java.lang.IllegalArgumentException: The provided url- https://api.twitter.com/1/statuses/oembed.json?id=1164243552722927616&omit_script=true&lang=en is not included in the whitelist!.Please add the url to whitelist to allow access

Review of outstanding work, and a discussion on related items that can make the LTAC/SNF specification better:

• Possible future enhancement would be to add a reminder message from the SNF to the hosptial to have the patient properly prepped.
• Maybe we can work with quality measuremnts to reflect the timeliness and completeness of information exchange, and reflect patient satisfaction.
• The US CDI had a lot of coverage at the ONC Interoperability Forum, and they are planning an update mechanism, where more data classes and element will be added over time. If there is a way to have context-specific core data, that will be a great opportunity to add LTAC/SNF transfer information to US CDI in the future.
• Before we can make suggestions for additions to USCDI, we need to determine the gap between the mandated assessment data that the SNFs need (i.e. the Data Element Library), and what is sent by the hospital. A possible path forward may be:
  • Survey existing discharge summaries to see if nurisng assessments are already part of the data
  • Find out what nursing assessment data is in the various EHRs by the time the patient is transferred to SNF
  • Compare the above information to the data grid that we reviewed, possibly provide a crosswalk between hospital nursing assessements and SNF assessments
  • Use the existing hospital data as a beaseline to introduce quality measures for timeliness and completeness of data (Terry O'Malley to reach out to Beth Connor in CMS)
  • Start a process of improvement in order to get the appropriate data to the SNF

The ONC Interoperability Standards Advisory is taking comments for the next publication of the list. Currently, 360X is under Section II, Summary Care Record, Support a Transition of Care or Referral to Another Health Care Provider. We would like to give more visibility both to the 360X for Clinical Consultation Referral guide, and to the new in-progress 360X for transitions to SNF guide. Over the next couple of meeting we will develop a comment in that regard to be submitted to the ONC before the deadline on September 23.

Call was cancelled due to preparation for the ONC Interoperability Forum demo.

Short call, reviewed the SNF transfer transactions as discussed in the last call. Update on the demo preparation for the ONC Interoperability forum.

Reviewed discussions on Argonaut Scheduling and 360X. Both workflow alternatives have pros and cons. One of the options to add the referral information is to include a service request resource during the creation of the schedule.

Update on the demo preparations for the ONC interoperability Forum.

Discussions on how to indicate the different steps of the workflow (as illustrated here). The following conclusions were made:

• The acute facility will identify the requested date and time for the patient transfer in the TQ1 segment (starting time). The SNF can also idicate the exact time they can accept the patient using ORC-27 in their accept message.
• The confirmation will be indicated by the ORC-1 and ORC-5 fields: ORC-1 set to SC and ORC-5 set to SC. A reminder that all other accepted facilitites need to receive a cancelation.
• The discharge transaction will have the HL7 OSU message as follows: ORC-1 set to SC and ORC-5 set to CM. The current agreement is that once the patient is discharged, the loop is closed.

There is a need to clarify that the transaction diagram reflects the multiple recipients of the request. Need to change the diagram. 

Continued discussion on using Cross-organizational FHIR scheduling (Argonaut Scheduling) with 360X. The following topics were discussed:

• Sequence of steps
  • Order for referral placed
  • Cross-organizational scheduling of appointment
  • Send Request package
  • Automatic acceptance
• Alternatively, it could be
  • Order for referral placed
  • Send Request Package
  • Accept received
  • Cross-organizational scheduling of appointment
• The first case seems to be better suited for when the patient gets an appontment before they leave the initating provider.
• Open questions
  • How do we link the appointment to the referral?
  • What types of appointments are best suited to be open for cross-organizational scheduling?
  • If the recipient modifies/cancells the apponitment, how will the initiator know? The Argonaut project is working on support for subscriptions, that would be one possible way.

• Spreadsheet with new column for PDPM relevance
• How to convey "confirmation" to the selected facitlity? Possible solutions
  • Status update message with Order Released code (OE) in ORC-1. Note that HL7 specifies that this code is to be used by the order filler (i.e. referral recipient), so it may not be appropirate
  • Add a special code to ORC-1 (hopefully not necessary)
  • Status update message with Status Change code (SC) in ORC-1, and In-process, Scheduled code in ORC-5 (the code is also SC).