Blog

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).

We did not consider the impact of the Independece Day holiday, so the call was adjourned due to low attendance.

We reviewed the CMS presentation on Patient Driven Payment Model for SNFs. Provding current and pertinent information from the hospital to the SNF can greatly enhance the proper documentation required for both appropriate patient care and for recieving payment comensurate to the needs of the patients.

Examples:

• Hospital Admission Diagnosis, and Hospital Discharge diagnosis can be used as input to determining the SHN Admission diagnosis

1. Discussion of cross-organizational scheduling, i.e. the ability of the initiator to directly schedule an appointment at the receipient's organization. A current specificaiton for doing that is the Argonaut Scheduling Implmentation Guide, which already haas some implementations.
   From the overall 360X workflow, we need to consider the following:
   1. As part of the referral initiation process, the initiator org schedules the patient at the recipient org, and then the referral request is sent to the recipient. The initiator's system needs to reflect the information about the scheduled visit.
   2. It is expected that in most cases the recipient will send an accept, and any changes to the appoinment after that will be handled via the Argo Scheduling mechanism to be conveyed back to the initiator (need to verify that), and the patient needs to be contacted (which is always the case, including with the existing 360X scheduling option.
   3. In rare cases where the recipient needs to decline, they need to cancel the already made appointment, and make sure the patient is contacted and made aware of that a new referral is needed.
   4. Discussion:
      1. We need to make sure it is clear that the ability to do cross-organizatiional scheduling usually implies a close business relationship, and thus scheduled apponitments for referrals are not expected to end up as declined referrals due to the recipient not being the appropriate provider for that patient.
      2. It is likely that Argo Scheduling needs any pre-auth to be done in order to justify allowing the appointment to be made. If that is the case, sending the pre-auth number may be required. We need to see if the Argonaut project have considered this, and whether 360X should make the insurance information option (and the a pre-authorization number) as required when cross-organizational scheduling is used.
      3. It is a good idea to create a companion diagram to visualize cross-organizational scheduling.
      4. Note: in the SNF case, CMS/Insurance is also very important, low income patients may be discharged to shelter.
2. Review of topics from the June 7th call
   1. Insurance infomation option - still work needs to be done
   2. eCQM measure 50 - Brett provided the value sets, Next step is to confirm with eCQM experts on what to include in Event Code List (if still necessary).
   3. Sending prior authorization information from initiator to recipient - reviewed the options, and an e-mail will be sent to request review and opiniions on the topic.
3. Review of initial scenario for ONC Interoperability Forum demo.

• Continue work on Data Elements spreadsheet. 
• Noted the distinction between headings and subheadings, will update the Google sheet to properly reflect the hierarchy
• PDPM - effect of new payment rules to data requirements. A CMS slide deck will be sent to the mailing list for education.

1. Reveiw outstanding work on agreed upon topics:
   1. insurance information option: this is an optional feature which implmeneters can claim, and defines the inclusion of the IN1 and GT1 HL7 v2 segments in the initial request (required for this option), and well as payer information in the referral note (otpional)
      1. add to IG wiki
      2. create and submit a Change Proposal (CP) to IHE PCC for inclusion in 360X profile.
   2. add information on how to incorporate the appropriate codes or eCQM measure CMS 50 "Closing the Referral Loop: Receipt of Specialist Report" (currently on version 8). The codes will be sent in the Event Code List in the metadata. Outstanding steps:
      1. retreive the value sets specified in the measure (identified by their OID) from the Value Set Authority Center at NLM and determine which codes are appropriate. Initial arget are the value sets for: "Consultant Report" (2.16.840.1.113883.3.464.1003.121.12.1006) and "Referral" (2.16.840.1.113883.3.464.1003.101.12.1046)
      2. add the guidance to the IG wiki
      3. create and submit a Change Proposal (CP) to IHE PCC for inclusion in 360X US Natianl extension
2. Topics agreed to in principle, but no detailed discussions yet:
   1. How to combine Argonaut Scheduling and 360X so that from a user's point of view there are few, if any, differences from the way 360X with the scheduling option is supposed to work.
      1. We will discuss at next meeting
3. New topic: Prior authorizations done by the referral initiator.
   1. Background: The development of 360X has stayed away from any interactions between providers and payers, as these interactions are governed by HIPAA and there are existing well-established workflows for them. The "products" of these interactions, however, are of interest to 360X, as the information is in many cases useful to be shared between referral initiator and referral recipient. This is what the insurance information option provides - since in most cases the referral initiator would have verified the coverage for the patient, so they can send the coverage information under which the referral is made to the referral recipient. In many cases, the referral recipient is the one who then performes any pre-authorization steps if necessary. Having the insurance information available helps with that task.
      There are cases, however, where the referral initiator will perform the pre-authorization check, and the approval then needs to be sent to the referral recipient. One example of when this might happen is when the initiator's organization is both the provder and the payer. In order to handle this, we need to determine how that information will be sent.
   2. Options to consider:
      1. Require the insurance option and send an authorization number in IN1-14. The format for this field is <Authorization Number (ST)> ^ <Date (DT)> ^ <Source (ST)>. The benefit of this is that we will be using the underlying standard without any changes to it. The downside of using this option is that this provides only very limitted information about the authorization.
      2. Change the implementation guide from using the OMG^O19^OMG_O19 message to using the REF^I12^REF_I12 message (chapter 11 of the HL7 V2 standard). Note that we discussed using the REF message when we started the project, and at that time we decided against it for two reasons: the definition of the referral identifier field, RF1-6 does not currently support the use of OIDs for assigining authority, and there was no extensive exeprience among implementers with REF messages. The problem with RF1-6 can probably be fixed with a change by HL7 to an arguably flawed definition, since the data type (EI) of the field is identical to the ones we use for referral adentifiers in the OMG message, and it seems that there are some cut and paste errors in the exisitng definition.
         The benefit of switching to the REF^I12^REF_I12 message is that we will gain the use of the AUT segment, which has an extensive set of fields to describe the authorization obtained, and there is a well defined PR1 segment to hanlde referrals for procedures (which are slightly different from referrals for consultations).
         The downside is that we will need to get a change from HL7 for RF1-6, that we don't have a good alternative for our use of the TQ1 segment (the RF1 segment defines effective dates for the referral, but not "needs to be seen by" date), and that we need to change the specification to refer to the REF message, which then opens the question on whether status updates are to be sent using REF and RRI messages, as oposed to the OSU message we are now using.
      3. Add the AUT segment to the OMG^O19^!MG_O19 message. The message definition is a general clinical order message, and as such it makes sense that some orders would need prior authorization, and having the AUT segment be part of the message is useful beyond the needs of 360X.
         The benefit of adding the AUT segment to the OMG message is that we will have an expressive way to descibe the authorization information, including a way to convey both the clinical referral request in terms of number of visits and time duration, and the authorized parameters separately. This will nto requrie any changes to the rest of our IG.
         The downside is that we will need to get a change from HL7 to add the AUT segment to the OMG message.
4. Information about demoing 360X at the ONC interoperability forum, and at HIMSS 2020

Continued review of the spreadsheet with data elements, it is now accessible from Google sheets.

Once we complete the general analysis, we will re-evaluate the need for specific sections, entries and document types.

Working on the spreadsheet for data elements for SNF transfer request.

Based on oncreased activity, and upcoming demos and associated testing, we will have weekly call. Starting with next week, May 31, we will have SNF transfer related calls every other calls, and general 360X calls startig June 7. 

1. BSeR Ballot - comments were submitted to HL7. Per Vassil, they were received very positively.
2. SNF Transfer/Referral use case
   
   1. Data in first message – should highlight red flags/conditions SNFs may want to know about in their decision to accept a patient.
   2. New Payment model coming starting October 1 – CMS Patient Directed Payment Model (PDPM) changes the way SNFs are paid from current formula of calculating therapy minutes to higher payment for more medical complexity. Will likely change the information SNFs may want to know in first messages, with more comprehensive list of conditions for treatment at facility. May be harder for hospitals to anticipate what info SNFs are looking for, but 360X could help facilitate.
   3. Facilities have built PDPM calculators to determine cost of treatment vs payment received for patient. 360X should help provide necessary info to enter into PDM calculator. Likely similar to previous information, with some more added. Higher clinical complexity = higher reimbursement.  See attached slide from Terry that includes some of the points for various treatment/conditions. CMS also provides a detailed worksheet for calculation of reimbursement
   4. Certain conditions have higher payment in first 3 days of stay at SNF, which further declines beyond 18 days. HIV/AIDS significantly higher than previous/other conditions. May be difficult to include/highlight due to privacy concerns/patient consent.
   5. SNFs will also need to start using ICD-10 codes in MDS submissions. If hospitals don’t include ICD-10 codes to each diagnosis, adds another burden for SNF staff. Might be good to recommend hospital ICD-10 code use to simplify on SNF end.
   6. For 360X, a reasonable approach could be to specifically call out/highlight anything 2 points or higher from calculator to show patient may be higher reimbursement value. Likely these would be in diagnosis list or in treatments (e.g. IV meds, IV feedings). If called out explicitly, could be helpful in faster decisions from SNFs on accepting patients.
   7. Internal processes may also change at SNFs – MDS specialists currently scour charts for record review within 7 days. Under PDPM, needs to be clinician documented in initial note. Needed by day 5 from initial admission and physical.
   8. More to discuss here for future
3. ONC Interoperability Forum
   1. Registration likely opening in next few weeks. Brett will notify group when open.
   2. No additional updates on session/demo of 360X, but planning work should continue as agenda is still being finalized.

1. BSeR and 360X
   1. What is BSeR? Bidirectional Services e-Referrals, a FHIR-based implementation guide for closed loop referrals to extra-clinical services.
   2. There are obvious similarities, main difference is that requests need to be very targeted, with minimal clinical data.
   3. The BSeR specification is under development, and is undergoing an HL7 ballot. They have requested the 360X project to provide feedback via the ballot.
   4. Vassil will fill out a ballot spreadsheet, and Brett will have it submitted on behalf of 360X.
   5. Main suggestions are to harmonize the state diagram between the two specifications, and to clarify that state transitions are equivalent to transactions
   6. The group will consider some clarifying text for BSeR to reference 360X and note that the two IGs server different use cases, but work together to harmonize their similarities.
   7. It was noted the Gravity Project is attempting to provide terminology for Social Determinants of Health: https://sirenetwork.ucsf.edu/TheGravityProject
2. Long Term Care discussion
   1. We had previously determined that there needs to be a clinical document in support of the SNF referral request step, and a clinical document in support of the patient transfer step. Should we pick one C-CDA document template, or keep with the practice in the base specification, where there is a preferred document template, but others are also possible?
      Outcome: The Transfer of Care document template was specifically crafted to cover transfers to SNFs, and other similar use cases. It defines and references many section templates that contain important information for this process. It is however not widely implemented. It would seem more beneficial to look at what data is needed for referrals/transfers to SNF, and then decide which document templates make sense to contain appropriate sections for these data elements. Terry will start the process.

1. LTC Discussion points
   1. Referral ID - one unique ID per request or one ID per referral intent (i.e. the same ID for all requests for a particular referral)?
      Outcome: At this point one ID per request seems to be a much better approach.
   2. Do we need to have a way to find the facilities with open beds, as a preliminary query or service before the request is sent? How would that fit in the workflow? How likely is it to have facilitates without available beds?
      Outcome: That is not necessary, it is unlikely that the facilities will be full. Additional complexity is not justified for marginal gain.
   3. Do we need to include the patient preference in the request (top preference or ranking preference)?
      Outcome: No, that is not helpful to the SNFs, however, we should note the need for governance on the acute facility side to properly determine how the choice from multiple facilities is to be made
   4. Do we need a light-weight request, the followed by a second transaction with more detailed data only to those who (conditionally) accept it?
      Outcome: No, one of the benefits of electronic referrals is that we can send a well populated request, and it will be either accepted or declined
   5. What is the initial workflow?
      Outcome: Send initial request as populated as possible, respond with committed acceptance, then notification of choice. If not chosen, send Cancel request, if chosen - what do we send? Need a new transaction.
   6. What does it mean to have the initial request as populated as possible?
      Outcome: There seem to be three major determinants for a smooth referral and transition: need for expensive medications (e.g. chemotherapy), need for pain management, or need for specific equipment. If these are in addition to the core data set (demographics, allergies, diagnoses/problem list, key vitals), that should be sufficient for the facility to accept or decline
   7. What other steps do we need to account for?
      Outcome: Sending pertinent information at discharge to the facility, most importantly: reconciled meds. The official, formal discharge summary will likely be created and sent at a later point. 
2. Follow-ups:
   1. List of red flags (Terry)
   2. Initial write-up and diagram (Vassil)
   3. Start process for IHE change proposals on the base specification (Vassil)
3. Announcements:
   1. Presentation to the EHRA
   2. EMDI pilot, and adding 360X as a use case