Scheduling
1.0.0-comment - ballot International flag

This page is part of the IHE ITI Scheduling (v1.0.0-comment: Publication Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

CapabilityStatement: IHE Scheduling Client

Official URL: https://profiles.ihe.net/ITI/Scheduling/CapabilityStatement/IHE.Scheduling.client Version: 1.0.0-comment
Active as of 2024-02-05 Computable Name: IHE_Scheduling_Client

Copyright/Legal: IHE http://www.ihe.net/Governance/#Intellectual_Property

CapabilityStatement for Client Actor in the IHE IT Infrastructure Technical Framework Supplement IHE FHIR Scheduling. See https://profiles.ihe.net/ITI/TF/Volume1/ch-38.html.

Raw OpenAPI-Swagger Definition file | Download

Generated Narrative: CapabilityStatement IHE.Scheduling.client

IHE Scheduling Client

  • Implementation Guide Version: 1.0.0-comment
  • FHIR Version: 4.0.1
  • Supported Formats: SHALL support application/fhir+xml, SHOULD support application/fhir+json
  • Supported Patch Formats:
  • Published on: 2024-02-05
  • Published by: IHE IT Infrastructure Technical Committee

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

SHOULD Support the Following Implementation Guides

FHIR RESTful Capabilities

Mode: client

IHE Scheduling client will

  1. query for Patient resources matching the IPA Patient resource query parameters,
  2. query for Appointment resources matching the IHE Scheduling Appointment resource query parameters,
  3. use the operations defined for the Appointment resource
Security

None mandated by IHE, encouraged IHE-IUA or SMART-on-FHIR

Summary of System-wide Interactions
  • Supports the search-systeminteraction.

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCSearches_include_revincludeOperations
Appointmenthttps://profiles.ihe.net/ITI/Scheduling/StructureDefinition/ihe-sched-apptyy_id, identifier, patient, date, specialty, appointment-type, practitioner, patient+date$find, $book, $hold
Patienthttp://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-patientyy_id, birthdate, family, gender, given, identifier, name, family+gender, birthdate+family, birthdate+name, gender+nameProvenance:target

Resource Conformance: SHALL Appointment

Profile Conformance
SHALL
Reference Policy

Interaction summary
  • Supports read, search-type.

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken

Logical id of this artifact

SHALLidentifiertoken

The client SHALL provide both the system and code values.

SHALLpatientreference

The patient, or one of the patients, for whom this apointement exists

SHOULDdatedate

The date, or date range, for the appointments being searched.

SHOULDspecialtytoken

The specialty for which the appointments being searched is.

SHOULDappointment-typetoken
SHOULDpractitionerreference

The provider, or one of the providers, with whom this apointement is scheduled

Combined Search Parameters
ConformanceParametersTypes
SHALLpatient+datereference+date
Extended Operations
ConformanceOperationDocumentation
SHALL$find

Document the find operation

SHALL$book

Document the book operation

SHOULD$hold

Document the hold operation

Resource Conformance: SHALL Patient

Profile Conformance
SHALL
Reference Policy
resolves

Interaction summary
  • SHALLsupport read, search-type.

Documentation

Client applications SHALL be able to access the patient record using the following API call:

GET [url]/Patient/[id]

Client application MAY use these search parameters that servers are required to support to access the patient record:

  • _id
  • identifier

Servers are not required to support any additional search parameters, and clients SHOULD not expect servers to do so.

Additional rules and guidance for supporting Patient.link:

  • The server:
    • SHALL have no more than one Patient with a status of active = "true" from the server being queried
    • MAY include inactive patients on the same server
    • MAY include inactive or active patients from a different server
    • When returning a search Bundle that contains more than one Patient record for the same patient, the Patient record(s) SHALL use the Patient.link attribute to cross-link the Patient resources.
  • The client:
    • SHALL be able to follow the link(s) to the other Patient resource(s) and understand the direction of the link (in other words, which Patient is linked to which other Patient)
    • SHALL understand the Patient.link.type code which defines the type of link between this Patient resource and another Patient resource
    • SHALL be aware of the linked Patient active flag and that inactive patients could have relevant information
Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLidentifiertoken

The client SHALL provide both the system and code values.

SHOULDbirthdatedate

A client SHALL provide a value precise to the day.

SHOULDfamilystring
SHOULDgendertoken

The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

SHOULDgivenstring
SHOULDnamestring
Combined Search Parameters
ConformanceParametersTypes
SHOULDfamily+genderstring+token
SHOULDbirthdate+familydate+string
SHOULDbirthdate+namedate+string
SHOULDgender+nametoken+string