Programme design and measurement

A care programme needs more than a set of questions. It needs a purpose, a schedule, people who will review the answers, and a clear account of what its results mean. This walkthrough uses Te Awa Health’s fictional heart failure recovery programme. Its symptom score and results are illustrative, not a claim about a validated clinical measure or customer outcomes. The programme page brings participation and current work together. People remain on the version they joined. A published version can be in use while changes are being prepared in a draft. The cohort shows check-in history and any reason for attention, linking the programme design to the team’s everyday work. Open the existing draft to see the design steps. The programme begins with a template, then covers who joins, anchors and timepoints, measures, review rules, messages and review hours. The participant preview sits alongside the configuration. That lets the team connect each design decision with what a person will actually see. The published schedule uses discharge as its anchor. It asks at discharge, six weeks, three months and six months. Each point has an answer window, and the primary comparison is identified. The table shows which measure, heartbeat and custom questions are included, together with the expected effort. Timing is part of the meaning of the result, not just a reminder setting. Review and rules define how the team handles responses. Here the mode is every response read. The configured rules include a request for contact, breathlessness at night, and a change in the symptom score. Clinical rules show a named approver and a review date. An operational rule covers repeated closed windows without an answer. These rules create work for people; they do not replace clinical judgement. Review hours and routing belong to the care team. The programme’s participant wording explains who reads answers, while urgent-help information remains visible. A service needs a workable review commitment, including what happens outside those hours. The software makes that arrangement explicit, rather than implying that an online answer is monitored continuously. Before reading outcomes, look at response. The table separates answered, missed, not sent and skipped check-ins. In this example, the six-week and three-month windows each have fourteen answers from sixteen closed windows. A skipped check-in is excluded from the rate. A check-in that was never sent is a team-side gap, rather than a failure attributed to the person. The outcomes view starts with the funnel. Seventeen people have an in-window baseline, sixteen have reached a closed primary window, and fourteen have a paired result. That is the group the comparison describes. The chart keeps the full score scale and shows separate timepoint groups. It does not draw a continuous line that implies every point contains exactly the same people. The paired comparison shows a mean change and an uncertainty interval. The page also warns that people who answer at follow-up may differ from those who do not, and that these figures are not adjusted for case mix. Small groups are suppressed. In this demo, the numbers illustrate how a result is presented; they do not establish that the service caused a clinical benefit. Return to the cohort and the design has a practical purpose. Questions arrive at meaningful points, review arrangements are visible, and the team can see outstanding follow-up alongside participation. A programme can be refined without silently rewriting the version that existing people joined. PulseMD brings programme design, everyday response and measurement into one connected workflow. The value is a clearer account of what was asked, who was heard, what the team did, and what the resulting evidence can support.