eReferral Spec Development work stream

Hello,

This weeks eReferrral spec group meeting will be cancelled.

Thanks
-Tim

Hi Tim,

Thank you for your quick reply. My email: Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

Thanks,
Sisira (NLCHI).

Hi Sisira,

Please let me know your email and i can invite you in.

Hi Tim,

Could you please include me in the Asana Project Group?

Thanks,
Sisira De Silva
EHR Informatics Consultant
Newfoundland & Labrador Centre for Health Information

eReferral workstream - July 11, 2017 Meeting Notes

Attendees:
1. Caryn Harris (Orion Health)
2. Tim Berezny (Caredove)
3. Shamil Nizamov (BC Health)
4. Olga Benko (eHealth Ontario)
5. Ted Jin (eHealth Ontario)
6. John Wills (eHealth Centre of Excellence)
7. Smita Kachroo (eHealth Ontario),
8. Vaughn van der Merwe (Strata Health),
9. Sisira De Silva (NLCHI)
10. Rita Pyle (eHealth Ontario)
11. Yaron Derman (eHealth Ontario)


Smita provided an overview of the data captured for providers and organizations in Ontario's PPR. The intent is to provide the workgroup with a starting point for the types of data that would be needed to share between two eReferral platforms

Discussion regarding the types of data

- The Endpoint is the 'digital fax number' to find out where to send the referral to the correct destination. In this case, it would be another eReferral platform
- ACTION 7:11:1 - Tim to pose question to be posted on the international FHIR community why there isn't a codeable concept in the ReferralMethod value set?
- The term 'secure messaging' is open to interpretation as to what is included/excluded. The US has the OPEN Direct standard but this doesn't limit what the 'payload' can be

- The main need is to answer the 3 following questions:
1) What the endpoint
2) what format
3) What the service name is

- This spec should also cover the retreival of service info for services that are not connected a eReferral platform (e.g. the Service Catalogue will expand the list of services that the local eReferral platform can offer the referral requestor, but some of these may not be supported on another eReferral platform e.g. they will only accept a fax)
- Geospatial coordinate are a nice to have but aren't necessary.
- It is assumed that a service that is offered at multiple locations will be assigned distinct endpoints
- Alberta and Newfoundland each have a delivery site registry with specific identifiers that are known to the users, therefore this should be included as optional
- Location resource:
○ Represents a service delivery location
○ This is already identified by both the physical location and the FHIR Resource ID, as well as a distinct endpoint
○ Include: identifier, type, telecom, address, managingOrganization
○ Don't require operationalstatus, mode, part of, endpoint
- Discussion around which resources' 'telecom' should be populated because it appears as an attribute in several resources
- Further discussion whether the Task and Category resources should be a part of this specification
- Endpoint
○ All of the attributes for this resources should be included
- Smita shared that a workflow between PCP and specialist which is using the FHIR Task resource, which tracks the status of the eReferral.

ACTION 7:11:2: Sisira to contact Tim to get included in the Asana project group

A reminder about today's eReferral spec WG meeting at 11 EST, meeting details can be found here

infocentral.infoway-inforoute.ca/en/news-events/event-calendar/icalrepeat.detail/2017/07/11/2193/1268/fhir-ereferral-spec-working-group