eReferral Spec Development work stream

Items to discuss at today's eReferral WG meeting:
- chat.fhir.org Canadian eReferral group (chat.fhir.org/#narrow/stream/279576-Canadian-eReferral)
- GET operations on ServiceRequest
- Collaboration with eConsult


MEETING INFO
=================================
11:00am Eastern
zoom.us/j/3673894036

teleconference #: 1 855 703 8985
Meeting ID: 367 389 4036

In the eReferral specification v0.10 on the "Profiles and Operations Page (simplifier.net/guide/eReferral-Ontario/ProfilesOperations) , it states:

"Documents, such PDF documents, can be attached to the bundle, if included by the provider at referral time. In this case the document content will be embedded in one or more DocumentReference resources as a base64 encoded binary payload."

I believe that what was discussed among the working group was to allow (in fact encourage) the use of urls for retrieving attachments, as POSTing large payloads can have network reliability issues. I think that this statement is specifically an implementation consideration for CHRIS, but should not be the broad eReferral specification case.

-Tim Berezny, CTO Caredove | Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

Next in 2 weeks we will have a SPECIAL extra meeting of the eReferral WG to discuss branching and chaining of referrals.

Zoom: infoway-inforoute.zoom.us/j/3673894036

This week we further discussed the event codes and state diagram. I believe it to be near completion, and I would like to incorporate it into a v0.11 version of the eReferral specification. You can see the updated diagram here: www.screencast.com/t/H6dZjPN9R

In the notes section on the bottom right, you will see a proposed mechanism for branching and chaining, which will be what we discuss in 2 weeks.

Hello,

At this week's eReferral working group meeting we had a lively discussion about updating the state-flow and events of referrals. The diagram we went over, with updates as discussed, can be found at this link:

www.screencast.com/t/G9Wr7M7zvifx

A few highlights:
- We decided that we would err on the side of LESS events using add/update pairs - and adding a "previousStatus" extension, instead of creating an event for every conceivable statue flow
- We discussed branching and forwarding a bit, I have since put some further thought into it and included some comments on the notes in the bottom right of the diagram
- "on-hold" state causes some problems, because after a referral leaves the hold state, you can't really know what state hold was in BEFORE it went on hold. I have added some commentary in the notes regarding this.
- Overall, we were in general agreement about the state-flow as depicted in this diagram

Reminder that the next meeting is on Tues Feb 6 at 11 EST. Branching and forwarding instate flow will be a primary topic.

-Tim Berezny, CTO Caredove | Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

Hello, a reminder about tomorrow's eReferral WG meeting, which will be an interesting one that we need lots of conversation about.

In continuation to last meetings discussion regarding events, I have drafted a new proposed eReferral state diagram. You can view it here:

www.screencast.com/t/woUGxrWx

I think that it addresses almost all of the issues we came across while discussing the BDeR state diagram last time, including RFIs and splitting referrals. This will be an important meeting to attend for those invested in the referral process nitty gritty.

MEETING INFO
=================================
11:00am Eastern
zoom.us/j/3673894036

-Tim Berezny, CTO Caredove | Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

The eReferral iGuide is based around messaging with the MessageHeader. There are three conversations I would like to have regarding eReferral messaging

iGuide: simplifier.net/guide/eReferral-Ontario/BusinessRules

1) The iGuide lacks guidance on how to use the MessageHeader.focus field. I believe that when submitting the referral initially, the focus should be the ServiceRequest (there is no Task resource yet, it is added by the target system). However, follow up messages from the Target system (e.g., and appointment was added) should have the MessageHeader.focus point to the Task resource. This insight is derived from a conversation I had with Lloyd M at FHIR North.

2. Would it be appropriate to consider using FHIRCast in place of some messages using MessageHeader?

3. Do we have the right event codes for the eReferral process (this was discussed at length at the last eReferral WG, and will be a main topic at the next WG).

Items 1 & 2 in particular I would appreciate some feedback on from those knowledgeable about the best way to use messaging and FHIRcast.

-Tim Berezny, CTO Caredove