Blog from June, 2019

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