Designing dispatch for in-home care

This dossier applies four methods published by the Software Engineering Institute at Carnegie Mellon University to one design problem, dispatch for in-home care. Each numbered section is a step of those methods, and the twelve figures are the views the methods call for.

The Quality Attribute Workshop (Barbacci, Ellison, Lattanze, Stafford, Weinstock, and Wood, 2003) supplies the requirements discipline: name the architectural drivers, then write scenarios in six parts, prioritize them, and refine the top few. Attribute-Driven Design (Wojcik, Bachmann, Bass, Clements, Merson, Nord, and Wood, 2006) supplies the design discipline: rank the drivers by importance and by impact on structure, choose a design concept from patterns and tactics, instantiate elements and allocate responsibilities, define interfaces, and verify. The Architecture Tradeoff Analysis Method (Kazman, Klein, and Clements, 2000) supplies the evaluation: a utility tree, then analysis of the architectural approaches that yields sensitivity points, tradeoff points, risks, and non-risks. Views and Beyond (Clements and colleagues) supplies the shape of the documentation: the relevant views first, then the information that applies across views, ordered how, what, why.

Three catalogs of architectural tactics name the design decisions in this document: the modifiability and performance tactics of Bachmann, Bass, and Klein (2002, 2003), and the availability tactics as refined by Scott and Kazman (2009). The 1995 taxonomy of quality attributes by Barbacci, Klein, Longstaff, and Weinstock supplies the vocabulary of concerns, factors, and methods for performance, dependability, and security. Two Carnegie Mellon courses supply the systems grounding: 15-445 Database Systems for transactions and concurrency control, and 15-440 Distributed Systems for time, synchronization, fault tolerance, and replication. The routing engine follows the constraint-based methods for vehicle routing presented by van Hoeve at the Tepper School of Business.

The views, in the terms of Views and Beyond: a context diagram (figure 02); a component-and-connector view of the running system (figure 03); a module view of the data (figure 04); a process view of planning (figure 05); behavior views as two sequences and a state machine (figures 06, 09, and 10); a module view of the client (figure 08); and two comparisons, transports and messages (figures 07 and 11). The board slice at the top is the artifact whose behavior the rest explains.

The Architecture Tradeoff Analysis Method opens with the business and mission drivers, and the Quality Attribute Workshop asks for the same presentation before any scenario is written: the context, the functional requirements, the constraints, and the stakeholders. Here they are for dispatch.

Business and mission goals

• More completed visits per clinician-day, with less time spent driving between them.
• Fewer missed visits, and a plan that survives the morning's cancellations without a dispatcher rebuilding it by hand.
• Patients told the truth about when someone arrives, and told it few enough times to keep reading.
• Records that pass an electronic visit verification audit and a payer's dispute without anyone editing history.
• New agencies onboarded by configuration, not by code.

Functional requirements

• Intake. Visits arrive from the electronic medical record (EMR), a partner API, or manual entry, with patient, service type, duration, time window, required skills, and recurrence.
• Plan. Each night, assign every visit to a clinician and sequence each clinician's day per territory. Dispatchers review, edit, publish.
• Board. A timeline per clinician and a map, drag to reassign, conflicts surfaced before publish.
• Track. Live location, visit status, schedule adherence, estimated arrival at the next stop.
• React. A cancellation opens a gap and proposes fills. A late visit cascades arrival estimates and notifies patients. An urgent add finds an insertion point.
• Clinician app. Today's route, hand-off to navigation, check-in and check-out with GPS and time, status, notes back to the EMR, all of it offline-capable.
• Patient messaging. Confirmation, reminder, morning window, arrival update, two-way replies.
• Audit and reporting. Who changed what and when; utilization, drive time, missed visits.

Design constraints

Attribute-Driven Design defines a constraint as a design decision with a predetermined outcome. Six are fixed before design begins.

• Multi-tenant software as a service: hundreds of agencies, each with territories, each fully isolated.
• The chosen stack: React and TypeScript on the web, React Native on phones, GraphQL with Apollo Client, Postgres, AWS, WebSockets and server-sent events.
• HIPAA for protected health information (PHI), and electronic visit verification (EVV) under the 21st Century Cures Act, which requires the service, the patient, the date, the location, the provider, and the start and end time of each Medicaid-funded visit.
• Clinicians lose signal constantly: basements, rural routes, hospital garages. Check-in and check-out must work offline.
• The EMR remains the clinical record. This platform owns scheduling and logistics, not the chart.
• Patients are reached by SMS first and voice second, through a messaging vendor under a business associate agreement.

Stakeholders

Dispatchers and schedulers on the web; clinicians in the field on phones; patients on their own phones; agency administrators who set policy; integration partners and EMR vendors; payers and auditors who read the visit record afterward; and the engineers who operate the platform. The method asks that scenarios come from all of them, not from the architect alone.

An architectural driver, in the glossary of Attribute-Driven Design, is any functional requirement, constraint, or quality attribute requirement that has a significant impact on the structure of the architecture. The method's third step ranks candidate drivers twice, once by importance to stakeholders and once by expected impact on structure, using high, medium, and low, and then picks five or six as the focus of design. The Quality Attribute Workshop reaches a similar list in its fourth step by distilling the business and architecture presentations.

Following the method's guidance to select five or six, the drivers rated high on both axes, board freshness, concurrent correctness, offline check-in, and intraday repair, together with operating without the optimizer and protecting PHI, are the architectural drivers that section 05 decomposes against. The rest are carried as requirements allocated to the elements that result.

The Quality Attribute Workshop insists that a quality goal is not a requirement until it is a scenario with a stimulus and a measurable response, and its eighth step refines each important scenario into six parts: the stimulus, the source of the stimulus, the environment, the artifact stimulated, the response, and the response measure. Attribute-Driven Design requires the same six parts before design can start. The workshop also asks that three kinds be covered: use case scenarios for anticipated uses, growth scenarios for anticipated change, and exploratory scenarios for stresses nobody planned for.

Performance scenarios need one more input. The 1995 taxonomy of quality attributes separates the concerns, latency, throughput, capacity, and modes, from the factors that determine them, chiefly the demand placed on the system as arrival patterns and execution times. The demand for dispatch is small everywhere but one place.

The scenarios below are the refined set. Each carries the six parts, its type, and the quality attribute it exercises. They are the leaves of the utility tree in section 04 and the test cases of the analysis in section 11.

The fifth step of the Architecture Tradeoff Analysis Method arranges the scenarios as a utility tree: utility at the root, the quality attributes beneath it, refinements beneath those, and scenarios at the leaves, each leaf rated twice, for importance to the success of the system and for the difficulty or risk of achieving it, on a high, medium, low scale. The tree tells the evaluation where to spend its limited time. Here it is for dispatch, with the leaves numbered as in section 03.

• Performance
  • Freshness of the board: S1, status to paint (H, H); S2, location to marker (H, M).
  • Responsiveness of the console: S10, the regional board (H, M).
  • Latency of repair: S7, a cancellation ten minutes out (H, H).
• Availability
  • Degraded modes: S4, the optimizer is down (H, M).
  • Connection loss: S6, the socket drops (H, M); S5, check-in with no signal (H, H).
  • Vendor outage: the messaging vendor is down, from the walkthroughs (M, M).
• Correctness and usability
  • Concurrent edits: S3, two dispatchers, one visit (H, H).
  • Honesty of the display: a marker that says how old it is, from the walkthroughs (H, L).
  • Message discipline: S11, the wobbling estimate (M, M).
• Security
  • Tenant isolation and PHI in telemetry: S8 (H, M).
  • PHI on a lost phone: remote revocation and cache purge, from the walkthroughs (H, L).
• Modifiability
  • Integrations: S9, a new EMR vendor (M, H).
  • Policy: a new agency's auto-apply rules and objective weights as configuration (M, M).
  • Compatibility: phones that update weeks late against an additive schema, from the walkthroughs (M, M).

Five leaves are rated high on both axes: S1, S3, S5, S7, and the pairing of S1 with S6 that makes the realtime path both fast and resumable. The deep dives in sections 06 through 10 follow those leaves, and the analysis in section 11 records what was found at each.

The fourth step of Attribute-Driven Design chooses a design concept: the major types of elements that will appear in the architecture and the relationships among them, selected from patterns and from architectural tactics that address each driver's design concerns. The fifth step instantiates those types and allocates responsibilities; the sixth defines interfaces as the provides and requires assumptions elements make about one another. A tactic, in the definition of Bachmann, Bass, and Klein, is a design decision that helps achieve a specific quality attribute response and that is motivated by an analysis model for that attribute. Patterns package several tactics; the tactic is the unit that can be analyzed.

The concept

Five patterns compose the design. A layered client-server arrangement puts a GraphQL gateway between every surface and every service, so authentication, tenant resolution, rate limiting, and idempotency live in one place. A publish-subscribe event bus carries facts, never commands: services publish what happened, and the realtime gateway, the push service, the notification service, and analytics consume. A single transactional writer, the scheduling service on Postgres, owns visits, assignments, and plan versions. A separate compute-bound process, the optimizer, proposes plans and repairs but applies nothing itself. Per-territory channels carry live events to consoles, authorized once at subscribe time.

The decisions that make those patterns meet the drivers are tactics from the Software Engineering Institute catalogs, named in the table. The modifiability and performance tactics are those of Bachmann, Bass, and Klein (2002, 2003); the availability tactics are the refined catalog of Scott and Kazman (2009); concurrency control follows the treatment in Carnegie Mellon's 15-445.

Three allocations of responsibility follow from the drivers and are worth stating as decisions in the sense of the method's fifth step. Pings never touch Postgres: they land in Redis for the latest position and in a time-series table with a seven-day time to live; the transactional database sees a visit's path only as a summary after check-out. The bus carries facts, not commands: nobody instructs the scheduling service over it, and commands arrive through the gateway with an actor and a version. The console holds two connections on purpose: queries and mutations over HTTP, where retries and caching are simple, and events over a socket that the page can lose without losing the page.

Interfaces

Attribute-Driven Design's sixth step defines interfaces as the services and properties each element provides and requires, including semantics, information exchanged, quality attribute requirements, and error handling, not signatures alone. The interface between the surfaces and the platform is a GraphQL schema, in the dialect of the chosen stack. Three properties of it carry requirements: mutations from phones carry an idempotency key, mutations from dispatchers carry the version they last saw, and the subscription takes a cursor so a reconnecting client can ask for what it missed.

• Errors as data. A version conflict is a normal outcome of two people dispatching, so it returns as a typed field the console can render, naming who changed the row and when, rather than as an error the client would have to parse.
• One day-scoped board query. The console loads one territory-day in one request; everything after that arrives as events. The normalized cache stays small and the subscription filter stays obvious.
• Partners get REST and webhooks. Visit creation over an idempotent endpoint, completion delivered by signed webhooks with retries. GraphQL is reserved for the platform's own surfaces, where the client is under the same control as the server.

The routing problem underneath dispatch is vehicle routing with time windows. In the constraint-programming treatment presented by van Hoeve at the Tepper School of Business, each visit is an activity with a start variable and a duration, each vehicle is a unary resource on which activities cannot overlap, travel times are sequence-dependent setup times between activities, and a time window bounds each start. Two facts from that work shape the design. Adding time windows makes the problem far harder than plain routing: exact methods handle on the order of a hundred locations. And constraint-based local search, which first constructs a feasible solution by a savings, sweep, or insertion heuristic and then improves it with moves that cut and reconnect a route, relocate a visit, or exchange visits between routes, finds good solutions to large instances within about a second.

One solver therefore cannot serve both jobs. The nightly plan is the whole territory's problem, allowed minutes and thorough search. The intraday repair is a local-search pass over the few visits still unlocked, allowed seconds, run while a dispatcher waits with a phone in hand.

Decisions in the planning element

• Objective. Minimize drive time and late arrivals, penalize breaking continuity of care, forbid skill and window violations as hard constraints. Agencies weight these differently, so the objective is configuration, not code: the raise-the-abstraction-level tactic applied to the solver.
• Travel-time matrix. The expensive input. It is cached by origin cell, destination cell, and time-of-day bucket, refreshed weekly, and queried live only for the next hop when an arrival estimate is computed. When the maps provider is unavailable, straight-line distance times a road factor stands in and the plan is marked as estimated travel.
• Explainability. Every proposal carries the constraint that forced it and the alternatives it rejected with their cost: which window would have closed, which credential was missing. A dispatcher who cannot see the reason overrides the proposal, and the override becomes a soft constraint the nightly plan learns from.
• Determinism. The solver is seeded and the run identifier is stored with the plan version, so a plan can be reproduced when someone asks why a patient was moved.
• Policy gate. Agencies set what auto-applies: a reorder that adds under five minutes of drive and moves no window may apply itself; a reassignment to a different clinician waits for a dispatcher. Clinical judgment stays human by configuration.

Scenarios S1, S2, and S6 trace this path. In the 1995 taxonomy's terms, the concern is latency and the factors are two event streams with different arrival patterns: status events, sporadic and rare, and location pings, periodic and plentiful. The performance tactics apply to the second stream and the availability tactics to the connection that carries both. The gateway pushes per territory, coalesces location, never coalesces status, and stamps every event with a monotonically increasing identifier so that a client can resume.

Why the gateway owns the channel

Clients subscribe to a territory-day and nothing finer. The gateway checks the subscriber's tenant and territory permissions once at subscribe time, then pushes everything on that channel; filtering per clinician on the client is cheap and keeps the authorization surface small. Presence, who is viewing the territory and who is dragging what, rides the same channel, which is what makes the two-dispatcher conflict in Deep dive C visible before it happens.

The transport as a tradeoff point

The chosen stack lists both WebSockets and server-sent events. The Architecture Tradeoff Analysis Method would call the transport a tradeoff point: a single decision to which more than one attribute is sensitive. Freshness and duplex messaging favor the socket; simplicity of infrastructure and behavior behind proxies favor the one-way stream; polling loses on both freshness and load.

The console is a board of clinician rows against a time axis, a map beside it, a drawer for the selected visit, and a strip of alerts. A large territory is 40 rows with 250 blocks; a regional view, scenario S10, is 400 rows and 3,000 blocks. Attribute-Driven Design applies to the client as it does to the server: the module view below is the result of choosing tactics for four drivers. One cache for server truth, with events written straight into it, is the information-hiding tactic. Rendering only what is visible is the tactic of controlling demand for resources. A worker for conflict detection is increased logical concurrency. And an interface that says when it is not sure is the honesty the display owes the dispatcher.

Why a normalized cache and not a plain store for server data

The hard problem is identity. A visit appears in a board row, on the map, in the drawer, and in an alert. With a cache normalized by type and identifier, one subscription event updates one entity and every view that reads it re-renders, with no reducer to keep in step. A conventional store keeps interface state: selection, drag ghost, filters, panel layout, connection status. Kept apart, the two can never hold a stale copy of the same server field.

How events land

The subscription handler switches on the event type and modifies the affected entity in the cache, or updates the board query when an assignment moves between rows. Location events are throttled on the client as well, coalesced per clinician and flushed once per animation frame, so 35 clinicians updating cannot cause 35 renders in a burst. Status events bypass the throttle and apply immediately.

The rendering budget

• Rows are virtualized. A 400-row regional view renders about 25. Row height is fixed so scrolling is arithmetic.
• Blocks are absolutely positioned by minutes since the day start times pixels per minute, inside a row that is one flex container. Dragging updates a transform on the ghost only; nothing else lays out until drop.
• Conflict detection moves to a worker above about a thousand blocks: overlap, skill mismatch, window violation, shift overrun. The worker returns a diff of conflict flags, not a new tree.
• The map batches. Marker positions go through the map library's feature state in one call per frame, clustering begins above 200 points, and off-screen territories are not subscribed at all.
• Budgets, stated. Interaction under 100 milliseconds, drag at 60 frames a second, event to paint under 500 milliseconds on an office laptop, first board under three seconds on a cold load.

Concurrency control, by the book

Carnegie Mellon's 15-445 divides concurrency control protocols into pessimistic ones, which prevent conflicts from arising, and optimistic ones, which assume conflicts are rare and deal with them when they happen. The failure both guard against is the write-write conflict, the lost update, in which one transaction overwrites another's change. Dispatching has rare conflicts and long-lived intentions: a dispatcher may hold a drag for seconds, and a laptop may sleep holding a lock forever. The optimistic protocol fits. The version on the assignment row is the validation: a write that names a version no longer current is refused in the same statement that would have applied it, and no lost update is possible.

Honesty about staleness

The connection is a small state machine: live, reconnecting after a missed heartbeat, stale after 30 seconds without a resume. The banner names the state and the age of the data. Each clinician marker carries its own last-seen time, so a phone that died in a basement shows as last seen twelve minutes ago, in amber, rather than as a confident dot in the wrong driveway. Adherence chips are computed from planned versus actual, and a block whose actual start is unknown is drawn hollow, not green.

Accessibility that survives a busy office

Every drag has a keyboard path: select a block, press a key, pick a row, confirm. Critical alerts, a missed check-in or a conflict, go to an assertive live region; location updates never do. Status is never color alone: the late block carries its text and the cancelled block its hatch. Contrast is checked in every page tone, because dispatch offices run dark screens at 6 a.m.

Testing and observability

Components are tested against mocked GraphQL handlers, including a subscription mock that replays a recorded morning. Drag and keyboard reassignment run in a browser harness. Types are generated from the schema, so a schema change fails the build rather than the dispatcher. In production, real-user monitoring records event-to-paint latency and long tasks; error reports arrive with PHI stripped before they leave the browser, and the URL never carries a patient name because routes use identifiers.

Sharing with the phone

The schema, the generated types, the data hooks, and the domain selectors are one package that both applications import. The screens are not shared. The phone needs a list of stops and two large buttons; the console needs a board. The shared layer is where the visit state machine lives, so both surfaces agree on what a transition means.

The phone is the source of electronic visit verification facts and of nothing else. It does not decide assignments; it records what happened to the visit it was given, with a GPS fix and a timestamp, and it must do that in a basement. Scenario S5 is the driver. The design is a visit state machine that runs locally and an outbox that delivers its transitions in order when the network returns, which is the availability catalog's transactions tactic for the local write and its checkpoint-based rollback for survival across an app kill.

Decisions in the mobile element

• Cache the day, not the world. At shift start the app pulls its route and caches it in encrypted storage. If the network dies at 8:05 the whole day is still on the phone.
• Delivery semantics. 15-440 teaches that a network can deliver a message zero, one, or many times, and that the receiver decides what a retry means. The outbox retries with exponential backoff, strictly in order, and the server deduplicates by client event id, turning at-least-once transport into exactly-once recording.
• Two clocks. Physical clocks drift and are set wrong. The record keeps the device time and the server's receipt time, flags a difference above five minutes, and lets the verification record carry both rather than choosing.
• Location is adaptive. Every 15 seconds en route, every two minutes during a visit, off outside the shift, in batches of up to ten points every 30 seconds. This is the control-the-sampling-frequency tactic applied to a battery: the difference between a usable phone at 4 p.m. and a dead one.
• Reassignment while offline. If the server moved a visit to another clinician at 9:00 and the original clinician, offline, checked into it at 9:02, the server keeps her verification record, marks the visit as an exception, and puts it on the dispatcher's board. Nobody's evidence is discarded.
• PHI on a phone. Biometric unlock, no patient names in push notification bodies, redacted application-switcher snapshots, tokens in the platform keystore, and a remote wipe that revokes the refresh token and purges the cache on next launch.

Every message is triggered by an event the system already produces, so the notification service is a consumer with templates and rules, not a new source of truth. Scenario S11 governs its discipline. The tactics are the performance catalog's: manage the event rate through hysteresis, bound the queue through a time to live, and make sends idempotent so a replayed event cannot text twice.

• Idempotent sends. The key is the visit, the message type, and the window. A retried event cannot send twice.
• Consent is data. SMS requires opt-in under the Telephone Consumer Protection Act; the patient row carries it, and the notification service refuses to send without it.
• Reply parsing is deliberately simple. Single letters and digits; everything else is routed to a person. A free-text reply about a hospitalized spouse is not a parsing problem.
• Vendor outage. Messages queue with a time to live; a morning window that cannot be delivered by 9:00 is dropped and the dispatcher is told, rather than sent at 10:15 when it is wrong.

The Architecture Tradeoff Analysis Method produces four kinds of finding. A sensitivity point is a property of one or more elements that is critical to achieving a particular quality attribute response. A tradeoff point is a property that is a sensitivity point for more than one attribute, so that changing it improves one response and worsens another. A risk is an architecturally important decision not yet made, or made without its consequences understood. A non-risk is a good decision that rests on assumptions which must remain true. The method asks that each be recorded with the decision, the response it affects, and the rationale.

Sensitivity points

Tradeoff points

Risks and their mitigations

Non-risks, and the assumptions they rest on

The eighth step of the Architecture Tradeoff Analysis Method takes the scenarios stakeholders brainstormed, ranks them, and traces each through the architecture as a test case. These thirteen were traced. Each opens to the path the system takes.

The method, its steps, and its vocabulary come from the following publications of the Software Engineering Institute and courses of Carnegie Mellon University, all publicly available. The design of the dispatch platform, its scenarios, tables, and figures are this document's own application of them; no text is reproduced from the sources.

Software Engineering Institute technical reports

• Mario R. Barbacci, Robert Ellison, Anthony J. Lattanze, Judith A. Stafford, Charles B. Weinstock, and William G. Wood. Quality Attribute Workshops (QAWs), Third Edition. CMU/SEI-2003-TR-016, August 2003. PDF. The six-part scenario, the three scenario types, and the eight workshop steps.
• Rick Kazman, Mark Klein, and Paul Clements. ATAM: Method for Architecture Evaluation. CMU/SEI-2000-TR-004, August 2000. PDF. The nine steps, the utility tree with its two-axis rating, and the outputs: risks, non-risks, sensitivity points, tradeoff points.
• Rob Wojcik, Felix Bachmann, Len Bass, Paul Clements, Paulo Merson, Robert Nord, and Bill Wood. Attribute-Driven Design (ADD), Version 2.0. CMU/SEI-2006-TR-023, November 2006. PDF. The eight design steps, the two-axis ranking of candidate drivers, design concepts from patterns and tactics, and interfaces as provides and requires assumptions.
• Felix Bachmann, Len Bass, and Mark Klein. Illuminating the Fundamental Contributors to Software Architecture Quality. CMU/SEI-2002-TR-025, August 2002. PDF. The definition of an architectural tactic and the modifiability and performance tactics.
• Felix Bachmann, Len Bass, and Mark Klein. Deriving Architectural Tactics: A Step Toward Methodical Architectural Design. CMU/SEI-2003-TR-004, March 2003. PDF. General and concrete scenarios, reasoning frameworks, and the tactics that control their parameters.
• James Scott and Rick Kazman. Realizing and Refining Architectural Tactics: Availability. CMU/SEI-2009-TR-006, August 2009. KiltHub. The refined availability catalog: fault detection, recovery, reintroduction, and prevention.
• Mario Barbacci, Mark H. Klein, Thomas A. Longstaff, and Charles B. Weinstock. Quality Attributes. CMU/SEI-95-TR-021, December 1995. PDF. The taxonomy of concerns, factors, and methods for performance, dependability, security, and safety.
• Software Engineering Institute. Views and Beyond: The SEI Approach to Architecture Documentation. 2018. PDF. Views as the organizing principle; the how, what, why order of documentation.

Carnegie Mellon course material

• Andy Pavlo. 15-445/645 Database Systems, Lecture 17: Concurrency Control Theory. Fall 2025. Notes; and Multi-Version Concurrency Control slides, Fall 2022. Transactions, the lost update, pessimistic and optimistic protocols, serializability.
• David Andersen and colleagues. 15-440 Distributed Systems, Spring 2014. Syllabus. Time and synchronization, fault tolerance, replication, and the systems principles of modularity and naming.
• Willem-Jan van Hoeve. Constraint-based solution methods for vehicle routing problems. Tepper School of Business, EWO seminar, November 2009. PDF. Routing with time windows as scheduling on a unary resource; constraint-based local search for large instances.

Each report carries Carnegie Mellon University's copyright and its no-warranty statement; the Architecture Tradeoff Analysis Method, ATAM, and Carnegie Mellon are marks of Carnegie Mellon University. The files consulted, their hashes, and the date of retrieval are recorded with this edition's source.