eReferral Spec Development work stream
- Tim Berezny
- Hors Ligne
- Messages : 84
il y a 7 ans 4 mois #2773
par Tim Berezny
Réponse de Tim Berezny sur le sujet eReferral Spec Development work stream
A reminder about the eReferral spec WG scheduled for tomorrow:
Agenda
1. Prototype System Proposal
2. Attaching a file: filename extension
3. HCN extension
4. /healthcareService in Payload
Meeting Info:
Biweekly meeting regarding the development of an eReferral FHIR specification
zoom.us/j/265383594
teleconference #: 1 877 369 0926
Meeting ID: 265 383 594
Chair: Tim Berezny
Co-Chair: Caryn Harris
Agenda
1. Prototype System Proposal
2. Attaching a file: filename extension
3. HCN extension
4. /healthcareService in Payload
Meeting Info:
Biweekly meeting regarding the development of an eReferral FHIR specification
zoom.us/j/265383594
teleconference #: 1 877 369 0926
Meeting ID: 265 383 594
Chair: Tim Berezny
Co-Chair: Caryn Harris
Connexion ou Créer un compte pour participer à la conversation.
- Yaron Derman
- Hors Ligne
- Messages : 41
il y a 7 ans 5 mois #2736
par Yaron Derman
Réponse de Yaron Derman sur le sujet eReferral Spec Development work stream
Good morning eReferral workstream colleagues,
For those with extra time and a keen interest in all things eReferral, integrating the healthcare enterprise (IHE) patient care coordination committee has published a draft profile for public comment that use HL7 v2 and CDA. my quick scan indicates that it assumes point-to-point, which is only a subset of the scope we are tackling, but it is useful as a reference. URL included below:
ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_360X_Rev1.0_PC_2017-05-26.pdf
For those with extra time and a keen interest in all things eReferral, integrating the healthcare enterprise (IHE) patient care coordination committee has published a draft profile for public comment that use HL7 v2 and CDA. my quick scan indicates that it assumes point-to-point, which is only a subset of the scope we are tackling, but it is useful as a reference. URL included below:
ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_360X_Rev1.0_PC_2017-05-26.pdf
Connexion ou Créer un compte pour participer à la conversation.
- Tim Berezny
- Hors Ligne
- Messages : 84
il y a 7 ans 5 mois - il y a 7 ans 5 mois #2692
par Tim Berezny
Réponse de Tim Berezny sur le sujet eReferral Spec Development work stream
Remind of eReferral Spec Development WG meeting Tuesday, June 13, 11:00am EST
zoom.us/j/265383594
teleconference #: 1 877 369 0926
Meeting ID: 265 383 594
Agenda
=======
1. Conformance Update
2. Decision: Using bundles for /referralRequest
3. Decision: How to attach files to a /referralRequest
4. Extension: Health Card Number
5. Extension: Filename
zoom.us/j/265383594
teleconference #: 1 877 369 0926
Meeting ID: 265 383 594
Agenda
=======
1. Conformance Update
2. Decision: Using bundles for /referralRequest
3. Decision: How to attach files to a /referralRequest
4. Extension: Health Card Number
5. Extension: Filename
Dernière édition: il y a 7 ans 5 mois par Tim Berezny.
Connexion ou Créer un compte pour participer à la conversation.
- Tim Berezny
- Hors Ligne
- Messages : 84
il y a 7 ans 5 mois #2644
par Tim Berezny
Réponse de Tim Berezny sur le sujet eReferral Spec Development work stream
Minutes from todays eReferral spec WG:
Minutes:
ATTENDEES:
Yaron Derman, Caryn Harris, Joel Francis, John Wills, Reed Macmillan, Ted Jin, Smita Kachroo, Tim Berezny, Shamil Nizamov
========
1. Welcome Caryn Harris as new WG co-chair
2. Updates to project workspace
ACTION 5:30:1: add permission to Asana for Joel Francis, Smita Kachroo, Ted Jin
. Article discussion:
Last meeting Yaron located some articles of interest. If you have the chance, please quickly review the articles/pages, we will discuss them in the WG.
--> fhirblog.com/2017/03/13/provider-registries-in-fhir/ (NOTE: I don't believe this covers the discovery and routing to services in another platform)
--> Argonaut Project Provider Directory profile: build.fhir.org/ig/Healthedata1/Argo-PD/
· Attila raised that there was a workstream at the Madrid HL7 WG connectathon around referrals. We should make sure we are aligned and not competing with that direction
ACTION 5:30:2: Attila will share the notes
· John raised that organizations should be considered as service providers and not only the name of the provider. Tim suggested that the destination of a referral can be 1) organization 2) service 3) practitioner and 4) location
3. Spec Questions for discussion.
We are now tracking the outstanding discussion items that recur during the WG. They are listed below. We will focus on the "Active discussion" items as time allows.
--- Resolved ---
- How to handle service discovery and routing? This is assumed that the destination is known; out of scope for our work
- Which version of FHIR to use? Most recent version STU R3
--- Active Discussions ---
- How to attach a file to a /referralRequest?
The FHIR community suggested using the documentReference resource with an attachment datatype (as a binary string in the field name or as a URL reference and then including the file as a bundle (with a bunch of resources)). This is how it's been implemented in the OMD/OTN eConsult specification
Caryn raised that there are two ways to consider an attachment: the attachment comes with the referral but is self-contained (no context) or there can be a section that relies on an attachment to 'fill in the section'. Tim clarified that the attachment concept doesn't link to a specific field and probably would require an extension.
For now, we will assume that for a 'base case spec', it will be assumed that the receiver can determine the relationship between the attachment; we won't develop an extension.
Once we've made sure there is alignment between OTN/OMD and the proposed approach above, we can have a base case spec for the next meeting
ACTION 5:30:3: Smita to post the eConsult spec to the Asana Research workspace
- Should the /healthcareService information be sent in the /referralRequest payload?
Should the 'category', person name, address be sent in the payload of the referralRequest - there are 2 pathways:
1. a direct referral to a specific service (e.g. I am referring to meals on wheels endpoint, so I don't need to say anything about the service because by definition of the endpoint, it is clear)
2. A central intake or service type (geriatric services), which can reroute the referral to multiple locations, organizations or service types
The difference will be whether this field would be mandatory and/or if it should be mandatory for specific scenarios. The sending system would already 'know' what type of info is required for each endpoint. On the other hand, it could send this info to every endpoint and the receiver can ignore that info. It will also make it more complicated for the sending system.
For now, we will explore whether there is a difference between brokered versus direct referrals.
- How to define HCN (and other key identifiers, e.g., band #)?
Can have multiple references to different types of identifiers e.g. band #. How should these be defined?
Smita explained how healthcard number is dealt with in the OTN/OMD eConsult spec
ACTION 5:30:4: Yaron to share the approach taken to create person identifiers for the Ontario provincial client registry: see the response to the forum post below:
infocentral.infoway-inforoute.ca/en/forum/266-fhir-implementations/1580-how-to-represent-health-card-number-and-other-identifiers-in-the-patient-identifier/2617
ACTION 5:30:5: Shamil to forward info about the project in Quebec that used ProcedureRequest to Attila
ACTION 5:30:6: Attila to forward to CHI Quebec representative to see if we can get more info about why they chose to use ProcedureRequest and if it is working
- What are the authentication requirements?
Attila suggested that this is something that is broader than eReferral and we shouldn't tackle this. He suspects that whoever the broker service will be (and manage the access policy) that will set the engagement pattern.
This will be moved into the 'resolved' section
--- Pending Discussions ---
- How to consider SMART on FHIR?
- How does the sending or receiving system validate the patient data structure?
- How to certify that a deployed API is conforming to the FHIR standard?
- Integration with a provider registry?
Minutes:
ATTENDEES:
Yaron Derman, Caryn Harris, Joel Francis, John Wills, Reed Macmillan, Ted Jin, Smita Kachroo, Tim Berezny, Shamil Nizamov
========
1. Welcome Caryn Harris as new WG co-chair
2. Updates to project workspace
ACTION 5:30:1: add permission to Asana for Joel Francis, Smita Kachroo, Ted Jin
. Article discussion:
Last meeting Yaron located some articles of interest. If you have the chance, please quickly review the articles/pages, we will discuss them in the WG.
--> fhirblog.com/2017/03/13/provider-registries-in-fhir/ (NOTE: I don't believe this covers the discovery and routing to services in another platform)
--> Argonaut Project Provider Directory profile: build.fhir.org/ig/Healthedata1/Argo-PD/
· Attila raised that there was a workstream at the Madrid HL7 WG connectathon around referrals. We should make sure we are aligned and not competing with that direction
ACTION 5:30:2: Attila will share the notes
· John raised that organizations should be considered as service providers and not only the name of the provider. Tim suggested that the destination of a referral can be 1) organization 2) service 3) practitioner and 4) location
3. Spec Questions for discussion.
We are now tracking the outstanding discussion items that recur during the WG. They are listed below. We will focus on the "Active discussion" items as time allows.
--- Resolved ---
- How to handle service discovery and routing? This is assumed that the destination is known; out of scope for our work
- Which version of FHIR to use? Most recent version STU R3
--- Active Discussions ---
- How to attach a file to a /referralRequest?
The FHIR community suggested using the documentReference resource with an attachment datatype (as a binary string in the field name or as a URL reference and then including the file as a bundle (with a bunch of resources)). This is how it's been implemented in the OMD/OTN eConsult specification
Caryn raised that there are two ways to consider an attachment: the attachment comes with the referral but is self-contained (no context) or there can be a section that relies on an attachment to 'fill in the section'. Tim clarified that the attachment concept doesn't link to a specific field and probably would require an extension.
For now, we will assume that for a 'base case spec', it will be assumed that the receiver can determine the relationship between the attachment; we won't develop an extension.
Once we've made sure there is alignment between OTN/OMD and the proposed approach above, we can have a base case spec for the next meeting
ACTION 5:30:3: Smita to post the eConsult spec to the Asana Research workspace
- Should the /healthcareService information be sent in the /referralRequest payload?
Should the 'category', person name, address be sent in the payload of the referralRequest - there are 2 pathways:
1. a direct referral to a specific service (e.g. I am referring to meals on wheels endpoint, so I don't need to say anything about the service because by definition of the endpoint, it is clear)
2. A central intake or service type (geriatric services), which can reroute the referral to multiple locations, organizations or service types
The difference will be whether this field would be mandatory and/or if it should be mandatory for specific scenarios. The sending system would already 'know' what type of info is required for each endpoint. On the other hand, it could send this info to every endpoint and the receiver can ignore that info. It will also make it more complicated for the sending system.
For now, we will explore whether there is a difference between brokered versus direct referrals.
- How to define HCN (and other key identifiers, e.g., band #)?
Can have multiple references to different types of identifiers e.g. band #. How should these be defined?
Smita explained how healthcard number is dealt with in the OTN/OMD eConsult spec
ACTION 5:30:4: Yaron to share the approach taken to create person identifiers for the Ontario provincial client registry: see the response to the forum post below:
infocentral.infoway-inforoute.ca/en/forum/266-fhir-implementations/1580-how-to-represent-health-card-number-and-other-identifiers-in-the-patient-identifier/2617
ACTION 5:30:5: Shamil to forward info about the project in Quebec that used ProcedureRequest to Attila
ACTION 5:30:6: Attila to forward to CHI Quebec representative to see if we can get more info about why they chose to use ProcedureRequest and if it is working
- What are the authentication requirements?
Attila suggested that this is something that is broader than eReferral and we shouldn't tackle this. He suspects that whoever the broker service will be (and manage the access policy) that will set the engagement pattern.
This will be moved into the 'resolved' section
--- Pending Discussions ---
- How to consider SMART on FHIR?
- How does the sending or receiving system validate the patient data structure?
- How to certify that a deployed API is conforming to the FHIR standard?
- Integration with a provider registry?
Connexion ou Créer un compte pour participer à la conversation.
- Tim Berezny
- Hors Ligne
- Messages : 84
il y a 7 ans 5 mois #2639
par Tim Berezny
Réponse de Tim Berezny sur le sujet eReferral Spec Development work stream
Hello, below is the agenda for the tomorrows spec WG meeting.
11:00am EST
zoom.us/j/265383594
teleconference #: 1 877 369 0926
Meeting ID: 265 383 594
Agenda - 30 May 2017 11:00am:
========
1. Welcome Caryn Harris as new WG co-chair
2. Updates to project workspace
3. Article discussion:
Last meeting Yaron located some articles of interest. If you have the chance, please quickly review the articles/pages, we will discuss them in the WG.
--> fhirblog.com/2017/03/13/provider-registries-in-fhir/ (NOTE: I don't believe this covers the discovery and routing to services in another platform)
--> Argonaut Project Provider Directory profile: build.fhir.org/ig/Healthedata1/Argo-PD/
4. Spec Questions for discussion.
We are now tracking the outstanding discussion items that recur during the WG. They are listed below. We will focus on the "Active discussion" items as time allows.
--- Resolved ---
- How to handle service discovery and routing?
- Which version of FHIR to use?
--- Active Discussions ---
- How to attach a file to a /referralRequest
- Should the /healthcareService information be sent in the /referralRequest payload?
- How to define HCN (and other key identifiers, e.g., band #)
- What are the authentication requirements
--- Pending Discussions ---
- How to consider SMART on FHIR?
- How does the sending or receiving system validate the patient data structure
- How to certify that a deployed API is conforming to the FHIR standard?
- Integration with a provider registry?
11:00am EST
zoom.us/j/265383594
teleconference #: 1 877 369 0926
Meeting ID: 265 383 594
Agenda - 30 May 2017 11:00am:
========
1. Welcome Caryn Harris as new WG co-chair
2. Updates to project workspace
3. Article discussion:
Last meeting Yaron located some articles of interest. If you have the chance, please quickly review the articles/pages, we will discuss them in the WG.
--> fhirblog.com/2017/03/13/provider-registries-in-fhir/ (NOTE: I don't believe this covers the discovery and routing to services in another platform)
--> Argonaut Project Provider Directory profile: build.fhir.org/ig/Healthedata1/Argo-PD/
4. Spec Questions for discussion.
We are now tracking the outstanding discussion items that recur during the WG. They are listed below. We will focus on the "Active discussion" items as time allows.
--- Resolved ---
- How to handle service discovery and routing?
- Which version of FHIR to use?
--- Active Discussions ---
- How to attach a file to a /referralRequest
- Should the /healthcareService information be sent in the /referralRequest payload?
- How to define HCN (and other key identifiers, e.g., band #)
- What are the authentication requirements
--- Pending Discussions ---
- How to consider SMART on FHIR?
- How does the sending or receiving system validate the patient data structure
- How to certify that a deployed API is conforming to the FHIR standard?
- Integration with a provider registry?
Connexion ou Créer un compte pour participer à la conversation.
- Yaron Derman
- Hors Ligne
- Messages : 41
il y a 7 ans 6 mois #2587
par Yaron Derman
Réponse de Yaron Derman sur le sujet eReferral Spec Development work stream
Hi everyone - thanks for the engaging discussion. below are my draft notes of today's call. my apologies for any typos.
BTW: a reminder that the tcon # and video conference info are the same for every meeting. you can pull down a meeting invite from the 'events' page of the FHIR implementation WG site..
Attendees: Tim Berezny (CareDove) [co-chair], Caryn Harris (Orion Health) [co-chair], Jeff Kavanagh (CognisantMD), Reed McMillan (Novari Health), John Wills (eHealth Centre of Excellence), Yaron Derman (eHealth Ontario)
BTW: a reminder that the tcon # and video conference info are the same for every meeting. you can pull down a meeting invite from the 'events' page of the FHIR implementation WG site..
Attendees: Tim Berezny (CareDove) [co-chair], Caryn Harris (Orion Health) [co-chair], Jeff Kavanagh (CognisantMD), Reed McMillan (Novari Health), John Wills (eHealth Centre of Excellence), Yaron Derman (eHealth Ontario)
1. Co-chair position
- Responsibilities include:
○ Agenda setting
○ Running the meeting
○ Follow up on action items
○ DECISION: Caryn has taken on the co-chair position.
○ Contact info: Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
2. FHIR connectathon @ FHIR North
a. John and Tim attended
b. Learnings:
i. implementation guide development
1) Use of XLS spreadsheet to constrain the resources
2) Run through a series of transforms to produce the FHIR implementation guide
3) Areas where an iGuide is very important over and above the base FHIR STU:
a) is for declaring extensions
b) Declaring where something is loosened or constrained more than the base STU
ii. Compliance testing on FHIR
1) Testing should be performed against the base STU against a central test rather than peer-to-peer
2) ACTION 5/17:1: Tim will be meeting with him and will see if it something that would be relevant to our work
iii. SMART on FHIR
1) Making FHIR 'plug and play' between different EHR platforms so that FHIR-compliant apps can contribute/consume data without customization for each EHR platform
2) Appropriateness of a referral might be a good application of the using SMART for referrals
c. eReferral work globally
i. HL7 international is working on the base resources e.g. ResourceRequest
ii. NHS UK has published a draft
iii. There likely isn't a spec using STU R3 as there are differences between STU R2
iv. ACTION 5/16:2: Yaron to post the David Hay's blog about provider directories : fhirblog.com/2017/03/13/provider-registries-in-fhir/ (NOTE: I don't believe this covers the discovery and routing to services in another platform)
v.(bonus) Argonaut Project Provider Directory profile: build.fhir.org/ig/Healthedata1/Argo-PD/
d. We need a "DNS-like" infrastructure to discover and route to service providers
i. Has heard that TELUS is building something like this
ii. Need to get started on this now because it will be needed in the future across eReferral platforms and jurisdictions (can use ONE ID federation broker and provider registry)
iii. One approach is to follow a SSL or PKI model
iv. NHS and Surescripts in the US may have a model in the place
v. ACTION 5/17:3 : Yaron to share the eHealth Ontario innovation lab URL - (www.innovation-lab.ca/)
e. STU 3 vs STU 2
i. Tim suggested that the workstream use STU 3 rather than STU 2
ii. DECISION: use STU 3 for eReferral workstream deliverables
f. Demo of FHIR-based eReferral API
i. Tim provided a walkthrough of a mock eReferral sent using FHIR
1) Referral submitted from a EMR 'lite' to CareDove using the ReferralRequest and Patient resources
2) The assumption is that the endpoint is defined for a specific service
3) How to deal with complex/data-heavy referrals? Send back to the referral creator a pointer to the full referral form that contains all the required fields. Should the sending or receiving platform (e.g. using an iFrame) render the form
4) ACTION 5/17:4: Reed will ask Novari Health developers if they are able to get involved.
CognisantMD will be interested in Autumn
- Responsibilities include:
○ Agenda setting
○ Running the meeting
○ Follow up on action items
○ DECISION: Caryn has taken on the co-chair position.
○ Contact info: Cette adresse courriel est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
2. FHIR connectathon @ FHIR North
a. John and Tim attended
b. Learnings:
i. implementation guide development
1) Use of XLS spreadsheet to constrain the resources
2) Run through a series of transforms to produce the FHIR implementation guide
3) Areas where an iGuide is very important over and above the base FHIR STU:
a) is for declaring extensions
b) Declaring where something is loosened or constrained more than the base STU
ii. Compliance testing on FHIR
1) Testing should be performed against the base STU against a central test rather than peer-to-peer
2) ACTION 5/17:1: Tim will be meeting with him and will see if it something that would be relevant to our work
iii. SMART on FHIR
1) Making FHIR 'plug and play' between different EHR platforms so that FHIR-compliant apps can contribute/consume data without customization for each EHR platform
2) Appropriateness of a referral might be a good application of the using SMART for referrals
c. eReferral work globally
i. HL7 international is working on the base resources e.g. ResourceRequest
ii. NHS UK has published a draft
iii. There likely isn't a spec using STU R3 as there are differences between STU R2
iv. ACTION 5/16:2: Yaron to post the David Hay's blog about provider directories : fhirblog.com/2017/03/13/provider-registries-in-fhir/ (NOTE: I don't believe this covers the discovery and routing to services in another platform)
v.(bonus) Argonaut Project Provider Directory profile: build.fhir.org/ig/Healthedata1/Argo-PD/
d. We need a "DNS-like" infrastructure to discover and route to service providers
i. Has heard that TELUS is building something like this
ii. Need to get started on this now because it will be needed in the future across eReferral platforms and jurisdictions (can use ONE ID federation broker and provider registry)
iii. One approach is to follow a SSL or PKI model
iv. NHS and Surescripts in the US may have a model in the place
v. ACTION 5/17:3 : Yaron to share the eHealth Ontario innovation lab URL - (www.innovation-lab.ca/)
e. STU 3 vs STU 2
i. Tim suggested that the workstream use STU 3 rather than STU 2
ii. DECISION: use STU 3 for eReferral workstream deliverables
f. Demo of FHIR-based eReferral API
i. Tim provided a walkthrough of a mock eReferral sent using FHIR
1) Referral submitted from a EMR 'lite' to CareDove using the ReferralRequest and Patient resources
2) The assumption is that the endpoint is defined for a specific service
3) How to deal with complex/data-heavy referrals? Send back to the referral creator a pointer to the full referral form that contains all the required fields. Should the sending or receiving platform (e.g. using an iFrame) render the form
4) ACTION 5/17:4: Reed will ask Novari Health developers if they are able to get involved.
CognisantMD will be interested in Autumn
Connexion ou Créer un compte pour participer à la conversation.