Blog from September, 2018

  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.