Skip to main content

HOW PHARMORIS WORKS

From attributable source to reviewable action.

PHARMORIS is designed around a target lifecycle in which source provenance, human triage, ActionCase ownership, decision material and later review states remain connected but distinct. The model describes intended product behaviour; it is not evidence that every component, source adapter or transition is implemented or live.

Human triage is mandatory before an ActionCase. PHARMORIS does not prescribe, approve a medicine, provide patient specific advice or replace professional judgement.

Review the lifecycleReview product assurance
Target operating model · Not a live interface
Model | Target operating lifecycleEvidence state | Not proof of live implementationAuthority | Human triage is mandatory

TARGET LIFECYCLE

A source does not become action automatically.

The target chain preserves the basis of the work before any operating record is created. A CandidateSignal remains pre operational until an authorised person accepts it for ActionCase creation. Reject, defer, request evidence and UNKNOWN routes remain visible.

Source evidence and receipt or snapshot → CandidateSignal → Human triage → ActionCase → EvidencePack version → Human gate → Publication → Acknowledgement → ValueReview
  1. 01

    Source evidence and receipt or snapshot

    Identify the source basis, date, permitted purpose, receipt or approved snapshot and any limitation before it supports work.

    Missing or invalid → Quarantine / UNKNOWN
  2. 02

    CandidateSignal

    Keep the pre operational trigger, source link, confidence, missing fields and triage status distinct from an ActionCase.

  3. 03

    Human triage

    An authorised person accepts, rejects, defers or requests more evidence. Software does not inherit this authority.

    Accept / Reject / Defer / Request evidence
  4. 04

    ActionCase

    Create the bounded working record with source links, owner, current state, activity and blockers only after acceptance.

  5. 05

    EvidencePack version

    Prepare versioned material for review. The pack is not the decision.

  6. 06

    Human gate

    The relevant authorised people review the material and record an outcome within their remit.

  7. 07

    Publication

    Record the controlled hand off of a defined version and scope.

  8. 08

    Acknowledgement

    Keep the receiver's response separate from publication and from adoption.

  9. 09

    ValueReview

    Review value and supporting evidence later without turning a state into automatic proof of savings.

Target operating model. Human decisions remain required. This text sequence does not establish current implementation, a live source, NHS deployment, clinical authority or realised value.

AUTHORITY BOUNDARY

Human triage creates the ActionCase boundary.

CandidateSignal is a prompt for authorised review, not an instruction or approved opportunity. The reviewer considers the source basis, missing information, intended use and local context before deciding whether a bounded ActionCase should exist.

No automated or model assisted output may create professional, clinical, financial, procurement or governance authority.

Human decision requiredProceed only inside an evidenced and governed scope.
01

Accept

Create an ActionCase only when the authorised reviewer records that the signal has enough basis to progress.

02

Reject

Record why the signal should not progress without erasing the source history.

03

Defer

Preserve the signal and reason for delay without presenting it as active work.

04

Request evidence

Keep the status incomplete until the missing source, permission or context is supplied and reviewed.

FAILURE IS A REAL STATE

Missing or invalid evidence stays visible.

The target interface must distinguish loading, empty, partial, invalid, permission denied, stale, unknown source, unsupported action and server error states. A failed source or API request must not be replaced by demo data outside an explicit, labelled demo tenant.

01

Validate

Use material only when the required source, schema, rights and freshness checks support the intended purpose.

02

Quarantine

Keep invalid or unauthorised material unavailable until it is resolved and reviewed.

03

UNKNOWN

Show UNKNOWN when the source, permission, current value or evidence state is not established.

STATE SEPARATION

Similar words do not mean the same thing.

The canonical target architecture uses separate state groups for each record. Exact interface and API enum names still require confirmation against the approved contract for the candidate being reviewed.

01CandidateSignal
Triage status does not create an ActionCase by itself.
02ActionCase
Operating state does not prove evidence quality or value.
03EvidencePack
Pack approval is not publication, adoption or deployment.
04Publication
Publication is a scoped release or hand off state.
05Acknowledgement
Receiver response remains independent of publication.
06ValueReview
Value lifecycle and evidence status are separate axes.

ONE CONFIGURABLE PRODUCT

Separate source handling, governance and operating state.

The intended architecture keeps source specific ingestion separate from shared workflow logic and tenant specific configuration. Variation belongs in controlled personas, tenant configuration and source adapters, not customer specific code forks.

01

Source layer

Define retrieval, rights, receipts, artefacts, validation, quarantine and source specific transformation.

02

Governance layer

Apply authorised roles, decision boundaries, required review and truthful stop states.

03

Operating layer

Maintain owner, lane, activity, blockers, closure and the controlled record.

04

Access boundary

Derive tenant and role context from authenticated server policy. The browser does not supply authoritative tenant identity.

REPRESENTATIVE WORKFLOW

Examine one bounded path without mistaking it for deployment.

A demonstration may use clearly labelled synthetic or approved public material to discuss the intended lifecycle. It is not proof that a source adapter, transition, tenant control or product surface is working in a current environment.

Review current product statusReview PHARMORIS assurance
01

Choose one workflow

Start with a specific medicines workflow or evaluation question.

02

Keep the evidence visible

Ask which source, limitation and human decision should remain connected.

03

Set the next gate

Define the evidence needed before any controlled non production evaluation discussion.

Classified public record

Inspect related publisher records

MEDICINES ANALYSIS + EXECUTION

You can identify the opportunity and still lose it in delivery.

Explore the financial, operational and governance questions that shaped PHARMORIS. Then check the product’s dated status before treating the model as implemented.

  1. PharmaphorumContributed analysis

    Approval is not access: Pilots' real test is implementation

    In pharmaphorum, Varun Sharma argues that medicines access pilots should measure the full chain from recommendation to funded delivery and outcomes.

    Read the implementation argument
  2. AI Ethics Now / University of Warwick IATLPodcast appearance

    AI and Accountability: When Does a Suggestion Become a Decision?

    Varun Sharma joins AI Ethics Now to examine false confidence, human responsibility and the point where AI assisted suggestions become accountable decisions.

    Hear the human accountability discussion
  3. NEUVIOR Founder ReflectionsNEUVIOR analysis

    After NICE: making medicines access operational

    A recommendation can clarify what should be available. You still need an accountable route from evidence to a local decision, delivery and review.

    Map the work after a medicines recommendation
Explore every medicines analysis

NEUVIOR Insights and After Publication reflections are company or founder analysis. Publisher records evidence publication, not endorsement, adoption, product readiness, savings or clinical outcomes.

DISCUSS ONE WORKFLOW

Explore a representative workflow.

Bring one bounded medicines workflow or evaluation question. The walkthrough remains synthetic or based on approved public material, non production and subject to human authority.

Request a PHARMORIS demoReview current product status

QUESTIONS · ANSWERED DIRECTLY

The useful answers, in one place.

Browse every question
01What problem does PHARMORIS address?

Medicines teams can identify an opportunity yet still lack a consistent way to connect the evidence to a decision, accountable owner, delivery tasks, blockers and a reviewed result. PHARMORIS is being built for that operational gap.

02Who is PHARMORIS intended for?

PHARMORIS is intended for authorised medicines, pharmacy, finance, procurement and operational teams working inside responsible healthcare institutions. Scope and deployment requirements must be agreed for each organisation.

03Does PHARMORIS replace professional judgement?

No. PHARMORIS is designed to structure evidence and accountable work while keeping professional and institutional decisions with authorised people.

04What is an ActionCase?

An ActionCase is the governed unit of work at the centre of PHARMORIS. It can hold the evidence basis, scope, owner, decisions, tasks, blockers and review record for a medicine opportunity.

05Is PHARMORIS ready for production or deployed?

PHARMORIS is under controlled development and should not be interpreted as a live, adopted or clinically approved product unless a current, specific deployment record says otherwise.

06Does the public demonstration use patient data?

No. Public and representative demonstrations are designed without live data that identifies patients. Any future institutional data scope would require separate governance, security and contractual controls.