This page is part of the Argonaut Scheduling Implementation Guide (v1.0.0: Release) based on FHIR R3. This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Provider based Scheduling Use Cases

• Introduction
• Use Case 1: Scheduling across systems
• Use Case 2: Scheduling for existing patient across systems
• Use Case 3: Scheduling for existing patient within a system
• Canceling/Rescheduling appointments
• Releasing holds
• Retrieving Patient appointments

Introduction

The Argonaut Scheduling Implementation Guide defines a series of interactions which cover the basic appointment creation workflow for provider based scheduling on behalf of a patient which includes: registration of patients and updating coverage information, discovery of available appointments and booking the canceling appointments. It also covers provider access to their appointments. The basic workflow steps and Argonaut Scheduling APIs for three use cases are detailed below. Note that the primary difference between these scenarios are the registration steps.

Use Case 1: Scheduling across systems

This use case accounts for both new and existing patients. The actual required steps depend upon factors such as if the patient is known to the external system, and if and when patient coverage information is needed. Use Case 2 and Use Case 3 in the sections below are simplified variations of this more generalized use case.

Preconditions:

• Does not matter whether patient is known or unknown to external system.
• Login and trust
  • System level trust or
  • User level trust
• Work flow for clinic staff vs a call center to make appointment (in person vs over phone) is same

Scenario 1a Provider schedules an appointment with a patient’s PCP on behalf of patient (Discharge follow-up):

 Hospital A has treated patient B. Upon discharge, Hospital A schedules a follow-up appointment with patient B's PCP (primary care provider).

This is a basic referral scenario in which the patient is registered with the referral recipient.

Scenario 1b Provider schedules an appointment with a provider on behalf of patient (Dermatology referral):

  Patient Y sees Doctor Z his PCP for a rash. After examining the patient, Doctor Z wants to Patient Y to see a dermatologist.  The clinic staff schedule Patient Y to see Doctor D for a dermatology consult.  Patient Y has never been to a dermatologist before.

This scenario is very similar to 1a above. However, the patient is presumed to be a new patient to the referral recipient.

Scenario 1c Provider schedules a procedure on behalf of patient (Imaging referral):

  Patient Y see Doctor X for a sore back. After examining the patient Doctor X recommends an MRI for Patient Y. The clinic staff schedule the MRI for Patient Y.  It is unknown whether the Patient Y has used the imaging service before.

This scenario is also very similar to 1a above, but is an appointment for a procedure instead of a direct referral.

Optional Find Patient

Prior to booking an appointment with a FHIR Scheduler, the Client can search across the systems for an existing FHIR Patient resource ID for the patient. If there is an existing FHIR Patient resource, finding it helps avoid double booking a patient.

Usage

To search and fetch the FHIR Patient reasource Id, use the $match operation as described in the FHIR Specification. It can be invoked as follows:

POST [base]/Patient/$match

Example

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "resource",
      "resource": {
        "resourceType": "Patient",
        "identifier": [
          {
            "use": "usual",
            "type": {
              "coding": [
                {
                  "system": "http://hl7.org/fhir/v2/0203",
                  "code": "MR"
                }
              ]
            },
            "system": "urn:oid:1.2.36.146.595.217.0.1",
            "value": "12345"
          }
        ],
        "name": [
          {
            "family": [
              "Chalmers"
            ],
            "given": [
              "Peter"
            ]
          }
        ],
        "gender": "male",
        "birthDate": "1974-12-25"
      }
    },
    {
      "name": "count",
      "valueInteger": "3"
    },
    {
      "name": "onlyCertainMatches",
      "valueBoolean": "false"
    }
  ]
}

HTTP/1.1 200 OK
[other headers]

{
  "resourceType": "Bundle",
  "id": "26419249-18b3-45de-b10e-dca0b2e72b",
  "meta": {
    "lastUpdated": "2016-03-18T03:28:49Z"
  },
  "type": "searchset",
  "total": 2,
  "entry": [{
    "fullUrl": "http://server/path/Patient/example",
    "resource": {
      "resourceType": "Patient",
      "id": "example",
      .. snip ...
    },
    "search": {
      "extension": [{
        "url": "http://hl7.org/fhir/StructureDefinition/match-grade",
        "valueCode": "certain"
      }],
      "mode": "match",
      "score": 0.9
    }
  },{
    "fullUrl": "http://server/path/Patient/292",
    "resource": {
      "resourceType": "Patient",
      "id": "292",
      .. snip ...
    },
    "search": {
      "extension": [{
        "url": "http://hl7.org/fhir/StructureDefinition/match-grade",
        "valueCode": "possible"
      }],
      "mode": "match",
      "score": 0.2
    }
  }]
}

New Patient Registration/Coverage Information Option A

New patients need to be registered and existing patients discovered prior to booking. This registration step MAY occur at this step or as a distinct step just prior to booking (step 5). Additional coverage information for both new and existing patients MAY be associated with this step or as a distinct step prior to (step 5) or following booking (step 7). The information is supplied by the patient or on behalf of the patient.

Registering or Fetching a Patient:

Usage and examples for this step are described in the Patient Use Cases.

Updating or creating Patient Coverage Information:

Usage and examples for this step are described in the Patient Use Cases.

Appointment Availability Discovery and Search

The Client searches for available appointments across system(s) based on simple search criteria provided by the patient or on behalf of the patient. This step is the key transaction for this Scheduling Use Case. It asks the questions: when to book? It is dynamic and complex because of multiple dependencies.

This step uses the Appointment Availability Search Operation and its usage and examples are described in the Patient Use Cases.

Optional hold appointment operation

After the patient or the provider on behalf of the patient selects from the available appointments returned in step 3 above, the Client requests a hold on the appointment to prevent the appointment from being booked by another client. This optional interaction may be needed to allow the patient or provider to complete additional steps such as end user data entry before the booking can be completed.

Usage and examples for this step are described in the Patient Use Cases.

New Patient Registration/Coverage Information Option B

This registration step MAY occur here or as a distinct step prior to the availability search step 2 where it is discussed in detail

Book appointment

After the patient or the provider selects from the available appointments returned in step 3 and the patient registration is complete, the appointment is booked.

Usage and examples for this step are described in the Patient Use Cases.

Optional exchange of patient information

Additional information MAY be exchange following the booking of the appointment. For example the exchange of CCD, other clinical documents or, if not transacted during the prior registration steps, coverage information. This exchange of clinical documents is covered by a separate standard and is currently out of scope for this guide. The details for the exchange of coverage information are described above.

Use Case 2: Scheduling for existing patient across systems

This use case is a simplified variation of this use more general use case 1 above. In this use case, the patient is an existing patient and either the patient ID can be retrieved via the Patient $match operation or by some other means.

Preconditions:

• External system knows patient
• Patient ID is known or retrieved
• Login and trust
  • System level trust or
  • User level trust
• Work flow for clinic staff vs a call center to make appointment (in person vs over phone) is same

Scenario 2a Provider schedules an appointment with a patient’s PCP on behalf of patient (Discharge follow-up):

 Hospital A has treated patient B. Upon discharge, Hospital A schedules a follow-up appointment with patient B's PCP (primary care provider).

This is a basic referral scenario in which the patient is registered with the referral recipient.

Scenario 2a Provider schedules a follow-up procedure on behalf of patient (Imaging referral):

 Patient Y has been seeing Doctor X for a sore back. After examining the patient Doctor X recommends a follow-up MRI for Patient Y. The clinic staff schedule the MRI for Patient Y.

This scenario is similar to 2a above, but is an appointment for a procedure instead of a direct referral with a practitioner.

This use case is discussed in detail in steps 1, 3, 4, 6, 7 in Scenario 1 above.

Use Case 3: Scheduling for existing patient within a system

This is the simplest variation of the more general use case 1 above. The patient and provider, service or procedure are all within the same system. Note that this scenario is typically performed by in-practice system and therefore of limited use for this interoperability specification.

Preconditions:

• same patient, provider, service, insurance

Scenario 3 Provider schedules an follow-up appointment with same provider on behalf of patient. (follow-up appointment):

   Patient Y sees Doctor Z for a rash. After examining and prescribing the appropriate treatment plan, Doctor Z wants to see Patient Y in two weeks for a follow-up visit to evaluate the response to treatment.  The clinic staff schedule Patient Y for a follow-up office call.

This simple use case is covered by steps 2, 3, and 4 in Scenario 1 above.

Canceling/Rescheduling appointments

Usage and examples are described in the Patient Use Cases.

Releasing holds

Usage and examples are described in the Patient Use Cases.

Retrieving Patient appointments

The provider searches for appointments on behalf of a patient or the provider.

Provider access to their scheduled appointments uses the standard FHIR search API.

APIs

The following Argonaut Scheduling artifacts are used in this transaction:

• Argonaut Appointment Profile.

Usage

To fetch scheduled appointments for a patient the Client SHALL use the standard RESTful search API as shown along with these standard search parameters:

• patient (optional) filter by the patient
• status (optional) filter by status such as ‘booked’
• date (optional) filter by a date or a date range ( including the date modifiers ‘ge’,’le’,’gt’,’lt’)
• practitioner (optional) filter by a practitioner(s)

GET [base]\Appointment?practitioner=[id]{&status=[status]&date=[date]}

Example