Security Patterns
Security in RPMS is not a layer added on top — it is embedded in the runtime. VA Kernel controls every user session, every menu option, every device connection. These patterns predate modern zero-trust frameworks by decades and solve the same problems in a healthcare-specific context.
Pattern: Kernel-Based Access Control
VA Kernel (XU) — the security model every application inherits
Menu-based access control
Every function in RPMS is a menu option. Access to any function — ordering labs, prescribing medications, viewing records, generating reports — requires explicit assignment of that menu option to the user or role. No menu assignment means no access. Not "access denied" — the option simply does not appear.
Electronic signature (ESIG)
Provider orders and clinical notes require electronic signature — a separate credential from the login password. The ESIG code is a second factor for clinical actions. Unsigned orders cannot be fulfilled. Unsigned notes are drafts, not part of the legal record.
Device-level access control
Kernel manages device (terminal) definitions. Certain functions are restricted to specific devices — a pharmacy terminal can dispense medications; a registration terminal cannot. Physical location maps to access scope.
Domain Pattern: Access control expressed as capability assignment, not role assignment. The atomic unit is a named function (menu option), not a role label. Roles are just named collections of menu options. Modern equivalent: capability-based access control (CBAC) vs. role-based access control (RBAC). The distinction matters when healthcare functions don't map cleanly to job titles.
Pattern: Comprehensive Audit Trail
User Security Audit (BUSA) — who did what, when, from where
Every access to sensitive data in RPMS is logged. The audit record captures: user identity, timestamp, workstation, action taken, and the record accessed. The User Security Audit (BUSA) package surfaces this data for compliance review.
Audit logs are write-once — users cannot modify or delete their own audit trail. Supervisors and compliance officers review the audit log independently from the clinical application.
Captured per access event:
- · User DUZ (unique identifier)
- · Timestamp (date + time)
- · Device / terminal
- · Application / menu option accessed
- · Patient record accessed (where applicable)
- · Action type (view, add, edit, delete)
Domain Pattern: Audit as a first-class system component — not a logging afterthought. The audit trail is a separate domain object with its own application (BUSA), its own access controls, and its own reporting tools. HIPAA requires audit logs; RPMS had them before HIPAA existed.
Pattern: Controlled Substance E-Prescribing
EPCS (BEPC) — DEA-compliant electronic prescribing with two-factor authentication
Identity proofing before enrollment
DEA regulations require in-person or remote identity proofing before a provider can be enrolled in EPCS. RPMS implements this as a formal enrollment workflow separate from standard user creation. The DEA registrant number is a required domain object — tied to the provider, not the facility.
Two-factor signing for controlled substance orders
Signing a controlled substance prescription requires: (1) the provider's electronic signature code, and (2) a hard token or logical access credential. A single credential is insufficient. The two-factor check is enforced at the order-signing step — not at login.
Schedule-aware drug validation
The pharmacy system (PSO) knows the DEA schedule of every drug in the National Drug File (PSN). Controlled substances are flagged at order entry. EPCS routing applies only to scheduled drugs — routing logic is schedule-aware, not blanket.
Domain Pattern: Security requirements vary by the sensitivity of the action — not uniformly applied to all actions. Controlled substances require a higher security bar than routine prescriptions. The domain model carries the sensitivity classification (DEA schedule) alongside the drug entity, and the security layer reads it at signing time.
Pattern: Credential Expiration as a Security Event
Medical Staff Credentials — time-bound access tied to license validity
A provider's ability to prescribe, order, and document is contingent on active credentials. RPMS tracks license expiration dates as domain objects and enforces them at the access control layer.
Automated alerts sent to provider and administration for upcoming expirations.
Prescribing and ordering privileges suspended automatically — not manually revoked.
Credentials updated, privileges automatically restored.
Domain Pattern: Time-bound access — credentials are not permanent grants. They are grants with expiration dates. The security model must treat expiration as an event, not a manual process. Modern equivalent: certificate-based access with automatic revocation on expiry.
The Security Domain Objects
RPMS's security model can be expressed as a small set of domain objects with well-defined relationships:
User (DUZ)
The unique user identifier. Every action is attributed to a DUZ. Cannot be reassigned or deleted — only inactivated.
Menu Option
The atomic unit of access. A named function in the system. Users are granted options; options can be grouped into menus for convenience.
Electronic Signature (ESIG)
A second credential required for clinical actions. Separate from login. Required for order signing and note authentication.
Device
A registered terminal or workstation. Access to certain functions is scoped to specific devices — location is part of the security context.
Credential
A professional license or privilege with an issue date, expiration date, and issuing authority. Tied to the Provider entity, not the User entity.
Audit Record
An immutable log entry: User + Action + Target + Timestamp + Device. Written at the kernel level — cannot be suppressed by application code.
Pattern: Security as a cross-cutting domain concern — not an application-level feature. Every RPMS application inherits audit, access control, and signature enforcement from Kernel. No application can bypass it. Modern equivalent: a policy enforcement layer in a service mesh — enforced at the infrastructure level, not per-service.
Related Packages
XU
VA Kernel
User authentication, menu access control, device management, security model foundation.
BUSA
User Security Audit
Audit log access and compliance reporting. Separate from the clinical applications it audits.
BEPC
Electronic Prescribing of Controlled Substances
DEA-compliant two-factor e-prescribing with identity proofing workflow.
GMRA
Adverse Reaction Tracking
Safety-critical allergy data. Only ART-documented allergies trigger order checks — a security boundary for patient safety.
PSN
National Drug File
Drug schedule classification (DEA I–V) as a domain object — drives EPCS routing and controlled substance order checks.
PXRM
VA Clinical Reminders
Rule-based alerts at the point of care — a clinical safety layer distinct from the access security layer.