Domain Model

RPMS encodes decades of healthcare operations into its data model. This page distills those domain objects — the core entities, relationships, and design decisions that recur across the system. This is an opinionated, open-source interpretation: the patterns worth carrying forward, not a transcription of the MUMPS globals.

Core Entities

Patient

The central entity. In IHS context, includes: MRN, demographics, tribal membership, IHS eligibility, and insurance. Identity resolution across facilities is handled by the Master Patient Index (AGMP).

AG · AGMP · PIMS

Encounter / Visit

A patient-provider interaction. The PCC Suite structures the encounter: chief complaint, diagnoses (ICD), procedures (CPT), vitals, notes, and orders. The encounter is the unit of care delivery and the unit of billing.

BJPC · APCD · APCH · GMRV

Problem

Active, chronic, or resolved conditions linked to the patient record. Updated at encounters. The Problem List is the longitudinal health narrative — referenced across all clinical applications.

PCC Problem List

Order

A provider directive: lab test, medication, radiology study, consult, immunization, nursing order. Orders are placed in EHR, routed to the relevant department, and tracked to completion. Quick orders (pre-defined sets) reduce entry time for common scenarios.

LR · PSO · PSJ · RA · GMRC

Result

The outcome of an order: lab values, radiology findings, consult notes. Results are surfaced at point of care — available to providers at terminals and on printers the moment they are reported.

LR · RA · BLE

Document / Note

Clinical documentation: SOAP notes, procedure notes, consult responses, discharge summaries. Text Integration Utility (TIU) provides the document framework. Templates define structure; providers fill in content.

TIU · EHR

Provider

A credentialed clinician or staff member. Linked to: credentials, privileges, expiration dates, alerts. Provider identity controls what a user can order, prescribe, document, and access.

Kernel · XU · Medical Staff Credentials

Adverse Reaction / Allergy

Tracked in the Adverse Reaction Tracking (ART) package — separate from the Problem List. Only ART-documented allergies trigger order checks. A safety-critical domain object with its own dedicated application.

GMRA

Code Systems & Vocabulary

RPMS manages multiple clinical vocabularies as first-class domain objects — not hard-coded strings. Each code system has an annual update cycle managed by a dedicated package.

ICD / AUM

ICD Diagnosis Codes

Annual updates via ICD Update package (AUM). Used for diagnosis coding on every encounter and for population reporting.

CPT / ACPT

Procedure Codes (restricted)

AMA-owned. Requires separate license. Annual updates. Used for billing and reporting. Restricted from open distribution.

SNOMED / BSTS

SNOMED Clinical Terms

IHS Standard Terminology package. Used for interoperability with external systems and CCDA document exchange.

Taxonomy / ATX

IHS Taxonomy

IHS-specific grouping of ICD codes into clinically meaningful categories for reporting and population health analysis.

BCQM

IHS Code Mapping

Maps between IHS-specific codes and standard vocabularies. The interoperability translation layer.

Document Exchange Evolution

RPMS's document exchange standard has evolved through three generations — a concrete lesson in standards migration that any health IT architect will eventually face:

BJMD (2011)

C32/CCD Clinical Summary — the first structured patient summary format. XML-based, HL7 CCD standard.

BCCD (2015)

Consolidated CDA (CCDA) — the Meaningful Use-era standard. Richer structure, more sections, ONC-required for certification.

BREH (2023)

RPMS EHI Export — Electronic Health Information export per 21st Century Cures Act. The current interoperability standard.

Pattern: Standards migrate. Design your domain model to be standard-agnostic — the export format should be a view over the domain model, not baked into it.

FileMan: Schema as Data

VA FileMan stores its schema — the definition of every file, field, and relationship — inside the database itself as data. This makes the schema introspectable, queryable, and modifiable at runtime without code changes.

Every RPMS FileMan file has a number (e.g., File 2 is the Patient file, File 9000010 is the Visit file). These numbers are stable identifiers — the equivalent of table names in a relational schema, but with guaranteed stability across all RPMS sites.

Pattern: A self-describing data store with a stable, numeric schema identity. Modern equivalents: schema registries, event schema versioning, database migration frameworks. The key insight is that the schema is part of the domain model — not a separate concern.