{
  "resourceType": "CodeSystem",
  "status": "draft",
  "content": "complete",
  "name": "ScheduleCodeCS",
  "id": "schedule-code",
  "title": "Schedule Code CodeSystem",
  "description": "How the appointments on a schedule are delivered.\n\nCarried on `Slot.serviceType` and `Slot.appointmentType`, and on `Schedule.serviceType` for the\nschedule those slots belong to -- the same elements a converted schedule uses for the source EMR's\nown template code.\n\nR4's bindings on those elements are example-strength and name *which service*, not *how it is\ndelivered*, so this concept has no standard system to draw from and is declared locally.\n\nThe list is complete: it is reconciled onto every deployment from one platform-side definition, so\na deployment holds these three codes and no others. The value set a client expands\n(`https://fhir.apps.health/ValueSet/schedule-code`) is a per-deployment artifact held in each\ndeployment's own store, not an artifact of this specification.",
  "url": "https://fhir.apps.health/CodeSystem/schedule-code",
  "concept": [
    {
      "code": "routine",
      "display": "Routine",
      "definition": "DEPRECATED -- write `ROUTINE` from HL7 v2-0276 instead. Ordinary booked appointments, with no delivery qualification. THE PUBLISHED CODE IS THE ONE THE BINDING ASKS FOR: `Slot.appointmentType` binds `http://terminology.hl7.org/ValueSet/v2-0276` at PREFERRED strength in base R4, and that value set contains `ROUTINE` with the same meaning. A preferred binding is FHIR saying which vocabulary to reach for first, so minting a local synonym of a code inside it is the case the binding exists to prevent. Retained because stored schedules carry this code and it must stay representable.",
      "property": [
        {
          "code": "status",
          "valueCode": "deprecated"
        }
      ]
    },
    {
      "code": "clinic",
      "display": "Clinic",
      "definition": "DEPRECATED -- write the appointment modality vocabulary instead. Appointments delivered in person at the clinic site the schedule names. THIS DUPLICATES THIS GUIDE'S OWN VOCABULARY, which is the sharper objection: `nexus-emr-appointment-modality-cs` already carries in-person and remote delivery, so one package published two local vocabularies for one axis. Where a schedule needs to state delivery, state it in the modality system; where an appointment states it, the modality extension is already the declared home. Retained because stored schedules carry this code.",
      "property": [
        {
          "code": "status",
          "valueCode": "deprecated"
        }
      ]
    },
    {
      "code": "telehealth",
      "display": "Telehealth",
      "definition": "DEPRECATED -- write the appointment modality vocabulary instead. Appointments delivered remotely, by video or telephone, rather than at a site. Same objection as `clinic`: this axis is already modelled in `nexus-emr-appointment-modality-cs`, and this guide should not carry two answers to one question. Retained because stored schedules carry this code.",
      "property": [
        {
          "code": "status",
          "valueCode": "deprecated"
        }
      ]
    }
  ],
  "experimental": false,
  "caseSensitive": true,
  "property": [
    {
      "code": "status",
      "uri": "http://hl7.org/fhir/concept-properties#status",
      "type": "code",
      "description": "Concept lifecycle status (active | deprecated | retired)."
    }
  ],
  "count": 3
}