SMART Scheduling Links
1.0.0 - STU 1 International flag

SMART Scheduling Links, published by HL7 International / Patient Administration. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/smart-scheduling-links/ and changes regularly. See the Directory of published versions

Conformance

Page standards status: Informative

This page contains a table listing all the free-text conformance statements found in this implementation guide. This table is provided as a useful summary for implementers for the purpose of evaluating key features and to support testing. However, reading this table alone is insufficient to understand or successfully implement the specification:

  • The table only includes conformance expectations expressed as free text. It does not include the computable expectations represented in capability statements, profiles, value sets, etc.
  • The text in the table only includes the 'formal' requirement. It does not provide the contextual language around the statement that will be needed for successful implementation. The id of each statement is a hyperlink to the place it appears in the text to assist with gathering the needed context.

A few other notes:

  • The ids are generally specific to the pages on which the requirements appear, but not always. If content is moved from one page to another, the id of a statement will be preserved.
  • Where a statement has been removed, its id is retired and gaps in the numbering may appear. This is not an error.
  • Guidance in the Slot Aggregators section is offered as recommendations rather than as conformance statements, so most of that section does not appear in this table.
IdExpectationRule
 SHOULD
 MAY
 SHALL
 SHOULD NOT
 SHALL NOT
§sched-1SHALL
MAY		 Wherever "timestamps" are used in this specification, they SHALL be in the format YYYY-MM-DDThh:mm:ss.sss+zz:zz (e.g. 2015-02-07T13:28:17.239+02:00 or 2017-01-01T00:00:00Z). The time SHALL be specified at least to the second and SHALL include a time zone offset (for UTC, the offset MAY be Z).
§sched-2SHALL For Bulk Publication Manifest requests, servers SHALL support at least the following Accept headers from a client, returning the same FHIR JSON payload in all cases:
§sched-3SHALL For Bulk Output File requests, servers SHALL support at least the following Accept headers from a client, returning the same FHIR NDJSON payload in all cases:
§sched-4SHOULD Slot Publishers SHOULD annotate each output with a list of states or jurisdictions as a hint to clients, allowing clients to focus on fetching data for the specific states or geographical regions where they operate;
§sched-5SHOULD Slot Publishers SHOULD include a Cache-Control: max-age=<seconds> header as a hint to clients about how long (in seconds) to wait before polling next.
§sched-6SHOULD NOT Clients SHOULD NOT request a manifest or any individual data file more than once per minute.
§sched-7MAY Clients MAY include standard HTTP headers such as If-None-Match or If-Modified-Since with each query to prevent retrieving data when nothing has changed since the last query.
§sched-8MAY Clients MAY include a ?_since={} query parameter with a timestamp when retrieving a manifest file to request only changes since a particular point in time.
§sched-9SHOULD Slot Publishers SHOULD host $bulk-publish content at open, publicly accessible endpoints when sharing general healthcare appointment availability (no required access keys or client credentials).
§sched-10SHOULD
MAY		 Slots MAY include only coarse-grained timing. Slot Publishers SHOULD provide finer-grained slot information with specific timing where it is available.
§sched-11SHOULD Clients SHOULD ignore any output items with types other than PractitionerRole, Location, Schedule, or Slot.
§sched-12SHOULD Slot Publishers SHOULD provide data with sufficient freshness to minimize staleness
§sched-13SHOULD When publishing a Slot with "status": "free", Slot Publishers SHOULD ensure the Slot is available for booking given current business rules.
§sched-14MAY Slot Discovery Clients and Slot Aggregators MAY enrich or filter slot data with additional attributes — such as insurance network, patient demographics, or geographic constraints — to improve the relevance of results for their users.
§sched-15SHOULD Provider Booking Portals SHOULD handle invalid slots gracefully, preserving as much of the user's original intent as possible.
§sched-16SHOULD Where a specific time slot is no longer available, the Provider Booking Portal SHOULD present remaining slots on or near the originally selected time and day, rather than simply displaying an error.
§sched-17MAY When the "Has Availability" extension is used on a Schedule, that Schedule MAY have no associated Slots.
§sched-18SHALL NOT Slot Publishers SHALL NOT use this capability in place of publishing granular Slots;
§sched-19SHOULD If a PractitionerRole is associated with organization-specific identifiers (such as role-specific employee numbers, provider numbers, or location-specific identifiers), Slot Publishers SHOULD include these.
§sched-20MAY If a PractitionerRole participates in external registry programs that assign role-specific identifiers, Slot Publishers MAY include these identifiers using the appropriate system URL for the registry.
§sched-21MAY Any number of additional identifiers MAY be included.
§sched-22SHOULD If a Location is associated with organization-specific identifiers (such as facility numbers, site codes, or store numbers), Slot Publishers SHOULD include these.
§sched-23MAY If a Location participates in external registry programs that assign location identifiers, Slot Publishers MAY include these identifiers using the appropriate system URL for the registry.
§sched-24MAY Any number of additional identifiers MAY be included.