Versions Compared

Old Version 1

changes.mady.by.user Vassil Peytchev

Saved on

compared with

New Version Current

changes.mady.by.user Vassil Peytchev

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  1. Reveiw outstanding work on agreed upon topics:
    1. Anchor
      InsOption
      InsOption
      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