R
RonanRx
Authorization flow proposal
Discussion draft Patient magic link Signature to PDF LinkQ / LinqApp handoff

Text PHI authorization

One signed screen that turns the thread from masked care coordination into clear clinical conversation.

The SMS/iMessage thread stays the patient surface, but the sensitive step moves to a secure RonanRx magic link. The patient reviews counsel-approved authorization language, signs with a finger or cursor, and Rails seals a PDF packet with the signature image, token evidence, and audit events.

Before Pointer-only text No medication, diagnosis, lab, dose, or pharmacy specifics leave the server in message copy.
Trigger Neutral magic link LinkQ sends a short secure link; Rails verifies token, phone binding, TTL, and single use.
After Signed authorization Message templates can carry clearer health terms, still governed by send guards, revocation, and audit logging.

End-to-end path

The flow is a portal detour, not a new app.

Everything starts and returns to the persistent patient thread. The only full-screen surface is the signature moment, because that is the step where a reply like "yeah" is not enough.

Counsel owns final authorization language. This artifact is a product and engineering template, not final legal copy.

RonanRx needs clear health copy

Conversation state hits a PHI boundary: diagnosis, medication name, dose, labs, pharmacy details, or specific care instructions.

LinkQ state

Rails mints a portal-bound token

Single-use magic link, phone-bound identity check, short TTL, and server-side authorization draft ID.

Rails API

Patient signs on RonanRx

The page renders patient fields, authorization scope, revocation terms, consent checks, and a touch signature pad.

Secure web

PDF packet is sealed

The signature image, field values, document text version, token evidence, IP hash, and timestamp become an immutable artifact.

Artifact job

Thread policy changes

Outbound templates may include clearer health terms until expiration or revocation; every message is stamped to Event and AuditLog.

Send guard

Patient screen prototype

Review, acknowledge, sign, and return to the thread.

The interaction is deliberately short. Patients should recognize the phone number and scope, see the exact health categories that may appear in text, then sign once.

Try the signature pad below. The preview document updates with the captured image after signing.
RonanRx secure authorization Expires in 54 minutes
Maya Alvarez
+1 512 ... 0184
Health terms in text

Authorization to communicate by text

I authorize RonanRx, participating doctors, Elite Care Pharmacy, and care support staff to send and receive health information with me in my LinkQ, iMessage, RCS, or SMS thread at the phone number above.

  • Information may include medication names, dose instructions, conditions, allergies, lab values, pharmacy status, shipping, billing-support details, and care coordination updates.
  • The purpose is care coordination, prescription routing, pharmacy fulfillment, support, and follow-up reminders.
  • This authorization expires 12 months after signature unless I revoke it earlier.
Signature
Waiting for signature.

PDF packet preview

Text PHI Authorization

AUTH-2026-0624-1042
doc_version: text_phi_auth_v1
Maya Alvarez
+1 512 ... 0184
RonanRx, participating doctors, Elite Care Pharmacy, support operations
Patient's LinkQ/iMessage/SMS thread at verified phone number
Care coordination, prescription routing, pharmacy fulfillment, follow-up
12 months after signature or earlier revocation
Captured signature preview Signature image will render here.
Awaiting signature signature_sha256: pending
signed_at: pending

Copy register

The signed state changes what the thread is allowed to say.

The simplest policy is to make the send guard aware of authorization state. Until signed, texts point to the portal. After signed, allowlisted templates can include medically specific terms.

Before authorization

  • Allowed: "Tap to review your secure care update."
  • Allowed: "Your clinician has a question in the portal."
  • Blocked: medication names, doses, diagnoses, lab values, allergy details, pharmacy instructions.
  • Link copy is neutral and tokenized.

After authorization

  • Allowed: "Dr. Kerr reviewed your tirzepatide transfer request."
  • Allowed: "Elite Care is preparing your 10 mg weekly dose."
  • Still blocked: non-template freeform PHI, unrelated marketing, unapproved clinical claims.
  • Revocation immediately returns the thread to pointer-only mode.

Artifact and data contract

The signature is not just UI; it produces a durable record.

Rails should treat this like a workflow artifact: immutable enough for audit, easy to retrieve for support, and explicit about which message policy changed.

Create

POST /api/v1/text_authorizations

Triggered when LinkQ detects that clear PHI copy would be useful. Rails creates draft authorization, mints token, and returns neutral link.

Render

GET /portal/authorizations/:token

Portal-bound token verifies phone, TTL, draft status, and document version. Page renders no unrelated patient history.

Sign

POST /portal/authorizations/:token/signature

Signature image is posted with acknowledgements. Server seals PDF, stores evidence, flips authorization state, and burns token.

Enforce

SendFilter.authorized_text_phi?

Outbound copy receives a per-patient policy decision before it leaves Rails or the LinkQ send path.

Record Fields to capture Why it matters
TextAuthorization patient_id, phone_hash, status, document_version, expires_at, revoked_at, signed_at Single source of truth for whether clear health terms are allowed in the thread.
Artifact pdf_key, signature_png_key, document_sha256, signature_sha256, generated_at Downloadable PDF packet for support, audit, counsel, and patient record access.
AuditLog actor, action, token_id, ip_hash, user_agent_hash, before_policy, after_policy Shows exactly when the message policy changed and why.
Event authorization.created, authorization.signed, authorization.revoked, text_policy.updated Lets the patient thread and support UI react without reading the PDF.
SupportMessage template_id, authorization_state, phi_classification, delivery_status Proves every outbound PHI-bearing message passed through the right policy state.

Team calls

Questions to settle before implementation.

These are the pieces that should be decided by product, counsel, and engineering before anyone treats the mock as a build spec.

Counsel language

Does this need to be a HIPAA authorization, a broader communication consent, or both in one short packet? Final language should be versioned before engineering starts.

Transport scope

Confirm whether the LinkQ/LinqApp BAA and iMessage leg support the desired post-signature copy. If not, keep pointer-only copy even after signature.

Revocation UX

Pick the revocation path: portal button, text keyword, support action, or all three. The send guard needs one authoritative state.

Signature provider

Choose custom Rails capture for speed or a third-party e-sign provider for stronger evidence workflows. The UI can stay nearly identical.

PDF rendering

Pick the generator in Rails: Prawn for deterministic server PDFs, or browser-rendered HTML to PDF if exact visual parity matters.

Demo posture

Decide synthetic, consented real patient, or hybrid by the demo data-posture gate. This prototype uses synthetic patient data only.