InfoRMS

Key	Summary	Description	Resolution	Resolution Description
ER-93	Language to indicate Requester's perspective on completion with eReferral vs eConsult	the state diagram is from the Requester's perspective. for eReferrals, I don't think the Requester will 'know' a referral is complete but for eConsult they will, so I would add a footnote to that effect Existing Wording: Business Events Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Modifications on L1: Send, Receive, Revoke page – https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L1-Send-Receive-Revoke.page.md?version=current Requester State Machine Diagram: * Add a superscript "1" beside the completed in the diagram * Below the diagram, the superscript "1" will inform readers of: Requesters are not responsible for completing eReferrals. Requesters are responsible for indicating eConsults as completed by using ServiceRequest.status:completed. Modifications on L2: Shared Workflow Status page - [https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L2-Shared-Workflow-Status.page.md?version=current] Performer State Machine Diagram: * Add a superscript "2" beside the completed in the diagram * Below the diagram, the superscript "2" will inform readers of: Performers are responsible for indicating eReferrals as completed by using Task.status:completed. Performers are not responsible for completing eConsults.
ER-96	Verbiage that implementers should negotiate upfront using URL or binary encoded methods of document sharing	Add verbiage that implementers should negotiate upfront which method of document sharing (URL or binary encoded) they are using to avoid surprises late Submitted By: Yaron Derman, OceanMD	Persuasive	Add "Recommended that implementers determine prior to integration of which method of document sharing will be used." To the following page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L1-Attaching-Supporting-Information.page.md?version=current This would be placed following the first line "In eReferral and eConsult workflows a Service Request is typically accompanied by Supporting Information needed to support intake, triage or processing of a referral including pathway or destination specific referral forms, results of diagnostic tests, images, etc."
ER-97	Service Record/ Task created belongs in L1: Send, Receive, Revoke	I believe this belongs in L1 on the 'Send, Receive, Revoke' page; that page seems to skip over the "Receive" capabilities/responsibilities and i think this belongs there. Existing Wording: includes Service Record / Task created as an L2 event Submitted By: Yaron Derman, OceanMD	Not Persuasive	Keep as is. This is a notify event, which requires the Target to send a status update back to the Source which aligns with L2 capabilities.
ER-98	Appointments should be L1 or L2 rather than L3	it seems to me that Appointments are a core component of any referral and therefore should L1 or L2 rather than L3. It should also be noted that appointments are not necessary for eConsults Submitted By: Yaron Derman, OceanMD	Not Persuasive	Appointments to remain a L3 capability due to the complexity that implementing appointment functionality brings to systems. One system can be L2 without sending appointment information to another system.
ER-99	Add RFI definition to Defined Terms	the definition for RFI should be moved to the Defined Terms section of the Home page Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Add "Requests for Information (RFI)" section from the L3 Communications page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Communications.page.md?version=current to the Defined Terms page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Home.page.md?version=current
ER-100	Move Communications Payload content from Business Events to the Communications (CA:eReC) page	including this section here seems incongruent with the other 'Business' pages > move the https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/FHIR-Artifacts/Communication-CA-eReC.page.md?version=current page (if it isn't already there) Submitted By: Yaron Derman, OceanMD	Persuasive	Move Communications Payload & Responses section from Business Events - L3 Communications page https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Communications.page.md?version=current to the Communication FHIR Artifact Page under the Usage section https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/FHIR-Artifacts/Communication-CA-eReC.page.md?version=current and place under Usage section.
ER-101	Re-evaluate SHALL rules on Communications Payload	there is an explicit assumption above that most communications will be RFIs and therefore are 'questions'. I think this was carried into the "In communication messages the Communication resource SHALL contain:" statement and it requires a string, when it could very well be that additional files/documents are being shared as 'general communication'. i think the SHALL rules here should be re-evaluated. Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Update description and verbiage for Communications https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Communications.page.md?version=current, make it clearer that it could be either a general communication or RFI. Below RFI section, include a new section for General Communications and include: A general communication is used to pass information to the performer or requester, there is no requirement to respond or to place the referral on hold.
ER-102	Child referrals from splitting typically go to the same Target System	this makes the assumption that the child referrals are going to different Target systems which in practice I think is the exception rather than the rule Existing Wording: Splitting: where service request containing multiple distinct services (e.g.: an imaging requistion) is split into multiple service requests and send each to Performer HCPs on different Target Systems. Proposed Wording: Splitting: where service request containing multiple distinct services (e.g.: an imaging requistion) is split into multiple service requests and send each to Performer HCPs on different Target System(s). Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Update description right under Advance Workflows header- Splitting: where service request containing multiple distinct services (e.g.: an imaging requisition) is split into multiple service requests and each sent to Performer HCP(s) Target System(s). https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current
ER-103	Clarify bullets under L3: Advanced Workflows - Sharing appointment information	unclear what these bullets are referring to Existing Wording: Note: Adding appointments to the Service Record, sharing using notify-update-service-record allows appointments to be correctly assoicated with the service request and version. Using a separate message to convey associated status updates allows a Central System to communicate status of a request or requisition to a L2 Source System Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Page Link: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current Update "Sharing Appointment Information" section description in notes: • Adding and updating appointments using notify-update-service-record allows appointments to be correctly associated with a service request. • A separate message can be used to convey associated status updates on the parent referral by a Central System to a L2 Source System. Additionally, introduce the parent/child verbiage earlier on the L3 Advanced Workflows page. 2. EXISTING: [L3] generate and transmit notifications to the Source System when a shared service record is created on the system for Case Assignment, when child requests are created as a result of splitting, and as the record updated with assignment of Performer HCP(s) (routing) • NEW: The original referral that was submitted is now considered the parent referral upon creation of the child referrals..
ER-104	Remove L3: Advanced Workflows - Support for Communications	not sure if this section's content is necessary Existing Wording: Support for Communications Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Introduce use of communications in Single Entry models earlier in the Business Context section Add information requirements for single entry models to the Business Events > Communications Remove communications from the Business Events > Advanced Workflows page TBD - Add Communication Events to Technical Context > Informer/Recipient Integration
ER-105	Clarify rationale for Chaining being 'SHOULD' and routing/splitting being 'SHALL'	why is chaining 'SHOULD' but routing and splitting is 'SHALL'? Existing Wording: Chaining section Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Modifications on L3: Advanced Workflows page - [https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current] Update the description under Routing & Splitting to make it clear that routing is a SHALL and splitting is a SHOULD based off expected Central Intake functionality. Chaining to remain as SHOULD. Modifications on Example: Central Intake in Point to Point [Business Models] page - [https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Models/Single-Entry-Models.page.md?version=current] Include a notes under the diagram with the following verbiage: * Central Intakes primarily supporting routing referrals. * Central Intakes could provide support for splitting and chaining referrals, but is not a requirement.

Language to indicate Requester's perspective on completion with eReferral vs eConsult

the state diagram is from the Requester's perspective. for eReferrals, I don't think the Requester will 'know' a referral is complete but for eConsult they will, so I would add a footnote to that effect

Existing Wording: Business Events

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Modifications on L1: Send, Receive, Revoke page – https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L1-Send-Receive-Revoke.page.md?version=current

Requester State Machine Diagram:
* Add a superscript "1" beside the completed in the diagram
* Below the diagram, the superscript "1" will inform readers of:
** Requesters are not responsible for completing eReferrals.
** Requesters are responsible for indicating eConsults as completed by using ServiceRequest.status:completed.

Modifications on L2: Shared Workflow Status page - [https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L2-Shared-Workflow-Status.page.md?version=current]

Performer State Machine Diagram:
* Add a superscript "2" beside the completed in the diagram
* Below the diagram, the superscript "2" will inform readers of:
** Performers are responsible for indicating eReferrals as completed by using Task.status:completed.
** Performers are not responsible for completing eConsults.

ER-96

Verbiage that implementers should negotiate upfront using URL or binary encoded methods of document sharing

Add verbiage that implementers should negotiate upfront which method of document sharing (URL or binary encoded) they are using to avoid surprises late

Submitted By: Yaron Derman, OceanMD

Persuasive

Add "Recommended that implementers determine prior to integration of which method of document sharing will be used." To the following page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L1-Attaching-Supporting-Information.page.md?version=current

This would be placed following the first line "In eReferral and eConsult workflows a Service Request is typically accompanied by Supporting Information needed to support intake, triage or processing of a referral including pathway or destination specific referral forms, results of diagnostic tests, images, etc."

ER-97

Service Record/ Task created belongs in L1: Send, Receive, Revoke

I believe this belongs in L1 on the 'Send, Receive, Revoke' page; that page seems to skip over the "Receive" capabilities/responsibilities and i think this belongs there.

Existing Wording: includes Service Record / Task created as an L2 event

Submitted By: Yaron Derman, OceanMD

Not Persuasive

Keep as is. This is a notify event, which requires the Target to send a status update back to the Source which aligns with L2 capabilities.

ER-98

Appointments should be L1 or L2 rather than L3

it seems to me that Appointments are a core component of any referral and therefore should L1 or L2 rather than L3. It should also be noted that appointments are not necessary for eConsults

Submitted By: Yaron Derman, OceanMD

Not Persuasive

Appointments to remain a L3 capability due to the complexity that implementing appointment functionality brings to systems. One system can be L2 without sending appointment information to another system.

ER-99

Add RFI definition to Defined Terms

the definition for RFI should be moved to the Defined Terms section of the Home page

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Add "Requests for Information (RFI)" section from the L3 Communications page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Communications.page.md?version=current to the Defined Terms page: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Home.page.md?version=current

ER-100

Move Communications Payload content from Business Events to the Communications (CA:eReC) page

including this section here seems incongruent with the other 'Business' pages > move the https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/FHIR-Artifacts/Communication-CA-eReC.page.md?version=current page (if it isn't already there)

Submitted By: Yaron Derman, OceanMD

Persuasive

Move Communications Payload & Responses section from Business Events - L3 Communications page https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Communications.page.md?version=current to the Communication FHIR Artifact Page under the Usage section https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/FHIR-Artifacts/Communication-CA-eReC.page.md?version=current and place under Usage section.

ER-101

Re-evaluate SHALL rules on Communications Payload

there is an explicit assumption above that most communications will be RFIs and therefore are 'questions'. I think this was carried into the "In communication messages the Communication resource SHALL contain:" statement and it requires a string, when it could very well be that additional files/documents are being shared as 'general communication'. i think the SHALL rules here should be re-evaluated.

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Update description and verbiage for Communications https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Communications.page.md?version=current, make it clearer that it could be either a general communication or RFI.

Below RFI section, include a new section for General Communications and include:

A general communication is used to pass information to the performer or requester, there is no requirement to respond or to place the referral on hold.

ER-102

Child referrals from splitting typically go to the same Target System

this makes the assumption that the child referrals are going to different Target systems which in practice I think is the exception rather than the rule

Existing Wording: Splitting: where service request containing multiple distinct services (e.g.: an imaging requistion) is split into multiple service requests and send each to Performer HCPs on different Target Systems.

Proposed Wording: Splitting: where service request containing multiple distinct services (e.g.: an imaging requistion) is split into multiple service requests and send each to Performer HCPs on different Target System(s).

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Update description right under Advance Workflows header- Splitting: where service request containing multiple distinct services (e.g.: an imaging requisition) is split into multiple service requests and each sent to Performer HCP(s) Target System(s). https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current

ER-103

Clarify bullets under L3: Advanced Workflows - Sharing appointment information

unclear what these bullets are referring to

Existing Wording: Note:

Adding appointments to the Service Record, sharing using notify-update-service-record allows appointments to be correctly assoicated with the service request and version.
Using a separate message to convey associated status updates allows a Central System to communicate status of a request or requisition to a L2 Source System

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Page Link: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current

Update "Sharing Appointment Information" section description in notes:

• Adding and updating appointments using notify-update-service-record allows appointments to be correctly associated with a service request.
• A separate message can be used to convey associated status updates on the parent referral by a Central System to a L2 Source System.

Additionally, introduce the parent/child verbiage earlier on the L3 Advanced Workflows page.

2. EXISTING: [L3] generate and transmit notifications to the Source System when a shared service record is created on the system for Case Assignment, when child requests are created as a result of splitting, and as the record updated with assignment of Performer HCP(s) (routing)
• NEW: The original referral that was submitted is now considered the parent referral upon creation of the child referrals..

ER-104

Remove L3: Advanced Workflows - Support for Communications

not sure if this section's content is necessary

Existing Wording: Support for Communications

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Introduce use of communications in Single Entry models earlier in the Business Context section
Add information requirements for single entry models to the Business Events > Communications
Remove communications from the Business Events > Advanced Workflows page
TBD - Add Communication Events to Technical Context > Informer/Recipient Integration

ER-105

Clarify rationale for Chaining being 'SHOULD' and routing/splitting being 'SHALL'

why is chaining 'SHOULD' but routing and splitting is 'SHALL'?

Existing Wording: Chaining section

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Modifications on L3: Advanced Workflows page - [https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current]

Update the description under Routing & Splitting to make it clear that routing is a SHALL and splitting is a SHOULD based off expected Central Intake functionality.

Chaining to remain as SHOULD.

Modifications on Example: Central Intake in Point to Point [Business Models] page - [https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Models/Single-Entry-Models.page.md?version=current]

Include a notes under the diagram with the following verbiage:
* Central Intakes primarily supporting routing referrals.
* Central Intakes could provide support for splitting and chaining referrals, but is not a requirement.


InfoRMS
Displaying 11 issues at 11/Jul/25 11:38 AM.