Projo FHIR Documentation - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Knowledge Artifacts

Knowledge Artifacts

Projo deploys FHIR knowledge artifacts (Questionnaires, PlanDefinitions, Libraries) as data. These are NOT vendored into this IG — they are operational deployment artifacts that live in infrastructure/fhir-artifacts/ and are deployed via deploy-artifacts.sh (idempotent PUT-by-id transaction Bundle). This page documents what capabilities they demonstrate.

Artifact catalog

Table of canonical URLs + versions:

• Library/DermaCareRoutingLogic 1.0.0 — CQL router library
• PlanDefinition/dermacare-onboarding 1.0.0 — intake plan
• PlanDefinition/dermacare-onboarding-routing 1.0.0 — router PlanDefinition
• PlanDefinition/dermacare-atopic-dermatitis-care 1.0.0 — follow-up
• PlanDefinition/dermacare-psoriasis-care 1.0.0 — follow-up
• PlanDefinition/dermacare-hs-care 1.0.0 — follow-up
• Questionnaire/dermacare-onboarding 1.0.0 — SDC $extract questionnaire
• PlanDefinition/showcase-onboarding 1.0.0 — showcase intake
• Questionnaire/showcase-onboarding 1.0.0 — showcase questionnaire
• LOINC instruments: POEM (http://loinc.org/q/89862-7), VAS pain, VAS pruritus, DLQI, PSS, SD-NRS, PEST, HADS, HISQOL

Capabilities demonstrated

Plan slots (ADR 0002, ADR 0007)

The plan-slot Organization extension binds plan kinds to versioned PlanDefinition canonicals. Each slot has a kind (onboarding, default, re-engagement, onboarding-routing) and a planDefinition canonical that MAY carry |version. The orchestrator reads slots to pick which PlanDefinition to $apply when an identity-resolution decision calls for a triggered plan.

CQL-based clinical routing (ADR 0006)

Clinical decision logic ships as data: CQL Library + router PlanDefinition. Projo evaluates PlanDefinition/$apply without _persist, then executes only allow-listed bounded actions. The router proposes; projo disposes.

Clinical data extraction

Questionnaires carry SDC extraction annotations: observationExtract (item-level), observationLinkPeriod (root-level), itemExtractionContext (group-level). The extraction-writeback extension (ADR 0010) enables Patient demographic write-back via Binary-wrapped JSON-Patch.

Version pinning (ADR 0007)

Canonical URLs carry |version (e.g. https://projo.evoleen.com/PlanDefinition/dermacare-onboarding|1.0.0). The plan-slot extension pins specific versions. This is FHIR-idiomatic: no schema migration needed when a new version is published — it's a distinct resource.

Deployment as data

• Artifacts live in infrastructure/fhir-artifacts/{showcase,dermacare,instruments}/
• Deploy via deploy-artifacts.sh (dry-run default, –apply for writes)
• Idempotent PUT-by-id transaction Bundle
• Dev first, then prod
• ELM cache: first $apply after new Library version pays compile cost, then cached server-side
• Activation: seed:routing-slot –org= --router=| --apply
• Rollback: repoint slot or remove

Validation gates

1. JSON well-formedness (jq -e .)
2. CQL compiles (Fire Arrow compiles to ELM, caches on first $apply)
3. Canonical + version present; cross-references pinned
4. Router action contract (unique non-empty title, bounded-action code)
5. Dev $apply spike under Device identity