MedQueue: Choosing Views for Offline Clinic Scheduling
MedQueue schedules appointments for 600 clinics and handles 18,000 bookings per day. Clinics lose connectivity for up to four hours; schedulers must still book, cancel, and check insurance eligibility offline, then reconcile without double-booking. The system must exchange HL7 v2 and FHIR R4 messages, retain an audit trail for seven years, and meet a 2-second p95 response for local booking. Twelve developers maintain it, and three regulator audits occur each year. The lead architect wants to model everything in UML class diagrams because the team knows UML; the product owner wants C4 diagrams; the security officer needs data-flow views. A previous architecture document was a 180-page Word file that nobody updated. The system is being re-platformed to Kubernetes over 18 months, with a hard cutover for 120 clinics in the first release.
1. Select the architecture viewpoints and model kinds for the re-platforming. Justify each against a named stakeholder concern, and state what you would deliberately not model.
Read the worked answer
Use views for concerns, not completeness
The correct question is which decisions are risky and which stakeholders need to reason about them. A complete class model would not answer the offline, security, or cutover concerns.
Viewpoints and model kinds
- Context viewpoint (C4 level 1): product owner and clinic operations need the system boundary, actors, HL7/FHIR gateways, and external insurers.
- Container viewpoint (C4 level 2): developers and operations need the deployable units, Kubernetes workloads, data stores, and message flows.
- Component viewpoint: developers need the booking, eligibility, sync, and reconciliation components and their interfaces.
- Deployment viewpoint: operations need cluster, region, clinic-edge, and network-failure topology for the 120-clinic cutover.
- Data-flow viewpoint: the security officer needs where patient data crosses trust boundaries and where encryption applies.
- Information viewpoint: regulators and developers need the appointment, eligibility, and audit entities, retention rules, and HL7/FHIR mappings.
- State machine and sequence models: developers and clinic staff need offline booking, queuing, reconnection, and conflict resolution behavior.
Deliberately not model
Do not model every class, UI screen, or internal algorithm. Do not produce a static 180-page document. Model only unstable or high-risk areas and link each view to the concern it answers.
Selection rule
Each view must have a named stakeholder, a concern, and a decision it supports. If a view does not change a decision, it is decoration.
2. Write one quality-attribute scenario for offline booking and explain how a model would let you test the design against it before implementation.
Read the worked answer
Scenario
Source: a clinic scheduler. Stimulus: connectivity is lost for four hours during the morning peak. Artifact: the appointment booking and reconciliation service. Environment: normal clinic load, with 30 bookings attempted offline. Response: bookings are accepted locally, queued, and reconciled on reconnection without double-booking. Measure: 100% of attempts receive a local confirmation or a clear rejection; zero double-bookings; 95% reconciled within two minutes of reconnection.
Why this is testable
The scenario names a source, stimulus, artifact, environment, response, and measure. It can be turned into a test rather than a vague requirement such as "works offline".
How the model helps
A state machine for the appointment lifecycle shows local-pending, confirmed, conflicted, and cancelled states. A sequence model shows the clinic edge queue, idempotency keys, server acknowledgement, and conflict resolution. Walking the scenario through the model exposes questions: what happens if two clinics book the last slot, whether eligibility checks are cached, and whether a timeout creates a duplicate. These become design decisions and test cases.
Validation before implementation
Simulate a network partition against the model, inject duplicate submissions, and review the conflict rules with clinic staff. If the model cannot show a deterministic resolution, the design is not ready. Add the scenario to the acceptance suite and monitor reconciliation lag after cutover.
3. What model-drift risks exist over an 18-month programme, and what concrete practices keep the models trustworthy?
Read the worked answer
Drift risks
The re-platforming changes deployment topology, service boundaries, and data flows faster than manual diagrams can follow. Multiple owners, contractor turnover, and a hard cutover for 120 clinics increase the chance that diagrams describe an obsolete design. A 180-page document is especially vulnerable because no one can tell which page is current.
Practices that work
- Model as code: keep C4, deployment, and data-flow definitions in a version-controlled repository and generate rendered views.
- Generate from source where possible: extract service dependencies, Kubernetes manifests, and data stores automatically.
- Review models in pull requests: a change that alters a boundary or data flow must update the relevant view or record an explicit waiver.
- Limit scope: maintain only views tied to named concerns and decisions.
- Assign ownership and review dates: each view has an owner and an expiry; stale views are flagged, not silently trusted.
- Link decisions to views: architecture decision records explain why a boundary exists and when it should be revisited.
- Run architecture tests: dependency rules, forbidden calls, and encryption boundaries checked in CI.
- Provide one entry point: a portal that shows current views, decisions, and known gaps.
Trust signal
A model is trustworthy when a developer can use it to predict a deployment or a security review outcome. If the model cannot support that, fix or retire it rather than expanding it.