Consent & policy

Draft pending clinical/legal review

This guide describes Railflo’s actual, implemented precedence logic — every rule below is real code, not a plan. It has not yet been reviewed for clinical/legal accuracy by the founder, who personally holds sign-off on this page (one of five specs held for her direct review before anything on this topic is presented as authoritative). Treat this as an accurate technical description of current behaviour, not yet a blessed compliance statement. See docs/dev/consent-pdp.md’s “Known gaps” for the specific open items her review will need to weigh.

The one rule that matters

Every exchange is checked against a policy decision point before it moves. There is no way to send an exchange that skips this check — not from the public API, not from Console, not from an internal Railflo tool. If the policy engine itself is unreachable, the exchange is refused, never silently allowed through.

What decides an exchange

Six kinds of rule can apply to a given exchange, in this fixed order of authority (a higher rule always wins over a lower one, when both apply):

1. Statutory mandate — a legal reporting duty (notifiable disease, mandated child-protection reporting, coroner notification). Cannot be overridden by anything below it, including the patient’s own wishes — a legal duty to report isn’t something a patient can opt out of.
2. Statutory prohibition — a legal bar on sharing, equally non-overridable.
3. Emergency override — a genuine break-glass path, but not a free pass: it requires a named clinician’s attestation (who they are and why) recorded at the time, and every use is reviewable afterwards. It can override a patient’s own standing preference, but not a statutory mandate or prohibition.
4. Patient directive — the patient’s own stated preference (e.g. “don’t share my record with organisation X,” or a blanket deny). This is what the sandbox’s consent-denied magic value demonstrates.
5. Org policy — your practice’s own default rule, if you’ve set one.
6. Jurisdiction default — what applies when nothing more specific exists. For Ireland at P0: sharing for treatment or transfer of care is permitted by default; sharing for administration is not; a patient’s own subject-access request is permitted when your practice is the one holding their record, and not otherwise (see Known gaps below).

If literally nothing applies, the request is refused — fail closed, never fail open.

What this looks like in practice

• Sending a referral for ongoing treatment: usually permitted by the jurisdiction default, with nothing more specific needed.
• A patient has told your practice they don’t want their record shared with a particular hospital: their directive blocks it, even though treatment-purpose sharing is otherwise the default — unless a statutory mandate or a properly-attested emergency override applies.
• A notifiable-disease report: goes through regardless of anything the patient or your practice’s own policy says, because it’s a statutory mandate.

Checking before you send

POST /v1/policy/preview runs the same decision the real send would, without creating anything — use it to explain to a practice manager or patient why an exchange would (or wouldn’t) go through, before committing to it.

Known gaps (stated honestly, not glossed over)

• The subject-access-request rule currently treats “is the patient’s own practitioner” as “is the sender the same tenant that holds the patient’s record” — a reasonable proxy today, but one that the founder has flagged as likely wrong for Railflo’s own role as an intermediary between practices, and tracked as an open architectural question, not a bug to quietly patch.
• The full precedence table above has been implemented and tested against every scenario the spec’s own acceptance criteria describe, but has not yet been through the founder’s own end-to-end review pass of the complete table — see this page’s caution banner.