Where you draw a boundary determines what you have to prove. That decision is usually made before sprint one, and usually for technical reasons.
The usual approach
- Split by team or stack preference.
- Apply safety classification after the boundaries are set.
- Keep clinical logic and reporting logic in the same service.
- Result: Class C verification burden on code that is Class A.
The better approach
- Draw boundaries around clinical risk, not around teams.
- Let classification drive decomposition first.
- Isolate Class C, so Class A never inherits its burden.
- Result: verification scope is precise and change control stays manageable.
What it costs to get this wrong
A service that mixes classes carries Class C verification on every change, for as long as it exists. IEC 62304 Edition 2 moves toward process rigor levels, but the obligation is the same: the more serious the consequence, the more evidence each change needs.
Before you architect, ask: what is the safety classification inside each boundary, and does the boundary isolate clinical risk or spread it?
Seen this differently?
Questions, corrections and counterexamples are welcome.
