...
| Info |
|---|
The table below reflects future behavior. A change is under way that will change the FHIR Communication created and correspondingly, the CommunicationRequest required to control the creation. |
Search
...
algorithm for “Reminder about appointment” and “Automated creation of medium nemsms…” communications
For most situations only a fixed set of reasonCodes are considered. However, a few remarks are in place for the situation “Automated creation of medium nemsms…”: When creating Communication/ehealth-message resources it is possible to specify a reasonCode, which provides the reason for the exchange of information. Using CommunicationRequest resources it is possible to opt-in for automatically created notifications about new messages. The set of reasonCodes is dynamic by nature when it comes to ehealth-message, ie. it may expand over time. Therefore it is meaningful to be able to create a CommunicationRequest, which is valid over time (for all or a specific EpisodeOfCare), and not sensitive to the introduction of new reasonCodes. Alternatively, it would be required to create new CommunicationRequest resources when introducing new reasonCodes, which would be rather cumbersome. Therefore, the semantics around CommunicationResources for ehealth-message notifications is slightly different than for other infrastructure events. For ehealth-message notifications (ie. the possibility for an automatically created ehealth-message with category=“notification”, medium=“nemsms”, and reasonCode copied from the original ehealth-message), it is possible to create a CommunicationRequest with no reasonCode provided, which will then logically match all possible ehealth-message reasonCodes (in contrast to other situations).
...
Look up CommunicationRequest resources that match both episodeOfCare and reasonCode. If no results are found continue with next step
Look up matching episodeOfCare and no reasonCode. If no results are found continue with next step
Look up matching reasonCode and no episodeOfCare. If no results are found continue with next step
Find results based on no reasonCode and no episodeOfCare. If no results are found, default behavior applies
Search algorithm otherwise
The infrastructure process of finding matching CommunicationRequests includes filtering the following:
valid “occurencePeriod”
status = “active”
recipient matching Communication.recipient
reasonCode matching Communication.reasonCode
category matcing Communication.category
In certain situations the CommunicationRequest also includes filtering on EpisodeOfCare, CommunicationRequest.basedOn matching the relevant ServiceRequest which Communication creation was based on and lastly explicit filtering on co-existence tags (meta/tag). Consult the two tables for controlling creation of messages to see whether any of the extra filtering is in effect.
Selection algorithm
With one or more CommunicationRequest results from the above algorithm, the following filtering applies:
...
Situation | Created by Default | Opt-in Supported | Opt-out Supported | Payload and Medium Overridable | Element category | Element reasonCode | Element episodeOfCare | Element basedOn | Element priority |
|---|---|---|---|---|---|---|---|---|---|
Unexpected measurement submitted | No | Yes | No |
|
| ServiceRequest reference | |||
Missing measurement determined | Yes | Yes | No |
|
| ServiceRequest reference | |||
Communication created by triage (or other infrastructure rules) | Yes | Yes | No | depends on rule | depends on rule | ServiceRequest reference | depends on rule | ||
EpisodeOfCare created/changed (in team, status, scheduledStatus or scheduledTeam) | Yes | Yes | No |
|
| EpisodeOfCare reference | |||
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam) | Yes | Yes | No |
|
| EpisodeOfCare reference | |||
Reminder about appointment | No | Yes | No | Only |
|
| EpisodeOfCare reference |
Scope for the control
| Info |
|---|
The table below reflects future behavior. A change is under way that will change the FHIR Communication created and correspondingly, the CommunicationRequest required to control the creation. |
<Description of search and selection algorithm>
...
Overriding the Payload and/or Medium
...