|
|
||||||
| eRec 1.1 Block Vote 1 (InfoRMS) | ||||||
| Displaying 26 issues at 02/Jul/25 1:42 PM. |
| Issue Type | Key | Summary | Status | Description | Resolution | Resolution Description |
|---|---|---|---|---|---|---|
| Change Request | ER-138 | PatientNeedsToBeSeen Extension - clarify use in guide |
Triaged | is this extension actually used by an Ontario implementation or is it only conceptual? If the latter, recommend removing it and relying on the Communications message events to relay that info
Submitted By: Yaron Derman, OceanMD |
Not Persuasive | We will keep this extension. Ontario Health will clarify if this is still the way to communicate this data in the future. |
| Change Request | ER-139 | ServiceRequesterDelegate Extension - Clarify use in guide with Request Authorizer vs Submitter pattern in Business Rules |
Triaged | I think the pattern of Delegates is already covered by this Business Rules section without requiring an extension: https://simplifier.net/guide/Pan-Canadian-eReferral-eConsult-CA-eReC-iGuide/Index/Business-Context/Business-Rules.page.md?version=current#request-authorizer-vs.submitter
Submitted By: Yaron Derman, OceanMD |
Not Persuasive with Modification | We will keep this extension and will add narrative in the Business Rules section on how this extension is used within the overall requester/owner pattern. |
| Change Request | ER-140 | ReferralIdentifier extension - Clarify use in guide |
Triaged | what is the necessity of this extension? It's better to avoid including it unless there is a clear business need for it
Submitted By: Yaron Derman, OceanMD |
Persuasive | We will remove this extension. |
| Change Request | ER-149 | CommunicationBarrier Extension: Remove MustSupport |
Triaged | I disagree that the CommunicationBarrier extension is MustSupport. This is information related to delivery of service and can be a part of the referral itself, if required, rather than the Patient resource
Submitted By: Yaron Derman, OceanMD |
Not Persuasive with Modification | CA-Core+ has moved the extension to the Patient so we will follow (given our other CA-Core+ work). We will make a request to make the extension not be MS. |
| Change Request | ER-153 | Communication: inResponseTo should not be mustSupport |
Triaged | it is very likely that most systems do not have a global unique identifier for their Communications resources (Ocean does) nor a place to store the identifier of one they have received from another system, so the 'inResponseTo' should not be mustSupport
Existing Wording: inResponseTo Submitted By: Yaron Derman, OceanMD |
Not Persuasive | You need the inResponseTo to link one communication to a previous communication. We found that during testing in the Projectathon. |
| Change Request | ER-160 | Patient.Gender: Cardinality gap against Ontario IG Mandatory (1..1) in Ontario IG; Optional (0..1) in Pan-Canadian IG |
Triaged | Observation:
There is a cardinality mismatch for the Patient.gender element between the Pan-Canadian IG and the Ontario IG. In the Ontario IG, this element is mandatory (1..1), while in Pan-Canadian, it is optional (0..1). This is just an observation and being reported for information purposes. Existing Wording: Patient.gender ● Cardinality stated as 0..1 Submitted By: OH Standards, Ontario Health |
Not Persuasive | We will keep this as 0..1 because of the extensions on it. |
| Change Request | ER-161 | DocumentReference.content: Cardinality gap against Ontario IG - 1..* in Pan-Canadian IG, 1..1 in Ontario IG i.e., each DocumentReference instance SHALL only reference a single attachment |
Triaged | There is a cardinality mismatch for the DocumentReference.content element between the Pan-Canadian IG and the Ontario IG. In the Ontario IG, this element has a cardinality of 1..1, requiring it to have only one entry, whereas in Pan-Canadian, the cardinality is 0..1, allowing for multiple entries.
There are architectural constraints in Ontario that necessate the cardinality to be 1..1. Are there situations which necessate for more then one? We anticipate that supporting more than one may prove to be complicated. Existing Wording: DocumentReference.content ● Cardinality stated as 1..* Submitted By: OH Standards, Ontario Health |
Persuasive | We will change the cardinality of this to be 1..1. |
| Change Request | ER-163 | MessageHeader.destination: Cardinality gap against Ontario IG -0..* in Pan-Canadian IG, 1..* on Ontario IG |
Triaged | There is a cardinality mismatch for this element between Pan-canadian and Ontario IGs. In the Ontario IG, the cardinality is 1..* whereas in pan-canadian it's 0..*.
Are there situations where we anticipate no destination? Does it make sense to have atleast one destination? Existing Wording: MessageHeader.destination ● Cardinality stated as 0..* Submitted By: OH Standards, Ontario Health |
Persuasive | We will make this 1..*. |
| Change Request | ER-164 | MessageHeader.author: Cardinality gap against Ontario IG - 0..1 in Pan-Canadian IG, 1..1 in Ontario IG |
Triaged | There is a cardinality mismatch for this element between Pan-canadian and Ontario IGs. In the Ontario IG, the cardinality is 1..1 whereas in pan-canadian it's 0..1.
Are there situations where we anticipate no author ? Does it make sense to always have one author? Existing Wording: MessageHeader.author ● Cardinality stated as 0..1 Submitted By: OH Standards, Ontario Health |
Not Persuasive | We intentionally changed the cardinality of this to handle the case where a central system is the author of the referral and can not be referenced as a Practitioner/PractitionerRole. |
| Change Request | ER-165 | Practitioner.name: Cardinality gap against Ontario IG - 0..* in Pan-Canadian IG, 0..1 in Ontario IG |
Triaged | There is a cardinality mismatch for this element between Pan-canadian and Ontario IGs. In the Ontario IG, the cardinality is 0..1 whereas in pan-canadian it's 0..*.
Do we anticipate situations where a practitioner would have more than one name to be communicated? Existing Wording: Practitioner.name ● Cardinality stated as 0..* Submitted By: OH Standards, Ontario Health |
Not Persuasive with Modification | We are making Practitioner.name mandatory (ER-204) but leaving it as 1..*. |
| Change Request | ER-166 | QuestionnaireResponse.partOf: Cardinality gap against Ontario IG - 0..* in Pan-Canadian IG, 0..1 in Ontario IG. |
Triaged | There is a cardinality mismatch for this element between Pan-canadian and Ontario IGs. In the Ontario IG, the cardinality is 0..1 whereas in pan-canadian it's 0..*.
Do we antcipate to have more than one reference to an Observation or Procedure in the QuestionnaireResponse? Existing Wording: QuestionnaireResponse.partOf Submitted By: OH Standards, Ontario Health |
Persuasive | We will make this 0..1. |
| Change Request | ER-167 | All Profiles: Recommend adding meta across resource profiles to facilitate information exchange in environments where more than one version of the specification is supported. |
Triaged | Data elements not in pan-Candian IG -
Patient.meta, Location.meta, DocumentReference.meta, MessageHeader.meta, Organization.meta, Practitioner.meta, PractitionerRole.meta, HealthcareService.meta, QuestionnaireResponse.meta, ServiceRequest.meta, Task.meta Existing Wording: .meta Submitted By: OH Standards, Ontario Health |
Persuasive | We will add xxx.meta.profile as a MS field but will not fix it to anything. The comment will be:
Implementers should be aware that some Canadian jurisdictions require vendors to use meta.profile declare which FHIR profile(s) and version(s) the resource conforms to. |
| Change Request | ER-176 | Patient.identifier: Cardinality gap against Ontario IG - 0..* in Pan-Canadian IG, 1..* in Ontario IG |
Triaged | There is a cardinality mismatch for this element between Pan-canadian and Ontario IGs. In the Ontario IG, the cardinality is 1..* whereas in pan-canadian it's 0..*.
Are there scenarios where we do not require atleast one patient identifier? Existing Wording: Patient.identifier ● Cardinality stated as 0..* Submitted By: OH Standards, Ontario Health |
Not Persuasive | We explicitly changed the minimum cardinality to be 0 out of projectathon testing when vendors discussed that they would not always have a patient identifier to send along. Rather than setting the minimum to 1 and having a DataAbsentReason, it was deemed better to set the cardinality to 0. |
| Change Request | ER-177 | QuestionnaireResponse.questionnaire: should be 0..1 MS. |
Triaged | QuestionnaireResponse.Questionnaire should be specifically called out as supported as there are likely situations where there needs to be a reference a questionnaire definitition so that answers on the questionnaire response have the proper context. Suggest that .Questionnaire should be 0..1 MS.
Existing Wording: QuestionnaireResponse.Questionnaire is 0..1 Submitted By: OH Standards, Ontario Health |
Not Persuasive | We don't want this to be MS as many systems will not support questionnaires but just rendering forms as QRs. |
| Change Request | ER-178 | ServiceRequesterDelegate extension to ServiceRequest: Cardinality gap against Ontario IG - 0..1 in Pan-Canadian IG, 0..* on Ontario IG |
Triaged | There is a cardinality mismatch for this element between Pan-canadian and Ontario IGs. In the Ontario IG, the cardinality is 0..* whereas in pan-canadian it's 0..1.
Consider harmonizing cardinality across both IG's or clearly document the rationale. Existing Wording: ServiceRequesterDelegate extension to ServiceRequest Submitted By: OH Standards, Ontario Health |
Persuasive | We will make this be 0..*. |
| Change Request | ER-190 | DocumentReference.context.related.identifier.use: Change to be MS and 1..1 cardinality |
Triaged | DocumentReference.context.related.identifier.use should be MS and 1..1 cardinality to identify the 'official' ServiceRequest being referenced
Existing Wording: DocumentReference.context.related.identifier.use ● Not MustSupport ● Cardinality stated as 0..1 Proposed Wording: DocumentReference.context.related.identifier.use ● MustSupport ● Cardinality stated as 1..1 Submitted By: Mark Fernandes, CHI |
Persuasive | We will make the specified element MS and mandatory as proposed. |
| Change Request | ER-191 | PractitionerRole.telecom.value: Change to be MS |
Triaged | PractitionerRole.telecom.value should be MustSupport as the cardinality is 1..1
Existing Wording: PractitionerRole.telecom.value ● Not MustSupport Proposed Wording: PractitionerRole.telecom.value ● MustSupport Submitted By: Mark Fernandes, CHI |
Persuasive | We will make telecom.value MS. |
| Change Request | ER-194 | ServiceRequest.identifier.use: shall be MustSupport |
Triaged | ServiceRequest.identifier.use shall be MustSupport to denote the single official business identifier for each eReferral/eConsult (see usage notes on .identifier)
Existing Wording: ServiceRequest.identifier.use ● Not MustSupport Proposed Wording: ServiceRequest.identifier.use ● MustSupport Submitted By: Mark Fernandes, CHI |
Persuasive | We will make .use MS as proposed. |
| Change Request | ER-195 | ServiceRequest.requester.reference: cardinality should be 1..1 |
Triaged | ServiceRequest.requester.reference shall be 1..1 as the resource must be referenced in the bundle (updated slimming rules)
Existing Wording: ServiceRequest.requester.reference ● Cardinality is 0..1 Proposed Wording: ServiceRequest.requester.reference ● Cardinality is 1..1 Submitted By: Mark Fernandes, CHI |
Persuasive | We will make this 1..1 |
| Change Request | ER-196 | ServiceRequest.performer.reference: cardinality should be 1..1 |
Triaged | ServiceRequest.performer.reference shall be 1..1 as the resource must be referenced in the bundle (updated slimming rules)
Existing Wording: ServiceRequest.performer.reference ● Cardinality is 0..1 Proposed Wording: ServiceRequest.performer.reference ● Cardinality is 1..1 Submitted By: Mark Fernandes, CHI |
Persuasive | Change cardinality as suggested. |
| Change Request | ER-199 | Patient.communication.extension:CommunicationBarrier: moved to Patient.extension |
Triaged | Patient.communication.extension:CommunicationBarrier moved to Patient.extension (on the root profile). Is this extension describing communication barriers with a specific language or in general?
Are there other barriers to account for beyond language (Expand valueSet) Submitted By: Mark Fernandes, CHI |
Persuasive with Modification | We will switch to using the CA-Core+ profile as our parent profile and thus inherit all of the extensions and where those extensions are.
NOTE: If we are unable to inherit from CA-Core+ in time for our release, we will at least ensure that our Patient profile is completely in sync with theirs. |
| Change Request | ER-201 | Patient.address.line, Patient.address.city should be MustSupport |
Triaged | Patient.address.line, Patient.address.city should be MustSupport
Existing Wording: Patient.address.line, Patient.address.city * Not MS Proposed Wording: Patient.address.line, Patient.address.city * Should be MS Submitted By: Mark Fernandes, CHI |
Persuasive | We will make address.line and address.city MS because that is the minimum required fields to support when an address is being sent. |
| Change Request | ER-202 | Location.telecom.value should be 1..1 |
Triaged | Existing Wording: Location.telecom.value
* stated as 0..1 Proposed Wording: Location.telecom.value * should be 1..1 Submitted By: Mark Fernandes, |
Persuasive | We will make the telecom.value mandatory because that is needed when a telecom element is being sent. |
| Change Request | ER-203 | ServiceRequest.supportingInfo: should reference CA Core+ for AllergyIntolerance and Condition resources |
Triaged | ServiceRequest.supportingInfo should reference CA Core+ for AllergyIntolerance and Condition resources
Existing Wording: ServiceRequest.supportingInfo reference: *AllergyIntolerance (PS-CA), Condition (PS-CA) Proposed Wording: ServiceRequest.supportingInfo reference: *AllergyIntolerance (CA Core+), Condition (CA Core+) Submitted By: Mark Fernandes, CHI |
Persuasive | We will change to use the CA-Core versions of these profiles instead of PS-CA. |
| Change Request | ER-204 | Practitioner.name: should have a minimum cardinality of 1 |
Triaged | Practitioner.name should have a minimum cardinality of 1
Existing Wording: Practitioner.name ● Cardinality stated as 0..* Proposed Wording: Practitioner.name ● Cardinality should be 1..* Submitted By: Mark Fernandes, CHI |
Persuasive | We will make name mandatory because that is a minimum requirement to identify the practitioner in a referral. |
| Change Request | ER-205 | Location.address.line should be MustSupport |
Triaged | |Location.address.line should be MustSupport
Existing Wording: Location.address.line * Not MS Proposed Wording: Location.address.line * MS Submitted By: Mark Fernandes, CHI| |
Persuasive with Modification | We will make address.line and address.city MS because that is the minimum required fields to support when an address is being sent. |
| Generated at Wed Jul 02 13:42:25 EDT 2025 by Jean Duteau using Jira 10.3.2#10030002-sha1:0a5d322ae1b7fd5b314be5b31a27d9661f8301b2. |