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: server

Argonaut Scheduling Conformance Requirements

This section outlines conformance requirements for the Argonaut Scheduling Servers application, 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 Server

  • 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 Server which is responsible for providing responses to the requests submitted by the Argonaut Scheduling Clients. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Argonaut Scheduling Servers are defined.

Behavior

Description:

The Argonaut Scheduling Server SHALL:

  1. Support at least one Argonaut Scheduling patient or provider use case.
  2. Implement the RESTful behavior according to the FHIR specification including returning the appropriate response classes as described in the FHIR specification for FHIR RESTful API and Extended Operations on the RESTful API.
  3. Conform to the US Core Implementation Guiide.
  4. Support json resource formats for all Argonaut Scheduling interactions.
  5. Declare a CapabilityStatement identifying the list of profiles, operations, search parameter supported.

The Argonaut Scheduling Server SHOULD:

  1. Support xml resource formats for all Argonaut Scheduling interactions.
  2. Identify the Argonaut Scheduling profiles supported as part of the FHIR meta.profile attribute for each instance.

Security:

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

Profile Interaction Summary:

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

Resource Type Supported Profiles Supported Interactions
Appointment Argonaut Appointment Profile read, search, patch, $find, $hold, $book
Bundle Argonaut Appointment Bundle Profile, Argonaut Slot Bundle Profile
Coverage Argonaut Coverage Profile create, update
Patient US Core Patient Profile search, create
Schedule Argonaut Schedule Notification Profile
Slot Argonaut Prefetch Slot Profile $prefetch
Subscription Argonaut Scheduling Subscription Profile create, delete

Resource Details:


Appointment

Supported Profiles: Argonaut Appointment Profile

Capabilities:

  1. A server SHALL be capable of returning Appointments using:

    GET [base]/Appointment/[id].

  2. A server SHALL be capable of returning Appointments using search:

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

    1. A server SHALL support the following search parameters:

      • _id
      • patient
    2. A server SHOULD support the following search parameters:

      • status
      • date - including the date modifiers ‘ge’,’le’,’gt’,’lt’
      • practitioner
  1. A server SHALL be capable of returning Appointments by supporting the Appointment Availability Operation.

    • Both the GET and POST Syntax SHALL be supported:

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

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

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

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

    POST [base]/Appointment/$hold

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

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

    POST [base]/Appointment/$hold

  4. A server SHALL be capable of updating Appointments by supporting patch and SHALL declare support for JSON, XML, or FHIRPath Patch.

    PATCH [Base]/Appointment/[id]


Bundle

Supported Profiles:

Coverage

Supported Profiles: Argonaut Coverage Profile

Capabilities:

  1. A server SHOULD be capable of updating or creating a patient's Coverage.

    • A server MAY reject certain updates to the coverage information (for example, type of coverage) and SHOULD return an OperationOutcome explaining the reason.

    PUT [base]/Coverage/[id]

    PUT or POST [base]/Coverage


Patient

Supported Profiles: US Core Patient Profile

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

  2. A server SHOULD be capable of creating Patients by supporting create

    POST [base]/Patient

    • The server SHOULD create a new patient resource only if the patient resource does not already exist in the system. If the patient is already registered within the system, the existing patient resource SHOULD be returned.

Schedule

Supported Profiles: Argonaut Schedule Notification Profile


Slot

Supported Profiles: Argonaut Prefetch Slot Profile

Capabilities:

  1. A server SHALL be capable of returning 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 server SHALL be capable of creating Subscriptions

    POST [base]/Subscription

  2. A server SHALL be capable of deleting Subscriptions

    DELETE [base]/Subscription