Boundaries — Example: Hospital Patient Management

The Scenario

A hospital system that manages patient registration, doctor scheduling, appointments, medical records, prescriptions, lab tests, billing, and insurance claims. Doctors view patient records. Nurses log vitals. Patients access a portal to see appointments and results.

This is the most complex example so far. Real hospital systems are among the most boundary-critical systems in existence — if data leaks between boundaries incorrectly, the consequences can be fatal.

Step 1: List the Nouns

• Patient
• Doctor
• Nurse
• Appointment
• Schedule
• Medical record
• Diagnosis
• Prescription
• Medication
• Lab test
• Lab result
• Vitals (blood pressure, temperature, heart rate)
• Bill/Invoice
• Insurance claim
• Insurance provider
• Payment
• Patient portal
• Department (cardiology, orthopedics, etc.)
• Room/Bed
• Admission (inpatient stay)
• Discharge
• Referral
• Allergy
• Medical history
• Emergency contact

25 nouns. Let's find the boundaries.

Step 2: Group by Responsibility

10 candidate modules. Let's evaluate.

Merge Decisions

Should Insurance merge with Billing? Billing is "calculate what's owed." Insurance is "submit claims to a third party, track approval/denial, handle coverage rules." Insurance has its own external dependencies (insurance company APIs, claim formats, pre-authorization workflows). Keep separate — insurance is complex enough to be its own domain.

Should Patient Portal be a module? The portal is a view into other modules' data — it shows appointments (Scheduling), lab results (Lab), bills (Billing). It doesn't own any unique data. It's a presentation boundary, not a data boundary. The portal is not a module — it's a consumer of other modules' contracts. Important distinction.

Should Department be a module? Departments are organizational metadata. They affect scheduling (which department a doctor belongs to) and potentially routing (which department handles a referral). But "Department" alone doesn't have enough logic to be its own module. Merge into People/Identity as an attribute.

Revised Module List

1. People — identity of patients, providers, staff
2. Scheduling — appointments and resource allocation
3. Clinical Records — medical data
4. Medications — prescriptions and pharmacy
5. Lab/Diagnostics — tests and results
6. Admissions — inpatient management
7. Billing — charges and payments
8. Insurance — claims and coverage

8 modules.

Step 3: Define Inside and Outside

People

• ✅ Inside: Patient demographics (name, DOB, address, phone), doctor/nurse profiles, credentials, department assignments, emergency contacts, user authentication for portal access
• ❌ Outside: Medical history (Clinical Records), what appointments they have (Scheduling), what they owe (Billing), what insurance they have (Insurance — though insurance ID might be stored here as an attribute)

Scheduling

• ✅ Inside: Creating/canceling/rescheduling appointments, doctor availability calendars, room/bed assignments, appointment reminders, waitlist management, recurring appointment series
• ❌ Outside: What happens during the appointment (Clinical Records), what it costs (Billing), patient demographics (People), test orders (Lab)

Clinical Records

• ✅ Inside: Diagnoses, clinical notes, vitals recordings, allergy lists, medical history, treatment plans, imaging records, visit summaries
• ❌ Outside: Prescriptions (Medications — though they link to diagnoses), test ordering (Lab — though linked to clinical decisions), billing (Billing), appointment logistics (Scheduling)

Why is Clinical Records separate from Medications and Lab? Because clinical records are the narrative of patient care — what was observed, what was decided. Medications and Lab are the actions — what was prescribed, what was tested. These change at different rates, are governed by different regulations, and are managed by different people. A pharmacist manages medications. A lab technician manages tests. A doctor manages the clinical record.

Medications

• ✅ Inside: Prescriptions (what drug, what dose, what duration), drug interaction checks, refill tracking, pharmacy dispensing records, medication history
• ❌ Outside: The clinical reason for the prescription (Clinical Records), patient identity (People), billing for medications (Billing)

Lab/Diagnostics

• ✅ Inside: Ordering tests, tracking sample collection, managing lab workflows, recording results, flagging abnormal results, test history
• ❌ Outside: Clinical interpretation of results (Clinical Records), billing for tests (Billing), patient identity (People)

Admissions

• ✅ Inside: Admitting patients (inpatient), bed assignments, transfer between departments, discharge processing, length-of-stay tracking, discharge summaries, referrals to other facilities
• ❌ Outside: Clinical care during the stay (Clinical Records), billing for the stay (Billing), identity (People)

Billing

• ✅ Inside: Generating charges from procedures/visits/tests/medications, creating invoices, processing patient payments, tracking outstanding balances, payment plans
• ❌ Outside: Insurance claims (Insurance — Billing passes charges to Insurance for claim submission), clinical details (Clinical Records), scheduling (Scheduling)

Insurance

• ✅ Inside: Insurance plan details, pre-authorization requests, claim submission, claim status tracking, coverage verification, denial management, appeal processing
• ❌ Outside: Generating charges (Billing — Insurance receives charges), clinical justification (Clinical Records provides this when needed for pre-auth), patient identity (People)

Step 4: Connection Diagram

                          ┌───────────┐
                          │  People   │
                          │           │
                          │- patients │
                          │- doctors  │
                          │- staff    │
                          └───────────┘
                         ▲  ▲  ▲  ▲  ▲
                "who?"  /  |  |  |  \  "who?"
                       /   |  |  |   \
          ┌───────────┐  ┌─┴──┴──┴─┐  ┌───────────┐
          │Scheduling │  │Clinical  │  │Admissions │
          │           │  │Records   │  │           │
          │-appts     │  │          │  │-admits    │
          │-calendar  │  │-diagnoses│  │-transfers │
          │-rooms     │  │-vitals   │  │-discharges│
          └───────────┘  │-history  │  └───────────┘
                         └──────────┘
                          │        │
           "prescribed    │        │  "ordered
            based on      │        │   based on
            diagnosis"    ▼        ▼   diagnosis"
                   ┌──────────┐ ┌──────────┐
                   │Medications│ │   Lab    │
                   │           │ │          │
                   │-scripts   │ │-tests    │
                   │-drugs     │ │-results  │
                   │-refills   │ │-samples  │
                   └──────────┘ └──────────┘
                        │              │
                        │ "charges"    │ "charges"
                        ▼              ▼
                      ┌──────────────────┐
                      │     Billing      │
                      │                  │
                      │  - invoices      │
                      │  - payments      │
                      └──────────────────┘
                              │
                              │ "submit claim"
                              ▼
                      ┌──────────────────┐
                      │    Insurance     │
                      │                  │
                      │  - claims        │
                      │  - coverage      │
                      └──────────────────┘

Critical Observation: Data Flows Downward

Notice the shape. People is at the top — everyone needs to know who someone is. Clinical Records is in the middle — clinical decisions drive medications, lab tests, and admissions. Billing is near the bottom — it receives charges from multiple sources. Insurance is at the very bottom — it receives data from Billing.

No arrows point upward. This is not an accident — it's good boundary design. Lower modules don't need to know about higher modules.

Why Hospitals Are the Extreme Case for Boundaries

Regulatory boundaries are real boundaries

Medical records have different legal protections than billing data. You can't show a receptionist the same data you show a doctor. Boundaries enforce access control. If Clinical Records and Billing are in the same module, it's harder to ensure the billing clerk can't see clinical notes.

Wrong data can kill

If Medications gets the wrong patient's allergy list from Clinical Records, the patient could receive a drug they're allergic to. If Lab results are attributed to the wrong patient, treatment decisions are made on false data. Boundary contracts in healthcare are literally life-critical.

Audit requirements

Every access to a medical record must be logged: who accessed it, when, and why. This is only possible if Clinical Records is a clear boundary with defined entry points. If patient data is scattered across every module, comprehensive auditing is impossible.

Comparing All Three Examples