Criteria Requirements Library Profile

Canonical	../StructureDefinition/nexus-criteria-requirements
Status	draft · 1.26.0
Base	Library (constraint)
Source	FSH · JSON

The data-requirements manifest generated for a compiled clinical criterion: a FHIR R4 Library with type = module-definition, declaring the resource types the logic retrieves, the profiles they must satisfy, the code and value-set filters applied, and the elements read. Derived from the compiled logic rather than authored beside it, so it cannot drift from the criteria it describes. A deployment artifact verified when a consuming host starts, not an API surface an application reaches.

Examples

Criteria Requirements Manifest - Diabetes Trigger

The data-requirements manifest generated for one compiled clinical criterion, reproduced from a shipped criteria pack. Three data requirements, two of which carry a code filter naming the element the codes apply to; the relative-date flag is true, so membership goes stale without anybody writing anything and a change feed alone will not keep the cohort current; six element-read paths, flat across all three resource types and carrying no type prefix. The id, meta.profile and narrative are added so this guide can publish and validate it -- a manifest inside a pack carries none of the three, and the profile requires none of them

Library/DM-01-requirements — claims conformance to Criteria Requirements Library Profile

{
  "resourceType": "Library",
  "id": "DM-01-requirements",
  "meta": {
    "profile": [
      "../StructureDefinition/nexus-criteria-requirements"
    ]
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns='http://www.w3.org/1999/xhtml'><p>The data-requirements manifest generated for one compiled clinical criterion: a diabetes trigger that looks for an HbA1c result and a diabetes medication on a patient. Everything below was written by the analysis that ran over the compiled logic -- nothing here was authored by hand, and nothing here can disagree with the criterion it describes.</p><p><strong>Three data requirements, and two of them carry a code filter.</strong> The Patient retrieve has none because it is unfiltered. Where a filter is present it always names the element the codes apply to: <code>code</code> for the Observation, <code>medication</code> for the MedicationRequest. A filter with no path is refused when the manifest is generated and refused again when a consuming host starts, so this element is never absent on a shipped manifest.</p><p><strong>criteria-relative-date is true here</strong>, because the criterion is anchored to a moving reference point. That means membership goes stale without anybody writing anything, so a change feed alone is not enough and a periodic re-evaluation is required. It is written on every manifest whichever way it comes out: an absent value would not mean false, it would mean this analysis did not produce the file.</p><p><strong>criteria-elements-read repeats, one path per occurrence.</strong> Six paths across the three resource types, flat and without a type prefix -- sizing a projection for the Observation means intersecting this list with the types in dataRequirement, not reading it straight through. It is a lower bound: derived from retrieves and property accesses, without inference across included libraries.</p><p><strong>The value set on the medication filter is not published by this guide, and is not meant to be.</strong> A criteria pack carries its own value sets as supplied expansions and a consuming host refuses to start on a pack naming one it was not given, so the canonical here resolves against the pack rather than against this specification. Do not read it as an artifact this guide defines.</p><p><strong>Three things on this page are not on the shipped file.</strong> A manifest in a pack carries no <code>id</code>, no <code>meta.profile</code> and no narrative; it is read from disk by the software that ships with it, not served from an endpoint. The three are added here so this specification can publish and validate the example, and the profile deliberately requires none of them.</p></div>"
  },
  "url": "../Library/DM-01-requirements",
  "name": "TriggerDM01",
  "version": "1.0.0",
  "status": "active",
  "type": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/library-type",
        "code": "module-definition"
      }
    ]
  },
  "dataRequirement": [
    {
      "type": "Patient",
      "profile": [
        "../StructureDefinition/nexus-emr-core-patient"
      ]
    },
    {
      "type": "Observation",
      "profile": [
        "../StructureDefinition/nexus-emr-core-observation"
      ],
      "codeFilter": [
        {
          "path": "code",
          "code": [
            {
              "system": "http://loinc.org",
              "code": "4548-4",
              "display": "HbA1c"
            }
          ]
        }
      ]
    },
    {
      "type": "MedicationRequest",
      "profile": [
        "../StructureDefinition/nexus-emr-core-medicationrequest"
      ],
      "codeFilter": [
        {
          "path": "medication",
          "valueSet": "../ValueSet/dm-medications"
        }
      ]
    }
  ],
  "extension": [
    {
      "url": "../StructureDefinition/criteria-relative-date",
      "valueBoolean": true
    },
    {
      "url": "../StructureDefinition/criteria-elements-read",
      "valueString": "authoredOn"
    },
    {
      "url": "../StructureDefinition/criteria-elements-read",
      "valueString": "category"
    },
    {
      "url": "../StructureDefinition/criteria-elements-read",
      "valueString": "code"
    },
    {
      "url": "../StructureDefinition/criteria-elements-read",
      "valueString": "effective"
    },
    {
      "url": "../StructureDefinition/criteria-elements-read",
      "valueString": "medication"
    },
    {
      "url": "../StructureDefinition/criteria-elements-read",
      "valueString": "value"
    }
  ]
}