Bundled plugins

These core plugins live in the repository under external-plugins/, are loaded from TypeScript source, and ship inside the API image (they are not published to the registry). They form the layered clinical foundation the demos build on (see Architecture for the layering rationale). Each row of a contributions table is a fact from the plugin's plugin.yaml. On a running instance, the console's Plugins page shows the events, contributions and manifest of each loaded plugin (see Inspect loaded plugins).

@posos/common

The most classic non-clinical building blocks, shared by every business plugin.

Everything domain-specific — including these classics and the context kinds themselves — is a plugin contribution; the engine itself holds only primitives and the meta type system.

@posos/clinical

dependsOn: @posos/common

The general-purpose clinical foundation, independent of any specific use case: core FHIR resources, the classic clinical events and their triggers, and the generic patient-record read/write and human-validation nodes. It owns the patient and prescription port contracts (@posos/clinical/ports, typed on the DPI model in @posos/clinical/domain) and ships their reference in-memory adapters (dev/demo, zero infra, seeded from the instance config) and their simulation sandboxes. Use-case-specific computations live elsewhere (e.g. in the example plugins).

@posos/fhir

dependsOn: @posos/clinical, @posos/common

Connects an existing FHIR R4 warehouse (tested with Blaze + Synthea) to the patient and prescription ports. Demonstrates port-adapter contribution: switch the target system without touching the engine or the workflows.

The event bindings produce events that @posos/clinical and @posos/common declare (fhir-creatinine → BioResultReceived, fhir-communication-received → CommunicationReceived…); the host checks each against the event's contract at load.

The fhir-validation-decided binding is the resolve-mode binding described in ADR 0002.

@posos/hl7

Receives and processes HL7 v2 ER7 messages and CDA R2 documents. HTTP and directory reception are provided by the host; the plugin adds MLLP and the protocol-specific identity, parsing, acknowledgement, mapping, and CDA logic.

The CDA parser extracts metadata, narrative sections, embedded PDF attachments, and external references without downloading them. It does not validate XSD or CI-SIS Schematron profiles. See Process a CDA R2 document.

The message bindings produce events that @posos/clinical declares; their require is checked against those contracts at load. The ORU bindings map known LOINC codes to analyte keys and convert their values to a reference unit per analyte. Binding options and emission rules are described in Connect an EAI.

@posos/pn13

Receives and processes PN13 SIPhII XML through host HTTP or directory connections. Its optional XSD profile validates a receipt before any workflow or message binding receives it.

Rejected XSD receipts stay in the durable inbox with a structured report that contains line and element diagnostics without XML values. See Connect an EAI and Map an HL7 or PN13 message.

@posos/llm

The LLM agent runner (Anthropic + OpenAI-compatible APIs) — an adapter for the agent port, selected by the instance manifest (ports.agent = { adapter: llm }). Keys via environment variables.

@posos/notify

Outbound notification delivery — it owns the notification port contract (@posos/notify/ports) and ships the notify.send node, its console and webhook adapters and the simulation sandbox. A channel is an adapter of the port that requires a connection type; notify.send designates a connection of such a type, else it uses the port bound by the instance (ports.notification). Distinct from the record trail (writing a FHIR Communication through the patient port): here we alert humans through a channel, we do not write clinical data. See Send notifications.

@posos/slack

Slack channel of the notification and validation ports, through the Web API with the bot token of a Slack app. A validation request is posted with buttons; clicks come back through a Socket Mode listening connection (see Decide validations in Slack). Depends on @posos/notify.

@posos/mail

Mail channel of the notification port: sends each notification through an SMTP server (nodemailer). The smtp connection type accepts smtp:// and smtps:// URLs and gives its credential to the plugin (exposeCredentials). Depends on @posos/notify.

@posos/decision

Decision models — the Décision intelligente node (decision.ask, category Agents IA) asks typed questions (yes/no, choice, score) about a state. It owns the neutral decision port contract (@posos/decision/ports) and ships its simulation sandbox, which answers without calling a provider; it ships no adapter. The node designates its connection (connection by port decision), else it uses the port bound by the instance. The node's configuration and ports are declared in its manifest (config[].schema, derivedPorts). See Ask a decision model typed questions.

@posos/typesafe

The typesafe adapter of the decision port (depends on @posos/decision): POST {baseUrl}/v1/systemone, the System One API of TypeSafe (model Jev), or any compatible server, through a connection of type typesafe-systemone (one connection per server). Selected by the instance manifest (ports.decision = { adapter: typesafe }) or by the connection a decision.ask node designates.

@posos/snomed

Contributes the terminology resolver for the snomed-ct code system (Hermes). Selected via the instance manifest (terminology.snomed-ct = { adapter: hermes }); the resolver reaches the server through a connection of type hermes (parameter languageRefsetId: display language by language reference set). See Configure terminology.