×

Clinical

Challenges

  • Eligibility rules depend on changing observations, thresholds, and histories.
  • Contraindications can be distributed across protocols and reference material.
  • Safety exceptions require clear escalation and accountable review paths.
  • Clinical logic must remain inspectable as guidance and evidence evolve.

Problems We Solve

  • Criteria Representation Structure eligibility conditions and relevant observations.
  • Contraindication Checking Identify conflicts between proposed actions and safety rules.
  • Pathway Simulation Explore decision paths across representative scenarios.
  • Safety Validation Check escalation triggers and required protective actions.
  • Review Support Prepare traceable summaries for qualified human review.

Domain portfolio

Application patterns

Compare two formal-assurance approaches, then explore the domain workflows as interactive state machines.

Clinical rule systems organize contraindications, eligibility criteria, observations, thresholds, escalation paths, and accountable review. Verified readback can make a narrowly stated rule inspectable as a setup-scoped formal proposition. The session author remains the authority on whether a reading captures the statement they attempted to formalize; a qualified clinician separately owns clinical-content approval and patient-care decisions. Every pattern below is clinical decision support only: none diagnoses, prescribes, enrolls a participant, or authorizes care. Type checking cannot establish that patient data are accurate, that guidance is current or appropriate, or that applying a rule is safe for an individual patient.
01 Emergency-department deterioration and escalation support Explore pattern

System/use case

A clinical decision-support module for authoring and reviewing escalation rules in emergency care, including acuity assignment, repeat observations, clinician reassessment, monitored placement, and activation of a higher-acuity response. It turns locally governed pathway statements into reviewable propositions without presenting them as autonomous triage decisions.

Operational setting

The module sits alongside the electronic health record (EHR), observation flowsheets, and an alerting platform. A versioned setup names observation categories, acuity bands, reassessment states, care locations, escalation triggers, and clinician actions. Patient data may be evaluated by a separate rules engine after normal validation; FF Scribe is used to author and review the logical statements, not to monitor patients in real time.

Decision/claim boundary

The checked proposition describes the shape of a locally modeled escalation rule, such as a relationship between a documented trigger and required reassessment. It does not determine clinical deterioration, assign acuity, decide disposition, or replace bedside assessment. A qualified clinician interprets the patient’s condition and retains authority for all clinical decisions, including deviation from decision support.

Candidate checked statements

Illustrative controlled-English propositions for a future setup include:

  • “Every patient state with a confirmed high-acuity trigger requires clinician reassessment.”
  • “If a required reassessment is overdue, the pathway enters an escalation state.”
  • “A discharge-ready state is unavailable while an unresolved critical observation remains active.”
  • “Every escalation state identifies a responsible clinical review role.”

These are candidate formalization schemas, not implemented clinical rules or recommendations.

Example architecture

A terminology and pathway service supplies stable, locally approved identifiers to a curated Agda setup. FF Scribe runs in a clinical-content management environment isolated from order entry and alert delivery. It records candidate types, compiler diagnostics, deterministic readings, setup versions, and explicit reviewer decisions. A separate executable rules engine consumes only content that has passed the institution’s normal clinical governance, validation, and release process. EHR integration validates patient identity, provenance, units, timestamps, and missingness. Qualified clinicians remain the final decision-makers; downtime and urgent-care procedures do not depend on formalization availability.

Where verified readback fits

A clinical informatician describes the intended pathway statement in natural language. Translation is restricted to the selected setup’s states and relations, producing one candidate Agda proposition or a clarification question. Agda checks that the proposition is well scoped and type correct. If the partial readback translator supports its structure, ff-readback produces a deterministic audited family with premise order and semantic-rule provenance intact; unsupported structure fails visibly. The informatician confirms whether a reading captures the authored statement, while a qualified clinician separately approves or rejects its clinical content. Neither action authorizes deployment or application to a patient.

Potential benefits

The workflow can expose ambiguity between an observation, a confirmed trigger, and a required response; reveal missing quantifiers or escalation outcomes; and give emergency clinicians, informaticians, and safety staff a stable review artifact. Explicit state and transition language can improve change-impact assessment when observation definitions or pathways are revised.

Limits/adoption considerations

Type correctness is not factual truth about a patient, clinical-policy correctness, real-world safety, completion of a proof, or confirmation of author intent. Those require data-quality controls and examination, governed evidence review, clinical validation and monitoring, separate proof evidence where relevant, and explicit qualified-clinician acceptance. Timing, measurement uncertainty, exceptions, and unavailable resources may not fit a small setup. Alert fatigue, workflow fit, equity impacts, and safe failure modes need evaluation before deployment.
02 Medication contraindication and order-review support Explore pattern

System/use case

A pharmacy informatics workbench for formalizing order-review statements involving patient-specific contraindication flags, active therapies, documented hypersensitivity, laboratory-state prerequisites, duplicate therapy, and required pharmacist or prescriber review.

Operational setting

Content specialists work from institutionally governed medication knowledge, formulary identifiers, and order-workflow states. A setup represents abstract concepts such as proposed order, active contraindication, evidence pending, alternative considered, and review completed. It does not contain dosing recommendations or infer clinical facts from raw records. A production clinical decision-support service, if separately validated and authorized, may later evaluate governed rules against normalized EHR data.

Decision/claim boundary

The proposition captures a review obligation or incompatibility in the modeled vocabulary. It cannot determine whether an allergy entry is valid, whether a laboratory result is clinically representative, whether expected benefit outweighs risk, or which medication should be ordered. Decision support may prompt review; a qualified prescriber and pharmacist retain authority for medication decisions.

Candidate checked statements

Potential controlled-English propositions include:

  • “Every proposed medication order with an active contraindication requires qualified clinical review.”
  • “A contraindication cannot be marked resolved while its required evidence remains pending.”
  • “If duplicate-therapy review is required, order verification depends on completion of that review.”
  • “Every overridden safety flag records an accountable reviewer role.”

These statements are illustrative and deliberately avoid asserting any particular drug rule or threshold.

Example architecture

A governed content repository maintains rule identifiers, semantic versions, source references, and approval status. A terminology service resolves local codes, while a clinical data pipeline handles provenance, units, temporal validity, and missing values. FF Scribe receives only the small authoring setup and natural-language rule; it has no write path to the medication administration record, computerized ordering, or dispensing systems. Accepted propositions are linked to test cases, clinical-review minutes, and release records. Production evaluation, override capture, audit, and monitoring remain independent controls, with qualified clinicians able to withhold, modify, or discontinue any proposed action.

Where verified readback fits

A pharmacist or clinical informatician states the desired review relationship. The agent either asks for clarification or proposes one type using setup-scoped terms. Agda validates formation and type use. The partial readback step either realizes supported structure through its finite audited family or fails visibly without a partial explanation. The author confirms whether scope, prerequisite, polarity, and accountability match the intended statement; a qualified pharmacist or clinician separately owns clinical-content approval. Neither the model’s proposal nor the compiler result is medication advice.

Potential benefits

Formalized readback can surface dangerous wording differences such as “contraindicated” versus “requires review,” or “evidence absent” versus “evidence pending.” It can improve consistency across content, tests, and reviewer-facing documentation, and make the effect of terminology or workflow changes easier to locate.

Limits/adoption considerations

A well-typed rule does not prove patient facts, the clinical validity or currency of the policy, safety of a particular order, satisfaction of the proposition, or the reviewer’s intended meaning. These need data verification, multidisciplinary content governance, patient-specific judgment and surveillance, proof or test evidence, and qualified-clinician confirmation. Knowledge maintenance, override usability, false-positive burden, interactions among rules, and locally available alternatives are major adoption concerns.
03 Clinical-trial eligibility prescreening Explore pattern

System/use case

A research informatics tool that formalizes inclusion, exclusion, and manual-review criteria for trial prescreening. It helps investigators and coordinators inspect how protocol language has been represented before candidate retrieval, without making an enrollment determination.

Operational setting

A trial setup names protocol-defined eligibility concepts, evidence states, time-window abstractions, cohort relations, and review outcomes. A separate query service may identify records for human screening. Source documents, amendments, EHR extracts, and research data carry independent version and provenance controls. The tool supports content design and review; it does not contact participants or alter study records.

Decision/claim boundary

The checked claim concerns the modeled criterion—for example, that satisfying all represented inclusion criteria and no represented exclusion criterion yields a manual-review candidate. It does not establish that source data are complete, that a person meets the actual protocol, that participation is clinically appropriate, or that consent exists. Only the authorized study team, with qualified-clinician input where required, determines eligibility and enrollment.

Candidate checked statements

Illustrative propositions include:

  • “Every prescreening candidate satisfies each represented inclusion criterion.”
  • “Any unresolved exclusion criterion routes the record to manual review.”
  • “Missing required evidence cannot be treated as evidence that the criterion is satisfied.”
  • “A prescreening match is distinct from a confirmed eligibility decision.”

They are proposed controlled-language targets, not a translation of any current protocol.

Example architecture

A protocol-ingestion workflow maps governed criterion identifiers into a study-specific setup reviewed by the principal investigator’s delegate and informatics staff. FF Scribe checks and reads back author statements in a segregated authoring environment. An honest-broker or approved query layer handles identifiable records and returns candidate references with provenance; FF Scribe need not receive patient-level data. Accepted propositions link to the exact protocol amendment and validation scenarios. Coordinators and qualified clinicians review original-source evidence and document eligibility through the authorized research workflow.

Where verified readback fits

The protocol specialist supplies a natural-language eligibility relationship. The translation step can use only the study setup and must clarify ambiguous time windows, evidence states, or universal conditions. Agda checks type correctness. When the checked structure is within the readback slice, the deterministic audited family exposes it for review; unsupported structure fails visibly. The specialist confirms whether the reading captures the authored criterion, while the investigator’s delegate and qualified clinician separately approve its protocol and clinical use. Those actions do not establish the truth of a participant’s eligibility.

Potential benefits

The pattern can make negation, missingness, conjunction, and manual-review routes visible before cohort queries run. It offers a traceable bridge from protocol criteria to query specifications and validation cases, and can identify which formalized criteria require reassessment after an amendment.

Limits/adoption considerations

Type correctness does not prove data accuracy, fidelity to the full protocol, safe or ethical participation, completion of an eligibility proof, or user-intent confirmation. Original-source review, protocol and ethics governance, qualified clinical judgment, documented eligibility assessment, and explicit semantic acceptance remain necessary. Temporal reasoning and narrative exceptions may exceed the supported formal slice. Privacy, minimum-necessary access, bias in data availability, and recruitment equity require separate controls.
04 Oncology treatment-pathway review support Explore pattern

System/use case

A multidisciplinary pathway-authoring assistant for expressing prerequisites, contraindication branches, reassessment points, and tumor-board review obligations across an oncology care pathway. It supports review of pathway logic and never selects a treatment for a patient.

Operational setting

Pathway owners define a small vocabulary of documented disease states, evidence statuses, treatment-intent categories, review states, and branch transitions. The setup is versioned alongside the pathway but remains separate from the EHR and order sets. Clinical evidence synthesis, molecular interpretation, patient preferences, and longitudinal assessment stay in established clinical processes.

Decision/claim boundary

The checked proposition describes a modeled prerequisite or review route. It does not confirm diagnosis or staging, interpret a biomarker, establish treatment benefit, or authorize an intervention. The multidisciplinary team and the treating qualified clinician retain authority and must consider the full patient context.

Candidate checked statements

Possible controlled-English propositions include:

  • “Every pathway branch with unresolved prerequisite evidence remains pending clinical review.”
  • “An active modeled contraindication prevents the branch from becoming pathway-eligible.”
  • “Every discordant diagnostic-evidence state routes to multidisciplinary review.”
  • “A pathway-eligible state is decision support and is not a treatment authorization.”

These are illustrative proposition forms rather than clinical recommendations.

Example architecture

A pathway-content platform owns terminology, provenance, review roles, and effective versions. FF Scribe checks candidate propositions in a non-production authoring workspace and returns accepted type/readback pairs to that platform. Evidence summaries, diagnostic systems, and the EHR remain separate data sources, while the approved pathway engine is subject to its own validation and monitoring. Tumor-board documentation and clinician orders are authoritative; no formalization output can place or sign an order.

Where verified readback fits

A pathway specialist describes the intended eligibility or escalation relationship. The candidate is constrained to the setup vocabulary and checked as an Agda type. Supported structure is rendered through deterministic audited readback candidates; unsupported translation fails visibly. The specialist confirms whether the reading captures the authored relationship, while a qualified clinical reviewer separately checks quantification, evidence status, exclusions, and clinical responsibility before content approval. The resulting artifact records reviewed meaning only; its presence is not proof that the pathway is clinically correct or followed.

Potential benefits

This workflow can help multidisciplinary reviewers distinguish eligibility for a pathway branch from a treatment decision, and distinguish absent evidence from negative evidence. Stable formal statements can improve pathway change control, reviewer handoffs, and traceability to validation scenarios.

Limits/adoption considerations

Type correctness is separate from factual patient truth, clinical-policy correctness, real-world safety, proof completion, and confirmation of intent. Each requires dedicated clinical evidence and data review, pathway governance, qualified individual judgment and outcome monitoring, proof/test artifacts, and explicit clinician acceptance. Evolving evidence, off-pathway care, comorbidity, patient goals, and uncertain or conflicting diagnostics make automation particularly limited. Decision-support behavior must be monitored for inequitable or burdensome effects.

Applicability frame

MLTTDB can plausibly validate finite, versioned clinical configuration packs or typed review packets. Proof-assistant source owns the clinical abstractions, row types, table declarations, invariants, and proofs. The SQLite term store owns ordered source-language records, UUIDs, metadata, and stored table definitions; it neither interprets clinical meaning nor establishes that a source observation is correct. Semantic checking is performed by Agda, Lean, or Rocq, even when the store orchestrates the checker subprocess. Agda currently supports finite lookup of stored rows by literal UUID. Lean and Rocq preprocessors currently generate and check definitions but do not support that lookup form.

Current data mode checks fetched rows as separate definitions; it does not expose a table to application proofs as an enumerable, first-class collection. Whenever an example below claims whole-snapshot coverage, uniqueness, or graph acyclicity, the architecture therefore assumes either a finite domain declared in proof source or an external snapshot compiler that emits a reconciled aggregate manifest/certificate term. The proof assistant checks that aggregate term, while external reconciliation establishes that it represents the table export supplied for review.

EHR, trial-management, pharmacy, laboratory, and blood-bank ingestion; terminology and patient-identity reconciliation; consent; access control; workflow orchestration; runtime alerts or hard stops; audit retention; and clinical formalization review are external production responsibilities. A successful check means the encoded artifacts satisfy the encoded properties under declared assumptions. It cannot establish diagnosis, data timeliness, patient identity, complete documentation, or an appropriate clinical action.

01 Clinical-trial eligibility and contraindication review pack Explore pattern

Operational context

A research site screens candidates against a protocol whose inclusion, exclusion, timing, prior-treatment, laboratory, consent, and cohort rules may span several documents and amendments. Coordinators reconcile EHR data, research records, imaging or pathology assessments, and investigator judgment. The assurance problem is twofold: release a faithful machine-readable criteria pack for the active protocol version, and make the internal consistency of a candidate review packet visible without allowing software to replace the investigator’s eligibility determination.

Why MLTTDB fits

The protocol criteria and a candidate’s reviewed evidence set are bounded and versionable. MLTTDB tables can represent criterion identifiers, required evidence categories, temporal relations, contraindication groups, permitted outcomes, and explicit unresolved states. Proofs can require every criterion to have an evaluation disposition, every contraindication to map to the correct review outcome, and no conclusion of “criteria met” while required evidence is missing or internally contradictory. Stable UUIDs preserve criterion identity across wording or ordering changes.

Example architecture

protocol/amendment repository ---> criteria authoring + dual clinical review
                                                    |
EHR/CTMS extracts -> identity/terminology reconciliation -> typed review pack
                                                    |
                                                    v
                                           MLTTDB term store
                                                    |
proof-owned eligibility model ----------------------+--> proof-assistant check
                                                              |
                                         review report -> investigator/CTMS

A validated authoring process translates the protocol into reviewed formal criteria. A separate site integration resolves patient, visit, laboratory, and terminology identifiers and presents provenance to coordinators. The term store holds source-language rows for a specific protocol and review packet. The checker returns validation status and native diagnostics. A project-owned adapter associates diagnostics with row UUIDs, maps them into reviewer-facing findings, and retains any explicitly generated proof artifacts. The CTMS records the accountable investigator’s disposition through its own workflow.

Representative typed artifacts

  • ProtocolVersion, Cohort, and Criterion, with explicit applicability and amendment provenance.
  • EvidenceItem, carrying category, observation time relation, source reference, verification status, and an explicit unknown/indeterminate case.
  • CriterionAssessment, linking a criterion to reviewed evidence and a reasoned state such as satisfied, not satisfied, or unresolved.
  • ContraindicationGroup and EscalationRequirement for investigator review.
  • An EligibilityReviewManifest aggregate term, built by the reviewed adapter and reconciled to protocol, criterion, evidence, and assessment row UUIDs.
  • Proof obligations for complete criterion coverage, protocol-version alignment, contradiction detection, and no positive modeled conclusion from unresolved required evidence.

Checks and evidence

Release checks can detect duplicate or dangling criterion references, a cohort rule tied to the wrong amendment, missing outcome semantics, and inconsistent temporal windows in the formal model. Packet checks can detect evidence linked to another protocol version, mutually inconsistent assessments, absent mandatory reviewer escalation, or a modeled eligible state reachable with an unresolved exclusion. Tests should use synthetic cases covering boundary times, missing data, competing cohorts, amended criteria, and explicit protocol deviations. Evidence includes source protocol revision, formalization review, terminology snapshot, row UUIDs, checker/version output, packet digest, and accountable review history maintained outside MLTTDB.

Potential benefits

This can make protocol translation inspectable, expose amendment drift across sites, and replace implicit spreadsheet behavior with typed evidence states. It may reduce clerical omissions and give investigators a focused explanation of which encoded obligation is unsupported or contradictory. Synthetic proof fixtures can also make protocol-configuration regression testing repeatable before an amendment is activated.

Deployment boundary

MLTTDB does not query the EHR, interpret free text, identify a patient, infer a diagnosis, determine eligibility, obtain consent, enroll a participant, or guarantee protocol compliance. Site procedures must control protocol interpretation, source verification, privacy, amendment activation, overrides, deviations, and investigator sign-off. The checked model and its UI require clinical validation and ongoing review against the authoritative protocol.
02 Oncology regimen-library release guardrails Explore pattern

Operational context

An oncology service maintains regimen templates across prescribing, pharmacy verification, compounding, administration, and monitoring systems. A regimen release can encode treatment phases, medication components, route and schedule categories, dose-adjustment methods, hold/escalation criteria, supportive-care dependencies, and required observations. Local practice and patient-specific judgment remain decisive, but the shared configuration library needs rigorous cross-component consistency before deployment.

Why MLTTDB fits

MLTTDB can serve as a release-time assurance layer over a finite regimen configuration baseline. Typed rows can distinguish regimen identity, phase, component role, adjustment rule, observation prerequisite, and exception workflow. Proofs can require that every component belongs to a declared phase, all modeled adjustment and hold states have an authorized review path, required dependencies are present, and incompatible alternative branches are not simultaneously active. The checked facts remain abstract configuration; they are not a patient-specific prescription.

Example architecture

clinical governance source + formulary + vendor build export
                         |
         terminology mapping and pharmacist reconciliation
                         v
              MLTTDB regimen candidate baseline
                         |
         proof-owned regimen model -> proof-assistant check
                         |
         release dossier + exact configuration digest
                         v
      CPOE/pharmacy build validation, simulation, approval, deployment

External tooling maps vendor concepts and medication identifiers to the formally reviewed catalogue. MLTTDB stores the ordered proof-language records and can expose verification through CI or an administrative service. A release controller binds the result to the vendor import package. Pharmacists and clinicians then inspect rendered templates and execute simulation and user acceptance tests before activating the configuration.

Representative typed artifacts

  • RegimenTemplate, TreatmentPhase, and RegimenComponent, each with stable identity and source provenance.
  • AdministrationConstraint, describing abstract route, sequence, or co-administration relationships without inventing clinical content.
  • ObservationRequirement, AdjustmentBranch, and HoldEscalation, including an explicit “requires clinician resolution” outcome.
  • SupportiveCareDependency and AlternativeBranch, with applicability conditions reviewed by domain experts.
  • A RegimenReleaseManifest aggregate term, reconciled to the vendor-package export and row UUIDs, enumerating the phases, components, branches, observations, and dependencies in the candidate release.
  • Proofs for reference closure, phase/component consistency, dependency presence, branch exclusivity, and complete modeled exception disposition.

Checks and evidence

The checker can reject orphan components, references to inactive catalogue items, an adjustment branch without a review outcome, simultaneous selection of exclusive alternatives, or a phase whose required observation category is absent. Synthetic regression fixtures should cover component substitution, phase omission, terminology remapping, unresolved hold state, and amendment of a shared supportive-care dependency. Evidence should retain formal source and checker revisions, approved terminology and formulary snapshot identifiers, row UUIDs and order, generated files, vendor package digest, independent clinical review, and downstream build-test results.

Potential benefits

Formal cross-record checks can expose library defects that are hard to see in screen-by-screen vendor review, especially when one shared component affects many templates. Typed identities and explicit exception states improve change impact analysis and interdisciplinary review. Reusable synthetic fixtures can turn a governance rule into a repeatable regression check for every candidate library release.

Deployment boundary

MLTTDB does not select a regimen, calculate or recommend a patient dose, interpret observations, prescribe, verify, compound, administer, or monitor therapy. It is not the CPOE or pharmacy runtime and supplies no clinical hard stop. Production use still needs accountable multidisciplinary governance, independent build verification, clinical validation, privacy/security control, human-factors testing, downtime procedures, and authorized activation in each target system.
03 Transfusion episode safety-gate configuration Explore pattern

Operational context

A transfusion workflow crosses ordering, specimen collection, laboratory testing, component selection, issue, transport, bedside identification, administration, and reaction management. Multiple systems enforce different parts of the process. Before configuration is released, a transfusion service needs assurance that every modeled episode state has the required identity, testing, authorization, component-status, and escalation preconditions, and that exceptional paths cannot be represented as ordinary completion.

Why MLTTDB fits

The proposed use is to validate the state-machine and rules configuration that surrounds operational safety gates. Tables can model episode stages, evidence classes, component states, permitted transitions, exception reasons, and required accountable roles. Proofs can show, for the finite configuration, that an administration-ready state is unreachable without all formally required prerequisites, that expired or unresolved evidence cannot satisfy a gate, and that mismatch or reaction states terminate in explicit stop and escalation paths. MLTTDB does not determine biological compatibility.

Example architecture

transfusion policy + LIS/EHR/device workflow dictionaries
                           |
          laboratory/clinical informatics reconciliation
                           v
              MLTTDB gate-configuration baseline
                           |
        proof-owned episode model -> checker service
                           |
          verified rule map + release evidence
                           v
 LIS/EHR/device integration tests -> transfusion governance approval

An external mapping layer aligns system-specific status and reason codes with a clinically governed formal vocabulary. The term store persists candidate rules as proof-language records. The checker validates the modeled transition system; integration-test harnesses then exercise the actual LIS, EHR, label, scanner, and device interfaces. A release record correlates all evidence with the deployed configuration version.

Representative typed artifacts

  • EpisodeStage, EvidenceClass, and GateRequirement, with explicit provenance and validity-state semantics.
  • ComponentStatus and IdentityEvidence, modeled as reviewed categorical states rather than values inferred by MLTTDB.
  • PermittedTransition, with source stage, required evidence set, accountable role, destination, and failure destination.
  • ExceptionPath for urgent, mismatch, unavailable-data, or reaction workflow categories defined by the organization.
  • An EpisodeGateManifest aggregate term, reconciled to the policy export and row UUIDs, materializing the states, evidence classes, transitions, and exception paths used for graph-wide checks.
  • Proofs for prerequisite completeness, stop-state absorption, exception escalation, and absence of an unreviewed path to the modeled ready state.

Checks and evidence

Checks can reject a transition with an unknown stage, a gate satisfied by an evidence state marked unresolved, an exception without an accountable role, or a stop state with an ordinary-progress edge. Test fixtures should include identifier mismatch, stale evidence, component status change after issue, interface timeout, emergency-process invocation, and suspected reaction. These are configuration tests using synthetic identifiers, not validation of patient-specific compatibility. Evidence includes policy and formalization revisions, status-code mapping, database/checker snapshot, negative test results, integration-test reports, and governance approval retained in the organization’s controlled quality system.

Potential benefits

The model can reveal gaps between departmental policy and cross-system status mappings before go-live. It gives laboratory, nursing, informatics, and device teams a common transition vocabulary and an explicit inventory of exceptional paths. Exhaustive checks over the modeled graph complement scenario testing, while stable rule identities make interface-code changes easier to assess.

Deployment boundary

MLTTDB does not identify patients or components, perform testing or crossmatch, authorize issue, control a bedside scanner, deliver a hard stop, or manage a reaction. Live identity, compatibility, status freshness, and emergency decisions remain with validated clinical systems and qualified personnel. The formal configuration must be independently validated against policy and actual interfaces, with privacy, security, quality, human-factors, downtime, and ongoing change-control measures.
04 Discharge medication-reconciliation review packet Explore pattern

Operational context

At discharge, clinicians reconcile pre-admission medicines, inpatient orders, new prescriptions, intended discontinuations, substitutions, monitoring requirements, and communication to the next care setting. Information arrives from EHR modules, pharmacy systems, patient or caregiver histories, and external records with differing identifiers and confidence. A useful assurance layer must preserve uncertainty and provenance, expose unresolved conflicts, and prevent a workflow configuration from labeling an internally incomplete packet as ready for sign-off.

Why MLTTDB fits

MLTTDB can validate a finite typed snapshot prepared for human review, or the workflow configuration that constructs such snapshots. Rows can represent source medication statements, reconciliation links, intended dispositions, unresolved discrepancy classes, communication obligations, and reviewer attestations. Proofs can require each in-scope source statement to have one explicit disposition or unresolved status, prevent mutually exclusive dispositions for one reconciled item, and require escalation before an incomplete packet reaches the modeled sign-off-ready state.

Example architecture

EHR/pharmacy/external lists -> patient + terminology reconciliation
                                      |
                             clinician review workspace
                                      |
                             typed candidate snapshot
                                      v
                              MLTTDB term store
                                      |
proof-owned reconciliation invariants +--> proof-assistant verification
                                                   |
                               consistency report -> clinician sign-off/EHR

Identity, terminology, duplicate detection, and source provenance are resolved by clinical integration services and displayed to the reviewer. Only the reviewed categorical statements needed by the formal model are serialized to MLTTDB, preferably with data minimization or pseudonymous references. The verification result returns to the workspace as an internal-consistency aid. The EHR owns the legal record, prescribing actions, attestation, and downstream communication.

Representative typed artifacts

  • SourceMedicationStatement, with source system, provenance reference, confidence/review state, and encounter scope.
  • ReconciledMedication, grouping reviewed source statements under a canonical identity assigned by external terminology services.
  • Disposition, representing continue, change, stop, replace, defer, or unresolved categories as locally governed abstractions.
  • Discrepancy, FollowUpObligation, and CommunicationTarget records.
  • A MedicationReconciliationManifest aggregate term, reconciled to the minimal EHR projection and row UUIDs, enumerating source statements, grouped medications, dispositions, and communication obligations.
  • Proof obligations for source-statement coverage, disposition exclusivity, unresolved-item escalation, and complete modeled communication obligations before readiness.

Checks and evidence

The checker can identify orphan source statements, one item assigned conflicting dispositions, a replacement with no reviewed target, an unresolved high-priority discrepancy without escalation, or a ready-state packet missing a required communication target. Synthetic tests should cover duplicate sources, terminology ambiguity, late source updates, intentional discontinuation, substitution, and deferred resolution. Evidence should bind the checker output to the packet and formalization revision and include source provenance references, ordered record UUIDs, reviewer actions, override reasons, and EHR audit events. MLTTDB’s database alone is not an immutable clinical audit trail.

Potential benefits

Explicit typed dispositions can make omissions and contradictions easier for a pharmacist or prescriber to see, while preserving “unknown” as a legitimate state instead of forcing false certainty. The same invariants can test workflow changes with synthetic packets before deployment. Stable row identity also helps explain which reviewed statement changed when a source list is refreshed.

Deployment boundary

MLTTDB does not retrieve a medication history, resolve terminology, detect all duplicates, assess appropriateness, recommend therapy, prescribe, discontinue, communicate with a patient, or sign the discharge record. Any finding is an internal model result for qualified review, never an autonomous clinical decision. Deployment requires validated interfaces, data-quality controls, privacy and access safeguards, clinician override and downtime workflows, human-factors testing, and accountable pharmacy and medical governance.

These read-only, pan-and-zoom models expose three abstraction levels for each workflow. They are explanatory examples, not live operational or decision systems.

01

Patient Deterioration Response

About this workflow

This example represents recognition and response when a patient’s observations begin to depart from their expected course. It joins trend monitoring, validation of warning signals, qualified triage, time-critical intervention, reassessment, and care transition. The model accommodates a local early-warning policy or specialty pathway without assuming that one threshold or score is appropriate for every patient.

The pathway starts with patient-specific baseline observations, scheduled trend and symptom assessments, active risk modifiers, and monitoring limits. When a warning appears, staff validate the measurement and timestamp, compare the trend with the applicable threshold, and notify the accountable care role. Clinical triage combines symptoms, trend severity, relevant history, and the governing safety pathway to determine urgency and whether local review or rapid-response escalation is required. A protective intervention assigns qualified actions, monitoring, and communication responsibilities while recording the timing and observed response. Protocol-defined reassessment repeats the necessary observations and compares them with stabilization criteria. A stabilized patient returns to baseline monitoring; unresolved deterioration moves to a care transition with the current condition, risks, and intervention timeline handed off and acknowledged.

The loops distinguish false alarms from unresolved risk without normalizing either. A confirmed measurement artifact can return to routine monitoring, but only after validation. Triage may restore monitoring when qualified assessment finds no continuing concern, or initiate an urgent care transition without waiting for a local intervention cycle. Reassessment can repeat or adjust the intervention when response is inadequate. Failure to meet stabilization criteria escalates care rather than resetting the warning. These controls matter to bedside nurses, treating clinicians, and rapid-response teams because delayed escalation often results from fragmented observations, unclear ownership, or failure to confirm response after an intervention. Explicit handoff acknowledgement reduces the chance that unresolved deterioration disappears between teams or care settings.

Layer 1 — Deterioration pathway

This layer gives the episode-level picture: baseline monitoring, warning detected, clinical triage, protective intervention, reassessment, and care transition. It is useful for charge nurses, clinical leads, and safety reviewers because it shows current risk posture and escalation direction. It intentionally excludes individual vital signs and tasks so an unresolved warning or transfer is not buried in detail.

Layer 2 — Escalation and reassessment procedures

This layer describes the procedural safeguards within the pathway: establish individualized baselines, validate abnormal measurements, notify the accountable role, classify urgency, assign interventions and responsibilities, repeat observations, apply stabilization criteria, and complete an acknowledged handoff. It supports local escalation policies and simulation scenarios. It does not prescribe specialty-specific treatments or universal trigger thresholds.

Layer 3 — Observation-level actions

This layer exposes the concrete clinical work: timestamp and repeat a measurement, compare trends, assess symptoms and history, document time-critical actions, trend the response, record unresolved risks, and transfer the observation and intervention timeline. It supports audit, debrief, and interface testing. Monitor protocols, device integrations, and the clinician’s diagnosis or treatment selection remain intentionally outside this general example.
02

High-Risk Medication Administration

About this workflow

This example represents the closed-loop administration of a high-risk medication, from drafting the order through verification, patient-specific preparation, bedside checks, post-dose monitoring, and completion or safety escalation. It emphasizes that safe administration depends on current clinical observations and independent controls, not solely on the presence of a signed order.

The normal pathway begins with the medication, indication, route, schedule, and protocol-specific monitoring requirements, linked to current weight, renal function, hepatic function, and other dose-relevant observations. Clinical verification checks allergies and prior reactions, drug interactions, duplicate therapy, contraindications, and dose calculation. Pharmacy or the authorized preparer selects the verified product and concentration, prepares and labels the patient-specific dose, and completes the required independent check. At the bedside, the care team matches patient, medication, dose, route, and time; confirms baseline observations; and verifies access to rescue resources and escalation contacts. After administration, protocol-defined response and safety signals, vital signs, and relevant laboratory results are trended and documented before therapy is completed.

The return and escalation paths keep new information from being bypassed. An unsafe or incomplete order returns to the prescriber for revision. A preparation mismatch found at the bedside goes back for correction rather than being informally reconciled. A newly identified contraindication before dosing, or an adverse signal afterward, enters safety escalation: further dosing is held, the patient is assessed, the protective response is initiated, and qualified review is required. The reviewed outcome may produce a new order and controlled resumption or terminate therapy. These controls matter to prescribers, pharmacists, nurses, and safety teams because renal function, weight, concurrent therapies, and patient condition can change between ordering and administration, while independent verification and prompt reaction management reduce preventable harm.

Layer 1 — Medication pathway

This layer presents the episode-level status: order drafted, clinically verified, dose prepared, ready for administration, under monitoring, in safety escalation, or complete. It lets the accountable clinical team see where responsibility and permission to proceed currently sit. It intentionally excludes individual checks and measurements so the medication pathway and any hold remain unmistakable.

Layer 2 — Safety verification procedures

This layer expands each status into the required safeguards: associate current organ-function and weight observations, check allergy and interactions, recalculate dose, perform an independent preparation check, confirm baseline monitoring and rescue readiness, and require qualified review after a safety signal. It is suited to medication-use policies and protocol design. It excludes drug-specific thresholds and local formulary instructions.

Layer 3 — Bedside actions

This layer identifies the observable tasks carried out by pharmacists and clinical staff: select concentration, label a patient-specific dose, perform the independent check, match the administration rights, record baseline values, administer, trend response, hold further doses, and reconcile administered, held, or discarded product. It supports checklist testing and incident reconstruction. Device commands, barcode formats, and EHR screen sequences are intentionally implementation-specific.
03

Clinical-Trial Screening and Enrollment

About this workflow

This example represents a candidate’s pathway from referral to a documented trial-screening disposition. It brings informed consent, protocol-defined eligibility, time-sensitive observations, contraindications, washout conditions, and qualified exception review into one inspectable workflow. It is not a substitute for the protocol or investigator judgment; it shows how the evidence and decisions required by those authorities should progress.

The expected pathway begins by confirming the candidate, requested cohort, and enrollment window. The current approved consent materials are presented before study-specific screening, and the team documents questions, decision-making capacity, voluntary agreement, and the consent version used. Screening then collects protocol-required history, examinations, laboratory results, and imaging, checking freshness windows as well as washout and concurrent-treatment conditions. Eligibility review evaluates each inclusion criterion, checks exclusions and distributed contraindications, and produces a criterion-by-criterion summary. A qualified candidate receives a cohort and enrollment identifier, with protocol activities and safety monitoring scheduled. The final disposition and its supporting record are retained when screening closes.

The exception paths reflect real screening work. Withdrawal after consent closes the candidate without proceeding. A stale laboratory result or observation returns for refresh rather than being treated as current. An ambiguous finding, missing evidence, or out-of-window assessment goes to protocol-authorized qualified review. The reviewer records the issue, authority, disposition, and rationale, then either returns the record for reassessment or closes an unresolved screening. A clearly ineligible candidate also closes without enrollment. These controls matter to investigators, coordinators, and monitors because enrollment pressure must not turn uncertainty into assumed eligibility, and because consent version, observation timing, contraindication review, and documented investigator decisions are central to participant safety and trial integrity.

Layer 1 — Enrollment pathway

This layer is the subject-level view used by the principal investigator, study manager, or monitor. It shows referral, consent, screening, eligibility review, exception review, enrollment, and closure, together with withdrawal and screen-failure paths. It intentionally excludes individual test results so the candidate’s status and the authority for each transition remain immediately visible.

Layer 2 — Screening and consent procedures

This layer expands the pathway into the protocol-facing procedures: verify enrollment timing, use the reviewed consent version, document capacity and voluntariness, collect required assessments, apply freshness and washout rules, review every criterion, and obtain qualified exception disposition. It is suitable for site procedures and monitoring review. It does not define the values or thresholds of a particular protocol.

Layer 3 — Observation-level actions

This layer shows the concrete evidence-handling work: record referral facts, capture consent questions, associate laboratory and imaging timestamps, check concurrent treatment, mark each inclusion and exclusion criterion, refresh stale observations, and retain the reviewer’s rationale. It supports source-data review and traceability. Instrument interfaces, EDC field layouts, and protocol-specific clinical interpretations are deliberately left to the study implementation.
Interactive state machine

Workflow demo

Skip to content

Domains

Clinical

Placeholder domain page for clinical rules involving contraindications, eligibility, and safety rules.

  • contraindications
  • eligibility
  • safety rules

Problems we solve

Checked boundaries and evidence

  • Eligibility rules depend on changing observations, thresholds, and histories.
  • Contraindications can be distributed across protocols and reference material.
  • Safety exceptions require clear escalation and accountable review paths.
  • Clinical logic must remain inspectable as guidance and evidence evolve.
Criteria Representation

Structure eligibility conditions and relevant observations.

Contraindication Checking

Identify conflicts between proposed actions and safety rules.

Pathway Simulation

Explore decision paths across representative scenarios.

Safety Validation

Check escalation triggers and required protective actions.

Review Support

Prepare traceable summaries for qualified human review.

Application patterns

Imported product records

These panels use the same generated application portfolio as the desktop workbench.

FF Scribe4 patterns
Clinical rule systems organize contraindications, eligibility criteria, observations, thresholds, escalation paths, and accountable review. Verified readback can make a narrowly stated rule inspectable as a setup-scoped formal proposition. The session author remains the authority on whether a reading captures the statement they attempted to formalize; a qualified clinician separately owns clinical-content approval and patient-care decisions. Every pattern below is clinical decision support only: none diagnoses, prescribes, enrolls a participant, or authorizes care. Type checking cannot establish that patient data are accurate, that guidance is current or appropriate, or that applying a rule is safe for an individual patient.
01Emergency-department deterioration and escalation support

System/use case

A clinical decision-support module for authoring and reviewing escalation rules in emergency care, including acuity assignment, repeat observations, clinician reassessment, monitored placement, and activation of a higher-acuity response. It turns locally governed pathway statements into reviewable propositions without presenting them as autonomous triage decisions.

Operational setting

The module sits alongside the electronic health record (EHR), observation flowsheets, and an alerting platform. A versioned setup names observation categories, acuity bands, reassessment states, care locations, escalation triggers, and clinician actions. Patient data may be evaluated by a separate rules engine after normal validation; FF Scribe is used to author and review the logical statements, not to monitor patients in real time.

Decision/claim boundary

The checked proposition describes the shape of a locally modeled escalation rule, such as a relationship between a documented trigger and required reassessment. It does not determine clinical deterioration, assign acuity, decide disposition, or replace bedside assessment. A qualified clinician interprets the patient’s condition and retains authority for all clinical decisions, including deviation from decision support.

Candidate checked statements

Illustrative controlled-English propositions for a future setup include:

  • “Every patient state with a confirmed high-acuity trigger requires clinician reassessment.”
  • “If a required reassessment is overdue, the pathway enters an escalation state.”
  • “A discharge-ready state is unavailable while an unresolved critical observation remains active.”
  • “Every escalation state identifies a responsible clinical review role.”

These are candidate formalization schemas, not implemented clinical rules or recommendations.

Example architecture

A terminology and pathway service supplies stable, locally approved identifiers to a curated Agda setup. FF Scribe runs in a clinical-content management environment isolated from order entry and alert delivery. It records candidate types, compiler diagnostics, deterministic readings, setup versions, and explicit reviewer decisions. A separate executable rules engine consumes only content that has passed the institution’s normal clinical governance, validation, and release process. EHR integration validates patient identity, provenance, units, timestamps, and missingness. Qualified clinicians remain the final decision-makers; downtime and urgent-care procedures do not depend on formalization availability.

Where verified readback fits

A clinical informatician describes the intended pathway statement in natural language. Translation is restricted to the selected setup’s states and relations, producing one candidate Agda proposition or a clarification question. Agda checks that the proposition is well scoped and type correct. If the partial readback translator supports its structure, ff-readback produces a deterministic audited family with premise order and semantic-rule provenance intact; unsupported structure fails visibly. The informatician confirms whether a reading captures the authored statement, while a qualified clinician separately approves or rejects its clinical content. Neither action authorizes deployment or application to a patient.

Potential benefits

The workflow can expose ambiguity between an observation, a confirmed trigger, and a required response; reveal missing quantifiers or escalation outcomes; and give emergency clinicians, informaticians, and safety staff a stable review artifact. Explicit state and transition language can improve change-impact assessment when observation definitions or pathways are revised.

Limits/adoption considerations

Type correctness is not factual truth about a patient, clinical-policy correctness, real-world safety, completion of a proof, or confirmation of author intent. Those require data-quality controls and examination, governed evidence review, clinical validation and monitoring, separate proof evidence where relevant, and explicit qualified-clinician acceptance. Timing, measurement uncertainty, exceptions, and unavailable resources may not fit a small setup. Alert fatigue, workflow fit, equity impacts, and safe failure modes need evaluation before deployment.
02Medication contraindication and order-review support

System/use case

A pharmacy informatics workbench for formalizing order-review statements involving patient-specific contraindication flags, active therapies, documented hypersensitivity, laboratory-state prerequisites, duplicate therapy, and required pharmacist or prescriber review.

Operational setting

Content specialists work from institutionally governed medication knowledge, formulary identifiers, and order-workflow states. A setup represents abstract concepts such as proposed order, active contraindication, evidence pending, alternative considered, and review completed. It does not contain dosing recommendations or infer clinical facts from raw records. A production clinical decision-support service, if separately validated and authorized, may later evaluate governed rules against normalized EHR data.

Decision/claim boundary

The proposition captures a review obligation or incompatibility in the modeled vocabulary. It cannot determine whether an allergy entry is valid, whether a laboratory result is clinically representative, whether expected benefit outweighs risk, or which medication should be ordered. Decision support may prompt review; a qualified prescriber and pharmacist retain authority for medication decisions.

Candidate checked statements

Potential controlled-English propositions include:

  • “Every proposed medication order with an active contraindication requires qualified clinical review.”
  • “A contraindication cannot be marked resolved while its required evidence remains pending.”
  • “If duplicate-therapy review is required, order verification depends on completion of that review.”
  • “Every overridden safety flag records an accountable reviewer role.”

These statements are illustrative and deliberately avoid asserting any particular drug rule or threshold.

Example architecture

A governed content repository maintains rule identifiers, semantic versions, source references, and approval status. A terminology service resolves local codes, while a clinical data pipeline handles provenance, units, temporal validity, and missing values. FF Scribe receives only the small authoring setup and natural-language rule; it has no write path to the medication administration record, computerized ordering, or dispensing systems. Accepted propositions are linked to test cases, clinical-review minutes, and release records. Production evaluation, override capture, audit, and monitoring remain independent controls, with qualified clinicians able to withhold, modify, or discontinue any proposed action.

Where verified readback fits

A pharmacist or clinical informatician states the desired review relationship. The agent either asks for clarification or proposes one type using setup-scoped terms. Agda validates formation and type use. The partial readback step either realizes supported structure through its finite audited family or fails visibly without a partial explanation. The author confirms whether scope, prerequisite, polarity, and accountability match the intended statement; a qualified pharmacist or clinician separately owns clinical-content approval. Neither the model’s proposal nor the compiler result is medication advice.

Potential benefits

Formalized readback can surface dangerous wording differences such as “contraindicated” versus “requires review,” or “evidence absent” versus “evidence pending.” It can improve consistency across content, tests, and reviewer-facing documentation, and make the effect of terminology or workflow changes easier to locate.

Limits/adoption considerations

A well-typed rule does not prove patient facts, the clinical validity or currency of the policy, safety of a particular order, satisfaction of the proposition, or the reviewer’s intended meaning. These need data verification, multidisciplinary content governance, patient-specific judgment and surveillance, proof or test evidence, and qualified-clinician confirmation. Knowledge maintenance, override usability, false-positive burden, interactions among rules, and locally available alternatives are major adoption concerns.
03Clinical-trial eligibility prescreening

System/use case

A research informatics tool that formalizes inclusion, exclusion, and manual-review criteria for trial prescreening. It helps investigators and coordinators inspect how protocol language has been represented before candidate retrieval, without making an enrollment determination.

Operational setting

A trial setup names protocol-defined eligibility concepts, evidence states, time-window abstractions, cohort relations, and review outcomes. A separate query service may identify records for human screening. Source documents, amendments, EHR extracts, and research data carry independent version and provenance controls. The tool supports content design and review; it does not contact participants or alter study records.

Decision/claim boundary

The checked claim concerns the modeled criterion—for example, that satisfying all represented inclusion criteria and no represented exclusion criterion yields a manual-review candidate. It does not establish that source data are complete, that a person meets the actual protocol, that participation is clinically appropriate, or that consent exists. Only the authorized study team, with qualified-clinician input where required, determines eligibility and enrollment.

Candidate checked statements

Illustrative propositions include:

  • “Every prescreening candidate satisfies each represented inclusion criterion.”
  • “Any unresolved exclusion criterion routes the record to manual review.”
  • “Missing required evidence cannot be treated as evidence that the criterion is satisfied.”
  • “A prescreening match is distinct from a confirmed eligibility decision.”

They are proposed controlled-language targets, not a translation of any current protocol.

Example architecture

A protocol-ingestion workflow maps governed criterion identifiers into a study-specific setup reviewed by the principal investigator’s delegate and informatics staff. FF Scribe checks and reads back author statements in a segregated authoring environment. An honest-broker or approved query layer handles identifiable records and returns candidate references with provenance; FF Scribe need not receive patient-level data. Accepted propositions link to the exact protocol amendment and validation scenarios. Coordinators and qualified clinicians review original-source evidence and document eligibility through the authorized research workflow.

Where verified readback fits

The protocol specialist supplies a natural-language eligibility relationship. The translation step can use only the study setup and must clarify ambiguous time windows, evidence states, or universal conditions. Agda checks type correctness. When the checked structure is within the readback slice, the deterministic audited family exposes it for review; unsupported structure fails visibly. The specialist confirms whether the reading captures the authored criterion, while the investigator’s delegate and qualified clinician separately approve its protocol and clinical use. Those actions do not establish the truth of a participant’s eligibility.

Potential benefits

The pattern can make negation, missingness, conjunction, and manual-review routes visible before cohort queries run. It offers a traceable bridge from protocol criteria to query specifications and validation cases, and can identify which formalized criteria require reassessment after an amendment.

Limits/adoption considerations

Type correctness does not prove data accuracy, fidelity to the full protocol, safe or ethical participation, completion of an eligibility proof, or user-intent confirmation. Original-source review, protocol and ethics governance, qualified clinical judgment, documented eligibility assessment, and explicit semantic acceptance remain necessary. Temporal reasoning and narrative exceptions may exceed the supported formal slice. Privacy, minimum-necessary access, bias in data availability, and recruitment equity require separate controls.
04Oncology treatment-pathway review support

System/use case

A multidisciplinary pathway-authoring assistant for expressing prerequisites, contraindication branches, reassessment points, and tumor-board review obligations across an oncology care pathway. It supports review of pathway logic and never selects a treatment for a patient.

Operational setting

Pathway owners define a small vocabulary of documented disease states, evidence statuses, treatment-intent categories, review states, and branch transitions. The setup is versioned alongside the pathway but remains separate from the EHR and order sets. Clinical evidence synthesis, molecular interpretation, patient preferences, and longitudinal assessment stay in established clinical processes.

Decision/claim boundary

The checked proposition describes a modeled prerequisite or review route. It does not confirm diagnosis or staging, interpret a biomarker, establish treatment benefit, or authorize an intervention. The multidisciplinary team and the treating qualified clinician retain authority and must consider the full patient context.

Candidate checked statements

Possible controlled-English propositions include:

  • “Every pathway branch with unresolved prerequisite evidence remains pending clinical review.”
  • “An active modeled contraindication prevents the branch from becoming pathway-eligible.”
  • “Every discordant diagnostic-evidence state routes to multidisciplinary review.”
  • “A pathway-eligible state is decision support and is not a treatment authorization.”

These are illustrative proposition forms rather than clinical recommendations.

Example architecture

A pathway-content platform owns terminology, provenance, review roles, and effective versions. FF Scribe checks candidate propositions in a non-production authoring workspace and returns accepted type/readback pairs to that platform. Evidence summaries, diagnostic systems, and the EHR remain separate data sources, while the approved pathway engine is subject to its own validation and monitoring. Tumor-board documentation and clinician orders are authoritative; no formalization output can place or sign an order.

Where verified readback fits

A pathway specialist describes the intended eligibility or escalation relationship. The candidate is constrained to the setup vocabulary and checked as an Agda type. Supported structure is rendered through deterministic audited readback candidates; unsupported translation fails visibly. The specialist confirms whether the reading captures the authored relationship, while a qualified clinical reviewer separately checks quantification, evidence status, exclusions, and clinical responsibility before content approval. The resulting artifact records reviewed meaning only; its presence is not proof that the pathway is clinically correct or followed.

Potential benefits

This workflow can help multidisciplinary reviewers distinguish eligibility for a pathway branch from a treatment decision, and distinguish absent evidence from negative evidence. Stable formal statements can improve pathway change control, reviewer handoffs, and traceability to validation scenarios.

Limits/adoption considerations

Type correctness is separate from factual patient truth, clinical-policy correctness, real-world safety, proof completion, and confirmation of intent. Each requires dedicated clinical evidence and data review, pathway governance, qualified individual judgment and outcome monitoring, proof/test artifacts, and explicit clinician acceptance. Evolving evidence, off-pathway care, comorbidity, patient goals, and uncertain or conflicting diagnostics make automation particularly limited. Decision-support behavior must be monitored for inequitable or burdensome effects.
MLTTDB4 patterns
This application set develops the contraindication, eligibility, safety-rule, and accountable-review themes in the upstream Clinical domain outline. It is grounded in the current MLTTDB demonstration architecture. The examples are assurance patterns, not medical guidance, clinical decision support, or claims of regulatory or production certification. Any implementation requires qualified clinical, pharmacy, laboratory, informatics, privacy, security, quality, and human-factors review for its intended care setting.
01Clinical-trial eligibility and contraindication review pack

Operational context

A research site screens candidates against a protocol whose inclusion, exclusion, timing, prior-treatment, laboratory, consent, and cohort rules may span several documents and amendments. Coordinators reconcile EHR data, research records, imaging or pathology assessments, and investigator judgment. The assurance problem is twofold: release a faithful machine-readable criteria pack for the active protocol version, and make the internal consistency of a candidate review packet visible without allowing software to replace the investigator’s eligibility determination.

Why MLTTDB fits

The protocol criteria and a candidate’s reviewed evidence set are bounded and versionable. MLTTDB tables can represent criterion identifiers, required evidence categories, temporal relations, contraindication groups, permitted outcomes, and explicit unresolved states. Proofs can require every criterion to have an evaluation disposition, every contraindication to map to the correct review outcome, and no conclusion of “criteria met” while required evidence is missing or internally contradictory. Stable UUIDs preserve criterion identity across wording or ordering changes.

Example architecture

protocol/amendment repository ---> criteria authoring + dual clinical review
                                                    |
EHR/CTMS extracts -> identity/terminology reconciliation -> typed review pack
                                                    |
                                                    v
                                           MLTTDB term store
                                                    |
proof-owned eligibility model ----------------------+--> proof-assistant check
                                                              |
                                         review report -> investigator/CTMS

A validated authoring process translates the protocol into reviewed formal criteria. A separate site integration resolves patient, visit, laboratory, and terminology identifiers and presents provenance to coordinators. The term store holds source-language rows for a specific protocol and review packet. The checker returns validation status and native diagnostics. A project-owned adapter associates diagnostics with row UUIDs, maps them into reviewer-facing findings, and retains any explicitly generated proof artifacts. The CTMS records the accountable investigator’s disposition through its own workflow.

Representative typed artifacts

  • ProtocolVersion, Cohort, and Criterion, with explicit applicability and amendment provenance.
  • EvidenceItem, carrying category, observation time relation, source reference, verification status, and an explicit unknown/indeterminate case.
  • CriterionAssessment, linking a criterion to reviewed evidence and a reasoned state such as satisfied, not satisfied, or unresolved.
  • ContraindicationGroup and EscalationRequirement for investigator review.
  • An EligibilityReviewManifest aggregate term, built by the reviewed adapter and reconciled to protocol, criterion, evidence, and assessment row UUIDs.
  • Proof obligations for complete criterion coverage, protocol-version alignment, contradiction detection, and no positive modeled conclusion from unresolved required evidence.

Checks and evidence

Release checks can detect duplicate or dangling criterion references, a cohort rule tied to the wrong amendment, missing outcome semantics, and inconsistent temporal windows in the formal model. Packet checks can detect evidence linked to another protocol version, mutually inconsistent assessments, absent mandatory reviewer escalation, or a modeled eligible state reachable with an unresolved exclusion. Tests should use synthetic cases covering boundary times, missing data, competing cohorts, amended criteria, and explicit protocol deviations. Evidence includes source protocol revision, formalization review, terminology snapshot, row UUIDs, checker/version output, packet digest, and accountable review history maintained outside MLTTDB.

Potential benefits

This can make protocol translation inspectable, expose amendment drift across sites, and replace implicit spreadsheet behavior with typed evidence states. It may reduce clerical omissions and give investigators a focused explanation of which encoded obligation is unsupported or contradictory. Synthetic proof fixtures can also make protocol-configuration regression testing repeatable before an amendment is activated.

Deployment boundary

MLTTDB does not query the EHR, interpret free text, identify a patient, infer a diagnosis, determine eligibility, obtain consent, enroll a participant, or guarantee protocol compliance. Site procedures must control protocol interpretation, source verification, privacy, amendment activation, overrides, deviations, and investigator sign-off. The checked model and its UI require clinical validation and ongoing review against the authoritative protocol.
02Oncology regimen-library release guardrails

Operational context

An oncology service maintains regimen templates across prescribing, pharmacy verification, compounding, administration, and monitoring systems. A regimen release can encode treatment phases, medication components, route and schedule categories, dose-adjustment methods, hold/escalation criteria, supportive-care dependencies, and required observations. Local practice and patient-specific judgment remain decisive, but the shared configuration library needs rigorous cross-component consistency before deployment.

Why MLTTDB fits

MLTTDB can serve as a release-time assurance layer over a finite regimen configuration baseline. Typed rows can distinguish regimen identity, phase, component role, adjustment rule, observation prerequisite, and exception workflow. Proofs can require that every component belongs to a declared phase, all modeled adjustment and hold states have an authorized review path, required dependencies are present, and incompatible alternative branches are not simultaneously active. The checked facts remain abstract configuration; they are not a patient-specific prescription.

Example architecture

clinical governance source + formulary + vendor build export
                         |
         terminology mapping and pharmacist reconciliation
                         v
              MLTTDB regimen candidate baseline
                         |
         proof-owned regimen model -> proof-assistant check
                         |
         release dossier + exact configuration digest
                         v
      CPOE/pharmacy build validation, simulation, approval, deployment

External tooling maps vendor concepts and medication identifiers to the formally reviewed catalogue. MLTTDB stores the ordered proof-language records and can expose verification through CI or an administrative service. A release controller binds the result to the vendor import package. Pharmacists and clinicians then inspect rendered templates and execute simulation and user acceptance tests before activating the configuration.

Representative typed artifacts

  • RegimenTemplate, TreatmentPhase, and RegimenComponent, each with stable identity and source provenance.
  • AdministrationConstraint, describing abstract route, sequence, or co-administration relationships without inventing clinical content.
  • ObservationRequirement, AdjustmentBranch, and HoldEscalation, including an explicit “requires clinician resolution” outcome.
  • SupportiveCareDependency and AlternativeBranch, with applicability conditions reviewed by domain experts.
  • A RegimenReleaseManifest aggregate term, reconciled to the vendor-package export and row UUIDs, enumerating the phases, components, branches, observations, and dependencies in the candidate release.
  • Proofs for reference closure, phase/component consistency, dependency presence, branch exclusivity, and complete modeled exception disposition.

Checks and evidence

The checker can reject orphan components, references to inactive catalogue items, an adjustment branch without a review outcome, simultaneous selection of exclusive alternatives, or a phase whose required observation category is absent. Synthetic regression fixtures should cover component substitution, phase omission, terminology remapping, unresolved hold state, and amendment of a shared supportive-care dependency. Evidence should retain formal source and checker revisions, approved terminology and formulary snapshot identifiers, row UUIDs and order, generated files, vendor package digest, independent clinical review, and downstream build-test results.

Potential benefits

Formal cross-record checks can expose library defects that are hard to see in screen-by-screen vendor review, especially when one shared component affects many templates. Typed identities and explicit exception states improve change impact analysis and interdisciplinary review. Reusable synthetic fixtures can turn a governance rule into a repeatable regression check for every candidate library release.

Deployment boundary

MLTTDB does not select a regimen, calculate or recommend a patient dose, interpret observations, prescribe, verify, compound, administer, or monitor therapy. It is not the CPOE or pharmacy runtime and supplies no clinical hard stop. Production use still needs accountable multidisciplinary governance, independent build verification, clinical validation, privacy/security control, human-factors testing, downtime procedures, and authorized activation in each target system.
03Transfusion episode safety-gate configuration

Operational context

A transfusion workflow crosses ordering, specimen collection, laboratory testing, component selection, issue, transport, bedside identification, administration, and reaction management. Multiple systems enforce different parts of the process. Before configuration is released, a transfusion service needs assurance that every modeled episode state has the required identity, testing, authorization, component-status, and escalation preconditions, and that exceptional paths cannot be represented as ordinary completion.

Why MLTTDB fits

The proposed use is to validate the state-machine and rules configuration that surrounds operational safety gates. Tables can model episode stages, evidence classes, component states, permitted transitions, exception reasons, and required accountable roles. Proofs can show, for the finite configuration, that an administration-ready state is unreachable without all formally required prerequisites, that expired or unresolved evidence cannot satisfy a gate, and that mismatch or reaction states terminate in explicit stop and escalation paths. MLTTDB does not determine biological compatibility.

Example architecture

transfusion policy + LIS/EHR/device workflow dictionaries
                           |
          laboratory/clinical informatics reconciliation
                           v
              MLTTDB gate-configuration baseline
                           |
        proof-owned episode model -> checker service
                           |
          verified rule map + release evidence
                           v
 LIS/EHR/device integration tests -> transfusion governance approval

An external mapping layer aligns system-specific status and reason codes with a clinically governed formal vocabulary. The term store persists candidate rules as proof-language records. The checker validates the modeled transition system; integration-test harnesses then exercise the actual LIS, EHR, label, scanner, and device interfaces. A release record correlates all evidence with the deployed configuration version.

Representative typed artifacts

  • EpisodeStage, EvidenceClass, and GateRequirement, with explicit provenance and validity-state semantics.
  • ComponentStatus and IdentityEvidence, modeled as reviewed categorical states rather than values inferred by MLTTDB.
  • PermittedTransition, with source stage, required evidence set, accountable role, destination, and failure destination.
  • ExceptionPath for urgent, mismatch, unavailable-data, or reaction workflow categories defined by the organization.
  • An EpisodeGateManifest aggregate term, reconciled to the policy export and row UUIDs, materializing the states, evidence classes, transitions, and exception paths used for graph-wide checks.
  • Proofs for prerequisite completeness, stop-state absorption, exception escalation, and absence of an unreviewed path to the modeled ready state.

Checks and evidence

Checks can reject a transition with an unknown stage, a gate satisfied by an evidence state marked unresolved, an exception without an accountable role, or a stop state with an ordinary-progress edge. Test fixtures should include identifier mismatch, stale evidence, component status change after issue, interface timeout, emergency-process invocation, and suspected reaction. These are configuration tests using synthetic identifiers, not validation of patient-specific compatibility. Evidence includes policy and formalization revisions, status-code mapping, database/checker snapshot, negative test results, integration-test reports, and governance approval retained in the organization’s controlled quality system.

Potential benefits

The model can reveal gaps between departmental policy and cross-system status mappings before go-live. It gives laboratory, nursing, informatics, and device teams a common transition vocabulary and an explicit inventory of exceptional paths. Exhaustive checks over the modeled graph complement scenario testing, while stable rule identities make interface-code changes easier to assess.

Deployment boundary

MLTTDB does not identify patients or components, perform testing or crossmatch, authorize issue, control a bedside scanner, deliver a hard stop, or manage a reaction. Live identity, compatibility, status freshness, and emergency decisions remain with validated clinical systems and qualified personnel. The formal configuration must be independently validated against policy and actual interfaces, with privacy, security, quality, human-factors, downtime, and ongoing change-control measures.
04Discharge medication-reconciliation review packet

Operational context

At discharge, clinicians reconcile pre-admission medicines, inpatient orders, new prescriptions, intended discontinuations, substitutions, monitoring requirements, and communication to the next care setting. Information arrives from EHR modules, pharmacy systems, patient or caregiver histories, and external records with differing identifiers and confidence. A useful assurance layer must preserve uncertainty and provenance, expose unresolved conflicts, and prevent a workflow configuration from labeling an internally incomplete packet as ready for sign-off.

Why MLTTDB fits

MLTTDB can validate a finite typed snapshot prepared for human review, or the workflow configuration that constructs such snapshots. Rows can represent source medication statements, reconciliation links, intended dispositions, unresolved discrepancy classes, communication obligations, and reviewer attestations. Proofs can require each in-scope source statement to have one explicit disposition or unresolved status, prevent mutually exclusive dispositions for one reconciled item, and require escalation before an incomplete packet reaches the modeled sign-off-ready state.

Example architecture

EHR/pharmacy/external lists -> patient + terminology reconciliation
                                      |
                             clinician review workspace
                                      |
                             typed candidate snapshot
                                      v
                              MLTTDB term store
                                      |
proof-owned reconciliation invariants +--> proof-assistant verification
                                                   |
                               consistency report -> clinician sign-off/EHR

Identity, terminology, duplicate detection, and source provenance are resolved by clinical integration services and displayed to the reviewer. Only the reviewed categorical statements needed by the formal model are serialized to MLTTDB, preferably with data minimization or pseudonymous references. The verification result returns to the workspace as an internal-consistency aid. The EHR owns the legal record, prescribing actions, attestation, and downstream communication.

Representative typed artifacts

  • SourceMedicationStatement, with source system, provenance reference, confidence/review state, and encounter scope.
  • ReconciledMedication, grouping reviewed source statements under a canonical identity assigned by external terminology services.
  • Disposition, representing continue, change, stop, replace, defer, or unresolved categories as locally governed abstractions.
  • Discrepancy, FollowUpObligation, and CommunicationTarget records.
  • A MedicationReconciliationManifest aggregate term, reconciled to the minimal EHR projection and row UUIDs, enumerating source statements, grouped medications, dispositions, and communication obligations.
  • Proof obligations for source-statement coverage, disposition exclusivity, unresolved-item escalation, and complete modeled communication obligations before readiness.

Checks and evidence

The checker can identify orphan source statements, one item assigned conflicting dispositions, a replacement with no reviewed target, an unresolved high-priority discrepancy without escalation, or a ready-state packet missing a required communication target. Synthetic tests should cover duplicate sources, terminology ambiguity, late source updates, intentional discontinuation, substitution, and deferred resolution. Evidence should bind the checker output to the packet and formalization revision and include source provenance references, ordered record UUIDs, reviewer actions, override reasons, and EHR audit events. MLTTDB’s database alone is not an immutable clinical audit trail.

Potential benefits

Explicit typed dispositions can make omissions and contradictions easier for a pharmacist or prescriber to see, while preserving “unknown” as a legitimate state instead of forcing false certainty. The same invariants can test workflow changes with synthetic packets before deployment. Stable row identity also helps explain which reviewed statement changed when a source list is refreshed.

Deployment boundary

MLTTDB does not retrieve a medication history, resolve terminology, detect all duplicates, assess appropriateness, recommend therapy, prescribe, discontinue, communicate with a patient, or sign the discharge record. Any finding is an internal model result for qualified review, never an autonomous clinical decision. Deployment requires validated interfaces, data-quality controls, privacy and access safeguards, clinician override and downtime workflows, human-factors testing, and accountable pharmacy and medical governance.
State Machine Studio3 demos
SMPatient Deterioration Response

This example represents recognition and response when a patient’s observations begin to depart from their expected course. It joins trend monitoring, validation of warning signals, qualified triage, time-critical intervention, reassessment, and care transition. The model accommodates a local early-warning policy or specialty pathway without assuming that one threshold or score is appropriate for every patient.

The pathway starts with patient-specific baseline observations, scheduled trend and symptom assessments, active risk modifiers, and monitoring limits. When a warning appears, staff validate the measurement and timestamp, compare the trend with the applicable threshold, and notify the accountable care role. Clinical triage combines symptoms, trend severity, relevant history, and the governing safety pathway to determine urgency and whether local review or rapid-response escalation is required. A protective intervention assigns qualified actions, monitoring, and communication responsibilities while recording the timing and observed response. Protocol-defined reassessment repeats the necessary observations and compares them with stabilization criteria. A stabilized patient returns to baseline monitoring; unresolved deterioration moves to a care transition with the current condition, risks, and intervention timeline handed off and acknowledged.

The loops distinguish false alarms from unresolved risk without normalizing either. A confirmed measurement artifact can return to routine monitoring, but only after validation. Triage may restore monitoring when qualified assessment finds no continuing concern, or initiate an urgent care transition without waiting for a local intervention cycle. Reassessment can repeat or adjust the intervention when response is inadequate. Failure to meet stabilization criteria escalates care rather than resetting the warning. These controls matter to bedside nurses, treating clinicians, and rapid-response teams because delayed escalation often results from fragmented observations, unclear ownership, or failure to confirm response after an intervention. Explicit handoff acknowledgement reduces the chance that unresolved deterioration disappears between teams or care settings.

Layer 1 — Deterioration pathway

This layer gives the episode-level picture: baseline monitoring, warning detected, clinical triage, protective intervention, reassessment, and care transition. It is useful for charge nurses, clinical leads, and safety reviewers because it shows current risk posture and escalation direction. It intentionally excludes individual vital signs and tasks so an unresolved warning or transfer is not buried in detail.

Layer 2 — Escalation and reassessment procedures

This layer describes the procedural safeguards within the pathway: establish individualized baselines, validate abnormal measurements, notify the accountable role, classify urgency, assign interventions and responsibilities, repeat observations, apply stabilization criteria, and complete an acknowledged handoff. It supports local escalation policies and simulation scenarios. It does not prescribe specialty-specific treatments or universal trigger thresholds.

Layer 3 — Observation-level actions

This layer exposes the concrete clinical work: timestamp and repeat a measurement, compare trends, assess symptoms and history, document time-critical actions, trend the response, record unresolved risks, and transfer the observation and intervention timeline. It supports audit, debrief, and interface testing. Monitor protocols, device integrations, and the clinician’s diagnosis or treatment selection remain intentionally outside this general example.
Open interactive model
SMHigh-Risk Medication Administration

This example represents the closed-loop administration of a high-risk medication, from drafting the order through verification, patient-specific preparation, bedside checks, post-dose monitoring, and completion or safety escalation. It emphasizes that safe administration depends on current clinical observations and independent controls, not solely on the presence of a signed order.

The normal pathway begins with the medication, indication, route, schedule, and protocol-specific monitoring requirements, linked to current weight, renal function, hepatic function, and other dose-relevant observations. Clinical verification checks allergies and prior reactions, drug interactions, duplicate therapy, contraindications, and dose calculation. Pharmacy or the authorized preparer selects the verified product and concentration, prepares and labels the patient-specific dose, and completes the required independent check. At the bedside, the care team matches patient, medication, dose, route, and time; confirms baseline observations; and verifies access to rescue resources and escalation contacts. After administration, protocol-defined response and safety signals, vital signs, and relevant laboratory results are trended and documented before therapy is completed.

The return and escalation paths keep new information from being bypassed. An unsafe or incomplete order returns to the prescriber for revision. A preparation mismatch found at the bedside goes back for correction rather than being informally reconciled. A newly identified contraindication before dosing, or an adverse signal afterward, enters safety escalation: further dosing is held, the patient is assessed, the protective response is initiated, and qualified review is required. The reviewed outcome may produce a new order and controlled resumption or terminate therapy. These controls matter to prescribers, pharmacists, nurses, and safety teams because renal function, weight, concurrent therapies, and patient condition can change between ordering and administration, while independent verification and prompt reaction management reduce preventable harm.

Layer 1 — Medication pathway

This layer presents the episode-level status: order drafted, clinically verified, dose prepared, ready for administration, under monitoring, in safety escalation, or complete. It lets the accountable clinical team see where responsibility and permission to proceed currently sit. It intentionally excludes individual checks and measurements so the medication pathway and any hold remain unmistakable.

Layer 2 — Safety verification procedures

This layer expands each status into the required safeguards: associate current organ-function and weight observations, check allergy and interactions, recalculate dose, perform an independent preparation check, confirm baseline monitoring and rescue readiness, and require qualified review after a safety signal. It is suited to medication-use policies and protocol design. It excludes drug-specific thresholds and local formulary instructions.

Layer 3 — Bedside actions

This layer identifies the observable tasks carried out by pharmacists and clinical staff: select concentration, label a patient-specific dose, perform the independent check, match the administration rights, record baseline values, administer, trend response, hold further doses, and reconcile administered, held, or discarded product. It supports checklist testing and incident reconstruction. Device commands, barcode formats, and EHR screen sequences are intentionally implementation-specific.
Open interactive model
SMClinical-Trial Screening and Enrollment

This example represents a candidate’s pathway from referral to a documented trial-screening disposition. It brings informed consent, protocol-defined eligibility, time-sensitive observations, contraindications, washout conditions, and qualified exception review into one inspectable workflow. It is not a substitute for the protocol or investigator judgment; it shows how the evidence and decisions required by those authorities should progress.

The expected pathway begins by confirming the candidate, requested cohort, and enrollment window. The current approved consent materials are presented before study-specific screening, and the team documents questions, decision-making capacity, voluntary agreement, and the consent version used. Screening then collects protocol-required history, examinations, laboratory results, and imaging, checking freshness windows as well as washout and concurrent-treatment conditions. Eligibility review evaluates each inclusion criterion, checks exclusions and distributed contraindications, and produces a criterion-by-criterion summary. A qualified candidate receives a cohort and enrollment identifier, with protocol activities and safety monitoring scheduled. The final disposition and its supporting record are retained when screening closes.

The exception paths reflect real screening work. Withdrawal after consent closes the candidate without proceeding. A stale laboratory result or observation returns for refresh rather than being treated as current. An ambiguous finding, missing evidence, or out-of-window assessment goes to protocol-authorized qualified review. The reviewer records the issue, authority, disposition, and rationale, then either returns the record for reassessment or closes an unresolved screening. A clearly ineligible candidate also closes without enrollment. These controls matter to investigators, coordinators, and monitors because enrollment pressure must not turn uncertainty into assumed eligibility, and because consent version, observation timing, contraindication review, and documented investigator decisions are central to participant safety and trial integrity.

Layer 1 — Enrollment pathway

This layer is the subject-level view used by the principal investigator, study manager, or monitor. It shows referral, consent, screening, eligibility review, exception review, enrollment, and closure, together with withdrawal and screen-failure paths. It intentionally excludes individual test results so the candidate’s status and the authority for each transition remain immediately visible.

Layer 2 — Screening and consent procedures

This layer expands the pathway into the protocol-facing procedures: verify enrollment timing, use the reviewed consent version, document capacity and voluntariness, collect required assessments, apply freshness and washout rules, review every criterion, and obtain qualified exception disposition. It is suitable for site procedures and monitoring review. It does not define the values or thresholds of a particular protocol.

Layer 3 — Observation-level actions

This layer shows the concrete evidence-handling work: record referral facts, capture consent questions, associate laboratory and imaging timestamps, check concurrent treatment, mark each inclusion and exclusion criterion, refresh stale observations, and retain the reviewer’s rationale. It supports source-data review and traceability. Instrument interfaces, EDC field layouts, and protocol-specific clinical interpretations are deliberately left to the study implementation.
Open interactive model
Explore patternsReview product applications

Cabinet index

Explore Formal Foundry

Search the archive

Find a page

Type to search the published content.