InfoRMS

Key	Summary	Description	Resolution	Resolution Description
ER-61	Provide guidance where the revocation reason can be captured in ServiceRequest	When eReCm-5 is sent from Referring Provider to revoke the service request, we need a place to capture the revocation reason in ServiceRequest which is the focus of the message. Currently there is no place where this could be captured. Possibly a need for extension (e.g. statusReason) similar to Task.statusReason?	Persuasive	We will add a reasonCode extension to ServiceRequest.status to allow documentation of revocation reason (etc). Proposed use: * MessageHeader.eventCode / MessageHeader.reason will say: requester / performer integration: "revoke-service-request" because "service-request-status-updated" (or reason not populated) where applicable, informer / recipient integration: "notify-update-service-record" because "service-request-status-updated" * ServiceRequest.status reasonCode would allow the reason the status changed (to revoked) to be documented.
ER-83	Request to add an extension to support business status in ServiceRequest	AB has other business status not currently supported in ServiceRequest.status (e.g. declined, deferred, etc.) and would like to capture these in ServiceRequest - possibly a businessStatus extension.	Not Persuasive	Status of a referral is always determined by the SR.performer and transmitted to the SR.requester using Task which has a .businessStatus. In the case where RMS is a Central System with its own business rules there is the possibility of using two separate Tasks to convey status to the Source System: * eReCm-7 / notify-update-process-request with Task in focus can be used to convey the Central System's status/businessStatus of the initial SR to the requester * eReCm-11 / notify-update-service-request with Task in focus can be used to convey the Performer's status/businessStatus of the child SR to the requester Use of Task to convey businessStatus also allows the eReC Performer to convey businessStatus to the Source System when the Target System lacks the ability to construct the full SR resource which we understand to be a constraint for some systems. == We will consider this when applying related ER-173
ER-87	Link to CA:CSD work	Will this profile utilize the information from the care service directory being developed in Canada? Submitted By: Debbie Onos, Alberta Health Services	Considered-Question answered	HealthcareService is aligned between the CA:eReC and CA:CSD specifications. The difference in profiling is due to the minimum supported elements needed to define a CA:CSD HealthcareService in a directory vs what is needed in CA:eReC HealthcareService to convey the referral through messaging.
ER-115	Clarify 'Link' concept and relevance to P2P architecture	I do not understand the 'link' concept in general and specifically why it is relevant to the P2P architecture. I performed a keyword search on many other pages in the IG and could not find more information about it. it looks like it is related to 'basedOn' and 'Replaces' but that linkage isn't clear. Another line of thinking was that the Recipient receives a link that it can use to access a central repository... again this it not clear to me as a reader Submitted By: Yaron Derman, OceanMD	Persuasive	Agree, the link option is described on the Actor Option page. At bottom of the role of technical actors section we will add the following note. --- eReC Recipients that support the Link option must be able to associate service requests / service records managed in the Central System with the service request sent by eReC Requester actor when receiving messages. See: [Actor Options\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Integration-Patterns/Actor-Options.page.md?version=current]
ER-116	Actor Options Table - Keep footnotes within table	rather than having the notes below the table and referencing them in the table, just at them to the table in the Notes column Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Will move the notes within the table to improve readability. (If table rendering is an issue when we test on laptop we will revert to existing layout.)
ER-117	Actor Groupings Table - Keep footnotes within table	rather than having the notes below the table and referencing them in the table, just at them to the table in the Notes column Submitted By: Yaron Derman, OceanMD	Persuasive	Will move the notes within the table to improve readability
ER-119	Messaging Compliance Table - clarify if footnotes apply only to CAT model or generally	it's not clear to me if these suggestions are specific to the CAT model or in general; i suspect the former, in which case, that should be added to the notes. Existing Wording: 1 Vendors claiming Level 3 compliance for the eReC Requester SHOULD demonstrate the actor's use with a compliant eReC Recipient (link). 2 Vendors claiming Level 3 compliance for the eReC Performer SHOULD demonstrate the actor's use with a compliant eReC Informer (link). Submitted By: Yaron Derman, OceanMD	Persuasive	Agree that the section needs clarification. Footnotes will be updated as follows: # Vendors claiming Level 3 compliance for the eReC Requester with the (link) option SHOULD demonstrate the actor's use with a compliant eReC Recipient (link). # Vendors claiming Level 3 compliance for the eReC Performer SHOULD demonstrate the actor's use with a compliant eReC Informer (link). See [Actor Options\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Integration-Patterns/Actor-Options.page.md?version=current] for additional information.
ER-123	Task.owner: Link rules to populate this element from Constructing Messages page	there are rules about how to populate the Task.owner in the page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages, I suggest adding these rules and/or a URL in the Task.owner comment section to ensure implementers are aware. Submitted By: Yaron Derman, OceanMD	Persuasive	We will link to [Use of HealthcareService vs PractitionerRole in eReC Messages\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages] from * Task.owner Comment in Structure Definition * Task.owner Usage note
ER-124	MessageHeader: link to rules for populating MessageHeader.author	include the URLs of pages describing rules for populating the MessageHeader.author element so that implementers are aware e.g. from this section: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages Submitted By: Yaron Derman, OceanMD	Persuasive	We will link to [Use of HealthcareService vs PractitionerRole in eReC Messages\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages] from * MessageHeader.author Comment in Structure Definition * MessageHeader.author Usage note
ER-125	Transaction Details tables - suggestions to reduce noise	remove the Maturity Level column (and maybe even the Message Type one) to make the tables less busy and they are already captured in other pages Submitted By: Yaron Derman, OceanMD	Persuasive	Agree that there is unnecessary with risk of becoming misaligned with other content. We will make the proposed change / remove the column from the tables.
ER-136	Messaging Events Table - Remove duplicate content already captured in Technical Context > Messaging	this content seems to already be captured in the Technical Context pages. I would suggest removing from one location to avoid reader confusion Submitted By: Yaron Derman, OceanMD	Not Persuasive	The Messaging Events page frames the applicable MessageBundle pages for ServiceRequest, Task, Appointment and Communication. It is formally included under the FHIR Artifacts section, and aligns with [MessageEventCode\|https://simplifier.net/ca-erec/message-event-code-duplicate-2]. The other Techical Context > Messaging pages do include this information as we are gradually introducing the actors and transactions, but this page is meant to be a definitive reference for implementers
ER-137	Extensions - move section to Business Rules page	I recognize that this section is using an extension and therefore can be seen to belong on this page. However, since this section is only provide advice, but not required implementation guidance, I would suggest removing it or moving it to the Business Rules section Submitted By: Yaron Derman, OceanMD	Not Persuasive	Will keep the Extensions Defined Externally section as is to document advice on use of extensions that are not defined in the guide.
ER-141	Move the Routing Options Business Rules content into that Extension's page	move the Routing Options Business Rules content into that Extension's page Submitted By: Yaron Derman, OceanMD	Persuasive	We will move Routing Options Business Rules to the extension's page
ER-142	Move the Patient Present Location content into that Extension's page	move the Patient Present Location content into that Extension's page Submitted By: Yaron Derman, OceanMD	Persuasive	We will move Patient Present Location Business Rules to the extension's page
ER-143	Clarify use of Terminology page when information is available in profiles	The information on this page exists within the profiles and appears to be only an aggregration. what purpose does this page serve i.e. who would reference it and for what purpose? It may be a consideration to remove the page Submitted By: Yaron Derman, OceanMD	Not Persuasive with Modification	Will be keeping this page: * As a definitive reference for Terminology bindings in the guide * to be consistent with other pan-Canadian specifications with dedicated Terminology pages * Example bindings from base FHIR will be removed * We will investigate if there's a way to generate the page dynamically from the Profile bindings
ER-147	QuesitonnaireResponse - Clarify Usage in eConsult	Is this a carryover from the Ontario IG? I don't believe seeing any other guidance in this IG that would provide context to this instruction. Existing Wording: For eConsult, the QuestionnaireResponse resource is used WITH the Questionnaire resource to provide structured data (e.g. provider survey responses) as a list of questions and responses. Submitted By: Yaron Derman, OceanMD	Persuasive	It is a carry-over from the OH v0.11.1 IG. We will reword the statement. Existing Wording: For eConsult, the QuestionnaireResponse resource is used WITH the Questionnaire resource to provide structured data (e.g. provider survey responses) as a list of questions and responses. Existing Wording: For eConsult, some jurisdictions may use the QuestionnaireResponse resource WITH the Questionnaire resource (not defined in this guide) to provide structured data (e.g. requester and performer survey responses) as a list of questions and responses.
ER-148	QuesitonnaireResponse - Clarify use of messaging in Usage Note	I believe this IG only describes the user of messaging, so I'm not clear on why this is called out? Existing Wording: if the resource is being transmitted via messaging Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Agree that Usage should be updated to reflect the scope of the guide which is currently only focused on Direct Messaging and does not include the Questionnaire resource. The Usage section will be replace with. h3. Usage In eReC integrations, the QuestionnaireResponse resource may or may not reference a Questionnaire defining the structured form data / list of questions being responded to. Where a Questionnaire is referenced in QuestionnaireResponse.questionnaire additional requirements will apply. See: https://build.fhir.org/questionnaireresponse.html#link
ER-154	Appointment: provide guidance on how to specify appointment modality	provide guidance on how to specify if the appointment will be in-person, video or by phone. Ocean has the following rules: The appointment medium (video, phone) can be specified in the Location.type field that is referenced by the Appointment.participant.actor field: If the medium is unknown/unspecified or known to be in-person: Include a participant containing an actor with code "LOC", display "Clinic Location" and a reference to the listing's Location resource. If the appointment is phone-based: Include a participant containing an actor with code "LOC", display "Phone Visit" and a reference "Location/X" to a Location with ID X in the Bundle. Set the Location's telecom to match the listing's phone number. If the appointment is a home visit: Include a participant containing an actor with code "HH", display "Patient Location" and a reference "Location/X" to a Location with ID X in the Bundle. Set the Location's address to match the patient's address if it is available. If the appointment is at an alternate location: Include a participant containing an actor with code "LOC", display "Alternate Clinic Location" and a reference "Location/X" to a Location with ID X in the Bundle. The Location resource must contain an address and it's description should match the description of the alternate location (e.g., "Alternate Clinic Visit Location: _ Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Agree that a mechanism is needed. To support the business requirement we will: * pre-adopt the Appointment.virtualService element from FHIR R6 as an extension on Appointment, and * add supporting narrative to Business Events > Appointments page.
ER-170	MessageHeader.extension: ReferralIdentifier&RoutingOption - Explicitly state usage context	The usage of both of these extensions is not explicitely stated in the CA:eReC IG. Suggest adding more context than the current wording. Existing Wording: MessageHeader Extension - ReferralIdentifier & RoutingOption extension --> USE CASE SUPPORT: Systems deployed in Ontario SHALL support Submitted By: OH Standards, Ontario Health	Persuasive with Modification	* ReferralIdentifier extension will be removed We will link to the RoutingOptions business rules to be included within the extension's page (given resolution on ER-141 https://informs.infoway-inforoute.ca/browse/ER-141)
ER-174	Splitting - remove line where original ServiceRequest can be closed when splitting	If a ServiceRequest is split into multiple child service requests, the original ServiceRequest should not be considered closed until all child service requests are completed. Existing Wording: After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed. Proposed Wording: Remove this line Submitted By: OH Standards, Ontario Health	Persuasive with Modification	Agree that ”3. After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed.” can be removed … it is eReC Performer’s role to determine status.” We will add a discussion of about closing Parent referrals to the section on [Splitting on the Advanced Workflows page \|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current]and with a cross link from the [Sequence diagram\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current].
ER-175	Update UC-03: Central Intake with information on eReC Informer and eReC Recipient actors	This use case predate the inclusion of the eReC Informer and eReC Recipient technical actors as well as the notify-add-service-record and notify-update-service-record messages. It would be helpful if UC-03 was updated to illustrate how those technical actors and messages would fit within the context of routing, chaining and splitting. Submitted By: OH Standards, Ontario Health	Not Persuasive	UC-03:Central Intake was reworked when we introduced UC:04: Central Access and Triage to use the same eReC Informer and eReC Recipient actors. The [UC-03: Central Intake sequence diagrams \|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Sequence-Diagrams/Sequence-Diagrams-for-UC-03-Referral-to-a-Central-Intake.page.md?version=current]shows this relationship
ER-179	Guidance on how a parent referral gets updated/completed in relation to the child referral(s)	Recommendation: Add guidance on how a parent referral gets updated in relation to the child referral(s). Should the parent referral be completed as soon as child referrals are created? Or should the parent referral be completed once the child referrals are themselves completed? Existing Wording: N/A Submitted By: Matt Wellhauser, Amplify Care	Persuasive	Agree that ”3. After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed.” can be removed … it is eReC Performer’s role to determine status.” We will add a discussion of about closing Parent referrals to the section on [Splitting on the Advanced Workflows page \|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current]and with a cross link from the [Sequence diagram\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current].

Provide guidance where the revocation reason can be captured in ServiceRequest

When eReCm-5 is sent from Referring Provider to revoke the service request, we need a place to capture the revocation reason in ServiceRequest which is the focus of the message. Currently there is no place where this could be captured. Possibly a need for extension (e.g. statusReason) similar to Task.statusReason?

Persuasive

We will add a reasonCode extension to ServiceRequest.status to allow documentation of revocation reason (etc). Proposed use:
* MessageHeader.eventCode / MessageHeader.reason will say:
** requester / performer integration: "revoke-service-request" because "service-request-status-updated" (or reason not populated)
** where applicable, informer / recipient integration: "notify-update-service-record" because "service-request-status-updated"
* ServiceRequest.status reasonCode would allow the reason the status changed (to revoked) to be documented.

ER-83

Request to add an extension to support business status in ServiceRequest

AB has other business status not currently supported in ServiceRequest.status (e.g. declined, deferred, etc.) and would like to capture these in ServiceRequest - possibly a businessStatus extension.

Not Persuasive

Status of a referral is always determined by the SR.performer and transmitted to the SR.requester using Task which has a .businessStatus.

In the case where RMS is a Central System with its own business rules there is the possibility of using two separate Tasks to convey status to the Source System:
* eReCm-7 / notify-update-process-request with Task in focus can be used to convey the Central System's status/businessStatus of the initial SR to the requester
* eReCm-11 / notify-update-service-request with Task in focus can be used to convey the Performer's status/businessStatus of the child SR to the requester

Use of Task to convey businessStatus also allows the eReC Performer to convey businessStatus to the Source System when the Target System lacks the ability to construct the full SR resource which we understand to be a constraint for some systems.

==

We will consider this when applying related ER-173

ER-87

Link to CA:CSD work

Will this profile utilize the information from the care service directory being developed in Canada?

Submitted By: Debbie Onos, Alberta Health Services

Considered-Question answered

HealthcareService is aligned between the CA:eReC and CA:CSD specifications.

The difference in profiling is due to the minimum supported elements needed to define a CA:CSD HealthcareService in a directory vs what is needed in CA:eReC HealthcareService to convey the referral through messaging.

ER-115

Clarify 'Link' concept and relevance to P2P architecture

I do not understand the 'link' concept in general and specifically why it is relevant to the P2P architecture. I performed a keyword search on many other pages in the IG and could not find more information about it. it looks like it is related to 'basedOn' and 'Replaces' but that linkage isn't clear. Another line of thinking was that the Recipient receives a link that it can use to access a central repository... again this it not clear to me as a reader

Submitted By: Yaron Derman, OceanMD

Persuasive

Agree, the link option is described on the Actor Option page. At bottom of the role of technical actors section we will add the following note.

---

eReC Recipients that support the Link option must be able to associate service requests / service records managed in the Central System with the service request sent by eReC Requester actor when receiving messages. See: [Actor Options|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Integration-Patterns/Actor-Options.page.md?version=current]

ER-116

Actor Options Table - Keep footnotes within table

rather than having the notes below the table and referencing them in the table, just at them to the table in the Notes column

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Will move the notes within the table to improve readability. (If table rendering is an issue when we test on laptop we will revert to existing layout.)

ER-117

Actor Groupings Table - Keep footnotes within table

rather than having the notes below the table and referencing them in the table, just at them to the table in the Notes column

Submitted By: Yaron Derman, OceanMD

Persuasive

Will move the notes within the table to improve readability

ER-119

Messaging Compliance Table - clarify if footnotes apply only to CAT model or generally

it's not clear to me if these suggestions are specific to the CAT model or in general; i suspect the former, in which case, that should be added to the notes.

Existing Wording: 1 Vendors claiming Level 3 compliance for the eReC Requester SHOULD demonstrate the actor's use with a compliant eReC Recipient (link).

2 Vendors claiming Level 3 compliance for the eReC Performer SHOULD demonstrate the actor's use with a compliant eReC Informer (link).

Submitted By: Yaron Derman, OceanMD

Persuasive

Agree that the section needs clarification. Footnotes will be updated as follows:
# Vendors claiming Level 3 compliance for the eReC Requester with the (link) option *SHOULD* demonstrate the actor's use with a compliant eReC Recipient (link).
# Vendors claiming Level 3 compliance for the eReC Performer *SHOULD* demonstrate the actor's use with a compliant eReC Informer (link).

See [Actor Options|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Integration-Patterns/Actor-Options.page.md?version=current] for additional information.

ER-123

Task.owner: Link rules to populate this element from Constructing Messages page

there are rules about how to populate the Task.owner in the page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages, I suggest adding these rules and/or a URL in the Task.owner comment section to ensure implementers are aware.

Submitted By: Yaron Derman, OceanMD

Persuasive

We will link to [Use of HealthcareService vs PractitionerRole in eReC Messages|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages]

from
* Task.owner Comment in Structure Definition
* Task.owner Usage note

ER-124

MessageHeader: link to rules for populating MessageHeader.author

include the URLs of pages describing rules for populating the MessageHeader.author element so that implementers are aware e.g. from this section: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages

Submitted By: Yaron Derman, OceanMD

Persuasive

We will link to [Use of HealthcareService vs PractitionerRole in eReC Messages|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Constructing-Messages.page.md?version=current#use-of-healthcareservice-vs-practitionerrole-in-erec-messages]

from
* MessageHeader.author Comment in Structure Definition
* MessageHeader.author Usage note

ER-125

Transaction Details tables - suggestions to reduce noise

remove the Maturity Level column (and maybe even the Message Type one) to make the tables less busy and they are already captured in other pages

Submitted By: Yaron Derman, OceanMD

Persuasive

Agree that there is unnecessary with risk of becoming misaligned with other content. We will make the proposed change / remove the column from the tables.

ER-136

Messaging Events Table - Remove duplicate content already captured in Technical Context > Messaging

this content seems to already be captured in the Technical Context pages. I would suggest removing from one location to avoid reader confusion

Submitted By: Yaron Derman, OceanMD

Not Persuasive

The Messaging Events page frames the applicable MessageBundle pages for ServiceRequest, Task, Appointment and Communication. It is formally included under the FHIR Artifacts section, and aligns with [MessageEventCode|https://simplifier.net/ca-erec/message-event-code-duplicate-2].

The other Techical Context > Messaging pages do include this information as we are gradually introducing the actors and transactions, but this page is meant to be a definitive reference for implementers

ER-137

Extensions - move section to Business Rules page

I recognize that this section is using an extension and therefore can be seen to belong on this page. However, since this section is only provide advice, but not required implementation guidance, I would suggest removing it or moving it to the Business Rules section

Submitted By: Yaron Derman, OceanMD

Not Persuasive

Will keep the Extensions Defined Externally section as is to document advice on use of extensions that are not defined in the guide.

ER-141

Move the Routing Options Business Rules content into that Extension's page

move the Routing Options Business Rules content into that Extension's page

Submitted By: Yaron Derman, OceanMD

Persuasive

We will move Routing Options Business Rules to the extension's page

ER-142

Move the Patient Present Location content into that Extension's page

move the Patient Present Location content into that Extension's page

Submitted By: Yaron Derman, OceanMD

Persuasive

We will move Patient Present Location Business Rules to the extension's page

ER-143

Clarify use of Terminology page when information is available in profiles

The information on this page exists within the profiles and appears to be only an aggregration. what purpose does this page serve i.e. who would reference it and for what purpose? It may be a consideration to remove the page

Submitted By: Yaron Derman, OceanMD

Not Persuasive with Modification

Will be keeping this page:
* As a definitive reference for Terminology bindings in the guide
* to be consistent with other pan-Canadian specifications with dedicated Terminology pages
* Example bindings from base FHIR will be removed
* We will investigate if there's a way to generate the page dynamically from the Profile bindings

ER-147

QuesitonnaireResponse - Clarify Usage in eConsult

Is this a carryover from the Ontario IG? I don't believe seeing any other guidance in this IG that would provide context to this instruction.

Existing Wording: For eConsult, the QuestionnaireResponse resource is used WITH the Questionnaire resource to provide structured data (e.g. provider survey responses) as a list of questions and responses.

Submitted By: Yaron Derman, OceanMD

Persuasive

It is a carry-over from the OH v0.11.1 IG. We will reword the statement.

Existing Wording: For eConsult, the QuestionnaireResponse resource is used WITH the Questionnaire resource to provide structured data (e.g. provider survey responses) as a list of questions and responses.

Existing Wording: For eConsult, some jurisdictions may use the QuestionnaireResponse resource WITH the Questionnaire resource (not defined in this guide) to provide structured data (e.g. requester and performer survey responses) as a list of questions and responses.

ER-148

QuesitonnaireResponse - Clarify use of messaging in Usage Note

I believe this IG only describes the user of messaging, so I'm not clear on why this is called out?

Existing Wording: if the resource is being transmitted via messaging

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Agree that Usage should be updated to reflect the scope of the guide which is currently only focused on Direct Messaging and does not include the Questionnaire resource. The Usage section will be replace with.
h3. Usage

In eReC integrations, the QuestionnaireResponse resource may or may not reference a Questionnaire defining the structured form data / list of questions being responded to. Where a Questionnaire is referenced in QuestionnaireResponse.questionnaire additional requirements will apply. See: https://build.fhir.org/questionnaireresponse.html#link

ER-154

Appointment: provide guidance on how to specify appointment modality

provide guidance on how to specify if the appointment will be in-person, video or by phone. Ocean has the following rules: The appointment medium (video, phone) can be specified in the Location.type field that is referenced by the Appointment.participant.actor field:
If the medium is unknown/unspecified or known to be in-person:
Include a participant containing an actor with code "LOC", display "Clinic Location" and a reference to the listing's Location resource.
If the appointment is phone-based:
Include a participant containing an actor with code "LOC", display "Phone Visit" and a reference "Location/X" to a Location with ID X in the Bundle. Set the Location's telecom to match the listing's phone number.
If the appointment is a home visit:
Include a participant containing an actor with code "HH", display "Patient Location" and a reference "Location/X" to a Location with ID X in the Bundle. Set the Location's address to match the patient's address if it is available.
If the appointment is at an alternate location:
Include a participant containing an actor with code "LOC", display "Alternate Clinic Location" and a reference "Location/X" to a Location with ID X in the Bundle. The Location resource must contain an address and it's description should match the description of the alternate location (e.g., "Alternate Clinic Visit Location: _

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Agree that a mechanism is needed.

To support the business requirement we will:
* pre-adopt the Appointment.virtualService element from FHIR R6 as an extension on Appointment, and
* add supporting narrative to *Business Events > Appointments* page.

ER-170

MessageHeader.extension: ReferralIdentifier&RoutingOption - Explicitly state usage context

The usage of both of these extensions is not explicitely stated in the CA:eReC IG. Suggest adding more context than the current wording.

Existing Wording: MessageHeader Extension - ReferralIdentifier & RoutingOption extension --> USE CASE SUPPORT: Systems deployed in Ontario SHALL support

Submitted By: OH Standards, Ontario Health

Persuasive with Modification

* ReferralIdentifier extension will be removed

We will link to the RoutingOptions business rules to be included within the extension's page (given resolution on ER-141 https://informs.infoway-inforoute.ca/browse/ER-141)

ER-174

Splitting - remove line where original ServiceRequest can be closed when splitting

If a ServiceRequest is split into multiple child service requests, the original ServiceRequest should not be considered closed until all child service requests are completed.

Existing Wording: After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed.

Proposed Wording: Remove this line

Submitted By: OH Standards, Ontario Health

Persuasive with Modification

Agree that ”3. After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed.” can be removed … it is eReC Performer’s role to determine status.”

We will add a discussion of about closing Parent referrals to the section on [Splitting on the Advanced Workflows page |https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current]and with a cross link from the [Sequence diagram|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current].

ER-175

Update UC-03: Central Intake with information on eReC Informer and eReC Recipient actors

This use case predate the inclusion of the eReC Informer and eReC Recipient technical actors as well as the notify-add-service-record and notify-update-service-record messages. It would be helpful if UC-03 was updated to illustrate how those technical actors and messages would fit within the context of routing, chaining and splitting.

Submitted By: OH Standards, Ontario Health

Not Persuasive

UC-03:Central Intake was reworked when we introduced UC:04: Central Access and Triage to use the same eReC Informer and eReC Recipient actors. The [UC-03: Central Intake sequence diagrams |https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Sequence-Diagrams/Sequence-Diagrams-for-UC-03-Referral-to-a-Central-Intake.page.md?version=current]shows this relationship

ER-179

Guidance on how a parent referral gets updated/completed in relation to the child referral(s)

Recommendation: Add guidance on how a parent referral gets updated in relation to the child referral(s). Should the parent referral be completed as soon as child referrals are created? Or should the parent referral be completed once the child referrals are themselves completed?

Existing Wording: N/A

Submitted By: Matt Wellhauser, Amplify Care

Persuasive

Agree that ”3. After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed.” can be removed … it is eReC Performer’s role to determine status.”

We will add a discussion of about closing Parent referrals to the section on [Splitting on the Advanced Workflows page |https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current]and with a cross link from the [Sequence diagram|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/Routing-Splitting-Chaining.page.md?version=current].


InfoRMS
Displaying 22 issues at 25/Jul/25 10:54 AM.