Summary
Introduction
The rapid shift toward distributed healthcare—where care occurs in homes and communities via messaging apps—has created a "data messiness" crisis. While these informal platforms are accessible, they produce fragmented, unstructured, and unauditable information. This study/proposal outlines a governable architecture designed to bridge the gap between rich but messy informal communication and the rigid, episodic nature of formal Electronic Health Records (EHR), while ensuring compliance with emerging regulations like the DPDP Act.
Methods
The proposed solution uses a minimal, role-based communication architecture centered on four design primitives:
Defined Roles: Explicitly identifying the Patient, Patient Advocate, Clinician, Contributor, and AI.
Three-Lane Architecture: Separating communication into the Circle of Care (input), Clinical Discussion (reasoning), and PaJR Record (knowledge).
Data Contracts: Rules governing what data is permitted in each lane and how it is transformed (e.g., de-identification, summarization).
Governance by Design: Embedding auditability and authority directly into the communication flow.
Results
Through case vignettes (e.g., "The Dizziness That Wouldn’t Settle"), the text demonstrates that introducing a Patient Advocate as a "signal generator" reduces noise. In the synthetic and real-world examples provided, the transition from unstructured messaging (50+ fragmented texts) to a structured "Patient Advocate" update resulted in:
Immediate clinical clarity regarding symptom onset and severity.
Reduced cognitive load for clinicians by shielding them from non-clinical family chatter.
A traceable path from observation to a validated clinical decision (e.g., medication adjustment or emergency referral).
Discussion
The tension remains between the current "messy" reality and the future of "Orwellian" ambient AI. Currently, the system relies on the human Patient Advocate (often a family member) who faces a steep learning curve. The text concludes that until ambient AI matures enough to handle seamless data collection and de-identification, the "Three-Lane" system serves as a necessary transition. It balances the need for "real evidentiary meaning" (as opposed to synthetic data) with the practical constraints of modern, resource-limited healthcare ecosystems.
Keywords
Distributed Care; Patient Journey Record (PaJR); Patient Advocate; DPDP Act Compliance; Asynchronous Interface; Clinical Reasoning; Data Minimization; Ambient AI; Case-Based Reasoning; Governance by Design.
Thematic Analysis
1. The "Messy" Input vs. Clinical Signal
There is a fundamental conflict between the "lived experience" of a patient (which is messy, anecdotal, and continuous) and the "clinical evidence" required for a diagnosis. The text highlights that "real learning insights" can only come from real patient data, but this data is currently trapped in unstructured messaging threads.
2. The Human-AI Gap (The "Orwellian" Wait)
A recurring theme is the wait for Ambient AI. The participants acknowledge that while AI could eventually solve the data-gathering problem through "Orwellian" (omnipresent) monitoring and automated de-identification, we are currently in an awkward middle phase. In this phase, humans—specifically patient advocates—must perform the "pre-processing" of data, a task that is labor-intensive and has a high barrier to entry.
3. Spatial Organization of Communication
The "Three-Lane" model is a thematic response to the chaos of a single chat thread. By creating "Lanes," the architecture imposes a hierarchy of truth:
Circle of Care: The messy, human reality.
Clinical Discussion: The analytical, de-identified reasoning space.
PaJR: The finalized, immutable legal record.
This separation ensures that governance is not an afterthought but is built into the geography of the digital conversation.
4. Regulatory Safeguards (DPDP) vs. Practice
The text emphasizes that the architecture must be "DPDP Act and Rules compliant." The theme here is Privacy by Design. By forcing data to be de-identified before moving from the "Circle of Care" to "Clinical Discussion," the system attempts to protect patient privacy without sacrificing the "meaningful closure" that comes from analyzing real-world events.
5. The Steep Learning Curve of Advocacy
Finally, there is a socio-technical theme: the "single patient advocate" is a bottleneck. Whether it is a family member or a community health worker, the system’s success depends on a human’s ability to navigate a complex interface. The "tension" lies in the realization that we are currently asking laypeople to act as professional data-entry bridges until technology can finally "steal this job."
From: hu2
Date: Sun, 3 May 2026, 18:15
The first case is a synthetic example but based on actual cases.On Sun, 3 May 2026 at 3:56 PM hu2 wrote:Okay I was probably also wondering if the first example was from any real patient data.Our current challenge is the key operational step that you suggested which we have been aware of earlier:...the designation of a single patient advocate for each episode of care. This does not exclude others from participating, but it creates a focal point for communication. Information from multiple sources is consolidated through the advocate before entering the next stage of the system.So currently that single patient advocate is often a family member negotiating a steep learning curve. We don't have resources to get other humans who can do the same job and AI may not be able to steal this job yet!On Sun, 3 May 2026, 15:23 hu1 wrote:Please do it or have it done to decide what is claimed is indeed doable and practicable.On Sun, 3 May 2026 at 11:37 AM hu2 wrote:This is very nice but we need to share the real patient data from one single prospectively archived (deidentified) case and then discuss what can be rectified in that retrospectively instead of two hypothetical cases because real learning insights can only come from the real patient events that evolved?On Sun, 3 May 2026, 08:50 hu1 wrote:I am trying to reimagine the system that you use so that it becomes DPDP Act and Rules compliant. These are my thoughts in the form of a book chapter:
CHAPTER:
From Conversation to System: Designing a Governable Architecture for Distributed Care
Epigraph
“In modern care, the patient journey is not recorded—it is reconstructed from fragments. This chapter is about turning fragments into a system.”
Chapter Overview
Healthcare delivery is increasingly distributed across homes, communities, and institutions, mediated by digital communication. In many real-world settings, especially those with limited resources, care coordination occurs through informal messaging systems that connect patients, caregivers, community health workers, and clinicians.
These systems are powerful but structurally fragile. Information is fragmented, reasoning is implicit, and accountability is diffuse. At the same time, formal systems such as electronic health records provide structure and auditability but often fail to capture the continuous, contextual nature of real-world care.
This chapter presents a minimal, role-based communication architecture that bridges this gap. By separating communication into input, reasoning, and record layers, and by defining roles, data constraints, and governance mechanisms, the model transforms informal messaging workflows into structured, auditable systems. It integrates:
- The Patient Journey Record (PaJR) as structured memory
- CBBLE as a framework for contextual clinical reasoning
- A patient advocate role as a bridge between lived experience and clinical interpretation
- AI-assisted tools as non-authoritative computational support
- Governance by design, aligned with emerging data protection frameworks
The goal is not to introduce a new platform, but to organise existing practices into a coherent system that is scalable, safe, and usable in resource-constrained environments.
Chapter Objectives
By the end of this chapter, the reader will be able to:
- Understand the limitations of unstructured, messaging-based care coordination
- Describe the role of patient advocates in distributed care systems
- Explain the three-lane communication architecture (Circle of Care, Clinical Discussion, PaJR Record)
- Identify how data is transformed across communication layers
- Understand how roles, authority, and participation are separated
- Describe the integration of AI as assistive, non-authoritative support
- Explain how governance (including DPDP principles) can be embedded within system design
- Apply the model to real-world distributed care scenarios
Keywords
Distributed care; Patient Journey Record (PaJR); CBBLE; patient advocate; community health worker; clinical communication; telehealth; messaging systems; governance by design; data minimisation; auditability; AI in healthcare; decision support; health systems design
1.1 The Problem: Care Without Structure
Care no longer occurs within the boundaries of a clinic. It unfolds across time and space—through conversations, observations, and decisions distributed among multiple actors. Messaging platforms have emerged as the default infrastructure for this coordination, particularly in settings where formal systems are inaccessible or insufficiently responsive.
These platforms enable a form of care that is continuous, responsive, and context-rich. A caregiver can report a symptom in real time; a clinician can respond asynchronously; a community health worker can provide follow-up. The system, in effect, becomes a living network of interactions.
Yet this apparent flexibility conceals a structural weakness.
Clinical information is embedded within unstructured message streams. Symptoms, observations, questions, and decisions are interwoven in ways that make systematic interpretation difficult. Clinicians must reconstruct patient status from fragments, often repeatedly. Decision-making is rarely explicit, and responsibility is distributed rather than defined.
From a governance perspective, the challenges are equally significant. Consent is implicit, data flows are uncontrolled, and auditability is limited. As regulatory frameworks such as the Digital Personal Data Protection (DPDP) Act evolve, these informal systems face increasing scrutiny.
At the other end of the spectrum, formal systems such as electronic health records offer structure, standardisation, and auditability. However, they are typically episodic and institution-bound. They capture snapshots of care rather than the continuous narrative of a patient’s journey.
The result is a fundamental disconnect:
- Informal systems are rich but unstructured
- Formal systems are structured but incomplete
This gap is not merely technical—it is conceptual. It reflects the absence of an architecture that can organise distributed care without suppressing its contextual richness.
Box 1.1 — Case vignette: When communication fragments care
An adult patient recently discharged after a hospital admission begins to experience persistent giddiness at home. A family member posts a message in a messaging group that includes multiple relatives and clinicians.
Over the next 24 hours, more than fifty messages are exchanged. The patient reports dizziness again, another family member shares a photograph of medications, and a third asks whether food intake might be the cause. Clinicians respond intermittently, asking clarifying questions and suggesting possibilities. Some responses are repeated because earlier messages are missed within the thread.
At no point is there a clear summary of:
- When the symptom began
- Whether it is improving or worsening
- Which medications have recently changed
A possible medication-related cause is suggested, but no explicit decision is recorded. By the end of the day, the conversation has grown, but clarity has not.
(Box ends)
This vignette illustrates how unstructured messaging mixes observation, interpretation, and decision into a single stream, making clinical reasoning and accountability difficult to sustain.
Case Title
“The Dizziness That Wouldn’t Settle” — A Distributed Care Journey
(Case ends)Case 1.1 — Fragmented Beginnings
A 62-year-old man, recently discharged after treatment for a cardiac condition, develops giddiness at home. His family uses a messaging group that includes relatives and a few clinicians.
Messages begin to accumulate:
- “He feels dizzy again.”
- “Maybe because he didn’t eat.”
- “BP was low yesterday.”
- A photo of medications is shared.
- Another message asks if he should stop a drug.
Over the next 24 hours, more than 40 messages are exchanged. Clinicians respond intermittently, asking for details that are already buried in the thread. Some suggestions are repeated. Others are missed.
No single message clearly states:
- When the symptom started
- Whether it is improving or worsening
- What medications changed recently
A possible drug-related cause is mentioned, but no explicit decision is recorded.
By the end of the day, there is more communication—but less clarity.
This illustrates how unstructured messaging mixes observation, reasoning, and decision, making care difficult to coordinate.
1.2 The Missing Layer: From Communication to Architecture
Existing approaches address parts of the problem:
- Messaging systems enable communication
- Community health workers provide mediation
- Multidisciplinary teams structure reasoning
- Electronic health records enable documentation
But these elements operate in isolation. What is missing is a unifying architecture that connects them.
Such an architecture must answer four fundamental questions:
- Who participates, and with what authority?
- Where does each type of communication occur?
- What data is allowed at each stage?
- How is governance enforced without disrupting care?
This chapter proposes that these questions can be answered through a minimal set of design primitives:
- Roles (patient, advocate, clinician, contributor, AI)
- Lanes (input, reasoning, record)
- Data contracts (what data flows where)
- Governance and enforcement mechanisms
Together, these transform communication from an informal activity into a structured system.
1.3 Patient Advocacy as a System Function (Expanded and Bridged)
A key insight underlying this architecture is the recognition of the patient advocate as a core system role.
In most real-world care systems, someone performs the function of translating patient experience into clinically meaningful information. This may be a family member, a community health worker, or a trained coordinator. However, this role is rarely formalised. It exists implicitly, often varying in quality and consistency depending on the individual and the context.
In this chapter, a patient advocate is defined as:
An individual who represents, communicates, and coordinates the patient’s condition, preferences, and care needs within the care system.
This role is functional rather than professional. It does not depend on formal training or designation, although such training can improve effectiveness. What matters is the ability to observe, interpret, and communicate patient-related information in a way that others in the system can act upon.
At a practical level, the patient advocate performs three interrelated functions.
First, they act as a signal generator. They bring forward information from the patient’s lived environment—symptoms, behaviours, and contextual factors that would otherwise remain invisible to the clinical system. Without this function, the system operates in partial blindness.
Second, they serve as a translator. Raw patient experience is rarely expressed in clinically structured terms. The advocate converts everyday language and observations into clearer, more organised input. This does not require medical expertise, but it does require attentiveness and consistency.
Third, they function as a coordinator. They help ensure that information flows in both directions—upward to clinicians and back downward to the patient. They facilitate follow-up, clarify instructions, and maintain continuity over time.
These functions are often performed informally and unevenly. One caregiver may provide detailed and structured updates, while another may communicate sporadically or ambiguously. In traditional systems, this variability is absorbed by clinicians, who must compensate by asking repeated questions or reconstructing incomplete information.
The architecture proposed in this chapter addresses this variability by making the role explicit and stabilising its function.
A key operational step is the designation of a single patient advocate for each episode of care. This does not exclude others from participating, but it creates a focal point for communication. Information from multiple sources is consolidated through the advocate before entering the next stage of the system.
This simple constraint has important effects. It reduces duplication, improves clarity, and creates accountability for the quality of input. More importantly, it transforms patient advocacy from an incidental activity into a defined interface within the system.
Seen in this way, the patient advocate is not merely a helper or intermediary. They are the first processing layer in a distributed care architecture. They convert lived experience into a form that can be interpreted, analysed, and ultimately acted upon.
This leads to a broader insight:
Clinical systems do not fail only because of lack of expertise.
They often fail because information enters them in an unusable form.By structuring the role of the patient advocate, the system ensures that the entry point of information is reliable, not random.
However, defining the role alone is not sufficient. Even with a clearly identified advocate, communication can still become disorganised if all interactions occur within a single conversational space. Signals, interpretations, and decisions may still become interwoven in ways that obscure meaning.
To address this, the system requires not only role clarity, but also spatial organisation of communication.
This is the transition from who does what to where it happens.
The next section builds on this foundation by introducing a structured communication architecture that separates the flow of information into distinct but connected pathways.
Box 1.2 — Case vignette: From multiple voices to one signal
In a similar scenario, a patient reports worsening breathlessness at home. Several family members attempt to communicate updates, leading to fragmented and partially overlapping messages.
A single caregiver is then designated as the patient advocate. Over the next hour, instead of multiple messages, a structured update is sent:
WHO: Patient
WHAT: Breathlessness
SINCE: 6 hours
SEVERITY: Increasing
RED FLAGS: Difficulty speaking full sentences
CONTEXT: Known cardiac condition(Box ends)The clinicians now engage with a single, coherent description rather than reconstructing information from multiple fragments.
The designation of a patient advocate converts dispersed observations into a usable clinical signal, stabilising the entry point of the system.
Case 1.3 — Introducing the Advocate
Recognising the confusion, one family member is designated as the patient advocate.
He gathers information from others and sends a single structured update:
WHO: Patient
WHAT: Giddiness
SINCE: 2 days
SEVERITY: Persistent, worse on standing
RED FLAGS: None
CONTEXT: New antihypertensive started 3 days ago(Case ends)For the first time, clinicians receive a coherent picture.
The advocate converts multiple fragmented inputs into a usable signal, stabilising the system’s entry point.
Table 1.1 — Role Clarity and Boundaries
Role
Primary Function
Can Do
Must Not Do
Patient / Caregiver
Provide lived experience
Report symptoms, share context
Interpret clinically
Patient Advocate
Structure and communicate input
Consolidate, summarise, relay decisions
Make clinical decisions
Clinician
Interpret and decide
Analyse, decide, validate record
Work from unstructured input
Contributor
Support reasoning
Suggest, question, summarise
Make final decisions
AI Tool
Assist processing
Summarise, highlight patterns
Replace clinical judgment
Operational RuleEvery role has authority in one function.
Crossing roles leads to confusion.1.4 From Roles to System Design: The Missing Organising LayerDefining the patient advocate as a system role clarifies who participates in distributed care and what function they perform. However, role clarity alone does not create a system.
In many real-world settings, roles exist without structure. Patients communicate, caregivers interpret, and clinicians respond. Yet despite the presence of all necessary actors, care remains fragmented. Information is duplicated, decisions are implicit, and coordination depends heavily on individual effort rather than system design.
This reveals a deeper issue:
Care does not become organised simply because the right people are present. It becomes organised when their interactions are structured.
To move from roles to a functioning system, an additional layer is required—one that defines how information flows, where it flows, and in what form.
This layer can be understood through four fundamental design primitives:
1. Roles: Who participates and with what authority
Roles define the actors within the system:
- Patient (source of experience)
- Patient advocate (signal generation and translation)
- Clinician (decision authority)
- Contributor (supporting reasoning)
- AI (assistive computation)
Crucially, roles also define boundaries of authority, ensuring that participation in discussion does not imply control over decisions or records.
2. Lanes: Where communication occurs
Different types of communication require different spaces. Without separation, input, reasoning, and documentation become entangled.
Lanes introduce spatial organisation to communication:
- A space for capturing reality
- A space for interpreting meaning
- A space for recording validated knowledge
This separation reduces cognitive load and improves clarity.
3. Data Contracts: What information is allowed where
Not all data belongs in all places. Raw, unstructured input is valuable at the point of capture but becomes burdensome during reasoning. Conversely, structured decisions are essential for records but inappropriate for initial communication.
Data contracts define:
- What types of information are permitted in each lane
- How data must be transformed as it moves between lanes
This ensures that information becomes progressively clearer, smaller, and more actionable.
4. Governance and Enforcement: How the system maintains integrity
Even well-designed systems can drift without constraints. Governance ensures that roles, lanes, and data rules are consistently followed.
This includes:
- Role-based access and authority
- Structured communication formats
- Validation before recording
- Auditability and traceability
Importantly, governance is not imposed externally. It is embedded within the design of the system itself.
From Fragmented Interaction to Structured Flow
When these four primitives operate together, communication is no longer a collection of messages. It becomes a flow of information through defined transformations.
- Experience is captured
- Signals are structured
- Meaning is constructed
- Decisions are validated
- Knowledge is preserved
This progression transforms care from an informal activity into a coherent, governable process.
Why This Layer Matters
Without this organising layer:
- Roles exist, but coordination fails
- Communication occurs, but meaning is lost
- Decisions are made, but not recorded clearly
With it:
- Each participant understands their function
- Each piece of information has a place
- Each decision has a traceable origin
Feynman Explanation
“It’s not enough to have the right people.
You also need to decide where they talk, what they say there, and who is allowed to decide what matters.”Bridge to the Next Section
The patient advocate defines how information enters the system.
The design primitives define how the system is organised.The next step is to see how this organisation is implemented in practice.
1.5 The Three-Lane Architecture: Separating Input, Reasoning, and Record
Modern distributed care systems rely heavily on conversation. Patients describe symptoms, caregivers add context, and clinicians respond with advice. Over time, these exchanges accumulate into a complex web of messages. While this conversational model is flexible and accessible, it lacks structure. Different types of clinical work—observation, interpretation, and documentation—occur simultaneously within the same communication stream.
This creates a fundamental problem. When everything happens in one place, nothing is clearly defined. Important signals are buried in repetition. Clinical reasoning is fragmented across messages. Decisions are implied rather than stated. Responsibility becomes diffuse. What begins as communication gradually becomes confusion.
The three-lane architecture addresses this by introducing a simple organisational principle:
Different kinds of clinical work should occur in different spaces.
Instead of forcing all communication into a single channel, the system separates it into three distinct but connected lanes:
- The Circle of Care, where reality is reported
- The Clinical Discussion lane, where meaning is constructed
- The PaJR Record, where validated knowledge is stored
Each lane has a clear purpose, a defined set of participants, and constraints on what can be communicated within it.
1.5.1 Circle of Care (CoC): Capturing Reality
The Circle of Care is where the patient’s lived experience enters the system. It includes the patient and those immediately involved in their care—typically family members, caregivers, or community health workers. These individuals are closest to the patient’s day-to-day condition and are therefore best positioned to observe change.
Communication in this lane is naturally unstructured. Patients do not speak in clinical categories. They describe what they feel, what they notice, and what concerns them. Caregivers add observations, sometimes repeatedly or from different perspectives. Messages may include text, images, or voice notes. This apparent disorder is not a flaw; it reflects reality as it is experienced.
However, unstructured input becomes problematic when multiple people communicate simultaneously without coordination. The same symptom may be reported several times in slightly different ways. Important details may be missed or diluted. Clinicians receiving this information must expend effort simply to reconstruct what is happening.
To address this, the system introduces a stabilising constraint:
For each episode of care, one patient advocate is designated to structure and relay information.
The advocate does not replace other participants. Instead, they organise input. They listen, synthesise, and translate patient experience into a clearer signal. This role may be performed by a caregiver, a community health worker, or another coordinator, depending on the setting.
This simple step transforms the Circle of Care from a stream of messages into a coherent source of information. It preserves richness while reducing redundancy.
1.5.2 Clinical Discussion (CD): Constructing Meaning
Once patient information has been structured, it moves into the Clinical Discussion lane. This is the space where clinicians interpret what is happening and decide what to do next.
Unlike the Circle of Care, this lane is deliberately restricted. It includes clinicians and, where appropriate, contributors such as trainees, researchers, or technical experts. AI tools may also be used here to assist with summarisation or pattern recognition. However, all participants are not equal in authority.
A critical distinction is maintained:
Many can participate in reasoning, but only clinicians can make decisions.
This separation is essential. It allows collaborative thinking without compromising accountability. Contributors may suggest possibilities, raise questions, or provide additional analysis. AI may highlight patterns or summarise information. But the responsibility for deciding—and for validating what becomes part of the clinical record—remains with the clinician.
Communication in this lane is structured and focused. Inputs are de-identified where possible. The emphasis is on interpretation rather than description. The question is no longer “What is happening?” but “What does this mean?”
By separating this reasoning process from raw input, the system reduces cognitive load. Clinicians engage with organised information rather than fragmented messages. Reasoning becomes visible, traceable, and deliberate.
1.5.3 PaJR Record: Preserving Knowledge
The final lane is the Patient Journey Record (PaJR). This is where the system commits information to memory.
Unlike the other two lanes, the PaJR is not conversational. It is structured, deliberate, and controlled. Its purpose is to capture what has been established as clinically valid: events, assessments, decisions, and plans.
Access to this lane is restricted. Only authorised individuals—typically clinicians and designated recorders—can enter information. Every entry must be validated by a clinician. This ensures that the record reflects not discussion, but agreed clinical understanding.
The PaJR follows a few key principles. It is append-only, meaning that past entries are not erased but built upon. It is attributable, with clear authorship and timestamps. It is minimal, containing only what is necessary for continuity and accountability.
In this way, the PaJR transforms transient communication into persistent knowledge. It allows any member of the care team to understand the patient’s trajectory without reconstructing it from scattered messages.
1.5.4 Flow Between Lanes: Transformation, Not Transfer
The strength of the system lies not only in separating lanes, but in how information moves between them.
Information does not pass unchanged from one lane to another. It is transformed at each step.
When data moves from the Circle of Care to the Clinical Discussion lane, it changes from raw and unstructured to organised and interpretable. When it moves from Clinical Discussion to the PaJR, it changes from reasoning to validated decision. When it returns to the Circle of Care, it becomes a clear and actionable plan.
This process can be understood as a progressive refinement:
From experience → to interpretation → to knowledge → to action.
The patient advocate plays a central role in this flow. They act as the bridge between lived experience and clinical reasoning, and again between clinical decisions and patient understanding.
Box 1.3 — Case vignette: Structured flow across lanes
A patient with known cardiac disease develops progressive breathlessness.
In the Circle of Care, the patient advocate reports a structured update describing symptom onset and severity.
This information is transferred to the Clinical Discussion lane, where clinicians review the case. Based on the presence of a red flag (increasing breathlessness with impaired speech), a clinician makes an explicit decision:
DECISION: Urgent referral
RATIONALE: Progressive dyspnea with red flag
RESPONSIBLE: Lead clinician
REVIEW: Immediate(Box ends)This decision is then entered into the PaJR as a validated record and communicated back to the patient as a clear instruction to seek immediate care.
The same clinical situation that previously produced fragmented discussion now results in a rapid, traceable decision through structured flow across lanes.
(Case ends)Case 1.5 — Separation Creates Clarity
The system is reorganised into two groups:
- Circle of Care (patient + family + advocate)
- Clinical Discussion (clinicians only)
The advocate forwards the structured update to the Clinical Discussion group.
Clinicians review the case without distraction from unrelated messages.
A focused discussion follows:
- Timing of symptom onset
- Possible drug effect
- Absence of red flags
Within minutes, the team converges.
Separating input from reasoning reduces noise and improves clarity.
1.5.5 Emergency Escalation: When Structure Must Yield to Urgency
While the system is designed for structured, asynchronous communication, not all situations allow for this.
In urgent scenarios, delays can be harmful. A patient experiencing severe breathlessness or chest pain cannot wait for structured discussion. In such cases, the system must prioritise immediate action.
(Box ends)Box 1.4 — Case vignette: When urgency overrides messaging
A patient reports sudden onset chest pain and sweating. The patient advocate relays this information immediately.
A clinician identifies a red flag and responds:
“Go to the nearest emergency facility immediately. Do not wait.”
The patient is transported without further messaging discussion. Later, the event is documented in the PaJR, including time of escalation, actions taken, and outcome.
Emergency escalation operates outside the messaging flow but remains integrated through post hoc documentation, preserving both safety and continuity.
This is addressed through a simple principle:
Urgency overrides messaging.
When a red flag is identified, care transitions to a synchronous mode. This may involve a phone call, emergency services, or direct referral. Importantly, this does not invalidate the system. Instead, it is an expected and integrated pathway.
After the urgent event, the details are recorded in the PaJR. The system then resumes normal operation.
In this way, the architecture remains safe without becoming rigid. It accommodates urgency without losing structure.
1.5.6 A Practical Mental Model
The entire system can be understood through three simple questions:
- What is happening? → Circle of Care
- What does it mean? → Clinical Discussion
- What do we record and do next? → PaJR
This framing helps users quickly orient themselves within the system, even in complex situations.
Feynman Explanation
“First, people describe the situation.
Then clinicians think about it.
Finally, only what is agreed upon is written down and acted upon.”Key Insight
The three-lane architecture does not attempt to simplify care. Instead, it organises complexity into a usable form. It allows rich, real-world input to coexist with structured reasoning and reliable documentation.
By separating functions while preserving flow, the system makes distributed care clearer, safer, and more accountable.
1.6 Data Contracts: What Information Is Allowed Where
If the three-lane architecture defines where communication occurs, data contracts define what is allowed to occur within each space. Together, they determine not just the flow of information, but its quality, safety, and usefulness.
In most real-world messaging-based care systems, there are no explicit constraints on the type of information that can be shared. Patients and caregivers send messages, images, and reports as they arise. Clinicians respond in the same stream. Over time, this creates a dense mixture of observation, interpretation, and decision. While this may appear flexible, it introduces a subtle but critical problem: the system loses the ability to distinguish between raw input, clinical reasoning, and verified knowledge.
When everything is allowed everywhere, the result is not freedom—it is confusion. Important signals are buried within irrelevant detail. Sensitive information is shared more widely than necessary. Unverified statements may be mistaken for conclusions. The absence of boundaries ultimately undermines both clarity and safety.
Data contracts address this by introducing a simple but powerful constraint:
Each lane permits only the minimum type and amount of information required for its function.
This is not an abstract principle. It is a practical rule that shapes how communication happens at every step. It also aligns directly with the idea of data minimisation, a central requirement of frameworks such as the Digital Personal Data Protection (DPDP) Act. However, in this model, minimisation is not imposed after the fact. It is built into the design of communication itself.
Data in the Circle of Care: Capturing Reality Without Losing It
The Circle of Care is the point at which information enters the system. At this stage, the goal is not to refine or interpret, but simply to capture what is happening to the patient as accurately as possible.
For this reason, the range of permissible data in this lane is intentionally broad. Patients and caregivers may describe symptoms in their own words, share observations, ask questions, or express concerns. They may send photographs of medications, images of wounds, or voice notes describing changes. Contextual information—such as recent travel, diet, behaviour, or environmental conditions—is also relevant and often essential.
This data is inherently unstructured. It may be repetitive, incomplete, or inconsistent. Yet this apparent disorder reflects reality as it is experienced. Attempting to constrain it too early risks losing important signals.
The key constraint in this lane is therefore not on what can be expressed, but on what can move forward. The patient advocate acts as the first point of transformation. Instead of forwarding all incoming messages, the advocate consolidates them, removes duplication, and extracts the elements that are clinically meaningful. In doing so, they convert a stream of conversation into a coherent representation of the patient’s current state.
In this way, the Circle of Care allows richness at the point of capture, while preventing that richness from overwhelming the rest of the system.
Data in the Clinical Discussion Lane: From Description to Interpretation
As information enters the Clinical Discussion lane, its purpose changes. The system is no longer trying to capture experience; it is trying to understand it.
This shift requires a corresponding change in the type of data that is allowed. Information in this lane must be structured, relevant, and focused on interpretation. The aim is to reduce cognitive burden so that clinicians can concentrate on reasoning rather than reconstruction.
Instead of raw messages, clinicians receive summarised inputs that highlight key elements: what is happening, how long it has been happening, how severe it is, and how it is evolving over time. Where possible, identifying details are removed or minimised, ensuring that only necessary information is shared within the discussion.
Full documents, long message histories, or unprocessed images are generally avoided. If such material is important, its essential features are extracted and presented in a concise form. This ensures that attention is directed toward meaning, not volume.
AI tools may assist in this process by summarising data or identifying patterns. However, their outputs are always treated as provisional. They contribute to discussion but do not define conclusions. This distinction preserves the boundary between computation and clinical judgment.
The guiding principle in this lane is straightforward:
Only information that helps clinicians think is allowed to remain.
Everything else is filtered out before it reaches this stage.
Data in the PaJR Record: From Information to Knowledge
The PaJR Record represents the final stage of the system’s information flow. Here, the focus is no longer on exploration or interpretation, but on commitment. What is entered into the record becomes part of the patient’s clinical history.
For this reason, the constraints on data in this lane are the most stringent. Every entry must be structured, minimal, and validated. It must clearly state what occurred, what was concluded, and what actions were taken or planned.
Unlike conversational spaces, the PaJR does not include raw discussions, speculative reasoning, or unverified information. AI-generated content does not enter the record unless it has been reviewed, confirmed, and reformulated by a clinician. Similarly, contributor opinions are not recorded unless they are adopted and validated within a clinical decision.
Each entry is attributable, with clear authorship and timing. The record is also append-only, meaning that changes are documented as new entries rather than overwriting previous ones. This preserves the integrity of the clinical narrative over time.
The PaJR thus transforms information into knowledge. It captures not everything that was said, but only what has been established as clinically meaningful and reliable.
Data Transformation: From Richness to Precision
The movement of data across lanes can be understood as a process of progressive refinement. Information begins in a rich, unstructured form. It is then organised, reduced, and interpreted. Finally, it is distilled into a minimal and validated record.
At each step, something is lost—but what is lost is redundancy, ambiguity, and noise. What remains becomes increasingly useful.
This progression can be summarised simply. In the beginning, data is broad and descriptive. In the middle, it becomes focused and analytical. In the end, it becomes precise and authoritative.
The system does not discard information—it shapes it into a usable form.
Data Minimisation and Governance by Design
The principles of data protection—such as minimisation, purpose limitation, and accountability—are often implemented as external requirements. In contrast, this architecture embeds these principles within the flow of communication itself.
Data is captured where it is most relevant, reduced before it is shared more widely, and further minimised before it is recorded. At each stage, exposure is limited and responsibility is clearly defined.
This approach ensures that governance does not interrupt care. Instead, it becomes an inherent property of the system. By controlling what information can exist in each lane, the system naturally limits unnecessary data exposure and supports accountability.
Common Failure Patterns
The importance of data contracts becomes clear when they are absent. In many systems, raw images are forwarded directly into clinical discussions without context. Entire message threads are copied into records. AI-generated summaries are accepted without verification. Multiple unfiltered inputs overwhelm clinicians, leading to delays and errors.
These failures are not due to lack of expertise, but to lack of structure. When boundaries are unclear, even well-intentioned participants contribute to confusion.
Data contracts prevent these patterns by establishing clear expectations. They ensure that information is presented in a form appropriate to its purpose.
A Simple Way to Think About It
The entire process can be understood in three steps.
At the beginning, everything is allowed so that nothing important is missed.
In the middle, only what matters is retained so that thinking becomes possible.
At the end, only what is true is recorded so that care can continue reliably.Feynman Explanation
“First, you listen to everything.
Then you keep only what helps you understand.
Finally, you write down only what you are sure about.”Key Insight
Data contracts do not restrict care. They make care usable.
By ensuring that each lane contains only the information it needs, the system becomes clearer, safer, and more efficient. It protects both the patient’s data and the clinician’s attention, allowing distributed care to function with reliability and trust.
(Case ends)Case 1.6 — Information Becomes Usable
Instead of forwarding all messages and images, the advocate extracts key information:
- Drug name and start date
- Symptom pattern
- Absence of alarming features
No unnecessary photos or repeated messages are shared.
Clinicians work with a small, high-quality dataset, rather than a large, confusing one.
Data minimisation is achieved through transformation, not restriction.
1.7 Governance and Enforcement: How the System Holds Together in Practice
Design alone does not guarantee reliability. A system may be logically sound and still fail when applied in real-world conditions. Messages may bypass structure, roles may blur, and urgency may override discipline. Over time, even a well-designed architecture can drift back toward the very fragmentation it was intended to solve.
This raises a practical question:
How does the system maintain its structure when used by real people under real pressures?
The answer lies in governance and enforcement—not as external controls imposed on the system, but as mechanisms embedded within it. In this model, governance is not a separate layer of compliance. It is the way the system sustains itself in practice.
1.7.1 Governance as a Property of Design
Traditional approaches to governance rely on policies, audits, and oversight mechanisms that operate outside day-to-day clinical work. While necessary, these approaches often feel distant from practice and are inconsistently applied.
In contrast, the architecture described in this chapter embeds governance within the structure of communication. The separation of lanes, the definition of roles, and the constraints on data together create an environment in which appropriate behaviour is the natural path, not an additional requirement.
In this sense, governance becomes less about enforcement and more about alignment. The system is designed so that:
- Information flows in a controlled manner
- Authority is clearly defined
- Data exposure is minimised
- Accountability is inherent
When these elements are present, compliance is not something that must be enforced—it is something that emerges from design.
1.7.2 Three Layers of Enforcement
Although governance is embedded in design, it still requires mechanisms that ensure consistency in practice. These mechanisms operate at three interconnected levels: structural, procedural, and record-level.
Structural Enforcement: Controlling Where Things Happen
Structural enforcement is achieved through the separation of communication into distinct lanes.
Each lane has:
- A defined purpose
- A defined set of participants
- Restricted access
For example, the Clinical Discussion lane is limited to clinicians and contributors, while the PaJR Record is restricted to authorised users. This prevents inappropriate mixing of roles and reduces the risk of sensitive information being shared unnecessarily.
The physical or digital separation of these spaces—whether through different groups, channels, or interfaces—creates a boundary that is both visible and enforceable. Participants quickly learn that different kinds of communication belong in different places.
Procedural Enforcement: Guiding How Communication Occurs
Structural separation alone is not sufficient. Within each lane, communication must also follow consistent patterns.
Procedural enforcement is achieved through simple, repeatable practices:
- Designating a single patient advocate for each episode
- Using structured formats for reporting and decision-making
- Clearly labelling roles in the Clinical Discussion lane
- Explicitly stating decisions rather than implying them
These practices do not require complex training. They rely on repetition and shared understanding. Over time, they become habits that stabilise the system.
Importantly, procedural enforcement is lightweight. It does not aim to control every action, but to guide communication in a way that maintains clarity.
Record-Level Enforcement: Controlling What Becomes Permanent
The PaJR Record provides the strongest form of enforcement. Unlike conversational lanes, it is governed by strict constraints.
No information enters the record without:
- Authorisation
- Validation by a clinician
- Attribution
The append-only nature of the record ensures that changes are transparent and traceable. This creates a durable audit trail, making it possible to understand not only what decisions were made, but when and by whom.
Record-level enforcement anchors the system. Even if communication in other lanes becomes temporarily disorganised, the PaJR preserves a reliable core of clinical knowledge.
1.7.3 Cross-Lane Discipline: Preventing System Drift
One of the most common ways systems fail is through gradual erosion of boundaries. Messages intended for one lane appear in another. Raw data bypasses the advocate. Contributors begin to issue decisions. Over time, the system reverts to a single, unstructured stream.
Preventing this requires cross-lane discipline.
This discipline is maintained through a few key principles:
- Information must pass through the appropriate transformation before moving to the next lane
- Roles must be respected at each stage
- Decisions must be explicitly recorded, not inferred
When violations occur, they are corrected not through punishment, but through redirection. A message posted in the wrong lane is gently moved or reformulated. Over time, these corrections reinforce the intended structure.
1.7.4 Managing Urgency Without Breaking Structure
A common concern is that strict structure may slow down care, particularly in urgent situations. In practice, the opposite is true—provided that urgency is handled correctly.
The system incorporates a defined mechanism for emergency escalation. When a red flag is identified, communication shifts immediately from asynchronous messaging to synchronous action. This may involve a phone call, emergency services, or direct referral.
This shift does not break the system. It is part of it.
After the immediate situation is addressed, the event is recorded in the PaJR, ensuring continuity and accountability. The system then resumes normal operation.
By explicitly accommodating urgency, the architecture avoids the risk of either:
- Delaying critical action, or
- Abandoning structure entirely
1.7.5 Monitoring and Feedback
For the system to remain effective, it must be observable. Participants should be able to recognise when it is functioning well and when it is drifting.
Simple indicators can provide this feedback:
- Are inputs structured before entering Clinical Discussion?
- Are decisions clearly stated and attributed?
- Does the PaJR reflect a coherent patient journey?
When these conditions are met, the system is functioning as intended. When they are not, adjustments can be made.
This form of monitoring is lightweight and continuous. It does not rely on formal audits alone, but on everyday awareness.
1.7.6 Governance and Trust
At its core, governance is about trust. Patients trust that their information will be handled appropriately. Clinicians trust that the information they receive is reliable. Teams trust that decisions are clear and accountable.
The architecture supports this trust by making:
- Data flow predictable
- Roles transparent
- Decisions traceable
Rather than relying on implicit assumptions, it creates visible structure.
A Practical Mental Model
The system holds together through a simple balance:
- Structure defines what should happen
- Practice reinforces how it happens
- The record ensures that what happened is preserved
When these three elements align, the system remains stable even under pressure.
Feynman Explanation
“You don’t keep a system working by watching people all the time.
You keep it working by making it easy to do the right thing, and obvious when something goes wrong.”Key Insight
Governance is not an add-on. It is what allows the system to function reliably over time.
By embedding constraints within roles, communication spaces, and data flow, the architecture ensures that distributed care remains:
- Structured
- Accountable
- Safe
- Adaptable
Case 1.7 — Decision and Accountability
A clinician states clearly:
DECISION: Likely drug-induced dizziness
RATIONALE: Temporal association + postural worsening
RESPONSIBLE: Dr. S
REVIEW: 24 hoursThe decision is not implied—it is explicit.
(Case ends)Responsibility is clear. Next steps are defined.
Governance emerges through clear roles and explicit decisions.
1.8 Putting It All Together: From Messages to a System of Care
Up to this point, the chapter has introduced the core elements of the model in parts. We have defined roles, clarified the function of the patient advocate, separated communication into lanes, constrained data through contracts, and embedded governance within design. Each of these elements addresses a specific problem. Taken together, they form something more important:
A system that converts conversation into coordinated care.
This section brings these elements together into a single, coherent operational view.
1.8.1 The System as a Flow, Not a Collection of Parts
It is tempting to think of the model as a set of components: roles, lanes, rules, and records. However, in practice, the system is better understood as a flow of information through transformations.
Care begins with lived experience. A patient notices a change, a caregiver observes a pattern, or a concern arises. This information enters the Circle of Care, where it is expressed in natural language. At this stage, it is rich but unstructured.
The patient advocate then transforms this input into a structured signal. This signal moves into the Clinical Discussion lane, where clinicians interpret it, generate hypotheses, and arrive at a decision.
That decision is then validated and recorded in the PaJR, becoming part of the patient’s longitudinal history. Finally, the decision is translated back into a clear, actionable plan and communicated to the patient.
This cycle repeats over time, forming a continuous loop of observation, interpretation, decision, and action.
The system does not store conversations. It transforms them into decisions and memory.
1.8.2 The Closed-Loop Nature of Care
A key feature of this architecture is that it is closed-loop. Information does not simply move forward; it returns to the point of origin in a transformed form.
The patient reports a symptom. The system processes it. The patient receives a plan. The outcome of that plan generates new information, which re-enters the system.
This loop ensures continuity. Each cycle builds on the previous one, creating a coherent narrative of the patient’s journey.
Without such a loop, care becomes episodic and fragmented. With it, care becomes continuous and adaptive.
1.8.3 Roles in Motion
While roles are defined statically, they operate dynamically within the system.
The patient remains the source of experience. The patient advocate continuously translates and coordinates. Clinicians interpret and decide. Contributors support reasoning where appropriate. AI tools assist with processing but remain non-authoritative.
At any given moment, each role is performing a specific function within the flow. The clarity of these roles prevents overlap and confusion, allowing participants to focus on their respective responsibilities.
Importantly, this structure does not limit collaboration. It enables it by ensuring that contributions occur in the right place and with the right level of authority.
1.8.4 Stability Through Repetition
One of the strengths of the model is that it relies on simple, repeatable patterns rather than complex rules.
Each cycle follows a consistent sequence: Capture, Structure, Interpret, Decide, Record, and Act. For ease of use, this sequence can be remembered as C-SIDRA.
Care begins with capturing what is happening to the patient. This information is then structured into a coherent signal. Clinicians interpret this signal to understand its meaning, leading to a decision. That decision is recorded in the PaJR, and appropriate action is taken. The outcome of that action generates new information, which begins the cycle again.
Because this sequence is repeated across cases, it becomes familiar over time. Participants learn not only what to do, but when to do it. The system stabilises not through rigid enforcement, but through pattern recognition and habit formation.
In practical terms, C-SIDRA acts as a cognitive scaffold. It allows participants to orient themselves quickly within a case, even when complexity is high. Instead of asking multiple disconnected questions, they can simply ask: Where are we in the cycle?
This reduces confusion, improves coordination, and ensures that no critical step is missed.
Feynman Explanation
“First you capture what’s happening.
Then you organise it.
Then you understand it.
Then you decide.
Then you write it down.
Then you act—and the cycle begins again.”Key Insight
The system works not because it is complex, but because it is consistent.
By repeating the same sequence—C-SIDRA—across cases, distributed care becomes predictable, teachable, and reliable, even in environments where resources and expertise may vary.
1.8.5 Balancing Flexibility and Control
A common tension in system design is the balance between flexibility and control. Too much flexibility leads to chaos; too much control leads to rigidity.
This architecture resolves that tension by applying control selectively.
The Circle of Care remains flexible, allowing rich and contextual input. The Clinical Discussion lane introduces structure to support reasoning. The PaJR imposes strict control to ensure reliability and accountability.
In this way, flexibility is preserved where it is needed, and control is applied where it matters most.
1.8.6 Safety, Accountability, and Trust
When the system functions as intended, several properties emerge.
Decisions become explicit and attributable. Data exposure is limited to what is necessary. Clinical reasoning is visible and traceable. The patient’s journey is recorded in a coherent and accessible form.
These properties support safety and accountability. More importantly, they build trust—among patients, advocates, and clinicians alike.
Trust, in this context, is not based on assumption. It is based on structure that makes behaviour predictable and transparent.
1.8.7 Minimal Technology, Maximum Structure
A notable feature of this model is that it does not depend on sophisticated technology. It can be implemented using widely available messaging platforms, supplemented by simple tools for record-keeping.
What makes the system effective is not the platform, but the organisation of communication.
This has important implications for scalability. The model can be deployed in resource-constrained environments without requiring significant infrastructure. At the same time, it can be adapted to more advanced platforms that provide enhanced access control and integration.
1.8.8 A Unified Mental Model
At its simplest, the system can be understood as a sequence of questions:
- What is happening?
- What does it mean?
- What should be done?
- What should be recorded?
Each question corresponds to a stage in the system. By answering these questions in order, the system ensures that care progresses logically and coherently.
Feynman Explanation
“The system works because everyone does their part in the right order.
First you understand the situation, then you think about it, then you decide, and finally you write it down so you don’t forget.”Key Insight
The power of this model lies in its simplicity. It does not attempt to replace existing practices, but to organise them.
By aligning roles, communication, data, and governance into a single flow, it turns everyday interactions into a reliable system of care.
(Case ends)Case 1.8 — Completing the Cycle (C-SIDRA)
The full cycle is now visible:
- Capture: Patient reports dizziness
- Structure: Advocate summarises
- Interpret: Clinicians analyse
- Decide: Drug-related cause identified
- Record: Entry made in PaJR
- Act: Medication adjusted
The patient is advised to hold the suspected drug and monitor symptoms.
C-SIDRA transforms conversation into coordinated care.
Figure 1. From fragments to flow: a distributed care journey (C-SIDRA in practice).
The figure illustrates how unstructured patient-generated input is progressively transformed into structured, interpretable, and actionable clinical information across three distinct communication lanes: Circle of Care (input), Clinical Discussion (reasoning), and PaJR (record). Each step—Capture, Structure, Interpret, Decide, Record, and Act (C-SIDRA)—represents a transformation in clarity, accountability, and clinical utility. The cycle repeats continuously, enabling coordinated and traceable care over time.1.9 Implementation in Practice: From Concept to Deployment
The model described in this chapter is intentionally designed to work within existing conditions. It does not require new infrastructure, specialised software, or extensive training. In most settings, it can be implemented using tools that teams already use, particularly smartphone-based messaging platforms.
The aim of implementation is not to introduce a new system, but to bring structure to communication that is already happening.
1.9.1 Getting Started: Setting Up the System
Implementation begins by creating three distinct communication spaces corresponding to the three lanes of the model. In practice, this usually means setting up two messaging groups and one simple record.
The first group represents the Circle of Care. It includes the patient, caregivers, and the designated patient advocate. This is where real-world information is shared. Messages in this group remain natural and conversational, but the advocate is responsible for consolidating and structuring updates before they move forward.
The second group is the Clinical Discussion space. This group includes clinicians and, where appropriate, contributors. Patients and general caregivers are not included here. This separation is important. It allows clinicians to focus on interpretation and decision-making without being overwhelmed by unfiltered input.
The third component is the Patient Journey Record. This is not a messaging group, but a structured document or system where validated information is recorded. It may be as simple as a shared document or a basic digital form. What matters is not the technology, but the discipline of recording decisions in a consistent and traceable way.
At this stage, nothing more is required. A basic setup of two groups and one record is sufficient to begin.
1.9.2 Making It Work Day-to-Day
Once the spaces are created, the system begins to function through a few simple habits.
The most important step at the beginning of each case is to clearly identify the patient advocate. This person becomes the primary point of communication from the Circle of Care to the Clinical Discussion group. Other participants may continue to share observations, but the advocate is responsible for consolidating and forwarding information in a structured way.
In practice, this often means converting multiple messages into a short, organised update describing who the patient is, what is happening, how long it has been happening, and whether there are any warning signs. This reduces duplication and allows clinicians to engage with a clear signal rather than fragmented information.
Within the Clinical Discussion group, the emphasis shifts from describing the problem to understanding it. Clinicians interpret the structured input, discuss possibilities where needed, and arrive at a decision. A key habit here is to make decisions explicit. Instead of leaving conclusions implied within conversation, they are clearly stated, along with responsibility and next steps.
Once a decision is made, it is recorded in the Patient Journey Record. This step is often overlooked in informal systems, but it is essential for continuity. The record ensures that decisions are not lost within conversation and can be referred to later.
The decision is then communicated back to the Circle of Care, usually through the patient advocate, in a form that is simple and actionable.
Over time, these steps—capturing, structuring, interpreting, deciding, recording, and acting—become routine. The cycle stabilises through repetition.
1.9.3 What to Expect (and Fix Early)
In the early stages, the system will not function perfectly. Participants may continue to send unstructured messages into the Clinical Discussion group. Multiple people may try to communicate at once. Decisions may not always be clearly stated or recorded.
These are expected challenges. They do not indicate failure, but adjustment.
The response is not strict enforcement, but gentle correction. Messages can be redirected to the appropriate space. The role of the advocate can be reinforced. Templates can be reintroduced where needed. Over time, these small adjustments lead to consistent behaviour.
It is also important to address urgency explicitly. Participants should understand that serious situations do not wait for structured discussion. When a red flag is identified, immediate action—such as a phone call or referral—takes priority. The event is then documented afterward, ensuring that the system remains both safe and coherent.
As the system stabilises, a few changes become noticeable. Communication becomes shorter and clearer. Clinicians spend less time reconstructing information. Decisions become visible and traceable. The Patient Journey Record begins to reflect a coherent narrative of care.
These are signs that the system is working.
A Practical Way to Think About Implementation
The process can be summarised simply:
First, separate where things happen.
Then, clarify who is responsible.
Finally, guide how information moves.Everything else follows.
Feynman Explanation
“You don’t need new tools.
You just need to decide where to talk, who should speak for the patient, and how to pass information from one place to another.”Key Insight
Implementation succeeds when the system feels natural.
By keeping the setup simple and the rules minimal, the model integrates into everyday practice rather than competing with it. Over time, structured communication becomes the default, and coordinated care emerges as a result.
Case 1.9 — System Stabilisation
Over the next few days:
- Updates become shorter and clearer
- Only the advocate sends summaries
- Clinicians respond with structured decisions
- The PaJR begins to reflect a clear timeline
The patient’s dizziness improves after medication adjustment.
The system now requires less effort than before, not more.
(Case ends)
Structured communication becomes natural through repetition.
Box 1.12 — Quick Start: 10-Minute Deployment
Purpose
Start using the system immediately with minimal setup and no new tools.
Do This First (in order)
1. Create two groups
- Circle of Care (CoC): patient + caregivers + advocate
- Clinical Discussion (CD): clinicians only
2. Assign ONE patient advocate
Designated Advocate: [Name]
All patient updates will come through this person.3. Start with ONE patient case
Focus on learning the flow, not scaling.4. Send ONE structured update (CoC → CD)
WHO: WHAT: SINCE: SEVERITY: RED FLAGS: CONTEXT:5. Clinician gives ONE clear decision
DECISION: RATIONALE: RESPONSIBLE: REVIEW:6. Record ONE entry in PaJR
Keep it simple—one validated decision is enough.Goal for Day 1
- One clear update
- One explicit decision
- One recorded entry
Field Insight
If it feels slower on Day 1, that is normal.
By Day 3, it should be faster and clearer than before.1.10 Limitations and Future Directions
No system is complete at the moment it is described. The architecture presented in this chapter is intentionally minimal and practical, but it operates within real-world constraints. Understanding where it may struggle, what remains unresolved, and how it might evolve is essential for responsible use and further development.
1.10.1 Where the Model May Struggle
The model depends heavily on human behaviour, particularly on role clarity and disciplined communication. In settings where participants are not accustomed to structured workflows, the separation of lanes may initially feel artificial. Messages may drift across lanes, roles may blur, and the intended flow may weaken over time.
The effectiveness of the system also relies on the presence of a capable patient advocate. When the advocate is inconsistent, unavailable, or insufficiently trained, the quality of input deteriorates. This can lead to either information overload in the Clinical Discussion lane or loss of important details. In such cases, clinicians may revert to direct questioning, partially bypassing the intended structure.
Another limitation arises from group size and complexity. As the number of participants increases, maintaining discipline becomes more challenging. Larger groups are more prone to duplication, side conversations, and unintended role overlap. Without active moderation, the system can gradually revert to an unstructured messaging environment.
The model may also face difficulty in high-acuity, rapidly evolving situations. While the system accommodates emergency escalation, frequent transitions between asynchronous and synchronous modes can create discontinuity if not managed carefully. In such scenarios, rapid documentation in the PaJR becomes even more critical but may be overlooked.
Technological limitations can also play a role. Messaging platforms are not designed as clinical systems. They lack built-in mechanisms for access control, structured data entry, and audit trails. While the architecture compensates for this through process design, there are inherent constraints in what can be achieved without dedicated tools.
1.10.2 What Remains Unresolved
Several aspects of the model require further exploration and refinement.
One unresolved area is the formalisation of the patient advocate role. While the chapter defines this role functionally, questions remain regarding training, certification, and accountability. In some settings, formal recognition may enhance reliability; in others, it may introduce barriers.
Another area is the standardisation of data formats. The templates described in this chapter are intentionally simple, but greater standardisation could improve interoperability with formal health systems. Balancing simplicity with standardisation remains an open challenge.
The integration of the PaJR with existing electronic health record systems is also not fully addressed. While the PaJR functions as a lightweight record, aligning it with institutional systems would require additional work on data structures, permissions, and workflows.
The role of AI remains an evolving domain. While this model clearly defines AI as assistive and non-authoritative, questions remain regarding validation, bias, and safe integration at scale. Ensuring that AI enhances rather than distorts clinical reasoning will require ongoing attention.
Finally, the model assumes a baseline level of digital access and literacy. In settings where these are limited, adaptations may be required to ensure inclusivity.
1.10.3 How the Model Can Evolve
Despite these limitations, the architecture provides a strong foundation for future development.
At a basic level, the system can evolve through refinement of practice. As teams use the model, they can adapt templates, clarify roles, and improve communication patterns. These incremental improvements can significantly enhance performance without altering the core structure.
Technological evolution offers additional opportunities. Messaging platforms may incorporate features such as:
- Structured input forms
- Role-based access controls
- Integrated record systems
- Automated summaries
Such features could strengthen the architecture while preserving its simplicity.
More advanced implementations may involve dedicated applications that embed the three-lane structure directly into their design. These could provide seamless transitions between input, reasoning, and record, along with built-in governance and audit capabilities.
The integration of AI is likely to expand. Future systems may offer real-time summarisation, risk flagging, and decision support. However, the principles outlined in this chapter—clear role boundaries and clinician validation—will remain essential to ensure safe use.
At a broader level, the model could inform policy and system design. By demonstrating how governance can be embedded within communication, it offers an approach that aligns with evolving regulatory frameworks while remaining practical.
1.10.4 Scaling Across Contexts
The strength of this model lies in its adaptability. Because it is not tied to a specific technology or institution, it can be applied across a wide range of settings—from rural communities to urban health systems.
Scaling does not require replication of infrastructure, but replication of principles:
- Clear roles
- Separate communication spaces
- Structured data flow
- Embedded governance
However, scaling also introduces new challenges. Training larger and more diverse teams requires standardised materials and ongoing support. Monitoring system performance becomes more complex. Ensuring consistency across contexts requires careful adaptation rather than rigid replication.
A Practical Perspective
It is important to recognise that this model is not a final solution. It is a framework for organising care that can evolve over time.
Its value lies in providing:
- A clear starting point
- A shared language
- A set of principles that guide practice
From this foundation, systems can grow, adapt, and improve.
Feynman Explanation
“This system won’t solve every problem.
But it gives you a way to organise care so problems become easier to see and fix.”Key Insight
Every system has limits. What matters is whether those limits are understood and whether the system can adapt.
By remaining simple, flexible, and grounded in practice, this architecture can evolve alongside the environments in which it is used, supporting better coordination, clearer decisions, and more reliable care over time.
(Case ends)Case 1.10 — Where It Could Have Failed
At several points, the system could have broken:
- Multiple family members continuing to send messages
- Raw data flooding the Clinical Discussion group
- No clear decision being made
- Failure to document
Each of these risks was mitigated by:
- Strong advocate role
- Lane separation
- Structured decision format
- PaJR discipline
Failures arise from boundary violations, not lack of knowledge.
Box 1.13 — Failure Case (When Structure Is Absent)
Case: Same patient, different outcome
A 62-year-old man reports dizziness after discharge. The family uses a messaging group with multiple members and clinicians.
Messages appear over several hours:
- “He is dizzy again”
- “Maybe BP is low”
- Photo of medications
- “Should we stop something?”
Different clinicians respond at different times. Some ask for details. Others suggest possibilities. No one consolidates the information.
Key details are missed:
- New medication started 3 days ago
- Symptoms worsen on standing
No single message summarises the case. No explicit decision is made.
By the next day:
- Symptoms persist
- Family is uncertain
- Clinicians are repeating questions
Eventually, the patient visits a local clinic, where the drug is stopped. Symptoms improve.
What went wrong
- No patient advocate
- Raw, unstructured input
- No separation of discussion
- No explicit decision
- No record
Key Lesson
The problem was not lack of knowledge.
It was lack of structure.1.11 When NOT to Use This Model
This model is designed for distributed, multi-actor care where communication is the primary challenge. It is not intended for every clinical situation. Using it where it does not fit can add unnecessary complexity or delay action.
1. Single Clinician, Simple Case
When care is being delivered by a single clinician managing a straightforward problem (e.g., a routine follow-up or minor acute illness), introducing multiple lanes and roles is unnecessary.
Use direct care. Do not add structure where none is needed.
2. High-Acuity or Time-Critical Situations
In emergencies—such as chest pain, severe breathlessness, loss of consciousness, or major trauma—there is no time for structured asynchronous communication.
Act first. Escalate immediately. Document later.
This model supports documentation after stabilisation, but it must never delay urgent care.
3. Intensive Care or Continuous Monitoring Settings
In environments such as ICUs or operating rooms, care is:
- Continuous
- Synchronous
- Closely supervised
Communication is already structured through protocols and direct observation.
This model does not replace real-time, bedside clinical systems.
4. Absence of a Reliable Patient Advocate
If no individual is able to:
- Consolidate information
- Communicate consistently
- Maintain continuity
then the system will not function effectively. Without an advocate, the Clinical Discussion lane becomes overloaded with fragmented input.
Do not implement the model without a clearly identified advocate.
5. Very Large, Uncontrolled Groups
When communication groups are large and participation cannot be moderated, enforcing role boundaries becomes difficult. Multiple simultaneous inputs can overwhelm the system.
Reduce group size or enforce strict role control before implementation.
6. Lack of Basic Communication Access
In settings with:
- No reliable mobile connectivity
- No consistent access to messaging or voice communication
the model may not be practical in its standard form.
Adaptations (e.g., periodic in-person consolidation with later recording) may be required.
7. When Governance Cannot Be Maintained
If:
- Roles are not respected
- Decisions are not made explicit
- Records are not maintained
the system will drift back into unstructured communication.
Without discipline, the model loses its value.
Practical Rule of Thumb
Use this model when care is distributed, asynchronous, and multi-actor.
Avoid it when care is simple, immediate, or fully controlled by one clinician.Key Insight
This model is not a replacement for clinical care systems. It is a way of organising communication when care is already fragmented.
Using it appropriately ensures that structure improves care. Using it unnecessarily may only add complexity.
1.12 Conclusion: A System for Making Care Work
Care does not fail only because of lack of knowledge.
It often fails because knowledge is poorly organised in practice.Across settings—homes, clinics, and communities—patients describe symptoms, caregivers observe changes, and clinicians make decisions. These elements are present everywhere. What is often missing is a way to bring them together into a coherent, reliable flow.
This chapter has proposed that the problem is not the absence of communication, but the absence of structure within communication.
From Fragments to Flow
In many real-world systems, care is reconstructed from fragments. Messages accumulate, decisions are implied, and responsibility is distributed. Over time, this creates uncertainty—for patients, for caregivers, and for clinicians.
The architecture described in this chapter offers a different approach. It does not replace existing tools or practices. Instead, it reorganises them.
By defining roles, separating communication into lanes, constraining data, and embedding governance within design, the model transforms scattered interactions into a continuous and traceable process.
What was previously a stream of messages becomes a system of care.
A Simple Cycle, Repeated Reliably
At the heart of this system is a repeatable pattern: Capture, Structure, Interpret, Decide, Record, and Act (C-SIDRA).
This sequence reflects how care actually unfolds. It begins with lived experience and ends with action, with each step building on the previous one. When this cycle is followed consistently, complexity becomes manageable. Participants know where they are in the process and what is expected of them.
Over time, repetition creates stability. The system does not depend on constant supervision. It sustains itself through shared understanding.
No comments:
Post a Comment