A hospital's administrative team might need the current room-booking process, a purchasing approval route or the owner of a facilities request procedure. Those are narrower questions than “ask anything about the hospital,” and they call for a narrower system.
This guide proposes an assistant for approved non-patient administrative SOPs. It excludes patient records and clinical decision protocols from the initial corpus and does not delegate policy authority to a model. It is a discovery-stage design, not a delivered hospital system, a claim about Remmly's institutional features or evidence of accreditation.
Choose a corpus whose boundary can be explained
Name the departments, document classes and permitted questions before selecting a model. A starting collection might cover meeting rooms, purchasing administration and routine facilities request routing. Even those documents require privacy review: a file labeled “administrative” can contain personal details, example identifiers or sensitive attachments.
Each source needs a responsible policy owner and approver. That person decides what the procedure means, when it changes and where questions go. The assistant can point to an approved section; it should not invent an exception, resolve contradictory policies itself or present its wording as the institution's authoritative instruction.
WHO's Laboratory Quality Stepwise Implementation document-control activity includes revision forms, a document-control log, retention lists and archiving. Its laboratory quality manual template offers laboratory-specific SOP, form and process examples. These are useful governance analogies. They are not hospital-wide software requirements, accreditation evidence or proof that this proposed assistant is compliant.
Give every SOP a publication contract
The index should know whether a document is approved, effective, overdue for review, superseded or retired. Do not infer authority from a filename containing “final.” Keep the approver's decision in a controlled publishing workflow.
| Proposed field | Purpose |
|---|---|
| sop_id, department | Stable procedure identity and organizational scope |
| owner, approver | Responsibility for interpretation and approval |
| version, supersedes | Pin a revision and its replacement relationship |
| effective_date, review_date | Separate when it applies from when review is due |
| permitted_roles | Explicit access boundary enforced outside the model |
| status | Distinguish draft, approved, superseded, retired and other agreed states |
Store source and passage locators with each indexed revision. When a result is shown, display the document title, current version, approval/effective information and owner contact. A review date is not automatically an expiry date: the institution must decide whether overdue documents are withheld or visibly flagged. Either way, the assistant must not conceal that state.
Make publication a controlled sequence
An illustrative workflow is submission → scope/privacy review → approval → versioned indexing → role-filtered lookup → owner review or retirement. Keep drafts outside the ordinary answer corpus. A failed indexing job should not silently leave a superseded policy looking current.
A proposed release manifest might look like this. All identifiers and values are synthetic, and the manifest is not a Remmly API:
{
"sop_id": "ADMIN-DEMO",
"department": "facilities-demo",
"owner": "policy-owner-demo",
"approver": "approver-demo",
"version": 3,
"effective_date": "2026-11-05",
"review_date": "2027-02-05",
"permitted_roles": ["facilities-demo-reader"],
"status": "approved",
"supersedes": 2,
"corpus_scope": "non-patient-administration"
}
Before publication, validate the allowed document class, approval state and role mapping. When version 3 becomes authoritative, update retrieval eligibility and invalidate cached answers referencing version 2. If that update cannot complete, expose a service limitation and route staff to the controlled source. Do not combine passages from competing revisions into a generated compromise.
Keep lookup separate from interpretation
A staff member asks how to request a meeting-room change. The system authenticates the user, resolves current permitted roles, finds the applicable approved procedure and returns the relevant section with its source and owner. If the question asks for an exception the source does not cover, it directs the person to the owner rather than writing a new policy.
A question containing a patient's details is outside scope even if the desired answer sounds administrative. Do not forward it to a general model and then decide afterward that it should not have been included. Design screening and handling before external processing, including a conservative route for ambiguous input. Screening can miss content; it is one control in an operational process, not proof that patient data can never enter the system.
Requests for diagnosis, treatment, clinical interpretation or patient-specific advice should receive a short scope explanation and the institution-approved human route. Do not repurpose this lookup lane as triage or an emergency queue. Qualified staff retain clinical decisions, and urgent matters need the institution's established channels.
Plan for accidental disclosure without reproducing it
A “no patient data” banner does not enforce a boundary. Define what happens if an upload, prompt or attachment contains prohibited information. Possible controls include blocking before ingestion, restricting a suspected document for designated review and preventing its inclusion in search or model context. The precise architecture needs the hospital's privacy, security and jurisdiction-specific review.
Keep operational logs useful without storing unnecessary sensitive prompt content. Record a protected event reference, decision category, responsible team and handling state; do not paste the offending content into a general error dashboard or support email. Any retention or disposal step must follow an approved incident process, rather than a developer making an ad hoc deletion decision.
There is a tradeoff between detailed auditability and collecting more sensitive material. Agree the smallest record that allows accountable investigation, who can access it and when it expires. Review vendor data flows and model-provider processing before a pilot; a locally labeled administrative corpus does not itself constrain every downstream processor.
Test authority, scope and escalation independently
Use fictional documents and synthetic prohibited-detail sentinels in an isolated environment with external processing unavailable. Do not use real patient records to see whether a filter catches them. Have policy owners inspect actual result wording, not just status codes.
| Seeded fixture | Question for the evaluation |
|---|---|
| An expired or overdue-for-review SOP | Does the agreed publication policy apply, with the state visible? |
| A department-restricted document | Is it excluded before retrieval for an unauthorized role? |
| A contradictory draft | Does the answer use the approved version and flag the owner route when needed? |
| A synthetic patient-detail sentinel | Is it blocked or restricted before indexing/model processing, with no content copied into general logs? |
| A request for clinical advice | Does the assistant refuse that scope and provide the approved human route? |
Track wrong-version answers, unauthorized passage exposure, boundary-test misses and owner-escalation handling. Include role revocation, delayed approval feeds and indexing failure in the test pack. Agree pass/fail thresholds and a rollback/stop plan with the institution before any limited pilot. This article presents no clinical, compliance or operational outcome results.
What comes from Remmly, and what does not
Remmly is a personal library for capture and recall. Its Ask documentation describes answers linked to saved sources and review of proposed changes. The owned-product study explains source inspection, processing states and deliberate sharing. These interaction patterns can inform an interface; they do not establish hospital permissions, audit controls or a validated SOP service.
A custom build needs upload screening, source approval, role enforcement, version invalidation, incident handling, staff education and an accountable document-owner queue. Remmly's privacy page states that backend and connected AI providers process content and that the product is not end-to-end encrypted. Do not put patient records into the personal product as a shortcut to this design.
Its operator setup requires source checkout; a public repository/license has not been announced and optional shared media processing requires an invitation. The web workspace is available and public mobile releases are forthcoming. These are distribution and processing facts, not institutional suitability claims.
Explore AI development and discuss a bounded administrative corpus. Bring a fictionalized example SOP, its owner and access rules, plus a clear list of questions the system must not answer.
Sources and evidence limits
Checked 5 November 2026: WHO LQSI document-control activities, WHO laboratory quality manual template, and the linked Remmly documentation. The WHO material is laboratory-specific; its publication is not certification of software. The LQSI page is a legacy page with readable activity content. No full laboratory toolkit validation, hospital deployment, independent security review or guarantee of patient-data exclusion is asserted.