Use Cases

Business Context > Use Cases

Use Cases

The use cases below provide basic illustrations of how actors interact with the PPR 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.
PPR	system	The EHR asset responsible for centralized storage and management of provider identity and demographic information. PPR exposes service endpoints to allow access to PPR information.
PPR Consumer	system	A software application interacting with PPR to retrieve provider identity and demographic information, to support local business needs.
PPR Consumer User	human	A person who interacts with a PPR Consumer to request and use provider information from the PPR.
PPR Service Endpoint*	system	A web service exposing PPR services to external stakeholders.

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

Use Case 1 (UC1) - Look up a Practitioner by Demographics(Practitioner EMPI Match)

A registration agent at a hospital (PPR Consumer User) uses a connected Hospital Information System (PPR Consumer) to retrieve summary information about a patient’s Primary Care Provider.

The Practitioner EMPI Match operation implements this use case.

Table - Use Case #1

Step	Description
1.	PPR 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 information to the PPR Consumer User.
2.	PPR Consumer User enters the provider’s first name, last name and city into the PPR Consumer (HIS) to look up the provider.
3.	PPR Consumer searches the local system using the first name, last name and city but does not find a match.
4.	PPR Consumer establishes connection to PPR FHIR Service Endpoint and submits a query with the appropriate credentials and the provider’s first name, last name and city to search for candidate providers in the PPR.
5.	Service Endpoint validates the credentials received and forwards the query to the PPR.
6.	PPR uses the first and last name and City from the query to return a list of candidates from the PPR, sending the reply to the PPR Service Endpoint with the information retrieved from the PPR.
7.	PPR Service Endpoint forwards the reply to the PPR Consumer
8.	PPR Consumer displays the matched candidates to the PPR Consumer User.
9.	PPR Consumer User selects the appropriate PPR provider from the candidate list, verifying the summary level information returned from the PPR with the patient to confirm the selection.
10.	PPR Consumer User completes the provider registration with the information returned from the PPR for the selected healthcare provider.

Alternate flows (not expanded) include:

1. Service Endpoint fails to validate credentials.
   1. Negative response returned to the PPR Consumer.
2. PPR fails to find a provider.
   1. Negative response returned to PPR Consumer.
3. Patient’s Primary Care Provider information not returned in the list.
   1. PPR Consumer User invokes alternative methods to get provider information.
4. PPR Consumer User performs alternative search operation

Use Case 2 (UC2) - Lookup a Practitioner by License Number (Practitioner Search)

An administrator at a hospital (PPR Consumer User) uses a connected Hospital Information System (PPR Consumer) to retrieve information about a provider from the PPR as part of their local re-credentialing workflow.

The Practitioner Search operation implements this use case.

Table - Use Case #2

Step	Description
1.	PPR Consumer User is completing re-credentialing activities for doctors practicing at the hospital.
2.	PPR Consumer User enters the provider’s license number including the regulatory college information into the PPR Consumer to look up the provider’s status in the PPR.
3.	PPR Consumer establishes connection to PPR Service Endpoint and submits a query with the appropriate credentials and license information (number and corresponding college source universal identifier) to search for the provider’s status in the PPR.
4.	Service Endpoint validates the credentials received and forwards the query to the PPR.
5.	PPR uses the college universal identifier and license number to return the provider information (including active or terminated status), and replies to the PPR Service Endpoint with the information found.
6.	PPR Service Endpoint forwards the reply to the PPR Consumer
7.	PPR Consumer displays the matched provider including their status to the PPR Consumer User.
8.	PPR Consumer User confirms that the provider is still in active status in the PPR, and proceeds with re-credentialing the provider with the appropriate authorities in the local HIS.

Alternate flows (not expanded) include:

1. Service Endpoint fails to validate credentials.

   1. Negative response returned to the PPR Consumer.

2. PPR fails to find a provider.

   1. Negative response returned to PPR Consumer.

Use Case 3 (UC3) - Look up a Practitioner by PPR Unique Provider Identifier (UPI)(Practitioner Search)

A PPR Consumer solution maintains a local repository of practitioners including the PPR assigned UPIs. Using the UPI for a given practitioner, the PPR Consumer automatically queries the PPR on a weekly schedule to retrieve the latest information for a provider from PPR. Comparing the latest data against the local data, and applying updates (if any) to the local data from PRR as the authoritative source.

The Practitioner Search operation implements this use case.

Table-Use case #3

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

Alternate flows (not expanded) include:

1. Service Endpoint fails to validate credentials.
   1. Negative response returned to the PPR Consumer.
2. PPR fails to find a provider.
   1. Negative response returned to PPR Consumer.

Use Case 4 (UC4) – Look up a Provider Location by Role (Location EMPI Match)

When preparing to discharge a provider, a Social Worker (PPR Consumer User) uses a connected care planning information system (PPR Consumer) to search for rehab treatment facilities in the provider’s neighborhood.

The Location EMPI Match operation implements this use case.

Table - Use Case #4

Step	Description
1.	PPR Consumer User identifies the Postal code of the nearby communities of their provider in the PPR Consumer solution to search for rehab treatment facilities in a specific community.
2.	PPR Consumer User enters the location role type (rehab treatment facility) and municipality (e.g. City - from the provider’s address) into the PPR Consumer to find provider locations.
3.	PPR Consumer establishes connection to PPR Service Endpoint and submits a query with the appropriate credentials, location role type and municipality to the PPR.
4.	PPR Service Endpoint validates the credentials received and forwards the query to the PPR.
5.	PPR uses the location role type and municipality to return a list of candidate locations from the PPR, and replies to the PPR Service Endpoint with the information found.
6.	PPR Service Endpoint forwards the reply to the PPR Consumer
7.	PPR Consumer displays the matched candidate’s information to the PPR Consumer User.
8.	PPR Consumer User selects the appropriate PPR provider from the candidate list, verifying the level information returned from the PPR with the provider to confirm the selection.
9.	PPR Consumer User completes the provider discharge with the identified rehab location information returned from the PPR.

Alternate flows (not expanded) include:

1. Service Endpoint fails to validate credentials.
   1. Negative response returned to the PPR Consumer.
2. PPR fails to find an location.
   1. Negative response returned to PPR Consumer.
3. No suitable Locations returned to the PPR Consumer User. (e.g. results are returned, but none that are suitable to the needs of the client

1. PPR Consumer User needs to change criteria and resubmit.

4. PPR Consumer User performs an alternative search operation.

Use Case 5 (UC5) - Look up a Provider Location by UPI (Location Search)

A PPR Consumer solution maintains a local list of authorized provider location UPIs to access a given EHR service. When a given provider location requests access to a given EHR service, the PPR Consumer solution queries the PPR by UPI to confirm the location is still authorized to access a given service based on its location status.

The Location Search operation implements this use case.

Table - Use Case #5

Step	Description
1.	PPR Consumer User receives a request from a given location to access a given EHR service.
2.	PPR Consumer User retrieves the Location’s UPI from the service request, and leverages it to query the PPR using the appropriate credentials.
3.	PPR Consumer establishes connection to PPR Service Endpoint and submits a query with the appropriate credentials and UPI to query for the provider location’s status in the PPR.
4.	Service Endpoint validates the credentials received and forwards the query to the PPR.
5.	PPR uses the UPI return the details view of the provider location (including active or terminated location status), and replies to the PPR Service Endpoint with the information found.
6.	PPR Service Endpoint forwards the reply to the PPR Consumer
7.	PPR Consumer User confirms that the provider is still in active status in the PPR, and proceeds with authorizing access to the requested EHR service for the given location.

Alternate flows (not expanded) include:

1. Service Endpoint fails to validate credentials.
   1. Negative response returned to the PPR Consumer.
2. PPR fails to find a provider.
   1. Negative response returned to PPR Consumer.