Business Context > Business Rules

Business Rules

The following business rules highlight some key business process in this implementation guide. More technical details on some of these items and others can be found in the Direct Messaging integration, SMART integration, RESTful FHIR API and FHIR Artifacts.

Messaging Paradigm

ServiceRequests are are primarily handled though the FHIR messaging paradigm.

ServiceRequest transmission and handling is primarily implemented using the FHIR messaging paradigm. In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens (this is essentially a "webhook"). Events mostly correspond to things that happen in the real world. The request message consists of a Bundle identified by the type "message", with the first resource in the bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the bundle depend on the type of the request. In a messaging paradigm, an event will trigger a full set of relevant information.

More details about messaging and the events used in this iGuide are detailed on the Direct Messaging Specification page.

RESTful API

This implementation guide supports RESTful API interactions enabling systems to search and retrieve service and provider related information. The interactions supported within this implementation guide are Search and Read.

Current implementations MAY support the RESTful paradigm in one or more of the following contexts:

1. To retrieve information from a FHIR Server as part of a SMART integration, minimally to GET Patient and Practitioner context information
2. To GET current information about ServiceRequest
3. To GET current information about a HealtcareService directory

It is expected that more RESTful operations will be added be included in future revisions to this implementation guide.

Future Iterations

This implementation guide will continue to evolve.

Requested features, changes and fixes are listed in the Future Development section of this IG. Furthermore, some currently excluded FHIR profile elements may be included in future revisions to FHIR Artifacts.

Source of Truth and the Responsibility of Referral Management System

Top

The "source of truth" is dependent on the implementation scenario. For example when a referral is created, the 'source of truth' would be the RMS Source system whereas in a scenario where an appointment is booked the 'source of truth' would be the RMS Target system.

Both the sending and receiving HICs shall retain all communications and documentation within the eConsult/eReferral submission for a time period established by their policies and regulatory college(s) in order to comply with applicable laws.​ The non-HICs are not required to retain communication and documentation within the eReferral-eConsult submission.​

The Referral Management System is intended to support exchange of data between the source and the target. It’s a bidirectional flow of data from one system to the other. This does not refer to which health information custodian or an agent acting on behalf of the health information custodian has the (most) accurate information.

Any correction and updates to the original referral would be submitted as an update to that referral and the original referral will not be altered or over-written in any way.

Determining the single "Source of Truth" regarding a referral and its status is not straightforward. Consider the following:

• The RMS Source is responsible for the contents of the ServiceRequest A requester at the RMS source creates the ServiceRequest and is responsible for its content. Thus, the Service request should not generally be modified by the RMS target

• If the RMS source makes a modification to a ServiceRequest, it should notify the RMS target

• The RMS Target is responsible for processing the ServiceRequest (with a process-request Task) A provider at the RMS Target receives a ServiceRequest, creates a Task resource (i.e., "process-request") to progress the referral through its workflow. This includes setting outcomes of the referral, adding appointments, care plans, communications, or even creating additional ServiceRequest(s) its users create)

• As the RMS target updates the Task (and related resources), it should notify the RMS source

• If the RMS target wishes to modify the ServiceRequest (e.g., fix client's phone number), it should send a "notify-data-correction" message to the RMS source

Receiving Referral Updates

RMS Sources must be trusted by RMS Target to receive referral updates from the RMS Target

For an RMS Source to receive an update about referral it has submitted to an RMS Target, the RMS Source must be pre-authorized and authenticated via some type of trust mechanism with the RMS Target.

Revoking Referrals

In the rare cases when a patient no longer wishes to be referred and removes previously granted consent for the referral to be transmitted or viewed by the target user, the status of the referral reflects that it is revoked. Revoke can be initiated from either the RMS Source or RMS Target.​

​When a patient withdraws their consent those directives will apply to future referrals.

Chaining & Branching Referrals

Chain & Branch Referrals with the ServiceRequest.basedOn element

For referral processes that generate more referrals (e.g., central intake, assessment centres, service navigation, etc.), the new "child" referrals will have a connected "parent" referral. In these cases, ServiceRequest.basedOn SHALL be used to associate the new referral(s) with the original referral it is based on.

In these cases, multiple messages will often be needed to:

• forward the new referral request(s),
• notify the requester that new referral request were created in response to the original, and potentially to
• notify other systems of the existence of the new requests.

See Branching and Chaining Requests for implementation details.

Provenance

RMS Systems Manage Provenance Internally

This implementation guide does not include a mechanism for deep provenance handling. It is the responsibility of the RMS systems to manage their related provenance appropriately.

Referral Status

From the perspective of a Requester, the status of a ServiceRequest is tracked using ServiceRequest.status element. It's the responsibility of the RMS Source (requester) to change the status of a ServiceRequest as deemed appropriate. For example, the requester could set the ServiceRequest.status as 'completed' if they are satisfied that the ServiceRequest has been processed.

Status updates by the RMS Source are communicate to the RMS Target using ServiceRequest Bundle Events

To track the overall status of the ServiceRequest processing, the RMS Source uses the process-request Task.status (draft | requested | received | accepted | etc.). Referral targets may also have their own custom statuses as defined by their internal process flow (e.g., waiting for manager approval), which can be communicated via Task.businessStatus.text, or use one of the common values in the extensible codeset published with this implementation guide.

Updates by the RMS Target are communicated to the RMS source using the Task Bundle Events

3rd Party Systems

3rd Party Systems such as patient portals and data registries may interact with eReferrals

While this document focusses on the interaction between RMS Sources, RMS Targets and POS systems other 3rd party systems may interact with the eReferral workflow in this implementation guide as well.

Some potential interactions could include:

• Sending notifications about new or modified referrals to a regional referral registry or repository
• Sending Communications to the RMS Target from a 3rd party Provider Portal regarding a referral
• Patients revoking consent to their referral via a patient portal

The 3rd party system would have to be registered with the RMS (Source or Target), with appropriate scopes, authorization and authentication mechanisms in place to ensure that appropriate systems can access the API or receive messages with appropriate controls.

Duplicate/Repetitive Data in FHIR Resources

One characteristic that implementers often find unintuitive about FHIR is that the same data is often duplicated/repeated among multiple resources, rather than be normalized. For example, the Patient is referenced from ServiceRequest and Task and Appointment resources, which may all be included in the same bundle. This is because FHIR is designed as a data exchange format and not a data storage format. When designing exchange formats, you almost always end up choosing robustness and stability (i.e., redundant data) over efficiency.

Learn more about using FHIR as a data storage format here.

When there are redundant fields that represent duplicate/repetitive data, it is expected that the data would be the same. This specification does not specify where priority is when redundant data fields differ, it is recommended to reject the payload in its entirety. Some examples where data is expected to match include (but are not limited to):

• Patient across ServiceRequest, Task, Appointment, Communication, DocumentReference
• ServiceRequest across Task, Communication, Appointment
• PractitionerRole across Service, ServiceRequest.requester and MessageHeader.author

Handling Clinical Resources & Un-profiled Data Elements

The initial focus of this implementation guide is on the workflow of eReferral, rather than clinical data associated with eReferrals (e.g., Medication/ Allergies, Observation resources).

The intention is that as clinical resources are profiled in releases of eReferral implementation guide, those resources should be used for communicating supporting clinical information. If there is a need for implementers to profile specific clinical resources the expectation is that they collaborate with the FHIR Implementers community and contribute the profiles to this implementation guide for broad use.

In the meantime, there are four options for handling data elements that are not mapped to an existing or newly developed profile:

• Convert into a human-readable text format and included in the ServiceRequest.note annotation element.
• Include the data in a QuestionnaireResponse resource, which will be included in the initial referral submission bundle, where QuestionnaireResponse.basedOn points to the referral.
• Include the data in a DocumentReference resource.
• Include the data in a Communication resource.

A specific FHIR implementation can be conformant with more than one FHIR implementation guide. If a project requires net new resources that do not exist in this provincial eReferral IG, it could develop additional profile(s) to supplement the provincial eReferral implementation guide, and work with the governance body to add the new requirements into the provincial eReferral implementation guide if there is a general applicability to the eReferral ecosystem.

Routing Options (Extension)

Some referral processes may ask the referrer to provide some data that impacts the receiver's automated referral processing rules. The rules for how a receiver processes their referrals can be unique to the receiver. Some examples include routing based on:

• The type of referrer (from the hospital, primary care, out of province, etc...)
• The patient's Postal Code FSA (e.g., K8N, L0L, etc...)
• The first letter of the patient's last name (e.g., A-J, K-Z)

To handle this, use the Routing Options extension, which is included in both the ServiceRequest AND MessageHeader (for add-servicerequest event) resources. By also including the extension in the MessageHeader, it makes it easier for implementers to find the key routing-related data fields without needing to dig further into the referral payload.

Note: When the eReferral process is combined with a service directory, the directory should be able to publish the valueSet of referral options that are available for a selected service.

Gender, Birth Sex & Gender Identity

Patient.gender is to be used to specify the observed patient gender at the time of the referral (regardless of the gender presentation at birth). This is also referred to as "administrative gender", which is the gender that the patient is considered to have for administration and record keeping purposes. This property is often used as an input to patient matching algorithms.

Due to its importance in patient matching algorithms, gender is a mandatory element. In the case where a referral does not need to know gender, set "Patient.gender" = "unknown"

Note that the FHIR Patient resource documentation discusses patient.gender in depth.

Regarding more detailed tracking of gender identity there are ongoing discussions in the standards community, this implementation guide is waiting on a community consensus. If more detailed gender values are required, an implementer may consider using the FHIR patient-genderIdentity extension. To specify birth sex, consider using the US Core birthSex extension or the CIHI IRRS FHIR Implementation Guide.

Patient Present Location (Extension)

Sometimes a referral needs to communicate where the patient is at the time of the referral (e.g., in Ward X of Hospital Y), which may be different from the patient's home address. To communicate this, use the PatientPresentLocation extension, which references a Location resource.

Present location can be nested using Location.partOf to communicate locations with multiple levels, e.g., Location.partOf > Location for WardX > HospitalY.

Request Authorizer vs. Submitter

Sometimes the person who authorizes a referral can be different from the person who submits it (e.g., a hospital physician authorizes a referral that is submitted by a discharge planner). In this scenario: the referral authorizer is captured by ServiceRequest.requester, and may also be mapped onto MessageHeader.author when submitting the referral. The referral submitter is captured by MessageHeader.sender, which upon message receipt is then mapped by the receiving system onto Task.requester.

For subsequent messages in the referral lifecycle (e.g., adding an appointment, updating the status, etc..), the MessageHeader.author will continue to be used to indicate the authorizer, and MessageHeader.sender will indicate who sent it.

In the case where authorizer and submitter are the same, only MessageHeader.author is needed (MessageHeader.sender can be omitted).

Patient Self Referral

The ServiceRequest.requester element can be left blank, which generally indicates that the ServiceRequest is a self-referral. To explicitly indicate this, set the ServiceRequest.request to be the same as the ServiceRequest.subject.

Requisitons/Multiple Connected Referrals

When multiple connected referrals are made simultaneously (e.g., 3 home care services after discharge from hospital to home, multiple lab tests such as blood work and urinalysis in a single requisition, etc...), they can all be submitted in the same message (event: add-servicerequest). This is known as a "requisition" (in the ServiceRequest resource). There is some special handling to consider for requisitions.

REQUISITION IDENTIFIER: Each service request in the add-servicerequest message will have a common identifier in the "ServiceRequest.requisition" element. The requisition identifier must be included in all future/subsequent MessageHeaders related to this referral, using the ReferralIdentifier extension.

COMMON DATA: Note that it is expected that duplicate common elements would have common values, e.g., all service requests should

• have the same patient
• have the same submitter,
• have a target ServiceRequest performer pointing to a HealthcareService (or ProviderRole) from a single organization

Some other fields are optionally the same depending on the use case. For example:

• Reason for referral (i.e., reasonCode.text) may be duplicated among all related referrals or may differ.

COMMUNICATIONS: If there is a communication that is related to the entire requisition, the communication should have Communication.basedOn reference all of the service requests within the requisition.

Specifying a Service

Every referral must specify a target service via ServiceRequest.performer, pointing to either a HealthcareService or PractitionerRole. This is typically shared as a reference to an externally hosted URL, which uniquely identifies this service. The meaning of this URL should be known by the RMS target, as a service that it can process an eReferral for.

In addition, ServiceRequest.code can be used to further define a specific procedure under a service. For example:

• performer = Orthopaedic Surgeon, code=Knee Surgery
• performer = Meals on Wheels, code = Frozen Meals

A service directory would also be required to specify what codes are available for a given HealthcareService or PractitionerRole.

eConsult Business Events

Although the DirectMessaging and RESTful FHIR API paradigms outlined within this Implementation Guide can be applied to both eReferral and eConsult workflows, there are some slight variations betweeen workflow that need to be taken into consideration when using this specification.

Searching for a Recipient (Specialist)

In the eConsult workflow, prior to a consult request being created, the referrer begins the process by searching for a recipient. The are two search functionalities supported:

1) BASE Managed Specialty

In the BASE Managed Specialty model, this option allows requests to be submitted to a regional Managed Specialty, which is a group of consultants responding to eConsult cases for a given specialty or sub-specialty. The case is routed to the closest Regional Managed Specialty or a Provincial Managed Specialty if a local one is not available. Case assignment is based on consultants' availability. The requester performs a search on the HealthcareService resource before creating a new consult request. The requester is prompted to select from a standardized taxonomy for Specialty Category and Specialty Option. The search will be conducted to locate Base Managed Specialties providing services for the for the Specialty option based on location. Users can override the default selection and view all Base Managed Specilialty groups published for the Specialty Option and select an alternate option.

2) Specific Provider or Group Model

In the Specific Provider model, the requester is prompted to search for a Specific Provider or Group. The requester will select a Provider or Group from the search results and this provider or group will be the recipient of the request. Requests will be submitted to specific consultants by name; or to organizational and self-organized groups.

Case Assignment

In the BASE Managed search model, case assignment may take place automatically using an algorithm that takes into account location, availability, specialty and sub-specialty. Cases may also be assigned by a human assigner.

Whereas in the Specific Provider model the case is assigned directly to a specialist, in the Group Model, the case is assigned by a human that works at the organization selected by the referrer. The case assigner will manually select a specialist based on availability.

Adding Notes

Consult notes can include text based notes and attachments. Notes can be added to an eConsult request at various stages of the process. The referrer may add notes when the consult is in the following states:

• Case Submitted
• Clarification Requested
• More Information Provided
  

The specialist may add notes during the following consult states:

• Consult Provided
• More Information Requested

Case Redirect

Cases may be redirected to different specialists by the referrer and the case assigner. If a specific provider is not available, the assigner may redirect the case to another specialist. This scenario will not cancel or close the original request but direct it to another target.

A referrer has the ability to redirect a case when it is not assigned and before a consult is provided. In this scenario, the original request is terminated and a new one is generated.

Requesting Clarification

After a consult has been provided, if further information is needed, the referrer has the ability to request clarification from the specialist. The consult state changes to Clarification Requested.

Case Completion

After a consult has been provided by the specialist, if the referrer is satisfied with the response they will then mark the case complete. At this stage, the case state is Case Completed.

A set of Key Performance Indicator (KPI) questions are required to be completed for billing and analytics upon completing an eConsult. One set of questions are to be completed by the requester, and the other by the specialist who responds to the consult. Questionnaire will contain key performance questions related to billing and service utilization.

HealthcareService Directories

RMS systems may maintain their own HealthcareService directories and share content from their respective directory with other systems. The section will supplement the HealthcareService Resource with additional information regarding HealthcareService directories and further implementation guidance.

Identifiers

Identifiers are applied to a HealthcareService in a generic way, with no special constraints. Multiple identifiers can be applied, such as directory identifiers (e.g., 211), industry issued identifiers (e.g., pharmacy IDs), local system identifiers, and master identifiers in a federated data sharing model.

It is envisioned that in a federated data sharing model, a “Master Record Holder" (MRH) can issue a “Jurisdictional Master Record” identifier which uniquely identifies the HealthcareService across an entire Canadian federated network of HealthcareService directories. When available, each directory participating in the federated network should maintain the “Jurisdictional Master Record (JMR)” identifier in its record data, to support interoperability and prevent data duplication.

A “Master record holder” (MRH) is the primary system which engages with the organization to keep its HealthcareService data up to date. This is often (but not always) the RMS that processes RECEIVING referrals for this HealthcareService. A HealthcareService must have only one MRH. An MRH must abide by a set of agreed upon rules in the federated network to ensure it is issuing its “Jurisdictional Master Record” identifiers in an appropriate way.

The “Master Record” concept also has corresponding data in the resource security and endpoint elements:

• Set the security tag=“MASTERMark” for the “Master Record”
• Set the security tag=”COPYMark” for any derivative federated records.
• Include a Healthcareservice.endpoint with connectionType=”master-record”, which points to the retrieval location for the Master Record.

NOTE: The pattern mentioned here is conceptual. Future implementations and discussions on this topic may result in further change.

Taxonomy

Taxonomy classification is expressed using the element – HealthcareService.type.

There are many approaches to taxonomies. For example, a taxonomy might be (but is not limited to) single tag based, multi-tag, multi-tag with a primary tag, hierarchical, faceted or a combination of these approaches.

For example, Google My business is a hierarchical multi-tag with primary tag taxonomy. 211 is a hierarchical multi-tag faceted taxonomy. Other common taxonomies are simply multi-tag or single tag based.

The HealthcareService handling of taxonomy should be flexible enough to accommodate most approaches.

Taxonomy classification of HealthcareService data is applied exclusively through the “type” field, and has the following features:

• A general “tag” style of classification taxonomy is applied.
• Multiple types from multiple taxonomy systems can be applied in a single HealthcareService.
• A “primary” type (modeled after Google My Business) is handled through an extension.
• A taxonomy “facet” (modeled after 211) is handled through an extension. It classifies terms along the following 5 dimensions: Services | Organization/Facility Type | Modality/Delivery Format | Named Programs, Target Populations
• With the exception of “facet”, taxonomy concepts that are implicit to the taxonomy itself are NOT explicitly expressed with the HealthcareService data. This includes concepts such as term definition, related terms, bibliographical references, taxonomy hierarchy, etc.

Type vs. Characteristics / Category / Specialty

Use the “type” element exclusively for classifying HealthcareService records in a taxonomy. DO NOT use category or specialty for taxonomy classification, as they overlap with the concept of type and complicates search implementations.

Use type in conjunction with the “characteristics” element to express “features” of a HealthcareService that may be searchable in a secondary way but are not inherently “taxonomy” in nature (e.g., wheelchair accessible, vegetarian meals, etc…).

Multiple Types

The “type” element can include multiple values with multiple systems. For example, a record might have a type “Colonoscopy Clinic” using a directory’s native taxonomy system, and may also have type “Gastroenterology” using the PractitionerSpeciality value set.

When more than one type is included, one type (per system) can be marked as the “Primary” type using the “primary-type” extension. This is modeled after Google My Business, which prioritizes the primary term above others in search algorithms.

Taxonomy Value Sets

Many directories have implemented their own taxonomy, or use external taxonomies from various sources (such as 211, Google, Caredove, Ocean, SNOMED, etc…). As such, this implementation guide is focused on enabling a variety of taxonomy implementations, and is not opinionated on which specific taxonomy to apply (with the exception of clinical specialties, as discussed in next section).

Specialties and Sub Specialties

Clinical specialty classifications should use the PractitionerSpeciality value set. This value set is a broadly adopted and robust yet simple taxonomy. Note that it does not contain non-clinical-specialty values (such as for social services), where alternate taxonomies need to be applied. This taxonomy is applied to the HealthcareService “type” field instead of the “specialty” field to simplify the implementation of taxonomy search to one field instead of multiple fields.

Specialties often need to be combined with sub-specialties. It is recommended to use “type” for sub-specialty classification.

Facets

A taxonomy “facet” (modeled after 211) is handled through the “facet” extension to the type element. Note that there is some data redundancy to the inclusion of facets as they are an intrinsic characteristic of the applied taxonomy system and term. However, it is worth including facet in the HealthcareService data to facilitate search within a facet, and to support integrations where a strong taxonomy mapping between integrating systems may not be in place.

Facets are limited to the following values (more details found at 211 - Introduction to Taxonomy: pg 7):

• Services - What a service DOES. E.g., “Meals on Wheels”, “Colonoscopy Clinic”, etc. It is assumed that a “type” has a service facet if no facet is specified.
• Target Populations - WHO is served by the HealthcareService. E.g., Seniors, People with disabilities, new mothers, etc…
• Organization/Facility Type - What the organization IS. e.g., “Hospital”, “Police Office”, “Community Health Centre”, etc…
• Modality/Delivery Format - HOW services are provided. E.g., advocacy, classroom training, group counseling, etc…
• Named Program - Major programs, generally governmental, that have broad recognition and durability over time. E.g., OHIP, Old Age security, etc… For regional and local programs, use the “HealthacreService.programs” element instead.

“Services” is the most important facet. It can stand alone without any of the other facets, but the other facets usually need to be used in conjunction with a service. “Target Populations” is the second most important, which should almost always be used in conjunction with a service taxonomy term.

Hierarchical Taxonomies

Only ONE tag within a hierarchical chain should be included in the HealthcareService.type element. Depending on the system, search on a service with a hierarchical tag might imply the inclusion of searching tags up or down the hierarchy. However, this hierarchical search behavior is a system and taxonomy specific functionality, and it does not need to be considered from an interoperability perspective.

Location

Location(s) are used to express where services may be provided. If an administrative office is listed off-site separate from where the HealthcareService is provided, its Location should not be referenced here (it can be referenced from the related Organization resource).

The HealthcareService may have multiple locations.

For organizations with many services and locations, it can be difficult to tell if a service should be represented as one service with many locations or as multiple services with their own locations. As general guidance:

• if a different method of access is used for different locations, then multiple HealthcareServices should be used (e.g., different eligibility criteria or different access phone #s).
• Otherwise, multiple locations can optionally be used for one HealthcareService. A specific implementation would also maintain the option to give a dedicated HealthcareService for each location.

To assist in sharing accurate lat/long information about addresses, the referenced Location resource can use the geolocation extension to express address coordinates.

Telecom

The HealthcareService.telecom field lists the inquiry phone, email, fax and informational web page for the healthcare service.

Note that “url” telecoms should reference the HealthcareService’s public website information page (usually found on the providing organization’s website). There must only be ONE url telecom, unless the additional urls reference common social urls in their path (i.e., facebook, linkedIn, instagram, tiktok).

Service request page URLs (e.g., a public booking page) are communicated elsewhere with the endpoint element.

Telecom can be provided in any/all of the HealthcareService, Location and Organization resources. As a rule of thumb, use HealthcareService.telecom for the purpose of ACCESS information (i.e., when a person can call to get started or ask for information), Location.telecom for OPERATIONAL information (i.e., for a person being provided service), and Organization.telecom as a fallback if the other two are not available. Telecom information may be available in one, two or all of these resources.

When presenting telecom information to the user, prioritize telecom as follows: HealthcareService >> Location >> Organization.

Program

The purpose of the "program" is to group services provided by one or many organizations under a formal “program” label. E.g.,

• Ontario eConsult
• Eastern Immunization Program
• Canada Craving Change

Generally the use of program should be avoided for simple single organization classification of services, as the meaning of organization level “program” is too diverse between organizations to have consistent interoperability interpretation. For example, an organization with an “Adult Day Program”, “Meals on Wheels”, and “Transportation” might classify that under their “Seniors Program”,

Since the creation (and dissolution) of programs is very dynamic, it is unlikely that a central coding system will be available for this, so be sure to use at least the .text element in the CodeableConcept for human readability. Using coding will be necessary to enable filtered search by program.

Characteristic

Treat this as a "tag field" or "keyword field". This can be used to communicate additional data fields that a specialized HealthcareService directory might have but is not otherwise included in this specification.

The usage of this field in this implementation guide is intended to facilitate maximum future implementer flexibility for less common data fields within a computable structure, without requiring broad consensus among differing directories or the creation of extensions for every conceivable data field. Over time, common standardized codes can be developed.

Note that this can also be accomplished with the “extra details” field, but without the benefit of coded computability. This could also be accomplished with extensions, but that approach comes with significant added complexity and loss of flexibility. The simplest way to tag a field is to use the .text element. It is encouraged to also use a coding system. Both published coding systems and local coding systems can be applied simultaneously (since the coding element is 0..*, see CodeableConcept documentation for details). coding system., even if it is the system’s local coding system.

The characteristic field can contain two types of tags, basic tags and faceted tags.

Basic tags:

Apply multiple characteristics to a service with a flat tagging structure. For example, a hospice program might have the following tags: Wheelchair accessible, Vegetarian meals, pets allowed, single rooms, non-smoking rooms, smoking rooms.

“Wheelchair accessible” could be represented as:

• coding.code=”wheelchair-accessible”
• coding.display=”Wheelchair Accessible”
• text=”Wheelchair Accessible”

Faceted tags:

Apply tags in a two-level hierarchy, which conceptually is like adding multiple tag fields (i.e., “facets”) to the healthcare service, each with its own set of applied tags. The same hospice program would would be represented by the following facet | tag combinations:

• Accessibility: Wheelchair Accessible, Pets allowed
• Meals: Vegetarian
• Room Types: Single, smoking, non-smoking

Faceted tags are coded by applying the “facet” extension to the characteristic element. When rendering faceted tags for display, the facet can be used as a label, and all of the characteristics that share that facet can be included as its values. For example, E.g., If “Wheelchair accessible” and “Pets allowed” both have the facet “Accessibility”, they can be displayed to the user as “Accessibility: Wheelchair accessible, Pets allowed”.

Available Time

Hours can be provided in the HealthcareService resource and/or the Location resource.

As a rule of thumb, use HealthcareService.availableTime for the purpose of ACCESS hours (i.e., when a person can call to get started or ask for information), and Location.hoursOfOperation for OPERATIONAL hours (i.e., when a person can be provided service).

Hours information may be available in one or both of these resources.

When presenting hours information to the user, HealthcareService hours should generally be prioritized over Location hours.

Location.hoursOfOperation and Location.availabilityExceptions can also be used, and take priority if included.

Endpoint

Technical endpoints providing access to services operated for the location. This includes endpoints that can be used for retrieving the master record of this HealthcareService, submitting a ServiceRequest, referral webpage URLs, SMART on FHIR URLs, and the service’s referral Questionnaire.

Master Record

Publish the endpoint where a GET operation can be performed to get the master record of this HealthcareService.

• connectionType=master-record
• Name=Master Record Endpoint
• address=URL to perform GET operation to retrieve the Master Record.

eReferral Endpoint

Publish the endpoints where an eReferral can be submitted. Use this endpoint to publish which version of the eReferral specification this HealthcareService can use to receive a ServiceRequest. There may be multiple eReferral endpoints to convey that multiple versions of the eReferral specification are supported. e.g.,

• connectionType=cad-ereferral-1-0
• name=Canadian eReferral v1.0
• address=URL endpoint to POST service requests to.

Note that there will be new connectionType values over time as successive versions of the eReferral iGuide are released.

Public Referral Website

This is the page that launches a service request process and is generally available for the public to self-register. It may contain a booking process. There must be only one public referral website per service.

• connectionType=service-request-page
• name=Service Request Page
• address=Web link url where the service request page can be found

SMART on FHIR (SoF) Service Request Page

This is the page that would be used to initiate a Service Request to this service using SMART on FHIR. The page should be structured to be embeddable and be able to accept SOF parameters. In many cases a registration process between the launching and hosting system would need to take place before this SoF functionality is available.

• connectionType=service-request-sof
• name=Service Request SMART on FHIR page
• address=Web link to be used as the SoF app. See the endpoint resource page in this iGuide for details on usage of other Endpoint fields such as managingOrganzation and contact.

Referral Questionnaire

This is the page where the service’s referral Questionnaire resource can be retrieved

• connectionType=service-request-questionnaire
• name=Service Request Form
• address=URL where GET [baseURL]/Questionnaire can be retrved