System Architecture
RPMS is a decentralized, site-based system. Each facility runs its own instance. Data flows upward to the Indian Health National Data Base for population-level reporting. Understanding how the four layers and infrastructure packages fit together is the foundation for building anything that interoperates with RPMS.
The Four-Component Model
Hardware
Flexible configurations supporting facilities from small rural clinics to large area hospitals. Originally AIX/Unix servers; now primarily virtualized or cloud-hosted IRIS instances.
Software
70+ MUMPS/M applications organized into Clinical, Administrative, and Infrastructure categories. Each application owns a namespace prefix that scopes its data and code.
Network
Site-level TCP/IP with RPC Broker handling client-server communication. HL7 interfaces connect RPMS to external systems — labs, pharmacies, imaging. MailMan provides internal messaging.
Database
InterSystems IRIS (formerly Caché) as the primary runtime. VA FileMan sits on top as the schema and data access layer — all application data is stored in FileMan files, making the schema itself queryable.
The Infrastructure Stack
Every RPMS application depends on this shared foundation. Understanding these packages is essential for any integration or reimplementation.
XU
VA Kernel
The OS abstraction layer. Handles user authentication, menu-based access control, device management, task scheduling, and the security model that all other applications rely on. Think of it as the OS kernel — nothing runs without it.
DI
VA FileMan
The database management and schema layer. All RPMS data is stored in FileMan files. Crucially, the schema itself is stored in the database — making it introspectable and queryable. FileMan predates relational databases as a common choice for medical records and solved the same problems differently: hierarchical globals with a metadata-driven access layer on top.
XWB
RPC Broker
The client-server bridge. GUI clients (VIM.exe, VueCentric) communicate with the MUMPS server by calling named Remote Procedure Calls over TCP. Every RPC is a named, registered entry point — a primitive but effective API contract. The RPC registry in FileMan is effectively a public API manifest.
HL
HL7 / BHL
HL7 v2 message handling for lab results, ADT events, pharmacy orders, and more. IHS Support for HL7 Interfaces (BHL) extends the base HL7 package for IHS-specific workflows. This is the primary integration pathway for connecting RPMS to external systems.
XM
MailMan
Internal messaging and notification infrastructure. Alerts, reminders, approval routing, and inter-facility communication all run through MailMan. An early, domain-specific event bus.
BMW
RPMS/Ensemble Cache Classes
The modern interoperability layer. BMW maps FileMan files to IRIS classes and exposes them via ADO.NET — enabling .NET applications like BPRM to query RPMS data using SQL-like semantics without touching MUMPS directly. The bridge between the legacy MUMPS world and modern web applications.
Decentralized by Design
Each facility runs its own RPMS instance. There is no central database — data lives at the site. This was a deliberate choice for resilience: a network outage at one site does not affect others. Facilities can operate fully offline.
Population-level data flows upward through periodic exports to the Indian Health National Data Base, satisfying reporting requirements (HEDIS, ORYX, GPRA) without centralizing day-to-day operations.
Pattern: This is a federated architecture with eventual consistency for analytics — a pattern now common in modern distributed systems, arrived at pragmatically decades earlier.
Standards & Conventions (SAC)
The RPMS Standards and Conventions Committee (SAC) maintains the rules that keep 70+ independently developed applications from breaking each other. Key documents include:
- RPMS Programming Standards and Conventions (MUMPS/M)
- RPMS Ensemble Programming Standards and Conventions
- RPMS GUI Programming Standards and Conventions
- SAC Developers' Handbook
- RPMS Documentation Style Guide
The SAC is the governance mechanism that makes a federated, multi-site, multi-decade codebase maintainable. Pattern: Explicit shared conventions enforced by a standards body — not a monorepo, not a single team, but agreed-upon rules.
IHS SAC documentation →