Argo-Scheduling Implementation Guide Release 1.0.0

This page is part of the Argonaut Scheduling Implementation Guide (v1.0.0: Release) based on FHIR R3. This is the current published version. For a full list of available versions, see the Directory of published versions

CapabilityStatement: client

Argonaut Scheduling Conformance Requirements

This section outlines conformance requirements for the Argonaut Scheduling Client applications, identifying the specific profiles that need to be supported, the specific RESTful operations that need to be supported, and the search parameters that need to be supported. Note: The individual Argonaut Scheduling profiles identify the structural constraints, terminology bindings and invariants, however, implementers must refer to the conformance requirements for details on the RESTful operations, specific profiles and the search parameters applicable to each of the Argonaut Scheduling actors.

Conformance requirements for the Argonaut Scheduling Implementation Guide Client

  • FHIR Version: 3.0.1
  • Supported formats: xml, json
  • Published: March 20, 2018
  • Published by: The Argonaut Project

The Section describes the expected capabilities of the Argonaut Scheduling Scheduling Client which is responsible for creating and initiating the queries for information about patient scheduling as well as creating and updating this information. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Argonaut Scheduling Servers are defined in the Argonaut Scheduling Server CapabilityStatement. Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

Behavior

Description:

The Argonaut Scheduling Client SHOULD:

  1. Support fetching and querying scheduling information, using the supported RESTful interactions and search parameters declared in the Argonaut Scheduling Server CapabilityStatement.
  2. Conform to the US Core Implementation Guide.

The Argonaut Scheduling Client MAY:

  1. Support creation and updates of scheduling and patient information, using the supported RESTful interactions and search parameters declared in the Argonaut Scheduling Server CapabilityStatement.

Security:

For general security consideration refer to the Security section in the US Core Implementation Guide.

Profile Interaction Summary:

Specific server search capabilities are described in detail in each of the resource sections below.

Appointment

Supported Profiles: Argonaut Appointment Profile

Capabilities
  1. A client SHOULD be capable of fetching Appointments using:

    GET [base]/Appointment/[id].

  2. A client SHOULD be capable of fetching Appointments using search:

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

    1. A client SHOULD support the following search parameters:
      • _id
      • patient
      • status
      • date - including the date modifiers ‘ge’,’le’,’gt’,’lt’
      • practitioner
  1. A client SHOULD be capable of fetching Appointments by supporting the Appointment Availability Operation using either the GET or POST syntax.

    GET [base]/Appointment/$find?{parameters}&?{_count}

    POST [base]/Appointment/$find?{_count}

  2. A client MAY be capable of creating or updating Appointments by supporting the Appointment Hold Operation.

    POST [base]/Appointment/[id]/$hold

    POST [base]/Appointment/$hold

  3. A client SHOULD be capable of creating or updating Appointments by supporting the Appointment Book Operation.

    POST [base]/Appointment/[id]/$hold

    POST [base]/Appointment/$hold

  4. A client SHOULD be capable of updating Appointments by supporting patch using either JSON, XML, or FHIRPath Patch.

    PATCH [Base]/Appointment/[id]


Bundle

Supported Profiles:

Coverage

Supported Profiles: Argonaut Coverage Profile

Capabilities
  1. A client MAY be capable of updating or creating a patient's Coverage.

    PUT [base]/Coverage/[id]

    PUT or POST [base]/Coverage


Patient

Supported Profiles: US Core Patient Profile

Capabilities
  1. A client SHOULD be capable of searching for Patients as defined in the US Core Implementation Guide.

  2. A client MAY be capable of creating Patients by supporting create.

    POST [base]/Patient


Schedule

Supported Profiles: Argonaut Schedule Notification Profile

  1. A client MAY be capable of consuming a Schedule notification as a response to a Argonaut Scheduling Subscription Profile.

Slot

Supported Profiles: Argonaut Prefetch Slot Profile

Capabilities
  1. A client MAY be capable of fetching Slots by supporting the Appointment Availability Operation.

    • Both the GET and POST Syntax SHALL be supported:

      GET [base]/Slot/$prefetch?{parameters}

      POST [base]/Slot/$prefetch


Subscription

Supported Profiles: Argonaut Scheduling Subscription Profile

Capabilities
  1. A client MAY be capable of creating Subscriptions

    POST [base]/Subscription

  2. A client MAY be capable of deleting Subscriptions

    DELETE [base]/Subscription