InfoRMS

Key	Summary	Description	Resolution	Resolution Description
ER-197	Usefulness of Constraints section in Profile pages	Is the Constraints section in each Profile page helpful, or should this be removed? Submitted By: Mark Fernandes, CHI	Persuasive	Will find a way to show only constraints applied on top of the base resource. If that is not possible, this section will be removed from all profile pages
ER-135	Conformance Requirements Tables - Need for 2 columns for optionality (Opt)	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.
ER-134	UC-04: CAT Sequence Diagram - add SR2/PR2 labels where missing	many of the transactions at the bottom (below 'Book and fulfill appointment') do not have the SR2 or PR2 label Submitted By: Yaron Derman, OceanMD	Persuasive	Will add the missing labels as indicated.
ER-133	UC-04: CAT Sequence Diagram- update with higher resolution image	the text in the image is blurry, can you please replace with a sharper image Submitted By: Yaron Derman, OceanMD	Persuasive	Will update with a higher resolution image
ER-132	UC-03: Chaining Referral Requests Sequence Diagram - Missing a Transaction Name and ID	the arrow from the Target System B eReC Performer to Central System eReC Requester is missing the message name and transaction ID (which should be Notify new request processing {eReCm-6] Submitted By: Yaron Derman, OceanMD	Persuasive	Will add Notify new request processing [eReCm-6] label as indicated.
ER-131	Sequence Diagrams Index Table - remove column 'Related Use Case'	remove the column 'related use case' from the table since they are referenced on the actual page of the sequence diagram. Submitted By: Yaron Derman, OceanMD	Not Persuasive with Modification	Will retain the Use Case Column in the Sequence Diagram table to help implementers find the links. Will add a Sequence Diagram Column to the [Use Case Table\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Use-Cases?version=current#use-case-index] for consistency
ER-130	Sequence Diagrams - clarify 'pre-requisite conditions' statement	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: These integration profiles are informative options to satisfy pre-requisite business requirements suggested for the particular use case.
ER-129	Sequence Diagrams - confirm link for 'here' in guidance is correct	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\|https://simplifier.net/guide/ps-ca/Home/Technical-Context/Sequence-Diagrams?version=2.1.0-DFT-Ballot]. * We will reword it as below and add all ‘How to read sequence diagrams’ bullets to each sequence diagram: The green swim lane provides a simplified view of the actors and transactions that are not explicitly illustrated on the diagram. The [Foundational Profiles\|https://infoscribe.infoway-inforoute.ca/display/RA021DFT/Foundational+Profiles] defined in the Reference Architecture are referenced as required. See the [Reference Architecture Release Information\|https://infoscribe.infoway-inforoute.ca/display/PCI/Reference+Architecture+Release+Information] page for information about released versions.
ER-128	Construcing Messages - reduce duplicate information with Message Bundle pages - suggestion 2	For reader clarity, I would remove this section from this page and put the relevant content in it on the relevant Bundle pages (for ServiceRequest and Task Bundles) Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Agree that description of when to use HealthcareService vs PractitionerRole in messages should be moved to the pages describing the MessageBundles. We will: * move the section describing the ServiceRequest Bundle to the MessageBundle - ServiceRequest page * move the section describing the Task Bundle to the MessageBundle - Task page * retain the section header and introduction on the Constructing Messages page with links to the other pages
ER-127	Construcing Messages - reduce duplicate information with Message Bundle pages - suggestion 1	this diagram and description are repeated on the https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/FHIR-Artifacts/Messaging-Events/MessageBundle-ServiceRequest-CA-eReC.page.md?version=current. I would recommend removing them from this page and guiding the reader to click on those links to see an example. You can then also remove the 'NOTES' in the Message Bundle Specifications section Existing Wording: Example: ServiceRequest Message Bundle Submitted By: Yaron Derman, OceanMD	Not Persuasive with Modification	This page exists to provide readers who are unfamiliar with FHIR messaging an overview of how to construct a message with a few technical details carried in from the FHIR specification * The bundle illustration on the page exists to help the reader visualize what is described in the text without navigating to other pages * The information in the notes below the diagram serve to put the FHIR artifacts into context Proposed improvements to layout to make that more clear: * increase font size of Example header so it appears in navigation menu at left * decrease font size of illustration header to remove from left, reflect that it is part of the example" * Replace "notes" with sub-header "Resource Profiles" remove "To enable conformance testing against the requirements of this IG," Change FHIR Profiles in sentence to "Resource Profiles" with hyperlink to page "../FHIR-Artifacts/Resource-Profiles"
ER-126	Constructing Messages -clarify eReC Performer including Resources it did not receive from the eReC Requester in a Bundle.entry statement	How would the eReC Performer know which resources it did not receive from the eReC Requester? Existing Wording: SHALL also include all other Resources not received from the eReC Requester in the message as Bundle.entry Submitted By: Yaron Derman, OceanMD	Persuasive	Agree that the flow is too open ended to develop to. We will either: * replace the sentence referenced in the feedback with a positive sentence representing information originating in the system, or * replace the third bullet with a sentence that represents what can be included using identifiers and remove the 2nd bullet (the latter is preferred)
ER-122	Communication.category: Remove MustSupport	I disagree that this element is 'MustSupport'. I suspect many systems do not have the business functionality to distinguish between a message that is meant as an RFI (response), general communication and service plan and i'm not sure what business functionality would be enabled by the receiver that they need to know this distinction. Submitted By: Yaron Derman, OceanMD	Persuasive	will remove MS on this item
ER-121	Messaging Compliance - clarification on actor support for transactions at a Maturity Level (statement 2)	since there L3, L2 and L1 across actors and this is a 'SHALL statement', it's important to be clear Existing Wording: An actor conforming to Maturity Level 3 SHALL implement transactions from Maturity Level 3, Maturity Level 2 and Maturity Level 1 Proposed Wording: An actor conforming to Maturity Level 3 SHALL implement transactions from Maturity Level 3, Maturity Level 2 and Maturity Level 1 associated with that actor Submitted By: Yaron Derman, OceanMD	Persuasive	Will update wording as proposed to be explicit that Maturity Levels are associated with an Actor
ER-120	Messaging Compliance - clarification on actor support for transactions at a Maturity Level (statement 1)	Existing Wording: Support all transactions corresponding to the Maturity Level being claimed and lower, and Proposed Wording: Support all transactions for that actor corresponding to the Maturity Level being claimed for and lower, and Submitted By: Yaron Derman, OceanMD	Persuasive	Will make the change as proposed
ER-111	Patient self-referrals indicated through ServiceRequest.requester reference	Ocean applies the following rule for patient self-referrals - we would ask that you not deviate: Patient self-referrals can be distinguished from service provider-initiated referrals because ServiceRequest.requester will reference a Patient resource rather than a PractitionerRole resource. (which i believe is aligned with the Ontario spec) Submitted By: Yaron Derman, OceanMD	Persuasive	Under the [patient-self referral section (Business Rules)\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Rules.page.md?version=current] add the following: To explicitly indicate a patient self-referral, set the ServiceRequest.requester to be the same as the ServiceRequest.subject.
ER-107	Remove Messaging Exchange Paradigm section from Business Rules	The Messaging Paradigm section may be a carry-over from the Ontario specs; i don't believe it provides any added information within the eReC spec and can be removed Submitted By: Yaron Derman, OceanMD	Persuasive with Modification	Updates to this page: 1. Move Messaging Exchange Paradigm content to Technical Foundation [page\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Technical-Foundation.page.md?version=current], and place within the Exchanging with Messaging section. Include hyperlinks that take the user to the FHIR Messaging Overview [page\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/FHIR-Messaging-Overview.page.md?version=current]. 2. Remove REST and SMART Paradigms on this page. This content can be found on the Technical Foundation [page\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Technical-Foundation.page.md?version=current], at the bottom.
ER-106	L3: Advanced Workflows - Merge chaining and routing/splitting content	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. Chaining has more distinct differences compared to Routing / Splitting not persuaded to merge content ([link\|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current]).
ER-94	Remove 'unknown' and 'entered-in-error' from Requester State Machine diagram	Unknown does not seem like a conceptual state, but rather a information gap. Entered-in-error seems to be a special case of 'revoked'. i would drop both of them from the diagram Submitted By: Yaron Derman, OceanMD	Not Persuasive with Modification	CA eReC inherits the code system from the base FHIR specification, and the binding strength is required. Not recommended to modify in this IG. [http://hl7.org/fhir/codesystem-request-status.html\|http://hl7.org/fhir/codesystem-request-status.html)] Add a footnote below the diagram to inform readers about the Unknown and Entered-in-Error states: 1. Unknown – this code is discouraged but can still be used. 2. Entered-in-error – Functionally similar to Revoked status.

Usefulness of Constraints section in Profile pages

Is the Constraints section in each Profile page helpful, or should this be removed?

Submitted By: Mark Fernandes, CHI

Persuasive

Will find a way to show only constraints applied on top of the base resource. If that is not possible, this section will be removed from all profile pages

ER-135

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

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.

ER-134

UC-04: CAT Sequence Diagram - add SR2/PR2 labels where missing

many of the transactions at the bottom (below 'Book and fulfill appointment') do not have the SR2 or PR2 label

Submitted By: Yaron Derman, OceanMD

Persuasive

Will add the missing labels as indicated.

ER-133

UC-04: CAT Sequence Diagram- update with higher resolution image

the text in the image is blurry, can you please replace with a sharper image

Submitted By: Yaron Derman, OceanMD

Persuasive

Will update with a higher resolution image

ER-132

UC-03: Chaining Referral Requests Sequence Diagram - Missing a Transaction Name and ID

the arrow from the Target System B eReC Performer to Central System eReC Requester is missing the message name and transaction ID (which should be Notify new request processing {eReCm-6]

Submitted By: Yaron Derman, OceanMD

Persuasive

Will add Notify new request processing [eReCm-6] label as indicated.

ER-131

Sequence Diagrams Index Table - remove column 'Related Use Case'

remove the column 'related use case' from the table since they are referenced on the actual page of the sequence diagram.

Submitted By: Yaron Derman, OceanMD

Not Persuasive with Modification

Will retain the Use Case Column in the Sequence Diagram table to help implementers find the links.

Will add a Sequence Diagram Column to the [Use Case Table|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Use-Cases?version=current#use-case-index] for consistency

ER-130

Sequence Diagrams - clarify 'pre-requisite conditions' statement

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:
These integration profiles are informative options to satisfy pre-requisite business requirements suggested for the particular use case.

ER-129

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

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|https://simplifier.net/guide/ps-ca/Home/Technical-Context/Sequence-Diagrams?version=2.1.0-DFT-Ballot].
* We will reword it as below and add all ‘How to read sequence diagrams’ bullets to each sequence diagram:

The green swim lane provides a simplified view of the actors and transactions that are not explicitly illustrated on the diagram. The [Foundational Profiles|https://infoscribe.infoway-inforoute.ca/display/RA021DFT/Foundational+Profiles] defined in the Reference Architecture are referenced as required. See the [Reference Architecture Release Information|https://infoscribe.infoway-inforoute.ca/display/PCI/Reference+Architecture+Release+Information] page for information about released versions.

ER-128

Construcing Messages - reduce duplicate information with Message Bundle pages - suggestion 2

For reader clarity, I would remove this section from this page and put the relevant content in it on the relevant Bundle pages (for ServiceRequest and Task Bundles)

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Agree that description of when to use HealthcareService vs PractitionerRole in messages should be moved to the pages describing the MessageBundles. We will:
* move the section describing the ServiceRequest Bundle to the MessageBundle - ServiceRequest page
* move the section describing the Task Bundle to the MessageBundle - Task page
* retain the section header and introduction on the Constructing Messages page with links to the other pages

ER-127

Construcing Messages - reduce duplicate information with Message Bundle pages - suggestion 1

this diagram and description are repeated on the https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/FHIR-Artifacts/Messaging-Events/MessageBundle-ServiceRequest-CA-eReC.page.md?version=current. I would recommend removing them from this page and guiding the reader to click on those links to see an example. You can then also remove the 'NOTES' in the Message Bundle Specifications section

Existing Wording: Example: ServiceRequest Message Bundle

Submitted By: Yaron Derman, OceanMD

Not Persuasive with Modification

This page exists to provide readers who are unfamiliar with FHIR messaging an overview of how to construct a message with a few technical details carried in from the FHIR specification * The bundle illustration on the page exists to help the reader visualize what is described in the text without navigating to other pages * The information in the notes below the diagram serve to put the FHIR artifacts into context Proposed improvements to layout to make that more clear: * increase font size of Example header so it appears in navigation menu at left * decrease font size of illustration header to remove from left, reflect that it is part of the example" * Replace "notes" with sub-header "Resource Profiles" ** remove "To enable conformance testing against the requirements of this IG," ** Change FHIR Profiles in sentence to "Resource Profiles" with hyperlink to page "../FHIR-Artifacts/Resource-Profiles"

ER-126

Constructing Messages -clarify eReC Performer including Resources it did not receive from the eReC Requester in a Bundle.entry statement

How would the eReC Performer know which resources it did not receive from the eReC Requester?

Existing Wording: SHALL also include all other Resources not received from the eReC Requester in the message as Bundle.entry

Submitted By: Yaron Derman, OceanMD

Persuasive

Agree that the flow is too open ended to develop to. We will either:
* replace the sentence referenced in the feedback with a positive sentence representing information originating in the system, or
* replace the third bullet with a sentence that represents what can be included using identifiers and remove the 2nd bullet

(the latter is preferred)

ER-122

Communication.category: Remove MustSupport

I disagree that this element is 'MustSupport'. I suspect many systems do not have the business functionality to distinguish between a message that is meant as an RFI (response), general communication and service plan and i'm not sure what business functionality would be enabled by the receiver that they need to know this distinction.

Submitted By: Yaron Derman, OceanMD

Persuasive

will remove MS on this item

ER-121

Messaging Compliance - clarification on actor support for transactions at a Maturity Level (statement 2)

since there L3, L2 and L1 across actors and this is a 'SHALL statement', it's important to be clear

Existing Wording: An actor conforming to Maturity Level 3 SHALL implement transactions from Maturity Level 3, Maturity Level 2 and Maturity Level 1

Proposed Wording: An actor conforming to Maturity Level 3 SHALL implement transactions from Maturity Level 3, Maturity Level 2 and Maturity Level 1 associated with that actor

Submitted By: Yaron Derman, OceanMD

Persuasive

Will update wording as proposed to be explicit that Maturity Levels are associated with an Actor

ER-120

Messaging Compliance - clarification on actor support for transactions at a Maturity Level (statement 1)

Existing Wording: Support all transactions corresponding to the Maturity Level being claimed and lower, and

Proposed Wording: Support all transactions for that actor corresponding to the Maturity Level being claimed for and lower, and

Submitted By: Yaron Derman, OceanMD

Persuasive

Will make the change as proposed

ER-111

Patient self-referrals indicated through ServiceRequest.requester reference

Ocean applies the following rule for patient self-referrals - we would ask that you not deviate: Patient self-referrals can be distinguished from service provider-initiated referrals because ServiceRequest.requester will reference a Patient resource rather than a PractitionerRole resource. (which i believe is aligned with the Ontario spec)

Submitted By: Yaron Derman, OceanMD

Persuasive

Under the [patient-self referral section (Business Rules)|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Rules.page.md?version=current] add the following: To explicitly indicate a patient self-referral, set the ServiceRequest.requester to be the same as the ServiceRequest.subject.

ER-107

Remove Messaging Exchange Paradigm section from Business Rules

The Messaging Paradigm section may be a carry-over from the Ontario specs; i don't believe it provides any added information within the eReC spec and can be removed

Submitted By: Yaron Derman, OceanMD

Persuasive with Modification

Updates to this page:
1. Move Messaging Exchange Paradigm content to Technical Foundation [page|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Technical-Foundation.page.md?version=current], and place within the Exchanging with Messaging section. Include hyperlinks that take the user to the FHIR Messaging Overview [page|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Messaging/FHIR-Messaging-Overview.page.md?version=current].

2. Remove REST and SMART Paradigms on this page. This content can be found on the Technical Foundation [page|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Technical-Context/Technical-Foundation.page.md?version=current], at the bottom.

ER-106

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

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. Chaining has more distinct differences compared to Routing / Splitting not persuaded to merge content ([link|https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Events/L3-Advanced-Workflows.page.md?version=current]).

ER-94

Remove 'unknown' and 'entered-in-error' from Requester State Machine diagram

Unknown does not seem like a conceptual state, but rather a information gap. Entered-in-error seems to be a special case of 'revoked'. i would drop both of them from the diagram

Submitted By: Yaron Derman, OceanMD

Not Persuasive with Modification

CA eReC inherits the code system from the base FHIR specification, and the binding strength is required. Not recommended to modify in this IG.

[http://hl7.org/fhir/codesystem-request-status.html|http://hl7.org/fhir/codesystem-request-status.html)]

Add a footnote below the diagram to inform readers about the Unknown and Entered-in-Error states:

1. Unknown – this code is discouraged but can still be used.

2. Entered-in-error – Functionally similar to Revoked status.


InfoRMS
Displaying 18 issues at 17/Jul/25 3:56 PM.