> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rxscale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Storefront Prescription Requests

> Reviewing a request a patient submitted and paid for through a storefront

# Storefront Prescription Requests

Some organisations publish a storefront: a public page where a patient with no account fills in a
questionnaire, names the medicines they are asking for, names the pharmacy that should receive the
prescription, and pays a **review fee** before anything reaches you.

By the time such a request appears in your queue, the patient has already paid. What they paid for
is your review — not medicine, and not a prescription. Declining is a normal outcome.

<Note>
  **The patient's email address is confirmed before they can submit anything.** The storefront emails
  them a link and nothing is collected until they open it, so the address the request is filed under
  is one they demonstrably read mail at. Nothing else about them is verified: the name, date of birth,
  address and answers are all self-reported, exactly as they are on any other request you review.
</Note>

<Note>
  Storefront requests only appear if your organisation runs a storefront. If yours does not, nothing
  on this page applies to you and your queue is unchanged.
</Note>

<h2 id="where-they-appear">
  Where they appear
</h2>

There is no separate list. A storefront request arrives as an ordinary prescription in the
Anamnesis Center, alongside everything else you review.

The one difference is that it arrives **unassigned** — no doctor is named on it. Any doctor in your
organisation can see it and pick it up.

<h2 id="claiming-a-request">
  Claiming a request
</h2>

Because an unassigned request is visible to all of your colleagues, you take it before you work on
it.

* **Reading is open.** You can open an unassigned request and read it before deciding whether to
  take it.
* **Writing needs a claim.** You cannot record prescribing details on a request that is not yours.
* **Only one doctor gets it.** If a colleague claims the same request a moment before you, you are
  told that it is already claimed. You are never silently given a case someone else is reviewing,
  and you are never silently relieved of one.

<Warning>
  If you are told a request is already claimed, do not carry on working on it. The colleague who
  claimed it holds the case.
</Warning>

<h2 id="what-the-patient-asked-for">
  What the patient asked for
</h2>

Each requested line records the patient's own words:

* **The medicine**, as they described it.
* **A dosage**, in free text and optional — for example "one tablet in the morning".
* **A quantity.**

Patients never supply a PZN or any other product code; that is deliberate, because a
patient-supplied code would look authoritative on a document nobody had checked.

<Note>
  What the patient wrote is a request, not a prescription, and it does not bind you. It is kept
  exactly as they typed it and is not overwritten by anything you record.
</Note>

You also have the questionnaire answers the storefront collected, and the patient's profile and
history as for any other review.

<h2 id="what-you-record">
  What you record
</h2>

Alongside the patient's request, you record what is actually to be prescribed:

| Field            | Meaning                                                      |
| ---------------- | ------------------------------------------------------------ |
| Medicine         | The medicine as it should be prescribed.                     |
| Quantity         | The quantity as it should be prescribed.                     |
| PZN              | The Pharmazentralnummer. Yours to set — never the patient's. |
| ED (Einzeldosis) | The single dose.                                             |
| TD (Tagesdosis)  | The daily dose.                                              |

The patient writes one free-text dosage; you read it and record the structured ED and TD. You can
change every one of these fields — prescribing something other than what was asked for, in a
different amount, or declining outright, are all normal outcomes of a review.

You can fill a request in over several sittings, and correcting a field you filled in by mistake is
a normal edit.

<Note>
  The order line behind a storefront request points at a **placeholder product**, not a real
  catalogue article — a patient can ask for something you do not stock. What the prescription says
  comes from the fields above, which is why the medicine name is normally required before signing: a
  blank one would fall back to the placeholder.
</Note>

<h2 id="before-you-can-sign">
  Before you can sign
</h2>

Your organisation decides which of the fields above must be filled before a request carrying them
can be signed. If any of them is missing, signing is refused and the missing fields are named — the
prescription is not signed with gaps in it.

The setting is per organisation and takes effect immediately. If it is stopping you on a field your
organisation does not want, ask your administrator to change it; it does not need a release.

<Note>
  Until your organisation sets its own list, a deliberately strict default applies: the medicine, the
  quantity, the ED and the TD are all required, and the PZN is not. That default is a starting point,
  not a clinical recommendation — agree the list with whoever owns clinical policy in your
  organisation before you go live.
</Note>

This gate only applies to prescriptions that carry a patient request. Everything you reviewed
before is unaffected.

<h2 id="after-you-sign">
  After you sign
</h2>

Signing freezes what the prescription says. If someone later renames a product in the catalogue,
the signed prescription still reads exactly as it did when you signed it.

The signed prescription then goes to **the pharmacy the patient named**, by email. The patient does
not receive it, and the pharmacy contacts them about the medicine, its cost and how it reaches them.

<Note>
  The patient's own status page shows the **outcome** of your review: that a prescription has gone to
  their pharmacy, or that none was issued. It never shows your reason for declining, your notes, or
  anything else from the prescription. If they ask you what it says, that is the whole of it.
</Note>

<h2 id="declining">
  Declining
</h2>

Declining a storefront request works the same way as declining any other prescription: give a clear
reason, which becomes part of the record.

<Warning>
  Declining does **not** refund the patient. The fee paid for your review, and the review happened. A
  refund is an administrative action taken separately, and it is decided case by case — never by the
  clinical decision. Do not tell a patient their money will be returned.
</Warning>

## Related Topics

* [Reviewing Prescriptions](/for-doctors/reviewing-prescriptions) — Approve, decline, or place a
  prescription on hold.
* [Signing Prescriptions](/for-doctors/signing-prescriptions) — How electronic signing works.
* [What the patient was told they were paying for](/for-patients/prescription-requests#what-the-fee-pays-for)
  — The wording shown at checkout, worth knowing when a patient asks.