Example plugins
These plugins live under external-plugins/ — outside apps/api, outside the workspace —
to demonstrate what "delivered separately" means: each builds to a self-contained bundle
and loads from PLUGINS_PATH or a registry, exactly like a third-party plugin would (see
Bundling and distribution).
Read them as worked examples of the contribution points documented in the
developing area. Contributions below are the facts from each
plugin.yaml.
@posos/demo
dependsOn: @posos/clinical
The demonstration use case (nephrology / critical result): use-case-specific clinical computations, their result resources, and the associated validations and notifications. Everything specific to the demo scenarios lives here — the foundation (core + common + clinical) stays independent of it. A good first example of a compute-and-notify plugin.
| Contribution | Items |
|---|---|
| nodes | clinical.egfr.ckd-epi-2021, clinical.condition.detect-from-egfr, clinical.drug-safety.renal, patient.append-derived-value, notify.drug-safety-alert, notify.ack-recorded, notify.escalate-on-call |
| types | EgfrResult, DetectedIssue, DrugSafetyReport |
| value-sets | renal-stage, issue-severity |
| conversions | EgfrResult → Decimal, DrugSafetyReport → Integer |
@posos/geriatrie
dependsOn: @posos/common, @posos/clinical, @posos/demo
A geriatrics extension — the example of a multi-agent plugin. It exposes business types and five chained agents for deprescribing, patient communication, and post-withdrawal follow-up.
| Contribution | Items |
|---|---|
| types | MedicationBurdenSummary, DeprescribingCandidate, DeprescribingAssessment, TaperStep, TaperPlan, CounselingPlan, FollowUpChecklist |
| value-sets | deprescription-reason, deprescription-priority, tapering-strategy, follow-up-trigger |
| agents | Geriatric prescription review · Priority-candidate selection · Medication taper plan · Patient & caregiver information · Post-deprescription follow-up |
@posos/posos
dependsOn: @posos/clinical
Integration with the Posos APIs (AORT v3): clinical calculators, contraindication
analysis (SNOMED conditions + LOINC observations), drug-interaction analysis, and adverse
effects. The example of a plugin wrapping an external authenticated API (Google IAP
service-account; see the POSOS_API_URL, POSOS_AUDIENCE, and
GOOGLE_APPLICATION_CREDENTIALS environment variables).
| Contribution | Items |
|---|---|
| nodes | posos.calculator, posos.contraindications, posos.interactions, posos.adverse-effects, posos.adverse-effect-detection, posos.drug-code, posos.autocomplete |
| value-sets | posos-calculator, drug-terminology, autocomplete-entity, drug-coding |
@posos/demo-softway
An integration demo for Softway Medical (an EHR): tools that analyse data captured in the record. The smallest example — a single-agent plugin whose one tool extracts observed symptoms from a nursing handover comment. Designed to grow.
| Contribution | Items |
|---|---|
| agents | Symptom extraction (nursing handover) |
@posos/aero-demo — cross-domain proof (aviation)
Self-contained demonstration that the core is domain-neutral: loaded ALONE (no
clinical plugin, pnpm run dev:aero with instance.aero.yaml), it brings a
complete domain — the flight context kind, its types and haul-type value
set, the flightlog port (contract + Ports augmentation in ports.ts,
in-memory reference adapter declared record: { contextKind: flight }, so
GET /api/records/flight/<id> serves the logbook, plus a simulation sandbox),
an OpenSky Network event source (open API, anonymous polling of aircraft states
over a bounding box, landing = airborne→ground transition) with its declarative
binding, and five nodes. The companion workflow (content/aero-demo/, seeded by
the instance seed: field) journals every observed landing and, when the
logbook knows the flight plan, computes the flight's carbon estimate (distance ×
per-haul emission factor × seats — factors overridable in config, the method
travels inside the report) and writes it to the logbook.
apps/api/tests/unit/aero-demo.test.ts pins the self-sufficiency: the plugin
loads alone and the shipped workflow validates against that catalog only.