BIDH5000 Chap.1 Digital Health Systems and Project Framing
Digital Health Systems and Project Framing
Digital health projects need a health and service problem before they need a product. This chapter maps individual, team, organisational and system factors, identifies stakeholders by their relationship to change, and defines a boundary that keeps the proposal honest. It then turns the frame into a chain of decisions about evidence, workflow, trade-offs and evaluation.
The central discipline is to separate an observable current-state gap from a preferred technical solution. Begin by reconstructing a pathway from the viewpoint of people receiving and delivering care. Describe triggers, decisions, handoffs, delays, workarounds and consequences before suggesting a feature.
A missed appointment may reflect confusing instructions, fragmented responsibility, transport difficulty, language, clinic capacity or several interacting mechanisms. Each explanation demands different evidence and a different response. The frame should preserve that uncertainty rather than collapsing it into a convenient technology problem. Stakeholder analysis also needs precision.
Name who uses the intervention, who supplies data, who changes work, who authorises resources, who receives benefits and who remains accountable for harm. Give each stakeholder a real decision and record where the distribution of benefit and burden differs. Boundaries make the project feasible, but they must not hide dependencies.
State the service setting, pathway segment, included groups and decisions that the team can influence, then identify external conditions such as connectivity, policy or workforce capacity. Turn the final frame into a decision chain. For every proposed element, record the evidence supporting it, the expected mechanism, the trade-off accepted, the owner responsible and the signal that would force revision.
This chain supports the draft plan, makes presentation questions answerable and gives the final plan a coherent structure.
What this chapter covers
- 01
Health and service problem framing
- 02
Individual, organisational and system factors
- 03
Stakeholder decisions and distributed burden
- 04
Workflow boundaries and external dependencies
- 05
Mechanisms, trade-offs and refutation signals
- 06
Project evidence and decision logs
Reframing missed follow-up after discharge
- 2State the observable gap, affected groups, setting and consequence without naming a product.
- 2Map workflow, stakeholder decisions and evidence needed to explain the mechanism.
- 2Set a boundary, identify one external dependency and name a revision trigger.
Key terms
- Problem frame
- A bounded description of an observable health or service gap, its context, affected groups and consequences.
- System boundary
- The explicit limit around the pathway, setting, groups and decisions included in the project.
- Stakeholder
- A person or group that uses, affects, authorises, supports or experiences consequences from the intervention.
- Mechanism
- The process through which an intervention is expected to change work, behaviour or care.
- External dependency
- A condition outside direct project control that can still determine implementation or outcomes.
- Decision log
- A traceable record of choices, evidence, alternatives, owners and reasons for revision.
Digital Health Systems and Project Framing FAQ
Why should a project avoid starting with a product?
A product-first frame hides alternative explanations and interventions. Describing the health gap, workflow and affected groups first lets the team test whether technology is necessary and which combination of service and technical changes addresses the mechanism.
How detailed should a stakeholder map be?
Map stakeholders by decisions and consequences rather than titles alone. Include users, people receiving effects, data suppliers, workflow owners, resource authorities and people accountable for harm. Record where benefit and burden fall differently.
What makes a system boundary defensible?
It states what pathway and setting are included, which groups and decisions are examined, and which dependencies remain outside control. A good boundary supports feasible work without pretending that excluded factors are irrelevant.
How does framing support assessment work?
A clear frame gives the draft and final plans a stable logic. It also makes presentation questions easier to answer because each feature can be traced to evidence, a stakeholder decision and an expected change in workflow or care.
Assessment move
Choose one fictional digital health service and write its frame in one paragraph. Remove every product noun, then test whether the health problem remains clear. Draw the current pathway and annotate actors, decisions, waits, workarounds and external dependencies. For every proposed feature, write the evidence that justifies it and the signal that would cause revision.
Rehearse explaining the project to a patient representative, clinician, manager and technical lead because each role exposes different assumptions. Build a four-column audit with claim, supporting observation, alternative explanation and next decision. Challenge the frame by changing the setting or access conditions and note which assumptions fail.
Compare two interventions that address different mechanisms rather than polishing the first idea. End with a one-minute spoken explanation that names the problem, boundary, stakeholder conflict and evidence still required. If the explanation becomes a list of features, return to the current-state pathway and rewrite it.
Keep the final boundary beside the proposal while drafting so later sections cannot quietly expand the population, setting or promised outcome beyond the evidence.
