2025-07-09 (InfoRMS)

Issue Type	Key	Summary	Status	Description	Resolution	Resolution Description
Change Request	ER-135	Conformance Requirements Tables - Need for 2 columns for optionality (Opt)	Triaged	is there a need to have two columns for optionality (Opt)? They seem to be identical? Submitted By: Yaron Derman, OceanMD	Considered for Future Use	Totally agree with the suggestion. This table is generally under consideration and needs to undergo improvements, as it is used across multiple specs. We have a trial version of the improvements in CA:FeX, but we are not happy with it yet, so it is still work in progress. We are tracking the work internally via is an internal Jira ticket.
Change Request	ER-130	Sequence Diagrams - clarify 'pre-requisite conditions' statement	Triaged	I don’t think it is correct to state 'these are a prerequisite' and I would suggest removing this bullet entirely. It is overlaying requirements that are not agreed upon or deployed by the eReC community Existing Wording: The green swim lane is a simplified view of the actors and transactions, referencing as required the Foundational Profiles, defined here, in addition to other ones that are not explicitly illustrated on the diagram. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied. Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Change from: These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied. Change to: Typically these represent pre-requisites suggested for the particular use case.
Change Request	ER-129	Sequence Diagrams - confirm link for 'here' in guidance is correct	Triaged	I'm not sure that the URL associated with 'here' in this line is the intended page > please confirm / update Existing Wording: The green swim lane is a simplified view of the actors and transactions, referencing as required the Foundational Profiles, defined here Submitted By: Yaron Derman, OceanMD	Not Persuasive with Modification	Yes, the intention is to point to the RA. I think this paragraph was copied from other specs such as PS-CA, but looks like it got modified to avoid maintaining versions. Here is a similar page in PS-CA spec. Alternatively we could word it as below (or similar): The green swim lane provides a simplified view of the actors and transactions that are not explicitly illustrated on the diagram. The Foundational Profiles defined in the Reference Architecture are referenced as required. See the Reference Architecture Release Information page for information about released versions.
Change Request	ER-106	L3: Advanced Workflows - Merge chaining and routing/splitting content	Triaged	this page would be enhanced if the chaining section was interwoven into the routing and splitting rather than standing on its own. Submitted By: Yaron Derman, OceanMD	Not Persuasive	Given ER-105 – Chaining should remain as is. It’s has more distinct differences compared to Routing / Splitting to not combine the sections (link).
Change Request	ER-105	Clarify rationale for Chaining being 'SHOULD' and routing/splitting being 'SHALL'	Triaged	why is chaining 'SHOULD' but routing and splitting is 'SHALL'? Existing Wording: Chaining section Submitted By: Yaron Derman, OceanMD	Persuasive	Update description: Chaining creates a net-new referral, it is not required (rather it is recommended) that this information flow upstream to the original source system (link). Add a sub-bullet after the note.
Change Request	ER-104	Remove L3: Advanced Workflows - Support for Communications	Triaged	not sure if this section's content is necessary Existing Wording: Support for Communications Submitted By: Yaron Derman, OceanMD	Not Persuasive	This section is key to highlight communications between providers occurs during R/S/C workflows use the send-communication-from____ events, rather than notify-update-service-record. This was a key finding during PCCG CT. Support for Communications section (link).
Change Request	ER-103	Clarify bullets under L3: Advanced Workflows - Sharing appointment information	Triaged	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	Update description: Adding and updating appointments using notify-update-service-record allows appointments to be correctly associated with a service request. Sharing Appointment Information section (link).
Change Request	ER-102	Child referrals from splitting typically go to the same Target System	Triaged	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	Update description - Splitting: where service request containing multiple distinct services (e.g.: an imaging requisition) is split into multiple service requests and send each to Performer HCPs Target System(s) (link).
Change Request	ER-101	Re-evaluate SHALL rules on Communications Payload	Triaged	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	Update description for Communications (link), make it clearer that it could be either a general communication or RFI.
Change Request	ER-100	Move Communications Payload content from Business Events to the Communications (CA:eReC) page	Triaged	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 (link) to the Communication FHIR Artifact Page under the Usage section (link).
Change Request	ER-99	Add RFI definition to Defined Terms	Triaged	the definition for RFI should be moved to the Defined Terms section of the Home page Submitted By: Yaron Derman, OceanMD	Persuasive	Move "Requests for Information (RFI)" section (link) to a new row in the table under Defined Terms (link).
Change Request	ER-98	Appointments should be L1 or L2 rather than L3	Triaged	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	Persuasive	Appointments could be considered an L2 capability as they use a "notify" event and fits with status updates. L1 is not an appropriate capability for appointments.
Change Request	ER-97	Service Record/ Task created belongs in L1: Send, Receive, Revoke	Triaged	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.
Change Request	ER-96	Verbiage that implementers should negotiate upfront using URL or binary encoded methods of document sharing	Triaged	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 (link). Credit to Yaron for the proposed wording.
Change Request	ER-95	Move events from L1: Attaching Supporting Information to L2/L3	Triaged	I find it confusing that there are two L1 page if both of them contain 'SHALL' components. Some of the 'supporting info' events seem to me to be 'advanced' and should be part of L2 or L3 e.g. changes content of the binary attachment and/or you should specify it is only for the CAT model implementers Submitted By: Yaron Derman, OceanMD	Persuasive	Add clarifying language on the "Detailed Capabilities by System Level" table (link), alongside adding the specific L# capability within the sub-pages in the "Trigger Events & Interactions" table (link).
Change Request	ER-93	Language to indicate Requester's perspective on completion with eReferral vs eConsult	Triaged	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	Add verbiage: “For eReferral, A requester will know that their referral is completed when they receive a task.status:completed from the performer.” under the state machine diagram. (Link) Caveat (eReferral): A requirement from ON PCCG to discuss on slide # (insert link & num)

Change Request

Conformance Requirements Tables - Need for 2 columns for optionality (Opt)

Triaged

is there a need to have two columns for optionality (Opt)? They seem to be identical?

Submitted By: Yaron Derman, OceanMD

Considered for Future Use

Totally agree with the suggestion. This table is generally under consideration and needs to undergo improvements, as it is used across multiple specs.
We have a trial version of the improvements in CA:FeX, but we are not happy with it yet, so it is still work in progress.
We are tracking the work internally via is an internal Jira ticket.

Change Request

ER-130

Sequence Diagrams - clarify 'pre-requisite conditions' statement

Triaged

I don’t think it is correct to state 'these are a prerequisite' and I would suggest removing this bullet entirely. It is overlaying requirements that are not agreed upon or deployed by the eReC community

Existing Wording: The green swim lane is a simplified view of the actors and transactions, referencing as required the Foundational Profiles, defined here, in addition to other ones that are not explicitly illustrated on the diagram. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Change from:
These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.

Change to:
Typically these represent pre-requisites suggested for the particular use case.

Change Request

ER-129

Sequence Diagrams - confirm link for 'here' in guidance is correct

Triaged

I'm not sure that the URL associated with 'here' in this line is the intended page > please confirm / update

Existing Wording: The green swim lane is a simplified view of the actors and transactions, referencing as required the Foundational Profiles, defined here

Submitted By: Yaron Derman, OceanMD

Not Persuasive with Modification

Yes, the intention is to point to the RA.
I think this paragraph was copied from other specs such as PS-CA, but looks like it got modified to avoid maintaining versions. Here is a similar page in PS-CA spec.

Alternatively we could word it as below (or similar):
The green swim lane provides a simplified view of the actors and transactions that are not explicitly illustrated on the diagram. The Foundational Profiles defined in the Reference Architecture are referenced as required. See the Reference Architecture Release Information page for information about released versions.

Change Request

ER-106

L3: Advanced Workflows - Merge chaining and routing/splitting content

Triaged

this page would be enhanced if the chaining section was interwoven into the routing and splitting rather than standing on its own.

Submitted By: Yaron Derman, OceanMD

Not Persuasive

Given ER-105 – Chaining should remain as is. It’s has more distinct differences compared to Routing / Splitting to not combine the sections (link).

Change Request

ER-105

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

Triaged

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

Existing Wording: Chaining section

Submitted By: Yaron Derman, OceanMD

Persuasive

Update description: Chaining creates a net-new referral, it is not required (rather it is recommended) that this information flow upstream to the original source system (link). Add a sub-bullet after the note.

Change Request

ER-104

Remove L3: Advanced Workflows - Support for Communications

Triaged

not sure if this section's content is necessary

Existing Wording: Support for Communications

Submitted By: Yaron Derman, OceanMD

Not Persuasive

This section is key to highlight communications between providers occurs during R/S/C workflows use the send-communication-from____ events, rather than notify-update-service-record. This was a key finding during PCCG CT.

Support for Communications section (link).

Change Request

ER-103

Clarify bullets under L3: Advanced Workflows - Sharing appointment information

Triaged

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

Update description:

Adding and updating appointments using notify-update-service-record allows appointments to be correctly associated with a service request.

Sharing Appointment Information section (link).

Change Request

ER-102

Child referrals from splitting typically go to the same Target System

Triaged

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

Update description - Splitting: where service request containing multiple distinct services (e.g.: an imaging requisition) is split into multiple service requests and send each to Performer HCPs Target System(s) (link).

Change Request

ER-101

Re-evaluate SHALL rules on Communications Payload

Triaged

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

Update description for Communications (link), make it clearer that it could be either a general communication or RFI.

Change Request

ER-100

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

Triaged

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 (link) to the Communication FHIR Artifact Page under the Usage section (link).

Change Request

ER-99

Add RFI definition to Defined Terms

Triaged

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

Submitted By: Yaron Derman, OceanMD

Persuasive

Move "Requests for Information (RFI)" section (link) to a new row in the table under Defined Terms (link).

Change Request

ER-98

Appointments should be L1 or L2 rather than L3

Triaged

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

Persuasive

Appointments could be considered an L2 capability as they use a "notify" event and fits with status updates. L1 is not an appropriate capability for appointments.

Change Request

ER-97

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

Triaged

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.

Change Request

ER-96

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

Triaged

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 (link). Credit to Yaron for the proposed wording.

Change Request

ER-95

Move events from L1: Attaching Supporting Information to L2/L3

Triaged

I find it confusing that there are two L1 page if both of them contain 'SHALL' components. Some of the 'supporting info' events seem to me to be 'advanced' and should be part of L2 or L3 e.g. changes content of the binary attachment and/or you should specify it is only for the CAT model implementers

Submitted By: Yaron Derman, OceanMD

Persuasive

Add clarifying language on the "Detailed Capabilities by System Level" table (link), alongside adding the specific L# capability within the sub-pages in the "Trigger Events & Interactions" table (link).

Change Request

ER-93

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

Triaged

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

Add verbiage: “For eReferral, A requester will know that their referral is completed when they receive a task.status:completed from the performer.” under the state machine diagram. (Link)

Caveat (eReferral): A requirement from ON PCCG to discuss on slide # (insert link & num)


2025-07-09 (InfoRMS)
Displaying 16 issues at 08/Jul/25 12:23 PM.