{
  "resourceType": "CodeSystem",
  "status": "draft",
  "content": "complete",
  "name": "AppointmentOceanSentCS",
  "id": "appointment-ocean-sent",
  "title": "Appointment Ocean Sent Tag CodeSystem",
  "description": "Records that an appointment has been sent to the Ocean eReferral integration. Carried as a tag on\n`Appointment.meta.tag`, where this is the tag's `system`.\n\n**A tag, not an extension.** The address identifies the `system` of a `Coding` in `meta.tag`, which\nis why it is declared as a code system. The vocabulary is the unusual part: the codes are the\nliteral strings `true` and `false`.\n\n**Absent means not sent.** A missing tag and the code `false` mean the same thing to a reader. The\nmarker is written only after a send returns successfully; a refused or failed send leaves the\nappointment untagged so it can be retried.\n\n**Match the code exactly, in lower case.** The reader compares the code to `true` character for\ncharacter, so `True` is not read as sent. This is stricter than the sibling system below, whose\nreader parses the code as a boolean and tolerates any casing -- a writer that emits lower case\nsatisfies both.\n\n**It selects the outbound event shape.** An appointment not yet marked is sent as a new appointment;\none already marked is sent as an update to the appointment the receiving system already knows. It is\nalso read to drop a duplicate send for the same appointment.\n\n**It is a send marker, not a delivery receipt.** It records that the send was made and was not\nrefused. It does not say the receiving system processed or accepted the record, and it carries no\ntime.\n\n**It says nothing about the appointment.** No clinical or scheduling fact follows from it, and the\nappointment's own status is unaffected by whether a send has happened.\n\n**One of two sibling systems, one per outbound integration.** The other is\n`https://fhir.apps.health/CodeSystem/appointment-acdr-arrived`, which carries this same `true` /\n`false` vocabulary under its own address; a third integration would be a third system. They are\nseparate because a writer keeps a single tag per system, replacing rather than adding, so two send\nmarkers sharing one system would erase each other. Read one for the state of one integration only:\nneither implies anything about the other.\n\n**Nexus EMR writes this today at\n`http://services.well.com/fhir/tags/appointment/ocean-sent` (FHIR-378)**: it is live in stored\n`Appointment.meta.tag` codings and in code, and is under migration to the canonical declared here.\nWrite the canonical; expect both until the migration completes, and match both addresses exactly\nrather than deriving one from the other -- the final segment differs between them, not only the\nhost.",
  "url": "https://fhir.apps.health/CodeSystem/appointment-ocean-sent",
  "concept": [
    {
      "code": "true",
      "display": "Sent",
      "definition": "The appointment has been sent to the Ocean eReferral integration and the send was not refused. A later change to the appointment is sent as an update to the appointment already known there rather than as a new one."
    },
    {
      "code": "false",
      "display": "Not sent",
      "definition": "The appointment has not been sent. Carries nothing an absent tag does not -- a reader should treat it exactly as an absent tag."
    }
  ],
  "experimental": false,
  "caseSensitive": true,
  "count": 2
}