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
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:
- Support at least one Argonaut Scheduling patient or provider use case.
- 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.
- Conform to the US Core Implementation Guiide.
- Support json resource formats for all Argonaut Scheduling interactions.
- Declare a CapabilityStatement identifying the list of profiles, operations, search parameter supported.
The Argonaut Scheduling Server SHOULD:
- Support xml resource formats for all Argonaut Scheduling interactions.
- 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:
-
A server SHALL be capable of returning Appointments using:
GET [base]/Appointment/[id]
. -
A server SHALL be capable of returning Appointments using search:
GET [base]/Appointment?patient=[id]{&status=[status]}{&date=[date]{&date=[date]}}{&practitioner=[id]}
-
A server SHALL support the following search parameters:
- _id
- patient
-
A server SHOULD support the following search parameters:
- status
- date - including the date modifiers ‘ge’,’le’,’gt’,’lt’
- practitioner
-
-
A server SHALL be capable of returning Appointments by supporting the Appointment Availability Operation.
-
Both the
GET
andPOST
Syntax SHALL be supported:GET [base]/Appointment/$find?{parameters}&?{_count}
POST [base]/Appointment/$find?{_count}
-
-
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
-
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
-
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:
-
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
-
A server SHALL be capable of searching for Patients as defined in the US Core Implementation Guide.
-
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:
-
A server SHALL be capable of returning Slots by supporting the Appointment Availability Operation.
-
Both the
GET
andPOST
Syntax SHALL be supported:GET [base]/Slot/$prefetch?{parameters}
POST [base]/Slot/$prefetch
-
Subscription
Supported Profiles: Argonaut Scheduling Subscription Profile
Capabilities:
-
A server SHALL be capable of creating Subscriptions
POST [base]/Subscription
-
A server SHALL be capable of deleting Subscriptions
DELETE [base]/Subscription