Scheduling
1.0.0-comment - ballot
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
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
application/fhir+xml
, SHOULD support application/fhir+json
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.
client
IHE Scheduling client will
None mandated by IHE, encouraged IHE-IUA or SMART-on-FHIR
search-system
interaction.The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include
_revinclude
Resource Type | Profile | R | S | U | C | Searches | _include | _revinclude | Operations |
---|---|---|---|---|---|---|---|---|---|
Appointment | https://profiles.ihe.net/ITI/Scheduling/StructureDefinition/ihe-sched-appt | y | y | _id, identifier, patient, date, specialty, appointment-type, practitioner, patient+date | $find , $book , $hold | ||||
Patient | http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-patient | y | y | _id, birthdate, family, gender, given, identifier, name, family+gender, birthdate+family, birthdate+name, gender+name | Provenance:target |
read
, search-type
.Conformance | Parameter | Type | Documentation |
---|---|---|---|
SHALL | _id | token | Logical id of this artifact |
SHALL | identifier | token | The client SHALL provide both the system and code values. |
SHALL | patient | reference | The patient, or one of the patients, for whom this apointement exists |
SHOULD | date | date | The date, or date range, for the appointments being searched. |
SHOULD | specialty | token | The specialty for which the appointments being searched is. |
SHOULD | appointment-type | token | |
SHOULD | practitioner | reference | The provider, or one of the providers, with whom this apointement is scheduled |
resolves
read
, search-type
.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
Conformance | Parameter | Type | Documentation |
---|---|---|---|
SHALL | _id | token | |
SHALL | identifier | token | The client SHALL provide both the system and code values. |
SHOULD | birthdate | date | A client SHALL provide a value precise to the day. |
SHOULD | family | string | |
SHOULD | gender | token | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. |
SHOULD | given | string | |
SHOULD | name | string |