Open questions and assumptions

US-45 lists A/P but gives no task. We assumed it records payment notices and checks them against reconciliation. A/R follows reconciliation and claim status.

Today the admin can do everything. We drew read-only access for transactions plus full control of the admin consoles, so one person cannot configure the system and also submit. Say if that blocks anyone at go-live.

US-16 does not say. We assumed the insurance approval officer.

Today it is admin and operations. We also gave it to the approval officer and the claims officer, because they wait for answers.

We drew Viewer (read only) as the default, because a legacy read-only user must not gain create rights on mapping. The administrator can change anyone afterwards. Confirm it, or name another role.

The story asks for an allow, deny or limit rule but does not pick one. The wireframe limits an account to one session: the second sign in is asked to end the older session first. The policy screen has the setting.

The story says configurable. We show 20 minutes as the sample value, with a warning 2 minutes before.

It is the lowest priority, but US-10 and US-40 mention it as an option, so the sign in screens show it.

The author commented that US-19 (Vision Rx field definition) is not relevant to this scope and that US-22 (conditional section framework) could be deleted. No screens are drawn for them. The Clinical context screen still hides what does not apply to Optical requests (US-18). The real portal has a Vision Rx section, so it is drawn as a section with its fields, but the field-level rules of US-19 stay excluded.

We drew the first option: both cover every transaction type (eligibility, prior authorization, advanced authorization, claims, communications and payments), with a search that narrows as you type and a global search in the top bar. The other option is to correct the labels instead.

We assumed most users belong to one facility (Facility A), and the administrator, the auditor and a central A/R desk see several. US-45b allows a role at any level, so the lists show a Facility column and the top bar a facility switcher for those users. See question 24.

The story suggests FHIR Condition but leaves it open. The Integrations screen shows the feed status and the draft contract we assumed, so the clinical vendor can confirm it.

US-45 names six roles and the Roles screen ships nine: the six plus Viewer and Auditor, both read only (question 22), and a system-level Super admin for Data sources (question 32). If custom roles are wanted, the New role screen (clone a role, change its matrix) is drawn and only needs approval. If not, it is removed. Without custom roles, Viewer is still added as a fixed role and Auditor waits.

The backlog does not mention language. The real portal is English only. We drew a language choice on the profile as a question, not as a screen. Say whether Arabic is in scope.

The story title says six tabs. The real portal has five and the wireframe draws five, each with its completion check. Confirm five.

We drew it as forced: a user who has not enrolled is taken to enrollment, with no way around it. Each user also gets 10 recovery codes and an administrator can reset two-step sign in. Confirm that this matches the Microsoft Entra setup.

The story says the list is loaded and maintainable. We drew an administrator screen to load a release and retire codes. Say whether a vendor feed replaces it.

The backlog is silent. We assumed the request is saved, a banner says so, and RaneemHCP sends it when NPHIES is back. Submit becomes Save and send later. Confirm that is acceptable for claims.

We drew two paths: a public Request access page for people with no account, and an Ask for access button on the No access screen that lands as a security alert. Both are logged. Confirm administrators want these requests in the portal.

We assumed the last active administrator can never be deactivated or moved to another role. The user screen shows that state. We also drew a sealed break-glass account whose sign in raises an alert (OP-10). Confirm it, or drop it.

Examples: A/R and A/P, or reception and approvals in a small clinic. Recommended default: yes, several roles per user (OP-8). Administrator can never be combined with a transactional role.

They sit beyond the six in US-45 and extend questions 5 and 13. Recommended default: yes. Viewer is the go-live default for users nobody mapped. Auditor reads the audit log across facilities (OP-5).

Recommended default: the first release is self-confirm with a mandatory reason and a distinct audit entry. A second person above a threshold you set per facility comes in the second release. The override screens say so.

Recommended default: yes. Support subtree scope, a Facility column and filter, and a facility switcher in the first release, together with US-52b isolation (OP-9).

Recommended default: every 15 minutes, all day, with Poll now kept as a fallback (OP-4). Confirm the allowed rate on the NPHIES IG at portal.nphies.sa/ig.

Recommended default: A/P records and acknowledges payment notices, usually as a second role of the A/R person. Confirm the direction and meaning of PaymentNotice on the NPHIES IG (extends question 1).

Recommended default: yes, and it is logged (OP-2). A supervisor role is a second-release item.

Recommended default: CSV on every list in the first release (OP-6). Reports in the second release: billed, accepted and paid by payer and facility, ageing buckets 0 to 30, 31 to 60, 61 to 90 and 90 plus, and the top denial reasons.

Recommended default: the source wins for Import and for Use as storage, per entity, with every overwritten field logged. A per entity "portal wins" option is a second-release item. Confirm with the hospital IT team.

Recommended default: a per entity fallback setting. Patients and payers allow manual entry, flagged "not verified" and reconciled when the source is back. Service and price catalogue and diagnosis codes read the last imported copy and block new items that are not in it. Confirm which entities may be entered by hand.

Recommended default: with Use as storage the record stays in the hospital system and the portal keeps a reference key plus a short-lived cache that is not written to backups. With Import the copy lives in the portal database, inside Saudi Arabia, like every other record. Credentials sit in a vault (masked after saving, rotated by the Super admin), never in the portal database or in logs. Confirm the residency rule with the hospital.

Recommended default: yes, one extra role outside every facility. It sees only Home, Inbox, Profile, Data sources, Integrations, Security policy, Audit log and API access, never patient or claim data, and it is never combined with another role. The group Administrator reads the status and the Auditor reads the change trail. If you prefer no new role, the Administrator at group scope can hold these screens, at the cost of one role that can both manage users and change what patient data the portal uses.

A later item, not drawn now. Recommended default: the same screens in Arabic, mirrored with CSS logical properties and dir=rtl, with labels translated and technical terms (NPHIES, FHIR, claim ids) kept in English. Readex Pro already supports Arabic. Plan it after the English wireframes are signed off. Extends the earlier question about Arabic scope.