Privacy Policy

Wasfaty & Raqeem Assistant is a Chrome browser extension for physicians. On pp.wasfaty.sa and wasfatypp.moh.gov.sa it applies pre-saved medication order sets with a single click, automatically filling prescription form fields. On raqeem.anat.sa and moh.raqeem.sa it adds clinical helpers — lab-result trend graphs, cardiovascular-risk scores, ICD-10 screening-code buttons, a new-diabetes assessment note, and record-and-replay action macros. All order sets and macros are created and managed entirely by the physician using the extension's built-in interface.

The extension does not send patient-identifying information to the maintainer. Clinical processing normally stays in the browser, subject to the clinician-initiated referral and browser-provider sync paths described below. The optional maintainer-operated Magic-ID cloud sync (see "Cloud Sync & Sharing" below) is anonymous and code-based. Premium native plan-preference sync is a separate authenticated settings flow described in "Native Plan Preferences (Local First)" below; Premium activation is the limited maintainer data flow described in its own section below. The only content the extension processes for the Repeat feature is text the physician explicitly pastes in — see the "Repeat From Prescription History" section for full details.

• Patient-identifying information is not sent to or stored by the maintainer. On Raqeem, chart values and patient-bound Smart History drafts are held in the current tab's memory while the relevant chart is open. Do not put a patient name, ID, or other identifier into reusable text that you choose to save: the extension does not automatically detect or redact identifiers from that text.
• No browsing history is captured.
• No crash reports are collected.
• No account registration, no email address, no login is required or supported for the free tools. The two limited exceptions are optional Premium Access — activated by pasting an emailed code, not by creating an account — and its optional free trial, which asks for an email address once, only to verify it and prevent repeat trials (see "Premium Access" below).

On raqeem.anat.sa and moh.raqeem.sa the extension adds clinical helpers that read information already shown on the patient's chart so it can present it more usefully:

• Lab-result trends — reads the patient's cumulative lab table to draw trend graphs (e.g. HbA1c, kidney function, LDL, triglycerides).
• Cardiovascular-risk scores — uses lab values plus age and sex to compute standard risk estimates (PREVENT, Pooled Cohort Equations).
• Screening-code & assessment helpers — read age, sex, and chief-complaint context to offer the right ICD-10 screening codes and a new-diabetes assessment note.
• Action macros — replay click/typing steps you recorded yourself; recordings are redacted of patient values before being stored on your device.
• Smart History — reads the current patient's chart values and existing documentation, builds patient-bound drafts in tab memory, and writes only the sections you explicitly choose into Raqeem. Its Undo control can restore text only while the same guarded editor content is unchanged; it is not a guaranteed rollback of anything Raqeem has already saved to the chart.
• Smart Plans and native save actions — a plan runs only after your explicit action and requires one uniquely matched diagnosis already present in the current visit; if it is absent, add it yourself through Raqeem first. The explicit doctor action can choose a native catalog plan for that exact existing ICD-10 diagnosis. The native catalog is read through a same-origin request to Raqeem; catalog results and clinical context stay only in the current tab's memory, while the explicitly selected reference (including its plan name) is the only catalog label retained in the reusable preference. The clinical filters remain in effect. Unless you choose manual review, the guarded runner may then click Raqeem's native Update control once after verifying the staged plan. That is a save in Raqeem, not a background draft save by the maintainer.

Chart values and generated, patient-bound Smart History drafts are held in the current browser tab while you view that patient and are not sent to the maintainer. Writing a chosen draft changes Raqeem's own editor, and an explicitly run Smart Plan may invoke Raqeem's native save as described above. Reusable saved text is handled separately in "Browser Storage for Reusable Raqeem Text" below. Where a helper needs results that are not already on screen (for example older lab values for a trend), it requests them from Raqeem itself, within your own signed-in session — exactly the data the portal would show you in its own Lab view — and that exchange stays between your browser and Raqeem. Closing or navigating away discards those in-tab chart values and drafts. When one of these helpers is actually used (for example a lab-trend view is opened or a screening code is played), the extension sends the authenticated anonymous feature-name counter described below. The request carries the feature name plus the opaque device-session token used to prove it is genuine; it never carries any of the clinical values above. Separately, the extension may send the health-center name currently shown in Raqeem's own toolbar using the center-only anonymous credential described below.

Reusable text is not the same as a patient-bound draft:

• Saved Past History text: when you choose Custom and confirm the browser-sync notice, up to 20 entries of up to 2,000 characters each are stored in chrome.storage.sync. Chrome may upload them to the Google account signed into that browser and synchronize them to other Chrome devices. This is Chrome's service, not Wasfaty, Raqeem, Magic-ID, or the maintainer's cloud.
• Local reusable settings: custom examination options, saved Doctor Notes, Smart Plan exact-name mappings, and custom Smart Plans are stored in chrome.storage.local on the browser profile. Examination options are limited to 30 fields, 100 saved options total, and 300 characters per option. Smart History reads at most 30 saved Doctor Notes, with at most 120 title characters and 4,000 body characters each. Smart Plan mappings and custom plans are limited to clinic plan labels/codes, titles, ICD-10 codes, and review mode; custom plans are capped at 50.
• Account separation: all of these Smart History and Smart Plan stores use a one-way verifier for the signed-in Raqeem account. They are still extension data in the same browser profile, so use only a trusted profile and follow your organisation's shared-device rules. If older unscoped saved text exists, the extension asks before copying it into the current account's store and leaves the older copy untouched.
• No automatic redaction: free text you save is stored as entered, subject only to length and format limits. Never enter patient names, national IDs, contact details, or other patient identifiers in reusable saved text.
• Deletion: use × beside a saved Past History entry to commit its removal to the synchronized index; if later item cleanup fails, the extension reports that cleanup is pending and does not restore the deleted text. Browser sync is last-write-wins across devices, not a transaction, and the provider may retain copies under its own service terms. Use Reset for a taught Smart Plan mapping and Delete for a custom Smart Plan. Removing the extension clears its local extension data.

When you explicitly choose a native catalog plan for an exact ICD-10 diagnosis already present in the current Raqeem visit, the extension may remember that choice as a reusable account setting. The remembered record contains only the diagnosis code and native catalog reference (icd, planId, planCode, andplanName). It is not a diagnosis list, a visit history, a patient identifier, or usage history. Existing custom plans and teaching definitions are not automatically synchronized; only this remembered native reference can be synchronized. Do not type patient identifiers into reusable labels.

• Local first: records are account-separated in chrome.storage.local, with up to 200 remembered choices per Raqeem account. The native catalog request stays same-origin with Raqeem; catalog results and clinical context are kept only in the current tab's memory, while the explicitly selected reference label is retained in the preference and the clinical filters remain active.
• Optional Premium sync: if you choose it, the maintainer's Premium settings service uses an authenticated Premium device session together with a bound one-way Raqeem account verifier. The verifier alone is not a credential. That service receives only the reusable preference records — never credentials, native-catalog staff metadata, patient data, prescriptions, or chart values.
• Controls and availability: the settings controls provide a GET/export action and separate clear-local and clear-cloud actions. If the network fails, the local choice remains usable and its synchronization stays pending; this does not block the clinical application. Removing the extension clears the local copy but does not delete a cloud copy.

At a small number of specific facilities the extension offers referral helpers that pre-fill a referral form on your device. These helpers are only shown at the facilities that use them, and the physicians there are informed of the applicable data-handling terms directly. In all cases the extension itself stores nothing and never transmits any patient details to its maintainer; the referral details go only to the health authority or centre operating the referral form, exactly as a referral you fill out by hand would.

Starting 7 September 2026, usage pings are accepted only from an extension that already holds a valid server-issued device session created by Premium activation or a free trial. The request uses that opaque device token only to prove it is genuine. The analytics tables never store the token, activation code, account, email, or raw install identifier. Instead, the server stores an anonymous, date-rotating hash and counts each device session at most once per feature per Saudi day. Each ping contains a feature name; the single exception is the guideline-link-click ping, which also includes a sanitized source label (described below). No patient data or IP address is stored. The tracked features, grouped the same way the maintainer's dashboard groups them, are:

• Lifecycle
  • popup_open — the extension popup was opened.
  • set_created — a new custom order set was created.
• Order-set apply
  • apply — at least one medication from an order set was successfully applied to the prescription form (legacy counter, kept for installs that have not auto-updated).
  • apply_starter — the applied order set was one of the built-in starter sets.
  • apply_custom — the applied order set was one the physician created.
  • egfr_used — the eGFR-based renal-dosing tool actually adjusted at least one dose.
  • repeat_used — the Repeat-from-history picker was used to re-issue medications from a previous prescription.
• Cloud sync
  • sync_connect — a device connected to cloud sync by entering or generating a sync code.
• Picker engagement
  • picker_open — the in-page order-set picker was opened.
  • picker_close_under_5s, picker_close_under_30s, picker_close_under_2min, picker_close_under_10min, picker_close_over_10min — when the picker is closed, exactly one of these records only how long it was open (under 5 seconds, under 30 seconds, under 2 minutes, under 10 minutes, or over 10 minutes). Nothing about its contents is recorded.
• Ticker engagement
  • ticker_open — the in-page clinical-guideline / news ticker was opened.
  • ticker_close_under_5s, ticker_close_under_30s, ticker_close_under_2min, ticker_close_under_10min, ticker_close_over_10min — when the ticker is closed, exactly one of these records only how long it was open (the same duration buckets as the picker).
  • ticker_link_click — a link inside the guideline / news ticker was clicked. This is the only ping that carries an extra label: the source, i.e. the name of the publication or guideline body behind the link (for example "MOH" or "Guideline"). That label is sanitized to a short, bounded piece of text and stored only as an aggregate (source, date, count) — the actual link URL, the page you were viewing, and who clicked are never recorded.
• Raqeem clinical features
  • raqeem_macro_replay — a self-recorded action macro or built-in favorite was replayed.
  • raqeem_icd10_use — an ICD-10 screening-code button was used.
  • raqeem_vaccine_use — a vaccine dose entry was started from the vaccine helper.
  • raqeem_labs_view — the lab-trends view was opened.
  • raqeem_labs_note — the labs summary was inserted into a clinical note.
  • raqeem_cvrisk_use — the cardiovascular-risk panel was interacted with.
  • raqeem_newdm_use — the new-diabetes assessment fill was started.
  • raqeem_mchat_use — the M-CHAT screening fill was started.
  • raqeem_redflag_use — a red-flag screening line was inserted into a note.
  • raqeem_mammo_use — the mammogram referral helper was used.
  • raqeem_wellbaby_open — the well-baby guidance panel was opened.
  • raqeem_wellbaby_fill — a confirmed well-baby template fill was started.
  • raqeem_growth_open — the growth assessment was run.
  • raqeem_cbahi_check — the CBAHI documentation check was run. Only the click is counted: the checklist is computed on your device from the page you are viewing, and neither the note text nor any result is stored or transmitted.
  As with every counter above, each accepted ping carries only the feature name plus the opaque authentication token in its request header — never the patient being viewed, never any chart value, and never which codes or results were involved. The server assigns the Saudi date.
• Center-ping diagnostics
  • raqeem_center_diag_submitted — the anonymous center-presence signal was submitted.
  • raqeem_center_diag_toolbar_missing, raqeem_center_diag_facility_slot_missing, raqeem_center_diag_facility_anchor_missing, raqeem_center_diag_facility_label_rejected, raqeem_center_diag_identity_missing, raqeem_center_diag_network_failed — a coarse reason the center-presence signal could not be prepared or delivered. These counters never contain the center name, patient data, doctor identity, or page URL.
• Premium activation health
  • raqeem_premium_hook_silent — a device with active Premium Access ran a Premium Raqeem feature, but the extension could not observe any signed-in Raqeem account locally on that page (a sign that Raqeem's login flow may have changed). Carries only this fact and the date — never any account value, activation code, or identifier derived from them.
  • raqeem_premium_hook_silent_header_missing, raqeem_premium_hook_silent_wrapper_conflict — the same situation as the counter above, but the counter name records a coarse reason the account could not be observed locally: either routine Raqeem page activity carried no readable account marker, or another program on the page had replaced the browser's network functions. Like the counter above, each carries only this fact and the date — never any account value, activation code, or identifier derived from them.
  • raqeem_premium_activate_no_verifier — the Activate button was pressed on the Raqeem page but the extension could not observe any signed-in Raqeem account locally from any source (a sign that Raqeem's login flow may have changed in a way that blocks activation). Carries only this fact and the date — never any account value, activation code, or identifier derived from them.
  • premium_locked_modal_shown — the explanatory "this feature is part of Premium Access" window was shown. Carries only this fact and the date — never which feature, account, or code.
  • premium_net_failure_timeout, premium_net_failure_error — a Premium server request could not reach our server at all (for example, a clinic network blocking the connection). Because the server never saw that attempt, the extension stores a small marker on the device (only a coarse reason class — "timeout" or "error" — and nothing else) and sends it as one of these counters the next time the network works. Never a URL, activation code, account value, or error text.
  • premium_activate_bad_format — text pasted into the activation window was rejected on the device because it did not look like an activation code at all, so no activation request was sent to the server. If an existing valid device session is available, the aggregate counter uses that session only to authenticate; it never carries the pasted text, any part of it, an activation code, account, email, or country.
  • report_dialog_opened — the problem-report window was opened (whether or not a report was then submitted). Carries only this fact and the date.

You and your patients cannot be identified from the analytics rows. The aggregate daily totals are visible to the extension's maintainer through an unauthenticated /api/event/statsendpoint. These are verified Premium-device-session counts, not whole-population adoption figures. There is no per-doctor breakdown, because the device token and Premium account are not written to the analytics tables. This feature is gated by the apiBaseUrl setting in the extension's configuration — if the URL is not configured, no pings are sent and the extension makes zero network requests.

Note on rate limiting: to prevent abuse, the server maintains a short-lived, auto-expiring per-IP request counter solely for rate limiting. This counter is keyed by IP address but is never associated with any usage event and is automatically deleted when the rate-limit window expires (within one minute). No IP address is written to or retained in the usage-events database table.

Coarse country aggregate: at the moment a usage ping is received, the server resolves the request IP to a two-letter country code (for example "SA" or "AE") using an offline lookup, and the IP itself is then immediately discarded. The country code is added to a separate aggregate counter — a row per (feature, UTC date, country) with a running count — used solely so the maintainer can see whole- verified-session usage by region (for example, "34 applies in SA on 2026-05-08"). No per-doctor data is recorded, the IP is never written to the database, and the lookup is done locally on the server (no third-party geolocation service is called).

So the maintainer can see which health centers actively use the assistant (and support them accordingly), the extension sends the facility name that Raqeem itself displays in its own toolbar (for example "Alpha PHC - 12345") — at most once for each distinct center shown on a Raqeem page. This lets the count reflect a doctor who changes facility after login. This is a workplace label, not personal data: it names a building, never a doctor and never a patient. Free and Premium installs use a separate, cryptographically random credential issued by our server solely for this center-presence endpoint. It is not linked to a Premium account, doctor, patient, email, browser fingerprint, or raw install ID. The server stores only its one-way hash plus issue, last-seen, expiry, and optional revocation timestamps; expired records are removed, and reinstalling creates a new anonymous installation by default. The extension rotates the credential before its 90-day expiry. It cannot authorize feature telemetry or any other API action. Issuance is protected by the same temporary, auto-expiring per-IP rate limiting described above; the IP is not stored with the credential or in center analytics. The analytics table stores only (Saudi date, center name, daily-rotated anonymous hash) so it can count unique admitted installations per center per day. The hash rotates at midnight (Saudi time), so rows for the same credential cannot be linked across days from that table, and no doctor identity is recorded there. If the toolbar label cannot be read, nothing is sent.

So the maintainer can understand whether authenticated devices keep using the extension, the server derives an anonymous measurement value from the opaque device-session token already used to authorize each usage ping. This value:

• Contains no patient or hardware information. It is derived from a random server-issued token, not from a name, email, IP address, browser fingerprint, or device characteristics.
• Is stored only as a one-way hash. The raw token is validated against the separate device-session record but is never written to an analytics table or request log.
• Counts an authenticated extension session, not a person. Re-activation may replace the token and begin a new anonymous session. The analytics rows do not contain the Premium account or activation code.
• Is used only for aggregate counts — how many authenticated sessions were active in the last 28 days and what share returned after their first day. There is no per-doctor activity timeline; only three coarse dates per anonymous session (first seen, last seen, and last day a core feature was used) are kept.

This is the one place the extension keeps an identifier that is stable across days. It exists solely to produce aggregate authenticated-session retention numbers and carries no patient or device-hardware data.

Wasfaty enforces its own maximum prescription duration and refill limits for some medications, and these limits occasionally change on Wasfaty's side. So the maintainer can keep the extension's expected limits in step with what Wasfaty actually enforces, when the extension detects that Wasfaty applied a limit different from the one it expected it sends a single anonymous report. Each report contains only:

• The drug code (e.g. a Wasfaty medication code) — not a patient, not a prescription.
• Which limit changed — "duration" or "refill".
• The numbers — the value the extension expected, the value Wasfaty enforced, the unit (days/weeks/months or refill count), and whether the limit got tighter or looser.

These reports carry no patient data, no prescription, no dose, no user identity — only an aggregate "drug X now allows N" signal. The server keeps a running count per (drug code, limit type, observed value) so the maintainer can see which limits changed and how often, then aggregates them; nothing per-doctor is recorded. A report is sent at most once per limit per browser session, and uses the same anonymous install identifier header described above (which the server only ever stores as a one-way hash). This feature is gated by the same apiBaseUrl setting — if the URL is not configured, no reports are sent.

Live limit corrections: after reviewing these reports, the maintainer can publish a corrected limit for a drug back to the extension. On startup the extension fetches this small, non-personal list of published limits and uses it to keep its expected caps accurate. Nothing is auto-applied to any prescription — the physician still reviews and confirms every medication; published limits only adjust the value the extension pre-fills and the warnings it shows. The extension never silently learns or stores limits on its own; it relies only on these explicitly reviewed, server-published corrections.

To re-issue medications from a previous prescription, the physician opens the previous-prescription dialog in Wasfaty, copies its contents (Ctrl+A then Ctrl+C inside the dialog), and pastes them into the textarea inside the extension's floating panel, then clicks "Parse". The extension then extracts the medications from that pasted text. This is:

• Doctor-controlled input. The extension never silently scrapes any page. The only input it ever sees for this feature is what the physician explicitly chose to paste.
• Anchored to drug-code rows only. The pasted text is scanned for occurrences of "Code: NNNNNN-NNN-NNN". Anything that isn't anchored to such a code (patient header, doctor name, breadcrumbs, notes, totals) is silently ignored.
• Bounded per-drug windows. For each drug code, the parser looks at only a small window around the code (the same line for the drug name, and up to ~1500 characters after it for the dosing sentence). The rest of the pasted text is never processed.
• Whitelisted output. Each parsed entry contains only nine fields: drug code, sanitized drug name, dose amount, frequency count, frequency interval, frequency unit, duration, route, and refill count.
• Temporarily preserved within the same browser session. So that an accidental panel close does not lose your work, the textarea contents and the parsed picker state are kept in chrome.storage.session — a sandboxed, in-memory area that Chrome automatically clears when the browser is restarted. This temporary store is keyed per patient route so it never crosses between patients, auto-expires after 30 minutes of inactivity, and a "Clear paste" button drops it on demand. Nothing in this temporary store is ever transmitted off your device.
• Save is opt-in. The physician must explicitly click "Save as new set" and provide a name; only then are the nine whitelisted fields written to local storage. The patient's identity is never associated with the saved set.
• Nothing is transmitted. The extension makes no network requests at any step of this flow.

Before its helpers can be used, the extension shows a one-time physician responsibility declaration (one for the Wasfaty prescribing portals, one for the Raqeem EMR) linking to the Terms of Use and this policy. Your acceptance is recorded only on your own device in chrome.storage.local, as a small flag containing the declaration version and the date you accepted. It is never transmitted anywhere, carries no identity, and is removed when the extension is uninstalled.

The extension is free and every clinical and safety feature works for everyone. The one exception is a small set of optional convenience automations behind the paid Premium Access subscription (see the next section); all core features stay fully usable without it. The extension shows no donation reminders and fetches no fundraising content. Payments happen entirely off-product: the support page links to an external subscription platform (under its own terms). The extension, this website, and the maintainer's server never process, request, or see any payment or card data.

A few convenience automations are unlocked by an optional paid subscription called Premium Access. Activation sends the emailed code. If Premium is activated for Raqeem, it also sends a one-way identifier derived from the signed-in Raqeem account, solely to keep Raqeem Premium use with that account. Wasfaty-only activation does not require or send a Raqeem account identifier. No patient data, order sets, macros, or clinical activity are attached to it. No separate website account is required.

Technical and retention details

• For Raqeem Premium use, the extension hashes Raqeem's opaque internal account id locally. The raw id does not leave the browser; the resulting one-way value is sent when you press Activate. If an activation completed while account confirmation was temporarily suspended on the service side (a rare recovery mode), the extension sends the same one-way value once afterwards, at the next Premium use on Raqeem, to attach the account to that existing activation. This step does not apply to Wasfaty-only use.
• The service stores the activation state, the bound one-way account value, a one-way digest of the device token, and relevant expiry dates. Purchase and contact details supplied to the external payment platform may also be retained privately for code delivery, subscription administration, and refunds.
• Premium works on one activated browser profile at a time, so activating elsewhere disconnects the previous profile. Wasfaty-only and other identity-free activations are limited within a subscription period; a confirmed Raqeem switch using the already-bound account does not consume that Wasfaty-only cap. Normal extension updates and restarts do not ordinarily require reactivation.
• To diagnose activation problems and email-delivery failures, the service keeps short-lived technical records: for each activation attempt, the outcome plus a one-way fingerprint of the entered code (never the code itself unless it matched a real code), and for each failed email send, the failure kind and a sanitized reason. These records contain no patient data and are pruned automatically.
• No patient data, order-set content, macros, or clinical usage history is linked to Premium activation.
• Free trial: the optional 5-day trial asks for an email address from a major provider (such as Gmail, Hotmail, Outlook, Live, MSN, or Yahoo) and sends it a one-time verification code, plus a single reminder shortly before the trial ends. The trial is one-time: to enforce that, the service keeps one-way digests of the verified email, the install identifier, and — for Raqeem use — the same one-way account value described above. The email address itself is kept only for the reminder and is used for nothing else; the trial never asks for payment details.

The popup ("🚩 Report") and the Help page ("Report a problem") open a small form so you can tell the maintainer directly when something breaks or you have a complaint — separate from any Wasfaty, Raqeem, or Chrome Web Store channel.

• What is sent: the category you pick (bug / complaint / other), the free-text message you type, your email address, the extension version, and the UI language. The email address is required so the maintainer can reply to your report — it is used for nothing else.
• What is never sent: no device identifier, no install id, and no IP address is stored alongside a report. The form itself warns you not to include patient names, national IDs, or other identifying patient details — unlike every other data flow described in this policy, this one accepts free text, so please keep it limited to describing the problem.
• Where it goes and who sees it: reports are stored on the maintainer's server and reviewed only by the maintainer, for the sole purpose of fixing problems and improving the extension. They are never shared with Wasfaty, Raqeem, the Ministry of Health, or any third party.

The extension stores medication order sets and the reusable local Raqeem settings listed above using chrome.storage.local — sandboxed storage attached to the Chrome profile. Unless you separately enable a feature described in this policy, this local data:

• Never leaves your device.
• Is never synced to any server or third party.
• Contains the order-set fields and reusable settings or text you entered yourself.
• Can be cleared at any time by removing the extension.

The extension includes an optional cloud sync feature so a physician can keep their order set library consistent across multiple devices, and hand a snapshot of their templates to a colleague. This feature is off by default and only activates when the physician explicitly enters or generates a sync code in the extension popup. There is no account, no email, no password, and no third-party sign-in involved at any step. Two anonymous mechanisms are offered:

• Magic-ID sync code (cross-device library sync): click "Generate code" in the popup and the server returns a short alphanumeric code (e.g. WOLF-4821). That code becomes the key your library is stored under. Enter the same code on a second device to keep the two in sync — every local edit is pushed up after a short debounce, and the in-page picker's manual ⟳ button pulls down the latest. Anyone holding the code can read or push to the slot, so treat it like a password and only share it with the devices you control. There is no password recovery and no user identity attached — just the code.
• One-time 6-digit share code (snapshot hand-off): click "Share my sets" and the server returns a 6-digit code (e.g. 483-201) tied to a one-time snapshot of your current templates. The receiver enters the code in their own popup ("Redeem code") and the snapshot is imported as separate copies — their existing sets are never overwritten. Share codes auto-expire after 30 days.
• What is uploaded: only your order set templates — drug codes, dose amounts, frequencies, durations, routes, instructions, and the names you gave each set. Nothing else.
• What is never uploaded to Magic-ID: any patient identity, prescription history, eGFR/weight values, the contents you pasted into the Repeat parser, Smart History chart values or drafts, saved Past History browser-sync entries, or Smart Plan settings. This statement concerns the maintainer's Magic-ID order-set service; Premium native plan-preference sync is a separate authenticated settings flow described above, and Chrome browser sync is a separate provider flow.
• Where it lives: templates are stored on a server operated by the maintainer of this extension. They are not logged in the request logs and not associated with any user identity, only with the sync code or share code itself.
• Disconnecting: click "Disconnect" in the popup's Sync code panel to stop pushing/pulling on this device. Your local sets are kept untouched. The cloud copy under the code is also left in place so other devices using the same code keep working — there is no "delete this code" button because the code carries no identity to authorise such an action against. Cloud copies that go unused are pruned by a server-side expiry sweep.
• Reverting to fully offline: never enter a sync code (or disconnect after entering one), and the extension behaves identically to a local-only build — only the authenticated aggregate usage pings above leave the device when a valid device session is present.

The extension's direct service requests go to the maintainer's own server — no analytics SDKs, no CDN scripts. Chrome may separately handle saved Past History entries through chrome.storage.sync, and the Raqeem clinical helpers may additionally exchange data with the Raqeem portal you are already signed in to, as described above; that traffic never involves the maintainer.) The categories of requests to the maintainer's server are:

• Authenticated anonymous usage pings (active when the API URL is configured and the extension holds a valid server-issued device session): a small fire-and-forget POST to the maintainer's server when certain features are used. The request authenticates with the same opaque device token used for Premium status checks and contains a feature name — with the single exception of the guideline-link-click ping, which also includes a sanitized source label (the publication behind the link, never the URL or who clicked). Analytics tables store neither the token nor a Premium account, patient data, user ID, raw install ID, or IP address. See the "Authenticated Anonymous Aggregate Usage Counts" section above for the full list of tracked features.
• Sync code traffic (only when you have entered or generated a sync code): the extension pushes your local templates to the server's slot for that code after every local edit, and the in-page picker's ⟳ button pulls the latest down. See "Cloud Sync & Sharing" above.
• Share / redeem code traffic (only when you click "Share my sets" or "Redeem code"): a one-time POST to create a snapshot, or a one-time GET to fetch a snapshot.
• Premium native plan-preference traffic (only when you explicitly save, retrieve, or clear those settings): an authenticated request using the Premium device session and the bound one-way Raqeem account verifier. It carries only the reusable native catalog reference records described above; an offline failure leaves the local change pending and does not block clinical use.
• Premium activation and status (only for Premium subscribers): activation sends the emailed code and, for Raqeem Premium use, the one-way account value described above; Wasfaty-only activation does not send that account value. Later checks use only the opaque device token — with one exception: an activation completed while account confirmation was temporarily suspended sends the one-way account value once afterwards to complete that same account attachment.

The extension also fetches a small clinical-pearls / news ticker feed from the same server for the in-page guideline ticker bar; this contains no personal data in either direction. It likewise sends anonymous medication limit-change reports and, on startup, fetches the maintainer's published limit corrections (see "Anonymous Medication Limit-Change Reports" above) — both carry only drug codes and numeric limits, never any patient or prescription data. No third-party analytics SDKs, trackers, or CDN scripts are bundled with the extension.

The extension runs only on these sites: pp.wasfaty.sa and wasfatypp.moh.gov.sa (the official Wasfaty prescribing portals), raqeem.anat.sa and moh.raqeem.sa (the Raqeem EMR, for the clinical helpers described above), and a single Google Forms address used by a facility-specific referral helper — which it only pre-fills; it cannot read or write any other Google page. These permissions allow the extension to inject its panels and fill form fields on those sites. It does not operate on any other website. On Wasfaty it never silently scrapes the page — the Repeat feature only processes text the physician explicitly pastes in; on Raqeem it reads chart values on your device only, as described in "Raqeem Clinical Helpers."

No patient data is ever sold, and none is shared with the extension's maintainer or any analytics, advertising, or tracking service — there are no third-party trackers or SDKs integrated into this extension. Two user-controlled paths involve another operator: a referral you choose to submit goes to the health authority or centre operating that form, and reusable Past History text you choose to save may be handled by Chrome's browser-sync provider. Neither path sends that content to the maintainer. Because saved free text is not automatically redacted, do not put patient identifiers in it.

This extension is intended solely for licensed medical professionals. It is not directed at children and does not knowingly interact with anyone under 18.

If this policy is ever updated, the revised version will be published at this URL with an updated date at the top.

If you have any questions about this privacy policy or the extension, please reach out via the Chrome Web Store support page for Wasfaty & Raqeem Assistant, or use "🚩 Report a problem" in the popup or the Help page (see "Report a Problem" above).