Blog

1. Update from HIMSS - demo went very well, we will try to show it via Webex on a future call
2. Long Term Care use case
   1. We want to make sure we scope this properly. There are significant differences among Skilled Nursing Facilities, Long Term Acute Hospitals, and Assisted Living Facilities
      1. Assisted Living Facilities would need detailed functional status, dietary requirements, social data, rehab services, if any, are outside of the facility
      2. SNFs usually have rehab capabilities on site; need only baseline functional status
      3. Long Term Care Acute Hospitals - previous (acute) level of care is still needed
      4. Conclusion: Long Term Care use case to focus on Skilled Nursing Facilities (NSF); make sure we don't mix with more general discharge planning or transition of care workflows
   2. SNF Referrals workflow points:
      1. requests to multiple facilities, hospital system must group them together
      2. Negotiations with the facilities until one is selected
      3. Include families in selection process
   3. Topics for further discussion

      1. referral identifier - one per request, or same one for multiple requests,

      2. how to manage negotiations

      3. what is closing the loop in this case

      4. What is necessary content in order to improve patient care

         1. Partners Healthcare has a list of red flags, therapy notes, high cost items that are sent with the request. In their experience, first-come, first-served is he most common approach in selecting the facility
      5. When sending requests to multiple facilities, what is the general approach? Two-step requests?

:

1. Recap of Connectathon testing
   1. Suggestion: Add 360X tests to pre-Connectathon testing
   2. Suggestion: Have a discussion with IHE on how to improve testing at the Connectathon (e.g. make it clear that a single test covers multiple facets of the specification)
   3. Change to specification: There is no need to have two MIME attachments for the request, remove any mention of an unwrapped CDA as a separate MIME attachment, and leave the XDM MIME attachment as the only one.
2. New topic: LTC referrals. Review high level process, identify where interoperability points are, and what is specific about them

   1. Requests are sent to multiple facilities

   1. Configuration

   2. UI indications

   2. Facilities request additional information

   1. How to request the type of data

   1. Clinical notes

   2. Medicare/Medicaid assessment

   3. Discharge summary

   2. Dependent on level of care

   3. What is possible with C-CDA

   4. Questionnaire (auto-populated)

   5. Based on the diagnoses, initial request can be specific, so no additional information is needed

   6. Handling of declined reference

   3. First week after admission in LT

   1. Who is the provider at the acute facility to contact (add treatment team to order)

   2. No current workflow for followup.

   4. nurses going to acute facility to evaluate before discharge - that will not be needed with an electronic process

   5. Standard vocabulary for LT transitions - data elements library, ONC efforts/regulations

   6. Next discussion March 1st.

1. Next testing sessions scheduled:
   1. Wednesday, January 9, 9 am - 1 pm Eastern
   2. Thursday, January 10, 9 am - 1 pm Eastern
      
      
2. Topics from previous discussions/emails:
   
   1. eCQM measure CMS50 - Closing the referral loop:
      
      1. SNOMED codes from value sets in VSAC for the have been added to previous minutes as well as below: 
         1. Referral, 2.16.840.1.113883.3.464.1003.101.12.1046,
         2. Consultant Report, 2.16.840.1.113883.3.464.1003.121.12.1006
            
   2. 360X and LTPAC:
      1. Call scheduled for February 1st - Ann Maldonado of Allscripts will join as an SME to discuss post-acute care
         
         
   3. Determining if an XDR message is a 360X message:
      1. Group seemed to prefer first option listed in Vassil's email: "look at typeCode of the submission set, and look for an HL7 v2 document entry (typeCode alone is not sufficient)"
      2. Action: Question for vendors to bring back to their organizations and discuss on next call (1/18):

         1. Are there cases where typeCode is referral and includes a HL7 v2 document attached via Direct, and it would not be a 360X message?

            
            

3. HIMSS Update: 
   1. Group continues preparations for use case demonstration at HIMSS 2019 Interoperability Showcase. 
   2. White Paper on 360X/closed loop referrals will be submitted to HIMSS for consideration to accompany the demonstration. It will be distributed to the group after submission to HIMSS. 

1. Recap testing from last week
   1. Connectivity established by all Demo participants
   2. Continuing work on minor changes to conform to the XDM part of the specification
2. Next testing sessions:
   1. Wednesday, January 9, 9 am - 1 pm Eastern
   2. Thursday, January 10, 9 am - 1 pm Eastern
3. 360X new topics
   1. eCQM measure CMS50 - Closing the referral loop
      1. The measure is currently at version 7. It seems new versions come out every few months
      2. The measure references a value set for Referral, 2.16.840.1.113883.3.464.1003.101.12.1046, and a value set for Consultant Report, 2.16.840.1.113883.3.464.1003.121.12.1006, both of which contain SNOMED CT codes.
      3. Providers using 360X can easily automate the recording and reporting on the above codes, if there is a place for them to be exchanges
      4. The 360X implementation guide has been enhanced to reference the measure, and provides the guidance for the referral initiator to receive the above codes. See sections 4.3.4. 4.3.7, 7.6.3.3, and 7.7.3.3
      5. It is worthwhile noting that the measure right now only poses requirements on the referral initiator. With the adoption of 360X, there is a now a technical capability that will allow the measure to also determine performance of the referral recipient, which, in turn will make measuring the compliance of the initiator much easier.
         
   2. 360X and long-term care transfers
      1. There is a new area to build that part of the specification
      2. We will hear from SMEs on the topic during the February 1st call.
   3. Adding insurance information
      1. The additional data elements to be added to the HL7v2 message will be part of the Implementation guide
      2. Potential additional means to determine in-network or preferred providers can become a separate area.
4. Enjoy the holidays and Happy New Year!

1. Recap of testing on October 22 and 24
   1. Successful connectivity testing by some of the newer participants
   2. Discovered a previously unknown issue in the implementation of Direct
2. Recap of HITAC Interoperability Standards Priorities Task Force meeting
   1. The meeting went very well, there was a good reception from the Task Force members
   2. The presentation slides are online and there is a video of the presentation as well (requires Flash plugin or Adobe Connect app)
3. New test dates
   1. Either November 8 and 9, or November 13 and 16
   2. A survey will be sent to determine the exact dates
4. Next meeting
   1. Plan for additions to the IG
   2. Look at eCQM support
   3. Look at long-term care use case(s)
   4. Review last pilot survey

1. Interoperability Showcase update
   1. We have a scenario to work with
   2. Referral from PCP to cardiologist, first specialist is not available, second specialist accepts the referral. Outcome is that the patient needs a bypass (360X)
   3. Operation at an acute facility, device interoperability, discharge summary to PCP (not 360X)
   4. Post operation referrals to behavioral health and cardiac rehab - show multiple visits (360X)
2. Dates for next testing session
   1. We decided on Monday, October 22 and Wednesday, October 24th
   2. We will make sure eClinical Works and Netsmart are aware of the testing dates
   3. Cerner would like to get sample 360X .zip packages shared with them
3. Update on the Annual ONC meeting - there won't be any opportunities to do a demo or to present, the time is very limited, and the format is not conducive for that.
4. Dr. Holly Miller and Vassil Peytchev will have a presentation at the HITAC Interoperability Prioritization Task Force on October 23rd. A link to the public meeting will be sent to the list.
5. Updates to the Implementation Guide
   1. Add discussion on how 360X and eCQM can work together to automate reporting.
   2. Consider a use case of acute to post-acute referrals. where there are multiple possible destinations
      1. One approach is to create multiple referrals, and send them to each possible destination, the first who accepts, gets it, all others get a cancel. Not clear what to do if the one who originally accepts, later declines.
      2. Another approach is to send to one possible recipient as a date-sensitive request, and wait for a response. If there is a decline, send to the next one, etc. With 360X this is possible, because of the potential changes to current workflows that can be enabled. Instead of the post-cute facilities having nursing staff at the acute facilities looking for potential matches, they can staff their incoming referrals office to promptly respond to referral requests.
      3. Other things to consider: What is the appropriate closing of the loop; How is the PCP kept in the loop.
      4. We will get an initial written proposal

1. Update on the Interoperability Showcase and Connectathon
   1. we have sufficient participants for a 360X use case, with the participation of two device vendors,
   2. the scenario is about a cardiac patient, and it will be developed based on the participant's capabilities.
2. We have received several times a question on how 360X can support the eCQM measure for closed loop referral. At first glance, it seems that anyone using 360X and managing referrals will simply need to reflect the information in their system to provide the corresponding counts for closed loop referral, using the appropriate SNOMED codes. We will enhance the implementation guide to describe this in some more detail, and for this we will need the feedback of the quality measures community.
3. Testing update. 
   1. Last week's testing sessions were low-key, with few participants. As we ramp up towards the Interoperability showcase we expect more participation based on the demo scenario
   2.  We had new participants and this was a good start to establish connectivity
4. Future testing sessions
   1. We agreed on 3 sessions before the holidays - week of October 22 (earlier in the week), week of November 12th (later in the week), and week of December 10th
   2. Specific days for the first session will be determined by next call
5. ONC annual meeting, November 29th and 30th. There might be an opportunity to present about 360X, especially with the link to satisfying eCQM measures. Brett will keep us informed

1. Interoperability Showcase and Connectathon updates
   1. ECW, Epic, Medallies, Qvera  will participate in Showcase and Connectathon
   2. Netsmart and Nextgen are still considering the Showcase, will participate in Connectathon
   3. Allscripts won't be able to participate, but will continue following the progress, and eventually participate in project testing
2. How would a 360X-enabled system communicate with a non-360X aware system
   
   1. On the initiator side, a 360X-enabled system could send a request package to recipient, without knowing whether the recipient is 360X-capable
      1. in many cases, an initiator is aware of the capabilities of all of their partners, in which case the initiator only sends a 360X request package to a 360X-capable recipient
      2. for the cases when the initiator is not aware of the capabilities of the recipient, the following is recommended:
         1. only non-urgent referrals should be sent using a 360X request package
         2. there should be a system configuration or a process that would alert the appropriate staff on the initiator's side when an accept or decline is not received within a given time frame.
      3. initially, the 360X project included the provision to send the C-CDA of the 360X request package as a stand-alone MIME part. This is now considered unnecessary, since the use of XDM has become more wide spread.
   2. On the recipient side, if a 360X-enabled system receives a Direct message that is not a 360X request package, but represents a referral request, the system should have a way to manually manage the request (for example, as if it was received via a telephone call). there is nothing else the 360X-enabled recipient system is expected to do in such a case.
3. Communication infrastructure for Connectahon and Showcase
   1. There might be issues with using the existing SMTP setup over the Internet, instead of having all network communications locally. We should be prepared to handle this either way.
   2. Even with proper routing over the Internet, we'll need to account for message delays for the Showcase. 

1. Discussions on participating in the HIMSS Interoperability Showcase and IHE Connectathon
   1. Dr. Miller and Brett to reach out to EHR vendors who currently don't usually participate in the calls (e.g. EClinicalWorks, athenahealth).
   2. The vendors who have been participating in recent calls (Allscripts, Cerner, Epic, Qvera, Medallies, Netsmart,  Nextgen) are interested, but most can't commit at this point, however most can have a more definitive answer by the next call on September 14.
   3. Regarding the protocol to use at Connectathon and at the Interop Showcase
      1. The specification requires the use of SMTP S/MIME + XDM, however it states that whenever a sender is aware of the capabilities of the receiver, they may use XDR instead
      2. For testing purposes, XDR is easier to set up
      3. In existing Direct implementations, most HISPs can transform between SMTP S/MIME + XDM and XDR, and many connections are managed at an organization level, where the sender already knows the capabilities of the receiver.
      4. The above points mean that we can make the appropriate accommodations at the communications level during Connectathon testing, and at the HIMSS Interop Showcase for anyone interested in participating.
2. Side discussion on payer/insurance information
   1. Currently, the specification state nothing regarding insurance information. Current C-CDA exchanges don't seem to consistently contain usable information.
   2. Because of the use of HL7 V2 message in the request, we have two possible places to represent the insurance information - the C-CDA payers section, and the GT1 and IN1 segments in the HL7 message.
   3. The Payers section is optional in the CCD document type, and is not part of the Referral Note document type. The latter is an open template, meaning that 360X could add a requirement to have a payers section in the Referral Note as well. Also, the Payers section has only optional entries (discrete data) - another thing that 360X may need to further specify.
   4. Current practice for the use of the Payers section is to include all known insurance information, not necessarily specifying which one is to be used for the purposes of the referral.
   5. Based on the above there is an opportunity to add a payer/insurance option, which will describe how to convey relevant insurance information by
      1. using the HL7 V2 message's GT1/IN1 segments to specify the insurance information that the referral initiator believes to be responsible for the referral
      2. using the C-CDA Payer's section to continue with the current practice to list all known insurance/payer information for the patient.
3. Dates for September testing: Monday, September 24th, and Thursday, September 27th. Details will be posted soon.
4. IG updates - some will be made during the month of September.

1. Report from the ONC Interoperability Forum demo
   1. Very successful, well received
   2. Worth the effort, based on the feedback of those participating
2. Lessons learned
   1. referenceIdList as a slot on the Submission Set needs to be emphasized as a requirement to avoid incomplete implementations
   2. There seems to be little utility in adding the stand-alone C-CDA MIME attachment to the Referral Request. For the purposes of the demo, this was disabled. There are various levels of requirements that make handling the XDM structure much more widespread than it was at the beginning of the project.
      Proposal: remove this requirements from the referral request. To be discussed again at next call
   3. When handling the XDM ZIP file contents, there were some issues with the presence of a Byte-Order-Mark (BOM) for files encoded in utf-8. The specification should mention this and either prohibit the use of utf-8 BOM, or alert implementers to properly handle it if present.
   4. Alert implementers that both Direct and XDM are content agnostic - there is no assumption that the content payload is a C-CDA file. Encourage testing of the transactions where the HL7 V2 message is the only payload.
3. Call for participation in the 2019 HIMSS Interoperability Showcase
   1. there is already a scenario (use case) for 360X; they require around 7 or more participants
   2. Participation at the 2019 IHE North American Connectathon is also necessary to prepare for the Interoperability Showcase
   3. We will need to agree on appropriate infrastructure, as using SMTP and DNS on the internet may not be reliable from the HIMSS floor.
4. Continued testing
   1. Next testing sessions will be scheduled for the week of September 24
   2. Goals: start preparing for Interoperability Showcase, test the scheduling transactions

We are continuing to test in preparation for a live demo at the ONC Interoperability Forum.

When: 10 am Eastern Time to 5 pm Eastern time 

Tentative schedule

1. 10:00am - 12:00pm Eastern – Closed Loop Referral – NextGen and Netsmart
   1. Required attendees – Mo & Dmitry (if needed), Kevin Arnold
2. 12:00pm Eastern - Break (30 minutes)
3. 12:30pm - 2:30pm – Acute to Ambulatory Discharge – NextGen
   1. Required attendees - Mo & Dmitry (if needed)
4. 2:30pm - 3:00pm – Break (30 minutes)
5. 3:00pm – 5:00pm – 360x Closed Loop Referral – Epic, Qvera, and NextGen
   1. Required attendees – Vassil, Mike Ross, Mo, and Dmitry (if needed)

How: We will use this Webex link to help with communications during testing. Meeting Number is 997 389 005, if prompted. Audio Connection: 202.774.2300, Access Code: 997 389 005

What:  End-to-end testing

As discussed at our call on July 6th, we are having a set of testing sessions to prepare for a live demo at the ONC Interoperability Forum.

When: 10 am Eastern Time to 5 pm Eastern time (times may be slotted for particular testing, but we plan to start all together).

Tentative schedule (TBD)

How: We will use this Webex link to help with communications during testing. Meeting Number is 999 826 727, if prompted. Audio Connection: 202.774.2300, Access Code: 999 826 727

What:  Discuss the clinical details for the demo, and start initial testing

The next testing session is on Thursday, June 14th.

When: 10 am Eastern Time to 5 pm Eastern time (times may be slotted for particular testing, but we plan to start all together).

Tentative schedule

10 am Eastern/ 9 am Central/ 7 am Pacific: Initial call-in and confirming the schedule

1pm Eastern/ Noon Central/ 10 am Pacific: 1st check-in call, status updates

3 pm Eastern/ 2 pm Central/noon Pacific: Final check-in call, wrap up

How: We will use this Webex link to help with communications during testing. Meeting Number is 992 095 345, if prompted. Audio Connection: 202.774.2300, Access Code: 992 095 345

What: Iron out Direct communications, test out workflows as described in Appendix D of the 360X Implementation Guide, test handling of possible error conditions:

• Initiator receives a referral accept message without previously sending referral request message
• Initiator receives a referral decline message without previously sending referral request message
• Initiator receives an intermediate results message without previously sending referral request message
• Initiator receives a referral complete message (close the loop) without previously sending referral request message
• Initiator receives an intermediate results message after previously receiving referral complete message (close the loop)
• Initiator or recipient receives any post-initiate message with correct referral ID, but different patient ID
• Initiator or recipient receives any post-initiate message with unknown referral identifier

Short meeting with the following updates:

1. Testing was continuing on exchanging messages between different HISPs. We discovered some properties that need to be corrected in the Epic certificates, and will continue testing after this meeting
2. The ONC Interoperability Forum will be on August 6th to 8th in Washington DC. there will be an opportunity to present updates on the 360X project, and possibly have a demo. Details will be discussed as information becomes available.
3. For the testing on Thursday, June 14, we will test messages to Epic, and scrutinize the contents of the XDM packages.

Current participants in the 360X project are planning another testing session on Wednesday, June 6th.

When: 10 am Eastern Time to 5 pm Eastern time (times may be slotted for particular testing, but we plan to start all together).

Tentative schedule

10 am Eastern/ 9 am Central/ 7 am Pacific: Initial call-in and confirming the schedule

noon Eastern/ 11 am Central/ 9 am Pacific: 1st check-in call, status updates

2 pm Eastern/ 1 pm Central/ 11 am Pacific: 2nd check-in call, status updates

4 pm Eastern/ 3 pm Central/ 1 pm Pacific: Final check-in call, wrap up

How: We will use this Webex link to help with communications during testing. Meeting Number is 998 389 746, if prompted. Audio Connection: 202.774.2300, Access Code: 998 389 746

What: Iron out Direct communications, test out workflows as described in Appendix D of the 360X Implementation Guide, test handling of possible error conditions:

• Initiator receives a referral accept message without previously sending referral request message
• Initiator receives a referral decline message without previously sending referral request message
• Initiator receives an intermediate results message without previously sending referral request message
• Initiator receives a referral complete message (close the loop) without previously sending referral request message
• Initiator receives an intermediate results message after previously receiving referral complete message (close the loop)
• Initiator or recipient receives any post-initiate message with correct referral ID, but different patient ID
• Initiator or recipient receives any post-initiate message with unknown referral identifier