Business Context > Use Cases

Use Cases

The use cases below provide basic illustrations of how actors interact with PHSD to consume provider information.

Actors

Table - Use Case Participants

Participant	Type	Description
Provider	human	A person, typically a licensed healthcare provider, who is the subject of the system interactions in the use case.
PHSD	system	The Ontario Health asset responsible for centralized storage and management of provider demographic information and service information. PHSD exposes secure service endpoints to allow access to PHSD information.
PHSD Consumer	system	A software application interacting with PHSD to retrieve provider or service information, to support local business needs. A PHSD Consumer may interact with PHSD Directly (an adhoc query) or synchronize data with the PHSD. If the Consumer synchronizes their data with the PHSD, the PHSD Consumer User will perform searches locally (i.e. in the PHSD Consumer system) against the data sourced from PHSD.
PHSD Consumer User	human	A person who interacts with a PHSD Consumer to request and use provider information from PHSD.
PHSD Data Supplier	system	A system that contributes locally managed data to the PHSD.
PHSD Service Endpoint*	system	A web service exposing PHSD services to PHSD Consumers.

*For brevity, other actors involved in the orchestration of non-PHSD complimentary EHR services, including identity management, authorization and authentication are not included.

NOTE: Use cases defined below identify the use cases using PHSD ad-hoc queries. In the case where the PHSD Consumer is synchronizing the data with PHSD, the PHSD Consumer system should provide similar capabilities to the PHSD Consumer User.

Pre-Condition: Authentication & Authorization

All access to the PHSD endpoints and data are secured. In order to access the data in the PHSD, a set of valid credentials must be provided and the appropriate authorizations granted. As a pre-condition for any step in the use case where connection to the PHSD interfaces/endpoints is required, the calling system/user must be authenticated and authorized. In the case where authentication OR Authorization of the access request is denied, the use case will end and an error returned to the requesting system.

Step	Description
1.	PHSD Consumer establishes connection (with the appropriate credentials) to PHSD FHIR Service Endpoint.
2.	PHSD Service Endpoint validates the credentials received and authorizes the request to the proceed.

Alternate flow:

1. Authentication or Authorization of the request fails.
   1. Error is returned to the requestor.
   2. Use case ends.

Use Case 1 - Practitioner Search - Find a Practitioner

The "Search Practitioner" interaction implements this use case. The search practitioner operation allows a number of combinations of parameters (e.g. Demographics (i.e. name, City, Identifiers such as licence or UPI or other externally assigned, but known ids) for a number of uses.

Table - Use Case #1a - By Name & City

A registration agent at a hospital (PHSD Consumer User) uses a connected Hospital Information System (PHSD Consumer) to retrieve summary information about a patient’s Primary Care Provider using demographic information such as name.

Step	Description
1.	PHSD Consumer User (registration agent) is completing a patient registration to the local HIS and asks to capture the patient’s Primary Care Physician (PCP) information. In order to capture the details of the patient’s healthcare provider, the patient identifies the provider’s demographic information (e.g. Name) to the PHSD Consumer User.
2.	PHSD Consumer User enters the provider’s first name, last name and city (minimum criteria) into the PHSD Consumer (HIS) to look up the provider.
3.	PHSD Consumer searches the local data using the first name, last name and city but does not find a match.
4.	PHSD Consumer submits a request using the provider’s first name, last name and city as parameters to PHSD Endpoint
5.	PHSD uses the first and last name and City (parameters) from the request to return a list of candidates from the PHSD, sending the reply to the PHSD Service Endpoint with any matching records retrieved from the PHSD.
6.	PHSD Service Endpoint forwards the reply to the PHSD Consumer
7.	PHSD Consumer displays the matched candidates to the PHSD Consumer User.
8.	PHSD Consumer User selects the appropriate provider from the candidate list, verifying the summary level information returned from the PHSD with the patient to confirm the selection.
9.	PHSD Consumer User completes the provider registration using the information returned from the PHSD as the PCP information.

Alternate flows (not expanded) include:

1. PHSD Consumer finds existing provider by First Name, Last Name and City.
   1. Use case ends.
2. PHSD fails to find a provider.
   1. Negative response returned to PHSD Consumer.
3. Patient’s Primary Care Provider information not returned in the list.
   1. PHSD Consumer User invokes alternative methods to get provider information.
4. PHSD Consumer User performs alternative search operation

Table - Use Case #1b - By License An administrator at a hospital (PHSD Consumer User) uses a connected Hospital Information System (PHSD Consumer) to retrieve information about a provider from the PHSD as part of their local re-credentialing workflow.

Step	Description
1.	PHSD Consumer User is completing re-credentialing activities for doctors practicing at the hospital.
2.	PHSD Consumer User enters the provider’s license number including the regulatory college information into the PHSD Consumer to look up the provider’s status in the PHSD.
3.	PHSD Consumer Submits a request using license information (number and corresponding college source universal identifier) as parameters to PHSD.
4.	PHSD uses the college universal identifier and license number (parameters) to find and return the provider information (including active or terminated status), and returns the information to the PHSD Service Endpoint.
5.	PHSD Service Endpoint forwards the reply to the PHSD Consumer
6.	PHSD Consumer displays the matched provider including their status to the PHSD Consumer User.
7.	PHSD Consumer User confirms that the provider is still in active status in the PHSD, and proceeds with re-credentialing the provider with the appropriate privileges in the local HIS.

Alternate flows (not expanded) include:

1. PHSD fails to find a provider.
   1. Negative response returned to PHSD Consumer.

Table - Use Case #1c - by PHSD Identifier A PHSD Consumer solution maintains a local repository of practitioners including the PHSD assigned UPIs. Using the UPI for a given practitioner, the PHSD Consumer automatically queries the PHSD on a fixed schedule to retrieve the latest information for a provider from PHSD. Comparing the latest data against the local data, and applying updates (if any) to the local data from PHSD as the authoritative source.

Step	Description
1.	PHSD Consumer establishes connection to PHSD Service Endpoint and submits a request to PHSD including the UPI’s of the selected providers as parameters.
2.	PHSD gathers the full details of the provider based on UPI, including the most current demographic and identity information for the provider, and replies to PHSD Service Endpoint with the information found.
3.	PHSD Service Endpoint forwards the reply to the PHSD Consumer.
4.	PHSD Consumer uses the details provided from the PHSD to compare and update the provider person details locally.

Alternate flows (not expanded) include:

1. PHSD fails to find a provider.
   1. Negative response returned to PHSD Consumer.

Use Case 2 - Find a Provider Location

The "Search Location" interaction implements this use case. The Search Location operation allows a number of combinations of parameters (e.g. Role (e.g. Hospital) or Address, or Name) for a number of uses.

Table - Use Case #2a - Find a location by Role When preparing to discharge a patient, a Social Worker (PHSD Consumer User) uses a connected care planning information system (PHSD Consumer) to search for rehab treatment facilities in the patient’s neighborhood.

Step	Description
1.	PHSD Consumer User identifies the Postal code of the nearby communities of their patient in the PHSD Consumer solution to search for rehab treatment facilities in a specific community.
2.	PHSD Consumer User enters the location role type (rehab treatment facility) and municipality (e.g. City - from the patient address) into the PHSD Consumer to find provider locations.
3.	PHSD Consumer submits a request to PHSD Service Endpoint using location role type and municipality as parameters to the PHSD.
4.	PHSD uses the location role type and municipality (parameters) to return a list of candidate locations and replies to the PHSD Service Endpoint with the information found.
5.	PHSD Service Endpoint forwards the reply to the PHSD Consumer
6.	PHSD Consumer displays the information from PHSD to the PHSD Consumer User.
7.	PHSD Consumer User locates the appropriate location from the candidate list.
8.	PHSD Consumer User completes the patient discharge with the identified rehab location information returned from the PHSD.

Alternate flows (not expanded) include:

1. PHSD fails to find an location.

   1. Negative response returned to PHSD Consumer.

2. No suitable Locations returned to the PHSD Consumer User. (e.g. results are returned, but none that are suitable to the needs of the client

3. PHSD Consumer User needs to change criteria and resubmit.

4. PHSD Consumer User performs an alternative search operation.

Table - Use Case #2b - Find a Service Delivery Organization by Identifier A PHSD Consumer solution maintains a local list of authorized provider location UPIs. In order to update the current status of the location the PHSD Consumer solution makes a request to the PHSD to confirm the location is still active.

Step	Description
1.	PHSD Consumer sends request to PHSD Endpoint providing the identifier (UPI) as the parameter.
2.	Service Endpoint forwards the request to the PHSD.
3.	PHSD uses the UPI to get the detailed view of the provider location (including active or terminated location status), and replies to the PHSD Service Endpoint.
4.	PHSD Service Endpoint forwards the reply to the PHSD Consumer.
5.	PHSD Consumer User confirms that the provider is still in active status in the PHSD, and updates the status in it’s local store.

Alternate flows (not expanded) include:

1. PHSD fails to find a provider.
   1. Negative response returned to PHSD Consumer.

Use Case 3 - Find a Healthcare Service

From a local PHSD Consumer System connected to the PHSD directly to perform ad-hoc queries against PHSD, a care coordinator is searching for a pediatric rehab program. the PHSD Consumer user enters information about the pediatric rehab program (service type) calls the PHSD Search Healthcare Service operation to directly search PHSD.

Table-Use case #3

Step	Description
1.	A PHSD Consumer makes a request to PHSD Endpoint to request all healthcare service records that match the criteria provided.
2.	Service Endpoint forwards the API call to the PHSD.
3.	The Search HealthcareService operation is invoked with search criteria (e.g. location, service category, service type, specialty, organization, etc.)
4.	PHSD sends the search results to the PHSD Service Endpoint.
5.	PHSD Service Endpoint forwards the matching records to the PHSD Consumer.

Alternate flows (not expanded) include:

1. Search HealthcareService operation fails.
   1. Negative response returned to the PHSD Consumer.
2. Search HealthcareService operation finds no matches.
   1. Positive response returned to PHSD consumer with no data.

Use Case 4 - Find Organization

From a PHSD Consumer system directly connected to PHSD, a care coordinator is looking to contact an organization’s administration office. The PHSD Consumer uses the Search Organization operation to generate a results list from PHSD.

The "Search Organization" interaction implements this use case.

Table - Use Case #4

Step	Description
1.	A PHSD Consumer makes a request to the search Organization operation with selected parameters.
2.	PHSD Service Endpoint forwards the API call to the PHSD.
3.	the PHSD performs a Search Organization operation with provided search criteria (e.g.name, type, address, etc.);
4.	PHSD sends the search results to the PHSD Service Endpoint.
5.	PHSD Service Endpoint forwards the response to the PHSD Consumer.

Alternate flows (not expanded) include:

1. Search Organization operation fails.
   1. Negative response returned to the PHSD Consumer.
2. Search Organization operations finds no matching data for criteria.
   1. Positive response returned to PHSD consumer with no data.

Use Case 5 - Search Questionnaire

From a referral management system, a care coordinator initiates an eReferral to a mental health service, to ensures the most current version of referral form is being used, the back-end uses the Search Questionnaire API to pull the latest form.

The "Search Questionnaire" interaction implements this use case.

Table - Use Case #5

Step	Description
1.	A PHSD Consumer makes a request to the Search Questionnaire operation with proper parameters
2.	PHSD Service Endpoint forwards the API call to the PHSD.
3.	The Search Questionnaire operation is invoked using the parameters provided in the request (url)
4.	PHSD sends the search results to the PHSD Service Endpoint.
5.	PHSD Service Endpoint forwards the response to the PHSD Consumer.

Alternate flows (not expanded) include:

1. Search Questionnaire operation fails.
   1. Negative response returned to the PHSD Consumer.
2. Search Questionnaire finds no matching Questionnaire(s)
   1. Positive response returned to PHSD consumer with no data.

Use Case 6 - Provide Updates to PHSD

From a referral management system, a service provider updates their service listing data (e.g. address, contact information, service capabilities). The referral management system as a PHSD Data Supplier needs to provide the updates to PHSD to allow PHSD to update other PHSD Consumers.

The "Bulk Import" interaction implements this use case.

Table - Use Case #6

Step	Description
1.	The PHSD Data Supplier generates data files containing the most recent information updated in their system (on a period basis) and all associated records
2.	The PHSD Data Supplier uploads the file(s) to a file share location
3.	The PHSD Data Supplier generates download URLs for each of the data files (per resource type).
4.	The PHSD Data Supplier makes a request to the PHSD Endpoint (Bulk Import operation) including the list of download URLs to the data files (as generated in step 3)
5.	PHSD acknowledges the request with an OK message.
6.	PHSD receives the request and downloads the files locally.
7.	PHSD takes the updates from the data supplier and applies them to the PHSD local copy of the data suppliers records.
8.	PHSD generates notifications related to changed data in PHSD.

Alternate flows (not expanded) include:

None.

NOTE: a subsequent report will be generated based on processing and validation of the incoming data. An error report will be generated and made available to the PHSD Data Supplier.

Use Case 7 - Request Updates from PHSD

A referral management system needs to receive updates on service provider listings from PHSD (e.g. address, contact information, service capabilities, status etc.). The referral management system as a PHSD Consumer needs to get updates from the PHSD to update their local directory.

NOTE: There are a number of parameters to filter and reduce the amount of data in the updates. It is expected that most, if not all, data consumers with local repositories will look for periodic updates from the PHSD, and will request the updates via Bulk Update operation using the “Since” parameter to limit the updates to those that have not been received since X date.

The "Bulk Export" interaction implements this use case.

Table - Use Case #7

Step	Description
1.	The PHSD Consumer makes a request to the PHSD Endpoint (Bulk Export operation) including parameters to identify the types and timing of updates they wish to receive.
2.	PHSD acknowledges the request with an “Accepted” message.
3.	PHSD starts the bulk export operation to generate the appropriate files from changes identified by the parameters supplied.
4.	The PHSD Consumer polls periodically to the PHSD Endpoint (Bulk Export operation) to check on the status of the job (responses 202 =in progress, 500 = error, 200 = complete) In Parallel, PHSD creates export files based on the parameters, and uploads the files to a file share.
5.	The PHSD Consumer receives a 200 message including Download URLs for the export files.
6.	The PHSD Consumer downloads the file(s) from the file share location
7.	PHSD Consumer applies the updates to the local system (add, updates and status changes)

Alternate flows (not expanded) include:

1. Polling (step 4) receives 500 error
   1. Use case ends, support required.
2. PHSD Consumer cannot access shared files
   1. Use case ends, support required.

NOTE: a subsequent report will be generated based on processing and validation of the incoming data. An error report will be generated and made available to the PHSD Data Supplier.