Manage care between visits. Keep experience and outcomes in view.

Between appointments, a person's experience can change. A care team needs a clear way to review what they share and keep the next step visible. This is a demonstration of PulseMD Care using fictional people and illustrative data. Start with the heart failure team's caseload. It brings together the reason someone needs attention, the person responsible, the due time and their check-in history. The team's review hours are shown here too. These are patient-reported check-ins, reviewed through the service's arrangements. Wiremu's response has triggered an urgent follow-up under a configured rule. Open his record and the context stays with him: who answers, his programme, the responsible clinician and the review hours. Ben is responsible, and the follow-up is already in progress. In Check-ins and scores, we can read the actual answers. Wiremu says he feels worse and reports breathlessness lying flat or at night. The screen preserves his response to the contact question as well. A rule helps route the response for human review; it does not make a diagnosis or decide treatment. Now open Follow-ups. Ben has recorded a phone call with no answer, and a note that he will try the landline next. That distinction matters. An attempted call is part of the record, while the follow-up remains in progress. The contact form gives the team a place to record what happened and the next step. Here we are previewing that workflow. We are not making a call or recording a new clinical outcome. Back on the person record, responsibility and the outstanding follow-up remain visible. The team can return to the same context instead of reconstructing it from separate notes and messages. PulseMD Care supports that continuing relationship: hear what the person reports, review it in context and organise follow-up. The service sets its response process and coverage. Stay connected between visits.

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.