The doctor’s whole chronic panel: who is overdue, who is slipping.
Analytics · Full PHI · General PracticeThe panel view — one row per enrolled chronic patient rather than one per task, carrying how many milestones they have missed, how many days behind the oldest is, and when anybody last saw them, furthest behind first — ships inside Care Plans rather than as an app of its own: it reads that app’s enrolments and milestones and keeps no register, so a second table would have been a second copy of the same facts. What is left of this idea is the part that needs data the product does not hold: deteriorating trends across a condition, and prescriptions dispensed elsewhere.
It does not score or grade a patient, because the thresholds that would do it are clinical guidelines and none is typed into this product. It does not drop somebody for being unreachable: "not seen since it fell due" is a fact about the visit record, and it keeps them on the list rather than off it.
Every app page carries this section. A listing with only benefits is an advertisement.PanelManager reads programme states, visit history and writes nothing — it is a read. Its data class is Full PHI. Every app works on the same patient record — nothing is copied into a silo.
It does not score or grade a patient, because the thresholds that would do it are clinical guidelines and none is typed into this product. It does not drop somebody for being unreachable: "not seen since it fell due" is a fact about the visit record, and it keeps them on the list rather than off it.
All clinical data stays in the record; operational history stays queryable.
PanelManager is in design: the surface exists and the platform underneath is ready. Join the waitlist and it moves up the build order.
Tell us what you run and we will show you this app inside a practice shaped like yours — or answer the question the page above did not.