{
  "resourceType": "CodeSystem",
  "status": "draft",
  "content": "complete",
  "name": "NexusConsentFamilyCS",
  "id": "nexus-consent-family",
  "title": "Consent Family CodeSystem",
  "description": "Which family a Consent resource belongs to, carried in `Consent.category` so that a search\nreturning several families can be told apart before any of them is interpreted.\n\nEvery Consent profile in this guide carries one of these codes, in the `family` slice of\n`category`, and that element is searchable -- so a family is selected in the search rather than\nsorted out after it:\n\n```\nGET Consent?patient={id}&category=https://fhir.apps.health/CodeSystem/nexus-consent-family|{code}\n```\n\nOmitting the category returns all three families mixed, because all three carry\n`scope = patient-privacy` and scope separates nothing.\n\nThis code says WHAT a decision governs -- an application, a catalogue item, or the record itself.\nIt does not say how to read the decision, because every family reads the same way: the decision is\n`provision.type` on the root provision, `permit` grants, `deny` restricts, and `status` says only\nwhether the record is operative.\n\nThat uniformity is new. Families used to disagree, and one element meaning opposite things across\nresources sharing a type, a scope and a search is how restricted information gets disclosed -- so\nthe divergence was removed rather than documented around. A consumer MUST NOT read a decision out\nof `status`, and MUST NOT infer the family from `status`, `scope`, or the shape of the provision\ntree.",
  "url": "https://fhir.apps.health/CodeSystem/nexus-consent-family",
  "concept": [
    {
      "code": "app",
      "display": "Application consent",
      "definition": "Whether the patient agreed to share their record with a named third-party application. `provision.type = permit` on the root is agreement, `deny` is refusal. Carried by the App Consent profile. Refusal used to be a nested deny and a grant the absence of one, which meant a truncated resource read as a grant."
    },
    {
      "code": "item",
      "display": "Item consent",
      "definition": "The patient's answer for one catalogue item -- email, SMS, AI scribe. `provision.type = permit` is yes, `deny` is no or withdrawn. Carried by the Item Consent profile. This family used to carry its answer in `status` alone, which is the divergence this guide removed: it made an active item consent mean permission while an active privacy directive means a restriction in force."
    },
    {
      "code": "privacy-directive",
      "display": "Privacy directive",
      "definition": "A standing patient restriction on the collection, use or disclosure of their personal health information -- what PHIPA calls a lockbox. `provision.type = deny` on the root is the restriction; `status = active` says only that the record is operative. Carried by the Privacy Directive profile."
    }
  ],
  "experimental": false,
  "caseSensitive": true,
  "count": 3
}