Raneem IT
RaneemHCPPortal wireframes
Open the portal as
Choose a role
ADAdministratorRCReceptionistAOInsurance approval officerCOClaims officerARAccounts receivable (A/R)APAccounts payable (A/P)VWViewer (read-only)AUAuditor (read-only)SASuper admin
Start at sign in

Backlog coverage

All 60 user stories of the RaneemHCP Backlog (v1.0, Hadeel AlShahry). Each one is on a screen, marked as having no screen, or excluded with the author's comment. 214 screens carry them, 600 states in all (the reviews added screens for sign in recovery, system pages, drafts, account tools, administration and the work queues). The last sections list the 11 operational additions and the 8 data sources items, which are not in the backlog.

On existing screens
33
the portal has the screen, the story changes it
New screens
24
the portal has no such screen today
No screen or design only
1
behaviour, tests, documents
Excluded
2
the author asked to remove them
Planned later: Arabic RTL. Arabic with right-to-left layout is planned for later. It is not a screen and is not drawn here. See the open question Arabic and RTL.
Story What it asks for Status Where to see it
US-09aHIGHEST APA Polling Without Bundle Reference (TC-AUTH-010)As the system, I need to poll NPHIES for payer-initiated Advanced Prior Authorizations without a reference Bundle ID, so payer-issued APAs are retrieved successfully.
Acceptance criteria
  • Given a payer has issued an APA with no prior request from us, when Poll NPHIES runs, then the APA is retrieved and appears in the Advanced Auth module.
  • Given the poll runs without a bundle reference, when NPHIES returns results, then the system correctly parses and links the APA to the correct patient/provider without requiring a pre-existing internal reference.
  • Given the APA exists, when a communication or cancellation/change is sent against it, then the related change reflects correctly.
 On existing screens

Advanced authorization Advanced authorization detail APA communication
US-01HIGHEST Automate Financial FieldsAs a claims processor, I want the system to auto-calculate Net Amount from Quantity and Unit Price, so I don't manually reconcile totals.
Acceptance criteria
  • Given Unit Price and Quantity entered, when the line is saved, then Net Amount = Quantity × Unit Price (auto-calculated, read-only).
  • Given a mismatch is detected, when the user attempts to submit, then the system displays a clear inline error identifying the discrepancy amount.
  • Test-restricted auto-calc fields enabled; editable only for confirmed exceptions.
  • Manual overrides flagged distinctly in the audit trail.
 On existing screens

Services Services Audit entry
US-02HIGHEST Net Amount Calculation LogicAs a claims processor, I want Patient Share + Payer Share validated against Net Amount, so that submissions aren't rejected for inconsistent totals.
Acceptance criteria
  • Given Patient Share and Payer Share are entered, when both are populated, then the system validates their sum = Net Amount within 0.01 SAR and blocks save on mismatch.
  • Given a mismatch, when the user attempts to submit, then a clear inline error identifies the discrepancy amount.
  • Given only one share is entered, when saved, then the system calculates the other.
 On existing screens

Services Services
US-03HIGHEST Linking ID StandardizationAs the system, I want cross-request links to always use the NPHIES Response ID (never the internal or bundle ID), so that linked requests resolve correctly and pass NPHIES validation.
Acceptance criteria
  • Cross-request links store the NPHIES Response ID, never internal/bundle ID.
  • Related-claim references tie to the original response's Response ID.
 On existing screens

Case timeline Authorization result Follow-up authorization Amend authorization Claim detail Resubmit claim Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Resubmit claim Resubmit claim Resubmit claim Resubmit claim
US-04HIGHEST NPHIES ID TraceabilityAs a support/functional user, I want the full NPHIES ID chain visible on each request, so that I can trace a request end-to-end when troubleshooting.
Acceptance criteria
  • Internal Req ID, NPHIES Req ID, Response, Response ID all visible per request.
  • Queued requests show "Pending," not blank/error.
  • Copy-to-clipboard on each ID.
 On existing screens

Inbox Notification centre NPHIES is not answering Case timeline Eligibility Eligibility result Prior authorization Authorization result Advanced authorization detail Claims Claim detail Batch result Payment notices Payment notice Reconciliation detail Messages Communication detail Status checker Task history NPHIES outbox Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Eligibility result Eligibility result Eligibility result Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker
US-05HIGHEST Service Date ValidationAs a user submitting eligibility or claims, I want the system to require a Service Date or Start/End range, so that my request isn't silently rejected by NPHIES.
Acceptance criteria
  • Service Date and Start/End both blank → hard-block with inline error.
  • Either completed to proceeds.
  • No previously-passing test case regresses.
 On existing screens

Purpose Claim setup
US-06HIGHEST Newborn Data IntegrityAs a user submitting a newborn request, I want all NPHIES-required newborn and mother fields captured and validated on-screen, so that my request doesn't fail server-side after I've marked the step complete.
Acceptance criteria
  • Dedicated DOB on Newborn step, or clear inline cross-reference to Patient Info DOB.
  • 90-day rule shown as inline help, not only a late blocking error.
  • Newborn details appear in Review.
  • All 7 NPHIES-required Mother fields marked required (*) and validated client-side before Continue.
  • Post-fix, a real newborn submission reaches a determinate NPHIES outcome.
 On existing screens

Newborn Review and submit Newborn and circumstances Review and submit Newborn and circumstances Review and submit
US-08HIGHEST Facility Type ValidationAs a provider user, I want to be warned if I enter a Facility Name without a Facility Type, so that my request isn't silently rejected by NPHIES.
Acceptance criteria
  • Given a user enters a Facility Name and leaves Facility Type blank, when they attempt to continue, then the system displays an inline warning/error requiring Facility Type.
  • "Facility Type (optional)" label corrected to conditional-required.
  • Both fields shown in the Coverage Review card.
  • Given both fields are completed, when the request is submitted, then no NPHIES rejection occurs for this reason.
 On existing screens

Provider Coverage Review and submit Insurance and coverage Review and submit Insurance and coverage Review and submit
US-09HIGHEST Care Team Submission GuardAs a claims submitter, I want the system to block progression when the Care Team step has zero members, so that I get a clear error immediately instead of a confusing empty picker later.
Acceptance criteria
  • Professional/Institutional/Dental-Oral + 0 members + Continue → hard-block.
  • ≥1 member → Services picker behaves as today.
  • Review with 0 members → Care Team card shows "Required, no data entered."
  • Pharmacy/Vision/Predetermination handled per their own rules (QA confirms Vision/Pharmacy).
 On existing screens

Care team Review and submit Care team Review and submit
US-09bHIGH - SHIP WITH US-09 Care Team Cascading Dead-EndAs a claims submitter, I want the per-service Care Team picker to guide me back to add a member when none exist, so that I'm not stuck in an unrecoverable dead-end.
Acceptance criteria
  • Care Team empty → each Service line's Care Team picker disabled with "Add Care Team in Step 6 first."
  • ≥1 member → pickers populate normally.
 On existing screens

Care team Services Care team Services
US-10HIGHEST 2FA Login (Microsoft) + Auto-UnlockAs a portal user, I want to log in using Microsoft Authenticator or email OTP, so my account is protected beyond a password.
Acceptance criteria
  • Given a user has Multi-Factor Authenticator enrolled via Microsoft Entra, when they log in with correct credentials, then they are prompted for Authenticator approval or email OTP before access is granted.
  • Given a user fails MFA 5 times, when the 5th attempt fails, then the account is temporarily locked per security policy. Auto-unlock after 15 min.
  • After auto-unlock and another 3 failed attempts within 24 hours, account is temporarily locked for admin to unlock. (full admin-unlock go to US-54).
  • Given MFA is enabled, when an existing user without enrollment logs in, then they are forced through enrollment before proceeding.
 New screens

Sign in Confirm it is you Enter your email code Set up Microsoft Authenticator Save your recovery codes Use a recovery code Lost your phone? Session and sign in
US-40HIGHEST Password Reset from Login with 2FAAs a portal user, I want to reset my password from the login screen using 2FA, so that I can regain access securely without contacting an admin.
Acceptance criteria
  • "Forgot password" on login → identity verified via 2FA (Authenticator/email OTP) before reset.
  • Reset link/flow expires after a defined window.
  • Successful reset forces re-login; old password invalidated.
 On existing screens

Forgot your password Verify before you reset Choose a new password Password reset successfully
US-51HIGHEST User Profile ScreenAs a portal user, I want a profile screen to view my email and organization and change my password, so that I can manage my own account.
Acceptance criteria
  • Authenticated user can open a Profile screen (none exists today).
  • Profile shows own email + associated organization.
  • User can change own password from Profile (current-password re-entry required).
  • Email edit is admin-only (view-only for the user). see US-53 for admin path.
 New screens

Profile Where you are signed in Recent sign ins Notification settings Change password
US-41HIGHEST Session ManagementAs a portal user, I want my session to time out after inactivity and fully end on logout, so that my account can't be accessed from an unattended or stale session.
Acceptance criteria
  • Inactive session times out after a configurable period → re-auth required.
  • Concurrent-session rule defined (allow/deny/limit).
  • Logout fully invalidates the session token.
 New screens

Sign in You were signed out You are signed out Another session is open Where you are signed in Session and sign in
US-56HIGHEST Password PolicyAs an administrator, I want enforced password complexity, expiry, and reuse rules, so that user accounts meet security standards.
Acceptance criteria
  • Enforce complexity rules (length:min 8 characters, character mix: special char, number, capital & small letter) on set/reset.
  • Optional expiry window configurable.
  • Reject reuse of the last 3 passwords.
 New screens

Sign in Choose a new password Replace your temporary password Your password has expired Change password Password policy
US-13HIGHEST Audit Logging (base)As a compliance/admin user, I want user actions logged, so that we have traceability for regulatory and internal review.
Acceptance criteria
  • Submit/edit/approve → log entry with user, timestamp, action, record ID.
  • Filter by user/date/action within agreed SLA.
  • Financial overrides (US-01) logged distinctly. (Role/permission-change auditing extends this in US-13b)
 New screens

Audit log Audit entry
US-44HIGHEST Org Hierarchy as Configured DataAs an administrator, I want organization entities (group, legal entity, facility, department) available as records, so that roles and users can be associated with the right part of the organization.
Acceptance criteria
  • Org entities (group, legal entity, facility, department) exist as records roles can reference.
  • Shallow/flat structure sufficient for BETA (for inheritance engine see US-44b).
  • Seed the demo org tree for client presentations.
 New screens

Organization structure
US-45HIGHEST RBAC: Named Roles + CRUD MatrixAs an administrator, I want named roles with enforced CRUD permissions, so that each user type can only perform the actions appropriate to their job.
Acceptance criteria
  • Ship named roles: admin, receptionist, insurance approval officer, claims officer, A/R, A/P.
  • CRUD permissions per role enforced on module actions (create/read/update/delete gated per role).
  • A user's role determines which modules/actions are visible and permitted.
  • Buttons/actions scope only (for row-level data isolation see US-52b).
 New screens

No access to this area Roles and permissions New role Edit role Security alerts
US-46HIGHEST User Migration + Default-Role AssignmentAs an administrator, I want all existing users assigned a role when RBAC goes live, so that no one is locked out at rollout.
Acceptance criteria
  • Every existing user assigned a role at RBAC go-live, no lockouts.
  • A safe default role defined for unmapped users.
  • Migration is reversible/auditable.
 New screens

Roles and permissions Assign roles to existing users
US-52aHIGHEST Data-Scoping Design + Org-Node StampingAs the system, I want every record stamped with its originating org-node and a data-scoping model designed, so that row-level isolation can be enforced later without a data retrofit.
Acceptance criteria
  • Design the row-level scoping model (deferred enforcement to US-52b).
  • Every record stamped with its originating org-node from now on.
 New screens

Organization structure Data scope and isolation
US-49MEDIUM Settings Admin Console (basic)As an administrator, I want a settings console for role management and organization definition, so that I can configure access and org structure in one place.
Acceptance criteria
  • Settings expanded beyond Org-only: role management + org definition surfaces.
  • High-impact org-wide saves get a confirmation dialog before commit.
  • Reporting groups + deep org config deferred to US-49b.
 New screens

Organization settings
US-14HIGHEST Pre-Auth Result Page FixesAs a provider user, I want the Pre-Auth Result page to clearly show Approved amount, Patient Share, and Outcome, so I understand the payer's decision without guessing.
Acceptance criteria
  • "Approved" displays the confirmed Net Amount from the payer response (not blank/zero).
  • Patient Share is visibly displayed, sourced directly from the NPHIES response payload.
  • Given any outcome (Approved/Partial/Denied/Error), when displayed, then the Outcome text matches the actual NPHIES response status - no default/placeholder text.
 On existing screens

Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result
US-15MEDIUM Patient-Form SegregationAs a user working across Eligibility, Pre-Auth, and Claims, I want a consistent patient-intake structure and required-field rules, so that I don't have to relearn the form per module.
Acceptance criteria
  • All three modules use the same patient-intake step structure.
  • Marital Status/Occupation required-status standardized across modules.
  • No regression in any module.
 On existing screens

Patients Patient identity Demographics Circumstances Patient identity Newborn and circumstances Patient identity Newborn and circumstances
US-16MEDIUM Pre-Auth Validity WindowAs a provider user, I want the system to enforce the 2-week pre-auth validity window, so that expired authorizations are flagged and can be extended correctly.
Acceptance criteria
  • 2 weeks elapsed without extension must show as Expired.
  • Extension request results in real-time reset with new service date.
  • Near-expiry requests to show highlighted as "Expiring Soon."
 On existing screens

Work queues Prior authorization Authorization result Extend authorization Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Extend authorization Work queues Work queues Work queues Work queues Work queues Work queues
US-18MEDIUM Optical/Vision Conditional DisplayAs a user submitting an Optical/Vision request, I want irrelevant Clinical Context fields hidden, so that I only see fields that apply to my request.
Acceptance criteria
  • Vision/Optical type shows only applicable Clinical Context fields render.
  • Other types unchanged.
 On existing screens

Clinical context Vision Rx
US-19MEDIUM Vision Rx Field DefinitionAs a user submitting a Vision prescription, I want mandatory and optional Vision Rx fields correctly defined and mapped to NPHIES, so that my prescription data isn't rejected.
Acceptance criteria
  • Mandatory/optional Vision Rx fields marked/validated per NPHIES IG.
  • Submitted Vision Rx maps to NPHIES per confirmed list.
 Excluded by the author

Review comment from Hadeel Alshahry: I think this needs to be removed and not considered in this scope because it does not seem relevant. No screen is drawn. See the open questions.
US-21MEDIUM Cross-Module Field StandardizationAs a user, I want consistent field names and behavior across modules, so that the system is predictable and easier to use.
Acceptance criteria
  • Differently-named shared fields standardized to one label.
  • UI-only. no backend/API change.
 On existing screens

Patient identity Demographics Prior authorization setup Patient identity Claim setup Patient identity New payment notice

Design system page
US-23HIGHEST Advanced Auth Coverage DisplayAs a user, I want insurance/coverage information displayed on the Advanced Auth record, so that I can see coverage details already retrieved from NPHIES.
Acceptance criteria
  • APA record with coverage data displays insurance/coverage info on detail view.
 On existing screens

Advanced authorization detail
US-32HIGH Claim Batch Submit ConfirmationAs a claims submitter, I want a confirmation step before submitting a claim batch, so that I don't send an irreversible bulk submission by mistake.
Acceptance criteria
  • Confirmation step listing per-claim validation status just before submitting batch.
  • Invalid claims flagged before send.
  • Confirm → sends; Cancel → returns unchanged.
 On existing screens

Claim batch Confirm batch submission
US-57HIGH Batch Size Validation (min 2, max 200)As a claims submitter, I want the system to enforce the batch size limits, so that my batch doesn't fail on submit for an invalid count.
Acceptance criteria
  • Fewer than 2 claims → Submit disabled with inline hint "A batch needs at least 2 claims."
  • Disable adding more than 200 claims to the batch, once the batch reaches 200 claims block adding more with a max-size alert message.
  • 2 to 200 claims → proceeds without a size failure.
 On existing screens

Claim batch
US-33HIGH Poll NPHIES State BugAs a user polling NPHIES, I want a clean, accurate poll state, so that I don't see a stale success and a failure at the same time.
Acceptance criteria
  • New poll attempt clears the prior result block before rendering.
  • "Last polled at" timestamp shown.
  • Failed + success blocks never render simultaneously.
 On existing screens

Home Inbox Poll NPHIES
US-42MEDIUM Diagnosis Code Dropdowns (ICD-10)As a user entering a diagnosis, I want searchable ICD-10 code pick-lists, so that I select valid codes without free-text errors.
Acceptance criteria
  • Diagnosis fields use searchable ICD-10 pick-lists (no free-text codes).
  • Standard ICD-10 set loaded and maintainable.
 On existing screens

Diagnoses Clinical context ICD-10 codes
US-43MEDIUM Basic Performance ChecksAs a user, I want the system to handle a 200-claim batch and large attachments without failing, so that high-volume operations work reliably.
Acceptance criteria
  • A 200-claim batch submits without functional failure.
  • Large document attachments upload/attach within accepted limits.
  • Functional-level only; full load/stress test is US-48.
 On existing screens

Supporting info and links Supporting info and links Batch result Basic performance checks
US-17MEDIUM API Discovery & ScopingAs the PM, I want a documented API scoping spec from workshops with the team, so Production API build has clear requirements.
Acceptance criteria
  • Workshops with Tech Leader to produce a spec: push vs. pull, target entities, auth model, rate limits, per the 3 named families (reception/eligibility, finance/payment/claim, diagnosis/doctor).
  • Spec explicitly confirms whether endpoints beyond the 3 named families are required.
  • Signed off by CEO before Production API build begins.
 On existing screens

API documentation API scoping spec
US-12HIGHEST API Security FrameworkAs a platform owner, I want a secure authentication/authorization layer for third-party clients, so that external systems can only access data they are explicitly scoped for.
Acceptance criteria
  • Provisioned client gets OAuth2 credentials or scoped API key per the US-17 spec.
  • Missing/invalid credentials → error code 401/403, no data.
  • Admin can revoke client’s access in near-real-time. An administrator can switch the API credentials off.
 New screens

API access Add API client API client
US-50HIGHEST API Security: Per-Endpoint ScopingAs a platform owner, I want each API endpoint family to have its own scope profile, so that clients only access the specific data they're authorized for.
Acceptance criteria
  • Each endpoint family (reception/finance/diagnosis) carries its own scope profile.
  • Out-of-scope entity request → rejected even with valid credentials.
  • Scope profiles reviewed against data-sensitivity per family.
 New screens

Add API client API client
US-27aHIGHEST API Endpoints: First Family (Reception/Eligibility)As a client integration, I want the first prioritized endpoint family exposed, so that we validate the build approach before scaling to other families.
Acceptance criteria
  • First prioritized family works per documented push/pull direction.
  • Valid scoped credential → response matches spec exactly.
  • Invalid push payload → clear validation error, not a 500.
 New screens

API documentation
US-27bHIGHEST API Endpoints: Remaining Families (Finance, Diagnosis)As a client integration, I want the remaining endpoint families exposed, so that clients have full API coverage.
Acceptance criteria
  • Finance/payment/claim + diagnosis endpoints follow the US-27a pattern.
  • Consistent behavior/error-handling across all endpoints.
  • Full API documentation finalized for a pilot client.
 New screens

API documentation
US-47MEDIUM Inbound Diagnosis Integration (vendor-agnostic)As a clinical/reception user, I want diagnosis data pulled from our clinical system into RaneemHCP, so that I don't re-enter diagnoses manually on the NPHIES-integrated system.
Acceptance criteria
  • RaneemHCP accepts diagnosis data pushed from an external clinical system (WeCare or other) into the diagnosis page, reducing manual re-entry.
  • Input contract defined (probably we will consider FHIR Condition-but to investigate further).
  • integration remains vendor-agnostic.
 New screens

Integrations
US-44bHIGHEST Org Hierarchy Deep EngineAs an administrator, I want a full organizational hierarchy with inheritance (Group→Legal Entity→Facility→Department), so that roles and permissions can be assigned and inherited across the org structure.
Acceptance criteria
  • Full model with inheritance.
  • Departments extensible (X-ray, consultation/doctors, ER/examination, operation, lab, nurse station…).
  • Roles can be assigned at any level, inheriting downward.
 New screens

Organization structure
US-45bHIGHEST RBAC Scoped Per Org LevelAs an administrator, I want permissions to resolve per role and per org node, so that a user's access is limited to the correct organizational scope.
Acceptance criteria
  • Permissions resolve per role and per org node (e.g., claims officer at Facility A only).
  • Uses the US-44b hierarchy for scope resolution.
 New screens

Edit role
US-52bHIGHEST Row-Level Enforcement + Facility IsolationAs a security/compliance owner, I want row-level data isolation enforced by org node, so that users can only see records belonging to their facility/subtree.
Acceptance criteria
  • Users see only records within their org node/subtree (uses US-52a stamping).
  • A facility user cannot view another facility's patients/claims.
  • Verified by logging in as a facility-scoped user and confirming isolation.
 New screens

This record belongs to another facility Data scope and isolation
US-53HIGHEST Admin: Create User + Temp Password + Forced ChangeAs an administrator, I want to create users with a temporary password and forced first-login change, so that new accounts are onboarded securely.
Acceptance criteria
  • Admin creates a user; system issues a temporary password (never plaintext-stored).
  • Forced password change on first login.
  • Admin can edit a user's email (the admin-only path referenced by US-51).
 New screens

Replace your temporary password Request access Add user User detail
US-54HIGHEST Account Lockout + Admin UnlockAs an administrator, I want the ability to manually unlock accounts, so that locked users can be recovered under control.
Acceptance criteria
  • Lockout policy: threshold (failed attempts before soft-lock): 5, Lock duration (auto-unlock): 15 mins, Counter Reset: after every successful login.
  • Admin can manually unlock a locked account.
  • Given an account soft-locks 3 times within 24 hours, when the 3rd lock occurs, then it becomes a hard lock requiring admin unlock (no auto-unlock).
  • Given a hard lock or a suspicious pattern (multiple accounts locking, or one account from many sources), when detected, then an admin is notified via in-app alert and email.
  • Given a hard lock, when the admin reviews it, then the failed-attempt history (from the audit log) is visible to support the decision.
 New screens

Sign in Recent sign ins Users User detail Locked accounts Lockout policy Security alerts
US-55HIGHEST Deactivate (not delete) UserAs an administrator, I want to deactivate rather than delete users, so that account history is retained for audit while access is revoked.
Acceptance criteria
  • Users deactivated, not hard-deleted; history retained for audit.
  • Deactivated users cannot authenticate.
 New screens

Sign in Users User detail
US-13bHIGHEST Audit Extension: Role/Permission ChangesAs a compliance/admin user, I want role and permission changes logged, so that we can audit who changed whose access and when.
Acceptance criteria
  • Role assignments and permission changes logged (who/what/when).
  • Org-settings changes (US-49) captured in the audit trail.
 New screens

Edit role Audit log
US-49bMEDIUM Settings: Reporting Groups + Deep Org ConfigAs an administrator, I want reporting groups and deep org configuration in settings, so that I can support grouped reporting and full hierarchy management.
Acceptance criteria
    		New screens

    Reporting groups
    US-27cHIGHEST API Integration Testing (Pilot Client)As the platform team, I want at least one pilot client integrated end-to-end, so that the API is validated against real third-party usage before broad rollout.
    Acceptance criteria
    • Pilot client completes ≥1 full push/pull cycle with no platform-side errors.
    • Issues triaged/fixed before PI-3 closes.
    • Serves as reference case for future onboarding.
    		 On existing screens

    Pilot client
    US-48HIGHEST Full Load/Stress TestAs the platform team, I want full load and stress testing at target volumes, so that we confirm performance under production-scale data before go-live.
    Acceptance criteria
    • 200-claim batches, large attachments, and high record volumes tested under concurrent load.
    • Response times and error handling within agreed thresholds.
    • Bottlenecks identified and remediated or logged.
    		 On existing screens

    Load and stress test
    US-20MEDIUM Related Requests TraceabilityAs a provider user, I want related requests shown on the Pre-Auth Result page, so that I can see linked requests without manual lookup.
    Acceptance criteria
    • Pre-Auth Result shows a Related Requests section (via US-03 linkage) with type/status/link.
    • None exist → "No related requests" shown, not hidden.
    • Click → opens the record directly.
    		 On existing screens

    Case timeline Authorization result Claim detail Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail
    US-22MEDIUM Conditional Section Visibility FrameworkAs a developer/administrator, I want a reusable framework to show/hide sections by request type, so that conditional visibility doesn't require one-off fixes per module.
    Acceptance criteria
    • Section marked conditional on request type → doesn't render for other types.
    • Can retroactively replace the US-18 one-off without behavior change.
    • Config-driven, new types need no custom code.
    		 Excluded by the author

    Review comment from Hadeel Alshahry: Maybe delete it. No screen is drawn. See the open questions.
    US-25MEDIUM Passport Country RegroupingAs a user entering claims patient identity, I want Passport Country grouped with Identity fields, so that related fields are together.
    Acceptance criteria
    • ID Type = Passport → Passport Country sits with Identity, not Contact.
    • UI-only; consistent with the US-15 structure, no regression.
    		 On existing screens

    Patient identity
    US-34LOW Worklist/Patient History ScopeAs a user, I want the Worklist and Patient History to cover all transaction types (or the labels corrected), so that "all transactions" is accurate.
    Acceptance criteria
    • Worklist + Patient History extended to Advanced Auth, Payments, Communications, or copy corrected to actual scope.
    • Dynamic search bar
    		 On existing screens

    Search Worklist Work queues Patients Patient history Eligibility Work queues Work queues Work queues Work queues Work queues Work queues
    US-30LOWEST Email OTP (Secondary 2FA)As a portal user, I want Email OTP as an alternative second factor, so that I can use 2FA without the Authenticator app.
    Acceptance criteria
    • Email OTP option at login.
    • Expired code → clear "request new code" message.
    • Additive to US-10, Authenticator OTP unchanged.
    		 New screens

    Enter your email code Session and sign in
    US-26LOWEST Soft Workflow SequencingAs a user, I want optional non-blocking guidance to the next logical module, so that the workflow is clearer without being forced.
    Acceptance criteria
    • After Eligibility → non-blocking suggestion to proceed to Pre-Auth for same patient.
    • Ignoring it blocks nothing.
    		 On existing screens

    Home Work queues Eligibility result Eligibility result Eligibility result Eligibility result Work queues Work queues Work queues Work queues Work queues Work queues
    US-24LOWEST Org Type Field RelocationAs an administrator, I want the Org Type set once in Org Settings rather than per request, so that it's not re-entered every time.
    Acceptance criteria
    • Org Type removed from Provider step, added to Org Settings.
    • Provider step keeps only relevant checkboxes.
    • Submissions pull Org Type automatically.
    		 On existing screens

    Provider Prior authorization setup Claim setup Organization settings
    US-35LOW Read-Only Module BannersAs a user, I want a clear receive-only banner on read-only modules, so that I understand why there's no Create action.
    Acceptance criteria
    • Advanced Auth + Payment Reconciliation show a receive-only banner explaining no Create path.
    		 On existing screens

    Home Advanced authorization Payments Reconciliation history Reconciliation exceptions
    US-37LOW Communications 6-Tab LoadAs a user, I want per-tab completion indicators and visible linked-record context in Communications, so that composing a message is less awkward.
    Acceptance criteria
    • Per-tab completion checkmarks added.
    • Linked-record context visible while composing.
    		 On existing screens

    Communications Messages Send communication Communication detail
    US-38LOW Wizard NavigabilityAs a user filling long wizards, I want to save a draft and resume, plus jump between completed steps, so that I don't lose work on long forms.
    Acceptance criteria
    • Persistent step indicator with jump-to-completed-step.
    • Save-as-draft + resume across Eligibility, Pre-Auth, Claims.
    • No partial submission to NPHIES from a draft.
    		 On existing screens

    Home Work queues Eligibility Eligibility drafts Purpose Patient identity Newborn Demographics Circumstances Provider Payer Coverage Review and submit Prior authorization Prior authorization drafts Prior authorization setup Patient identity Newborn and circumstances Insurance and coverage Clinical context Vision Rx Care team Diagnoses Services Supporting info and links Review and submit Follow-up authorization Claims Claim setup Patient identity Newborn and circumstances Insurance and coverage Clinical context Care team Prescription (pharmacy, vision) Services Supporting info and links Review and submit Send communication Work queues Work queues Work queues Work queues Work queues Work queues
    US-36LOWEST Terminology StandardizationAs a user, I want consistent terminology across the app, so that the same concept isn't labeled differently in different places.
    Acceptance criteria
    • "Preauth" vs "Prior Authorization" (and similar) standardized app-wide via a glossary pass.
    		 Design system

    Design system page

    Operational additions for the first release

    Not in the backlog. They come from an operational review of how a hospital insurance desk really works, and they reuse existing screens as states, with one new queue screen. OP-1 to OP-10 are first release (P1). OP-11 is drawn as an option for the second release.

    Item What it asks for Status Where to see it
    OP-1P1, not in the backlog Role work queuesAs a desk user, I need named queues for my role with an ageing column, so I see what to do next without searching.
    Acceptance criteria
    • Queues: Ready to bill, Rejected, Expiring soon, Payer questions, Queued, My drafts. Each shows the days since service, submission or rejection.
    • Home tiles open the queue for the role. Counts match the list.
    • Queues are shared inside the role and the facility. A queue can be filtered to My work.
    		 Drawn New screen

    Home Worklist Work queues Work queues Work queues Work queues Work queues Work queues Work queues
    OP-2P1, not in the backlog Case owner, assign and take overAs a desk user, I need a case to have an owner I can change, so work does not get stuck when someone is absent.
    Acceptance criteria
    • A case shows its owner, or "No owner".
    • A colleague of the same role and facility can Assign to someone or Take over. Each is logged.
    • Deactivating a user shows their open drafts and cases and asks who takes them over.
    		 Drawn

    Work queues Case timeline Authorization result Claim detail User detail Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Work queues Work queues Work queues Work queues Work queues Work queues
    OP-3P1, not in the backlog Internal case notesAs a desk user, I need to leave a note on a case that stays inside RaneemHCP, so the next person knows what was tried.
    Acceptance criteria
    • A note shows its author and time. It is never sent to NPHIES and says so.
    • Notes appear on the case timeline and on the authorization, claim, advanced authorization and message pages.
    • A note cannot be edited or deleted after it is saved. A correction is a new note.
    		 Drawn

    Case timeline Authorization result Advanced authorization detail Claim detail Communication detail Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail
    OP-4P1, not in the backlog Background NPHIES pollAs the system, I poll NPHIES on a schedule, so answers and payer-issued authorizations are not missed.
    Acceptance criteria
    • Task poll shows the schedule, the last poll and the next one. Poll now stays as a fallback.
    • Every page shows the last poll in the top bar. A failed poll says so in the top bar.
    • New answers land in the Inbox. The administrator sets the interval (confirm the allowed rate on the NPHIES IG).
    		 Drawn

    Home Inbox Poll NPHIES Integrations
    OP-5P1, not in the backlog Viewer and Auditor rolesAs an administrator, I need two read-only roles, so management and compliance can look without acting.
    Acceptance criteria
    • Viewer is the go-live default for users nobody mapped (US-46). It never gets create, update, delete or run.
    • Auditor reads the audit log, users, roles and security settings at group scope, and nothing else is changed by it.
    • The legacy viewer role maps to Viewer, not to Receptionist.
    		 Drawn

    Roles and permissions Edit role Assign roles to existing users Audit log
    OP-6P1, not in the backlog CSV export and printAs a desk user, I need to export a list to CSV and print a result, so I can hand it to finance or file it with the patient.
    Acceptance criteria
    • Every list has Export with CSV. The export says how many rows it holds and is logged.
    • Eligibility, authorization and claim results have Print or save as PDF.
    • A role that cannot read a list cannot export it.
    		 Drawn

    Worklist Eligibility Eligibility result Prior authorization Authorization result Claims Claim detail Payment notices Reconciliation history Reconciliation exceptions Users Audit log Authorization result Authorization result Authorization result Authorization result Authorization result Authorization result Eligibility result Eligibility result Eligibility result Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail Claim detail
    OP-7P1, not in the backlog Permission matrix fixesAs an administrator, I need the permission matrix to match daily work, so people can do their job and no more.
    Acceptance criteria
    • A/R can read the status checker and reply on messages linked to a claim it chases.
    • Delete means a draft of your own, never a submitted record. Submitted records are cancelled.
    • An override above a threshold needs a second person in a later release. The override screen says so.
    		 Drawn

    Services Services Messages Send communication Status checker Roles and permissions Edit role Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker Status checker
    OP-8P1, not in the backlog Several roles per user and admin scopeAs an administrator, I need one user to hold several roles and an administrator to work for one facility, so small teams and groups both fit.
    Acceptance criteria
    • A user can hold several roles at the same or different organization nodes. A list shows them all.
    • Administrator is never combined with a transactional role. The screen blocks it and says why.
    • Administrator has two scopes: group (roles, security, API, integrations, quarantine, codes) and facility (users, unlock, two-step reset for that facility).
    		 Drawn

    Roles and permissions Edit role Add user User detail
    OP-9P1, not in the backlog Facility scope for multi-facility usersAs a central desk user, I need to see work from several facilities and switch between them, so one desk can serve a group.
    Acceptance criteria
    • Lists show a Facility column and a Facility filter for a user with more than one facility.
    • The top bar has a facility switcher. A record of a facility outside the scope is refused with a clear reason (US-52b).
    • A user with one facility sees none of this.
    		 Drawn

    Worklist Work queues Eligibility Prior authorization Claims Reconciliation history Data scope and isolation Work queues Work queues Work queues Work queues Work queues Work queues
    OP-10P1, not in the backlog Audit coverage and break-glassAs a compliance owner, I need every sensitive action logged and a sealed emergency account, so nothing happens unseen.
    Acceptance criteria
    • The audit log also records cancel, quarantine replay, assign, take over, export and an administrator opening a clinical or finance record.
    • An administrator cannot change their own role. The attempt is blocked and logged.
    • Signing in with the break-glass account raises a security alert and an email to the other administrators.
    		 Drawn

    Users User detail Security alerts Audit log
    OP-11P2, not in the backlog Second release optionsAs a team lead or finance user, I need an exceptions queue and an outbox view, so I can chase short payments and failed sends.
    Acceptance criteria
    • Reconciliation exceptions: short-paid, unmatched and unpaid claims in one queue.
    • Outbox: what is queued, retried or failed at NPHIES, with the last success.
    • Drawn as options for the second release. Approve or drop them.
    		 Drawn New screen

    Reconciliation exceptions NPHIES outbox

    Added by scope: data sources

    Not in the backlog. RaneemHCP is not the system of record for hospital data, so a Super admin links it to the hospital systems through plugins. Each kind of record is imported here, read live from the source, or stored here. DS-1 to DS-8 add one area of new screens (Data sources) and small states on the daily screens that look up patients, practitioners, services, payers and diagnoses.

    Item What it asks for Status Where to see it
    DS-1P1, not in the backlog, added by scope: data sources Data sources area and Super admin roleAs the platform owner, I need one area, outside daily work, where a Super admin links RaneemHCP to the hospital systems, so patients, practitioners and the rest are not typed twice.
    Acceptance criteria
    • Only the Super admin (a system level role outside any facility) can add, change or remove a data source. The group Administrator sees the status read only. The Auditor reads the change trail. Everyone else sees only a source badge on records.
    • First-time setup is a guided wizard of seven steps. Afterwards the area is a small console: overview, plugins, entities, sync history, quarantine, health and audit.
    		 Drawn New screen

    Data sources Choose a plugin Sync rules and activate
    DS-2P1, not in the backlog, added by scope: data sources Plugins, connection and credentialsAs a Super admin, I need to install a connector plugin and test the connection, so I know the hospital system answers before anything depends on it.
    Acceptance criteria
    • A plugin is a way to reach a source: REST or FHIR API, SQL database, HL7 feed, file drop (SFTP or CSV) or a vendor plugin. The catalog shows installed and available plugins.
    • Credentials are masked after saving and live in a vault, never in the portal database. Test connection shows what was reached, how fast and what failed.
    		 Drawn New screen

    Integrations Plugins Plugin detail Choose a plugin Connection and test
    DS-3P1, not in the backlog, added by scope: data sources Entities and storage modeAs a Super admin, I need to say, for each kind of record, whether RaneemHCP imports a copy or reads the hospital system live, so the portal never becomes a second system of record by accident.
    Acceptance criteria
    • Entities offered by a plugin: Patients, Practitioners, Payers and insurance plans, Facilities and departments, Service and price catalogue, Diagnosis codes, Coverage and members, Medications, Appointments (optional).
    • Each entity has exactly one mode: Import (a copy owned by the portal, fast, can drift), Use as storage (live reference: the source is the store, the portal keeps a key) or Stored here (no source, the default).
    • The choice screen explains each mode in plain words with its consequences.
    		 Drawn New screen

    Plugin detail Choose entities Import or use as storage Entity
    DS-4P1, not in the backlog, added by scope: data sources Field mappingAs a Super admin, I need to map source fields to portal fields with a sample row, so the data arrives in the right place.
    Acceptance criteria
    • Each portal field shows its source field, whether it is required and a sample value. Transforms: trim, date format, code lookup.
    • An unmapped required field blocks activation and says which one.
    		 Drawn New screen

    Map fields Entity
    DS-5P1, not in the backlog, added by scope: data sources Identity and matchingAs a Super admin, I need a matching key per entity, so a record from the hospital system and one in RaneemHCP are never duplicated.
    Acceptance criteria
    • One matching key per entity (national ID or iqama for patients, license number for practitioners) and a rule for duplicates: merge, keep both flagged, or send to quarantine.
    • The screen shows how many existing records would match before activation.
    		 Drawn New screen

    Identity and matching Entity
    DS-6P1, not in the backlog, added by scope: data sources Sync rules, history and quarantineAs a Super admin, I need schedules, a run history and a place for bad rows, so a failing feed is seen and fixed, not silently ignored.
    Acceptance criteria
    • Per entity: schedule, pull now, conflict policy (the source wins), retry and failure handling.
    • History lists runs with counts, failures and quarantined rows. A quarantined row can be fixed and replayed, or skipped. Both are logged.
    		 Drawn New screen

    Sync rules and activate Sync history Quarantined rows
    DS-7P1, not in the backlog, added by scope: data sources Guarded change of mode, with auditAs a Super admin, I need to change a mode safely once data exists, so no transaction loses its patient or its code.
    Acceptance criteria
    • With no data the change is free. With data, a case screen shows the records already imported and the transactions that reference them, the allowed paths (keep a snapshot and switch, migrate references, or wait until open transactions close) and requires a typed confirmation and a reason.
    • Every change is audited and readable by the Auditor in the data source change trail.
    		 Drawn New screen

    Audit log Change storage mode Data source changes
    DS-8P1, not in the backlog, added by scope: data sources Source badge, lookup and health on daily screensAs a desk user, I need to find a patient, practitioner, service, payer or diagnosis from the hospital system while I work, and to know when it is not available, so I keep working.
    Acceptance criteria
    • Pickers offer Find in hospital system. Records from a source carry a source badge and a reference id, show source fields read only and offer Refresh from source.
    • When the source is down a banner says so. Last known data may be shown where allowed. Creating a request for that entity is blocked or allowed with manual entry, as the per entity fallback setting says.
    • Roles that can read Data sources see a source health indicator in the top bar and on Home.
    		 Drawn New screen

    Home Patients Patient history Patient identity Payer Patient identity Care team Diagnoses Services Patient identity Clinical context Care team Services Data sources Source health