case-study.md

Case Study: Picture Archiving and Communication System (PACS)

The Picture Archiving and Communication System (PACS) is a hospital system that manages the storage, retrieval, and distribution of medical images. This document describes what the PACS example is: the system it models, the architecture it commits to, the scenarios it runs, and the parameters that define its operating point. It is the first of three companion documents. For the method that drives the example see procedure.md; for the dimensional derivation and the results see report.md.

PACS is the illustrative example of the DASA methodology. It is not a validation case study: it exists to show a practitioner how the method is applied end to end, twice, on a system whose behaviour is well documented in its own domain literature.

---

1. Overview

A Picture Archiving and Communication System manages the storage, retrieval, and distribution of medical images for a hospital. The example models one serving a 500-bed regional hospital across Radiology, Cardiology, and Emergency Medicine, with concurrent access by physicians, radiologists, and clinical staff.

The system is grounded in the documented PACS domain rather than invented. Hood and Scott [1] give the canonical topology, in which the archive mediates between the imaging modalities and the hospital's Radiology Information System (RIS) and Hospital Information System (HIS), carrying images over DICOM and reports over HL7 across short-term and long-term storage tiers. Van de Wetering and Batenburg's PACS Maturity Model [2] fixes the capability of the hospital modelled here at their third level, Clinical Process Capability, where hospital-wide distribution and HIS/RIS/PACS integration are already in place. Dias et al. [3] justify reading Performance and Availability as the competing quality attributes, since slow or unavailable retrieval lengthens radiology tasks and propagates into clinical error.

1.1 Workload

The archive handles imaging modalities of very different sizes, and the traffic profile follows the clinical working day.

Modality	Payload per study	Source
X-ray	approximately 1.0 MB	Emergency
CT	2.0 MB to 4.0 MB	Radiology
MRI	8.0 MB to 16.0 MB	Neurology

Arrivals are Poisson with $100 \leq \lambda \leq 500$ req/s during peak imaging hours (08:00 to 18:00, weekdays). Service is exponential. The competing quality concerns are Performance (archival and retrieval latency) and Availability (uptime and effective throughput under growing request volume).

---

2. Architecture

The architecture is service-oriented, so that archival, retrieval, and metadata services scale independently and absorb burst clinical traffic. Requests reach the archive through a load balancer, are held in bounded FIFO queues, and are served by a configurable number of concurrent service instances backed by a DICOM database.

Two design decisions shape everything downstream. Queues are bounded, so the model must account for capacity rather than assume an infinite buffer. Errors are rework self-loops at each service, so a fraction $\varepsilon$ of every arrival stream fails to depart on its first pass.

2.1 Iteration 1: the archival service in isolation

The first iteration establishes the dimensional foundation on a single node.

Medical staff send imaging requests through the Equipment Console, which forwards DICOM C-STORE messages to the Archival Server. The Image Archival Service runs $c$ concurrent instances to distribute the incoming load, each managing a FIFO queue bounded at $K$ request slots with $M_{\mathrm{buf}}$ of allocated buffer memory to absorb DICOM payloads. Each instance serves at rate $\mu$, and the service tolerates up to a 1.0 % error rate through rework self-loops. Archived images persist to a dedicated database server.

This collapses to a single M/M/c/K queue [6]. The Equipment Console sits outside the PACS boundary, and the Archival Server and database server behave as one service from the request's point of view: each arrival is served by an available instance, persisted, and acknowledged before the next request enters service. Under queueing theory the two internal servers become one logical station with $c$ parallel servers sharing a common FIFO queue.

2.2 Iteration 2: the seven-node network

The second iteration scales the same dimensional framework from one node to a full request-reply pipeline, modelled as a Jackson open queueing network.

Seven components form a five-layer pipeline: ingress, write/read processing, persistence, reply dispatch, egress.

Node	Component	Service	Path
IB	Inbound Broker	Broker	both
IW	Image Writer	Archival	write
IR	Image Reader	Retrieval	read
DB	Database Manager	Database	both
WN	Write Notifier	Archival	write
RN	Read Notifier	Retrieval	read
OB	Outbound Broker	Broker	both

IB classifies each arrival and splits it between IW for archiving and IR for retrieval. Both channels converge at DB, the shared persistence layer carrying the aggregate load. The return path separates again through WN for write acknowledgements and RN for retrieved image payloads, before OB dispatches responses back to the originating clients.

Each component is itself an M/M/$c_j$/$K_j$ queue, which is what makes the network tractable: Poisson arrivals at rate $\lambda_j$, $c_j$ parallel workers at exponential rate $\mu_j$, a FIFO queue bounded at $K_j$, and a rework self-loop with probability $\varepsilon_j = 0.01$.

The $7 \times 7$ routing matrix $\mathbf{P}$ is parameterised by the read fraction $\alpha$ and the per-node self-loop $\varepsilon$. Rows and columns are ordered IB, IW, IR, DB, WN, RN, OB; entry $P_{ij}$ is the probability of routing from node $i$ to node $j$.

$\mathbf{P}$	IB	IW	IR	DB	WN	RN	OB
IB	$\varepsilon$	$(1-\varepsilon)(1-\alpha)$	$(1-\varepsilon)\alpha$	$0$	$0$	$0$	$0$
IW	$0$	$\varepsilon$	$0$	$1-\varepsilon$	$0$	$0$	$0$
IR	$0$	$0$	$\varepsilon$	$1-\varepsilon$	$0$	$0$	$0$
DB	$0$	$0$	$0$	$\varepsilon$	$(1-\varepsilon)(1-\alpha)$	$(1-\varepsilon)\alpha$	$0$
WN	$0$	$0$	$0$	$0$	$\varepsilon$	$0$	$1-\varepsilon$
RN	$0$	$0$	$0$	$0$	$0$	$\varepsilon$	$1-\varepsilon$
OB	$0$	$0$	$0$	$0$	$0$	$0$	$\varepsilon$

Only the IB and DB rows vary with the workload mix. The OB row sums to $\varepsilon$, the remaining probability being the exit from the network.

---

3. Quality attributes

Performance (archival and retrieval latency) and Availability (uptime and effective throughput) are the competing quality concerns introduced in Section 1.1. Each iteration expresses them as a concrete quality scenario, and the second iteration's design goals make them measurable.

3.1 Iteration 1 quality scenario

The scenario follows the six-part form of Bass et al. [5].

Attribute	Description
Source of stimulus	Imaging modalities: CT scanners, MRI machines, X-ray equipment, ultrasound devices
Stimulus	Concurrent medical image archival requests during diagnostic sessions
Artifact	PACS archival service cluster
Environment	Normal operation during peak imaging hours (08:00 to 18:00, weekdays)
Response	The archive confirms persistence of the image to storage
Response measure	Latency $W \leq 500$ ms; throughput $\chi \geq 100$ req/s with error rate $\varepsilon \leq 1.0%$

3.2 Iteration 2 quality scenarios

An inbound broker partitions the total load $\lambda = 100$ req/s by a read fraction $\alpha$, giving $\lambda_R = \alpha \lambda$ to retrieval and $\lambda_W = (1 - \alpha) \lambda$ to archival. Both channels share one downstream database, so each channel gets its own scenario.

Attribute	Write channel	Read channel
Source of stimulus	Imaging modalities	Clinical staff requesting stored images
Stimulus	Archival requests routed to the write cluster (20 % of load, 20 req/s at baseline)	Retrieval requests routed to the read cluster (80 % of load, 80 req/s at baseline)
Artifact	Broker-mediated archival cluster	Broker-mediated retrieval cluster
Environment	Peak imaging hours	Peak clinical review hours
Response	Archival acknowledged through the outbound broker	Images fetched from the database and delivered through the outbound broker
Response measure	$W \leq 500$ ms; $\chi_W \geq 20$ req/s at $\varepsilon \leq 1.0%$	$W \leq 500$ ms; $\chi_R \geq 80$ req/s at $\varepsilon \leq 1.0%$

3.3 Design goals

The five goals the second iteration is designed against, each with an explicit dimension:

Goal	Predicate	Dimension
Latency	$W_j \leq 500$ ms per node	$[T]$
Throughput	$\chi_W \geq 20$ req/s and $\chi_R \geq 80$ req/s	$[S \cdot T^{-1}]$
Utilisation	$\rho_j \leq 0.50$	dimensionless
Memory	$M_{\mathrm{act},j} \leq M_{\mathrm{buf},j}$	$[D]$
Shared database	$\lambda_{DB} = \lambda_W + \lambda_R \approx 99$ req/s absorbed without saturation	$[S \cdot T^{-1}]$

How these are decided, and what the runs found, is the subject of report.md.

---

4. Adaptation

PACS is not a self-adaptive system. It is an illustrative example with static configurations and no runtime adaptation logic, a scope limit set out in report.md Section 7. What the example varies instead is the workload mix it runs under, through the five routing environments below, and the design itself, across the two iterations of Section 2. The routing environments are the nearest analog to an adaptation axis.

4.1 Routing environments

Five routing scenarios span the workload mixes the archive sees in practice, from a read-only review session to a bulk import.

Scenario	$\alpha$	Label
100R	1.00	100 % read
80R20W	0.80	80 % read, 20 % write (baseline)
50R50W	0.50	balanced
20R80W	0.20	20 % read, 80 % write
100W	0.00	100 % write

80R20W is the declared setpoint: it is the typical clinical working-hours mix.

---

5. Operating point and parameters

5.1 The dimensional framework

Physical dimensional analysis works over Length, Mass, and Time. A software service has no useful notion of mass, so the example defines its own set of Software Architecture Fundamental Dimensional Units (SAFDUs):

SAFDU	Meaning	Unit	Examples
$[T]$	Time	seconds	waiting time, service time, inter-arrival time
$[S]$	Structure	requests	queue positions, service instances, requests in system
$[D]$	Data	bits	request payload, buffer memory

These three are independent, complete over the phenomena of interest, and measurable, which is what the Pi-theorem requires of a dimensional basis [4].

Unit convention for $[S]$. Structural quantities count different things: $c$ counts service instances, $K$ counts capacity slots, $L$ counts requests in the queue. The example narrows $[S]$ to requests throughout, reading $c = 2$ req as two-request concurrent processing per node and $K = 16$ req as a sixteen-request buffer. Since each request occupies exactly one container, the container-count reading follows by integer multiplicity and the two are mathematically equivalent. Stating the operating point in the unit of the quantity being managed keeps it consistent with the rate-like $[S \cdot T^{-1}]$ variables ($\lambda$, $\chi$, $\mu$, all in req/s).

5.2 Iteration 1 parameters

The shipped configuration is data/config/PACS-vars-iter1.json, which declares eleven variables over $[T]$, $[S]$, and $[D]$.

Variable	Category	Dimension	Setpoint	Swept over
$\lambda$ arrival rate	input	$[S \cdot T^{-1}]$	100 req/s	100 to 500 req/s
$K$ system capacity	input	$[S]$	8 req	$\lbrace 4, 8, 16 \rbrace$
$d_{\mathrm{req}}$ data density	input	$[D \cdot S^{-1}]$	5000 kB/req	fixed
$W$ waiting time	output	$[T]$	5 ms	derived
$\mu$ service rate	control	$[S \cdot T^{-1}]$	400 req/s	$\lbrace 100, 200, 500 \rbrace$
$c$ service instances	control	$[S]$	1 req	$\lbrace 1, 2, 4 \rbrace$
$\varepsilon$ error rate	control	dimensionless	0.01	fixed
$\chi$ effective rate	control	$[S \cdot T^{-1}]$	99 req/s	derived
$L$, $L_q$ queue length	control	$[S]$	0.99 req	derived
$M_{\mathrm{act}}$ active memory	control	$[D]$	11 MB	derived
$M_{\mathrm{buf}}$ buffer memory	control	$[D]$	32 MB	fixed

The sweep crosses $c$, $K$, and $\mu$ into 27 configurations, each ramped across the arrival range.

5.3 Iteration 2 per-node parameters

From data/config/PACS-vars-iter2.json, at the 80R20W setpoint:

Node	$\lambda_j$ (req/s)	$\mu_j$ (req/s)	$c_j$	$K_j$ (req)	$M_{\mathrm{buf},j}$ (MB)	$d_{\mathrm{req},j}$ (MB/req)
IB	100	1000	1	16	64	0.41
IW	20	500	2	16	32	2.00
IR	80	500	2	16	32	0.01
DB	100	1000	1	32	64	0.41
WN	20	500	2	16	32	0.01
RN	80	500	2	16	32	0.01
OB	100	1000	2	16	64	8.00

Every node carries $\varepsilon_j = 0.01$.

The heterogeneous data density is the point of interest. IW carries full DICOM payloads at 2.0 MB/req while IR carries 0.01 MB/req, a factor of 200. This asymmetry is what gives the $[D]$ dimension something to say, and it is invisible to a utilisation figure such as $\rho = \lambda / (c \cdot \mu)$.

5.4 Design space

Each node is swept over the same three levers, giving 216 configurations per scenario across the seven nodes, evaluated in all five environments:

$$\mu_j \in \lbrace 200, 500, 1000 \rbrace \text{ req/s}, \qquad c_j \in \lbrace 1, 2, 4 \rbrace, \qquad K_j \in \lbrace 4, 8, 16 \rbrace \text{ or } \lbrace 4, 8, 16, 32 \rbrace$$

The brokers and the database (IB, DB, OB) carry the wider $K$ grid, since they absorb aggregate rather than per-channel traffic.

5.5 End-to-end paths

Three aggregations lift the per-node coefficients to system level:

• Read path $R_{\mathrm{PACS}}$: IB, IR, DB, RN, OB
• Write path $W_{\mathrm{PACS}}$: IB, IW, DB, WN, OB
• Overall $\mathrm{PACS}$: the combined pipeline

---

6. Limits of the source material

PACS is the methodology's illustrative example rather than a validation case study, so its grounding is domain literature rather than a measured deployment. The topology follows Hood and Scott [1], the hospital's capability level is fixed by the PACS Maturity Model of van de Wetering and Batenburg [2], and the choice of Performance and Availability as the competing attributes follows Dias et al. [3]. Where the sources stop, the model makes explicit modelling commitments (Markovian M/M/c/K queues, static configurations, a uniform per-node error rate) rather than importing measured behaviour. Those commitments and their consequences are enumerated as threats in report.md Section 7 and as scope limits in procedure.md Section 5.

---

References

[1] M. N. Hood and H. Scott, "Introduction to Picture Archive and Communication Systems," Journal of Radiology Nursing, vol. 25, no. 3, pp. 69-74, Sep. 2006, doi: 10.1016/j.jradnu.2006.06.003.

[2] R. van de Wetering and R. Batenburg, "A PACS maturity model: A systematic meta-analytic review on maturation and evolvability of PACS in the hospital enterprise," International Journal of Medical Informatics, vol. 78, no. 2, pp. 127-140, Feb. 2009, doi: 10.1016/j.ijmedinf.2008.06.010.

[3] C. R. Dias, M. R. Pereira, and A. P. Freire, "Qualitative review of usability problems in health information systems for radiology," Journal of Biomedical Informatics, vol. 76, pp. 19-33, Dec. 2017, doi: 10.1016/j.jbi.2017.10.004.

[4] H. Gortler, Dimensionsanalyse: Theorie der physikalischen Dimensionen mit Anwendungen. Springer, 2011 (softcover reprint of the 1975 first edition).

[5] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed., SEI Series in Software Engineering. Addison-Wesley Professional, 2012.

[6] P. J. Denning and J. P. Buzen, "The operational analysis of queueing network models," ACM Computing Surveys, vol. 10, no. 3, pp. 225-261, Sep. 1978, doi: 10.1145/356733.356735.