# Home Welcome to the Lattice Innovations blog. We have organized our posts into three levels: concept, model and function. These mirror our approach to projects, where we conceptualize solutions, design models, and finally, enable those models to function—using software. ### Concepts Domain-specific ideas.


Population-scale healthcare: concept, model and function	joseph-chan-I23WeOTsA8M-unsplash.jpg	Population-scale health
Focused factories: disrupting traditional healthcare delivery	petri-heiskanen-vqO_1fUCNxg-unsplash.jpg	Focused factories
Consent in digital health	philip-myrtorp-LAbOEEj-p3E-unsplash.jpg	Consent in Digital Health
Quality control	tolga-ulkan-9k36QqhA0cU-unsplash.jpg	Quality control

### Models Blueprints that (hopefully!) bring a concept to life.


Kaizen paradigm in practice: OPD process improvement	IMG_20141203_101442.jpg	Process improvement consulting
Authorization equals consent	philip-myrtorp-LAbOEEj-p3E-unsplash.jpg	Authorization equals consent
Managing projects	simon-gibson-FT362qyhd58-unsplash.jpg	Managing projects
The Jugaadathon playbook	jugaadathon.png	The Jugaadathon playbook

### Functional systems Enabling models to function, using software.

	Cover image
Finding the critical path	sed-creatives-sardar-r-1EBbpJTFE-unsplash.jpg	Finding the critical path
If you want to type, then Retype	arun-sharma-rTAdnqmYS40-unsplash.jpg	If you want to type, then retype
API Security	arthur-mazi-a8CxRWIu8yw-unsplash.jpg	API security
Universal record identifier	igor-omilaev-VyD_UzTDm9o-unsplash.jpg	Universal record identifier

# Population-scale health December 19, 2022 This post first appeared in [Medium](https://medium.com/lattice-what-is/population-scale-health-assessment-intervention-from-concept-to-function-ece418cf3942), titled "Population-scale health assessment & intervention: from concept to function". It forms the basis of [Agni by Lattice](https://agni.thelattice.in), a mobile-first, offline-capable platform for community and primary care delivery. Agni soon be available as an open-source codebase. {% content-ref url="/pages/xb0E0QLkJgP4Ta5e9GQW" %} [Part I: Conceptual framework](/readme/population-scale-health/part-i-conceptual-framework) {% endcontent-ref %} {% content-ref url="/pages/5p4OrakxHfMGGYv6o9Hb" %} [Part II: Model design](/readme/population-scale-health/part-ii-model-design) {% endcontent-ref %} {% content-ref url="/pages/dFIXJ6viJgKDOZBv5l3A" %} [Part III: Enabling the model to function, using software](/readme/population-scale-health/part-iii-enabling-the-model-to-function-using-software) {% endcontent-ref %} *Photo credit:* [*Joseph Chan*](https://unsplash.com/@yulokchan?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/aerial-photography-of-four-cars-surrounded-with-people-I23WeOTsA8M?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) # Part I: Conceptual framework

Progressive risk assessment Our health status is analog, not digital. We do not transition overnight from being at-risk of hypertension, to being a confirmed hypertensive. To accurately assess our health, we need a model that measures risk progressively. The evidence used to build a risk model can be split into two dimensions—its source, and its nature. ### Source of evidence Arranged by proximity to patient: * Patient (i.e. self-reported) * Family member, friend, at-home caregiver * Community health worker * Nursing, technical and paramedical staff * Physician Patient-reported experiences of illness are a crucial but oft-missed dimension of population health. Healthcare episodes start with the experience of being unwell—long before they are labeled “diseases” or “conditions” by healthcare providers. ### Nature of evidence * Experienced: patient’s subjective experience * Observed: about the individual, or their environment * Measured: quantifiable, verifiable parameters Source & nature together determine the strength of evidence. For instance, in April 2021, “feeling feverish” had me worried that I had COVID-19. However, the evidence lacked strength. I took an RT-PCR test the next day, performed by a technician in an accredited lab. This movement from `patient + experienced` to `technical staff + measured` greatly increased the strength of evidence. Finally, the strength of evidence—how confident are we that there is Coronavirus nucleic acid in my pharynx—combined with utility of the evidence—how useful is a single positive RT-PCR test in determining COVID-19—generates a risk estimate. In this example, a [positive test](#user-content-fn-1)[^1] equalled near-certainty. ### Risk stratification To make risk assessments actionable, they have to be stratified. Each stratum provides a threshold to trigger action. Here, we propose four strata—at-risk, suspected, provisionally diagnosed, and definitively diagnosis—based on a clinical understanding of a disease’s progress.

Figure 2: from risk assessment to risk stratification

### Capability mapping Across diseases and conditions, we **map four risk strata to five** **tiers of care — at-home, community, primary, secondary, and tertiary**. These tiers provide a structure to which both assessments and interventions are mapped, based on how capable the health system is. Consider a health system where homes have ready access to glucometers, BP monitors, and pregnancy test kits, but RT-PCR and sputum tests are limited to secondary care facilities. The assessments, or diagnoses, enabled by this system can be represented by the following capability map:

This map is a collection of nodes—each node represents the intersection of a tier of care, and a disease or condition. At each node, we use available skills and tools; collectively, capabilities. Using these capabilities, we update our risk model, and re-stratify the risk faced by the patient. Similar maps can be developed for interventions. A capability map evolves as processes mature, technologies develop, and care providers acquire new skills. Accurate, inexpensive rapid-antigen tests are moving definitive diagnosis of COVID-19 from labs to homes, similar to how self-use test strips moved pregnancy detection from labs to homes. In the domain of interventions, community-based vitals monitoring & drug dispensing are replacing a large portion of facility-based management of hypertension and diabetes. These maps enable us to identify nodes that need new, innovative ways of delivering care to achieve high public health impact. Thus, they tell us where we are, and help us see where to go. ### Group-based intervention Interventions are the last element of our conceptual framework. Effective intervention design requires targeting, which necessitates grouping. Within a single risk strata, a population can be divided into groups based on the need for, and the access to, healthcare services. Groups are based both on a population’s characteristics, and how the health system is organized. While designing groups, consider the following dimensions, or axes: 1. Location: proximity to public health facilities, access to transportation, environmental conditions near home or work. 2. Socioeconomic status: measured through parameters such as housing, income, access to clean water \[[1](https://doi.org/10.1080/16549716.2018.1438840)], and education. 3. Risk velocity: change in risk over time, as a supplement to risk strata. 4. Secondary risk factors & comorbidities: At the minimum, relationships where risk of one disease increases risk of another. Example: HIV/AIDS is a 20–40x risk-amplifier for TB \[[2](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3685687)]. Thus, working-age urbanites form a different group than rural pensioners, even if they have the same risk of hypertension. [^1]: In case you are wondering, I did test positive for COVID. # Part II: Model design ## From snapshots to temporal data Conventional risk assessment models assess risk at a particular point in time. This is based on the paradigm that past data is inaccessible — a paradigm that is ripe for inversion. For instance, the [INTERHEART](https://www.thelancet.com/journals/lancet/article/PIIS0140-6736$04$17018-9/fulltext) 10-year-risk score for acute myocardial infarction emphasizes smoking history & status. However, this information is sought at one specific point in time — a snapshot. If smoking status were available across time, we would be able to compute a more graded risk score — with higher confidence. ## Risk assessment: choosing what to ask Risk assessment design starts by deconstructing risk factors by disease. Then, based on how much each factor contributes to population-scale health, they have to be reintegrated. For instance, the utility of measuring oxygen saturation has significantly increased since 2020 — low SpO2 is a risk factor for both COVID-19 and chronic respiratory illnesses. This cycle of deconstruction and reintegration has to be performed each time a new disease is added to the scope of population health. The choice of which diseases to address is a function of their incidence, prevalence, morbidity and mortality. The desired result — clinically useful estimates of risk for the majority of diseases affecting the population. One limitation of clinical utility is — many prominent risk models originate in western countries, and do not translate well to most of Asia and Africa. Primary research is required to correct this imbalance. ## Enabling configurable algorithms Risk is population-specific, hence algorithms need to be configurable. However, the master set of factors that drives risk assessment is relatively constant. It needs to be updated only when a new predictor of risk is identified. In this manner, we can determine a master set of factors, and use subsets to assess risk of individual diseases in specific populations. Consider cardiovascular disease, where large bodies of evidence have been used to create several risk models — such as FRS, PROCAM, SCORE, INTERHEART and WHO-CVD-PEN protocols. These models vary in the weights they assign to a risk factor, and their applicability varies across populations. However, they use a common set of parameters — Age, Gender, Family history, Smoking status & history, Systolic and diastolic blood pressure, Total & HDL cholesterol, and Diabetes status. Though configurable, the system should provide pre-set algorithms — to introduce a deliberate bias towards scientific rigor and evidence-based medicine. Health systems may override these presets if they have more robust, context-specific evidence. ## Integrating self-reported data Data acquired directly from individuals provides early signals that can trigger interventions well ahead of traditional, facility-centric health information systems. Self-reported health status is the foundation on which community- and facility-based care can be delivered. ## Expanding data sources Public health extends beyond health — it involves the environment, socioeconomics, education, nutrition, and more. Thus, data sources must extend to non-healthcare information systems, such as employment & income data housed in labor departments, or sanitation data from public works departments. These data sets need not be precisely mapped to individuals. They should be mappable to population groups, so that *a priori* risk can be estimated more accurately. Such estimates help direct community-based screening programs for maximum impact. For instance, data about sanitation conditions aids screening efforts for dengue, chikungunya and malaria. # Part III: Enabling the model to function, using software The model design presented in the prior section needs software to function. Temporal health data, risk assessment algorithms, capability maps, and group-based interventions—all of these elements require digital representation to perform to their full potential. In this concluding section, we will identify key functions that a software system should perform to enable population-scale health assessment and intervention. We assume a **mobile-first software system**, in which beneficiaries, community health workers, and primary care staff, all use mobile apps. We assume that smartphones are commonly available among beneficiaries, but do *not* assume that they are ubiquitous. In such a system, data is housed both on mobile devices, and in a central server. All elements of the model map to functions, as shown in the table below.

We conclude with a section on separating clinical aspects from procedural ones, informed by our implementation experiences. ## The right questions, at the right time In a temporal risk profile, every interaction between a beneficiary and a care provider adds data to the beneficiary’s health record. To build such longitudinal records, the data collection instrument—such as an app used by a community health worker (CHW)—has to deliver intelligent prompts. Such prompts help collect the most valuable data first — enabling efficient service delivery. Efficiency is a key objective, because care providers have limited time. For example, if a 60-year old male reports no current complaints, then two data points have immediate value — abdominal obesity, and resting blood pressure — to assess their risk of diabetes and cardiovascular disease. However, if the same person reports being chronically short of breath, then response to a salbutamol inhaler is a valuable next step — to assess risk of COPD versus Asthma. Question selection is as critical as question sequencing. For instance, a 2017 Peruvian study \[[4](https://www.thelancet.com/journals/laninf/article/PIIS1473-3099$17$30447-4/fulltext)] demonstrated that exposure to indoor smoke was a more important contributor to TB risk than self-reported cough frequency; the latter had no meaningful impact. Thus, to estimate TB risk, it would be of far greater value to ask how a household cooks, rather than how much it coughs. Yet cough is a common question in TB screening forms, and indoor smoke data is rarely captured. Question selection also should take into account the shelf-life of data. Education and employment data has a relatively long shelf-life, whereas parameters like blood glucose are most valuable when “fresh”, and need to be checked often. ## Dimensions of configurability ### Adapting to varying capabilities Assessments and intervention capability maps determine who acquires what information, at which tier of care. Hence, a CHW’s scope of work is the sum total of all the assessments and interventions mapped to the “Community” tier of the system. In a generalizable software system, capability mapping has to be configurable — to provide a mutable structure within which care pathways operate. Even so, the system needs to be loosely coupled; it cannot be strictly sequential. A hypertensive patient may be directly diagnosed at a tertiary care center, because they chose not to participate in community screening efforts. The system must accommodate such scenarios. ### Offline-capable A software system that spans homes, communities and facilities has to be offline-capable. In most low-resource settings, internet access is erratic, and bandwidth is often limited. Thus, the mobile app has to be able to perform all critical functions when offline. Consequently, it must store relevant data locally on the device, and exchange it with the server as and when the internet is available. During such sync operations, the app should limit both the bandwidth used, and the total payload. Also, any logical updates, such as new risk algorithms, have to be packetized and then delivered to the app. Such packets should enable the app to reconfigure itself. Thus, the app has to be configurable, and cannot depend wholly on static code. Finally, offline-capable designs need to incorporate added layers of data protection, because records are now available locally on phones. ## Beneficiaries as actors Healthcare professionals in the public sector are often overloaded. This is particularly true of CHWs, who spend a large portion of their time moving door-to-door. The underlying assumption is that CHWs have to seek out beneficiaries in-person in order to effectively deliver services. While this is true for many aspects of care delivery, it can be supplemented by the actions of beneficiaries. Beneficiaries should be given the agency to act in concert with their CHW. The commonest way in which health systems give greater agency and access to patients is by offering them telemedicine. However, this is a resource-intensive starting point, requiring good internet connectivity, new service delivery processes, and well-equipped smartphones. Also, it risks disintermediating the CHW, because access to telemedicine encourages patients to directly seek out doctors. Instead, we recommend a system that strengthens the CHW-beneficiary link. Given this paradigm, the beneficiary app should enable two types of tasks: 1. **Load-leveling tasks**: Tasks that reduce data entry burden on CHWs — such as adding addresses and family member details of a beneficiary. 2. **Early-detection/ disease surveillance tasks**: Tasks that provide basic measures of a beneficiary’s wellness, without the need for any measurement tools — such as a smartphone-based vision test. These two types of tasks are complementary — they free up the CHW’s time, and enable the CHW to utilize this time to contribute more meaningfully to community health. ## Patients’ ownership of data Health records, and more generally, protected health information (PHI), is highly sensitive. Be it online or offline, it needs strong controls. ## Patient are data owners PHI belongs to the patient. Often, patients assign these rights implicitly during the treatment process — this is implied consent. For example, when I interact with a CHW for a hypertension checkup, I grant them access to my vitals signs data. This consent is not expressly granted; rather, it is implicit based on my actions and the circumstances. The software system must support rules that distinguish between implicit and explicit consent, and the latter should be supported digitally. ### Public health systems as data fiduciaries A fiduciary is a person who holds a legal or ethical relationship of trust with a beneficiary, particularly when the fiduciary is more informed or skilled than the beneficiary. Medicine and law are everyday examples; we depend on our doctor or lawyer to use their specialized skills for our benefit. In the context of PHI, public health systems act as data fiduciaries. Health systems maintain records of consent granted by patients, and control access to PHI based on the requestor’s identity. This is particularly critical when entities of varying affiliations contribute to, and access, a single individual’s PHI. An example — a private care provider accesses a patient’s blood pressure and body weight history collected by a CHW, arrives at a diagnosis, and provides a prescription. The software that governs such a system has to authenticate users, apply consent policies, and log the exchange of data — in a transparent, rigorous manner. ### Data storage principles Once data is captured, its storage must be governed by three fundamental principles of purpose, duration, and proportionality. Data should be stored for a clearly defined purpose, for a fixed period of time, and in quantities or proportions that match the purpose. The principles have to be converted to policies, and policies have to be enabled by the software system. ## Interfacing with external systems A wide variety of health indicators and operating processes has led to the creation of many customized software systems. Customization makes interfacing & interoperability challenging. A simple example is a patient’s name. Some software systems store it as a single string, whereas others store it in parts: given name, middle name, and family name. This difference in data models makes the two systems incompatible. The increasing adoption of Fast Healthcare Interoperability Resources (FHIR®) has brought standardization to both data models, and mechanisms of exchange. FHIR is a core part of HL7 standards. It adds value in the following ways: 1. It defines the minimum structure that common data objects must adhere to. 2. It encourages the use of contemporary software interfaces for data exchange. 3. It provides easy integration of standardized clinical nomenclature systems, such as ICD-10, SNOMED-CT, and LOINC. The first two focus on conditions, diseases and symptoms. LOINC focuses on physiological parameters & lab tests. 4. It leaves room for healthcare systems to add their own customization, without disturbing the core data model, using a feature called Profiling. Today, any software system developed for a large health system must be FHIR compliant by design. Interfaces with external, non-health systems can and will lie outside FHIR — and require judicious customization. Some design considerations for external interfaces are: 1. External systems may require batch processing — in such a case, APIs (application programming interfaces) should be able to handle batch data. 2. Data should be exchanged only via APIs. Direct data insertion must be avoided. 3. External systems that contribute to health data may, someday, ask for their data to be discarded. This must be considered while designing partitions between internal and external data sets. ## Separating the clinical from the procedural Procedural aspects emerge from administrative policies used to govern a health system, but are unrelated to clinical knowhow. For instance, medicine dispensing at home may require approvals from administrative officers, and periodic inventory verification. Procedural elements must be kept separate from clinical elements, so they they can be independently configured. # Focused factories Soura Bhattacharyya | Feb 18, 2015 ## “Focused factories” that disrupt traditional healthcare delivery Focused factories for surgical interventions focus solely on one treatment — such as hernia repair or gall bladder removal — and address diseases that are widespread, well-characterized, and can be addressed with surgery. ## The Current Paradigm Hospitals in India, and around the world, are currently focused on bigger is better — building capital-intensive facilities which cater to a wide variety of patients and conditions. Conditions treated range from those which are truly complex, to simple diagnostic and therapeutic interventions. Even Ambulatory Care Centers, such as Apollo Clinics, address a wide variety of patients. Such systems try to solve three kinds of problems under one roof: 1. Those that involve **intuitive medicine**, requiring an array of specialists under one roof to find answers to complex diseases and administer multi-specialty treatment plans. The likelihood for success varies widely from one patient to another. 2. Those that involve **empirical medical**, consisting of treatment for diseases where probabilistic statements about outcomes can be made. Prostate cancer surgery is such an area, where screening algorithms and intervention rules are well articulated, but there is still some uncertainty for an individual patient. 3. Those that involve **precision medicine**, where the problem as well as solution is well understood. An ear infection that requires a drain to be placed through the ear drum is an instance of such a problem. ## Why change the paradigm? By the very nature of these medical problems, a single umbrella organization cannot setup systems and processes that do all of these jobs efficiently. Intuitive medicine requires a consulting-like approach, with a fee-for-service model — the outcomes are so uncertain that paying for results is not feasible. Empirical medicine, however, can adopt a pay-for-outcomes approach, whereas precision medicine can go down to a fee-for-process-compliance model. Combining these business models under a single roof is like trying to create a factory that produces both Ferraris and Maruti 800s. The goal of “focused factories” is to solve ONE empirical medicine problem that is currently both under-addressed by existing medical systems, and unprofitable for these medical systems to address. A treatment system oriented around empirical medicine requires a disease area that has adequate volume to support an economically viable enterprise. India offers such an opportunity, as has been demonstrated by the success of Aravind Eye Care in addressing “curable blindness”, provided the right model of care is built around it. ## The “Ideal” Disease: thinking beyond scale Beyond incidence and prevalence, there are certain attributes that make a disease suited for treatment using the focused-factory paradigm. These are: 1. **Easy to self-identify**: The “ideal” disease can be quickly understood by the patient and his/her family or friends, enabling some of self-diagnosis that makes the secondary screening step more efficient. 2. **Easy to screen**: Once patients do get to the treatment center (or an outreach arm of the center), there should be an efficient mechanism to classify patients, in order to serve those who meet strict inclusion criteria, while referring complex cases to integrated medical centers. 3. **Clear short-term outcomes**: In order to validate process adherence, a rapid, intra-operative or post-operative measure of success is crucial. 4. **Minimal post-operative recovery**: A complex or lengthy recovery protocol is hard to administer in India. Closure of treatment within a single episode of care is ideal. There are two ways to position such an entrant relative to incumbents. The first approach would be to go head-to-head against them, as a cheaper alternative. Alternatively, such an enterprise can be positioned as a referral institution, to elicit a cooperative response from incumbents. The growth of balloon angioplasty in the US is a case in point. In its early days, this intervention, provided by cardiologists, rather than cardiac surgeons, had a 50% treatment success rate. Those patients who could not be treated with balloon angioplasty were sent over by cardiologists to cardiac surgeons. The surgeons found that a large number of patients who would otherwise not consider cardiac bypass as a first line of treatment, we now turning up at their doors with a referral in hand. They had no incentive to fight back, and this was compounded by their perception—later proved wrong-- that balloon angioplasty would remain a sub-optimal treatment choice for the foreseeable future. Even if incumbents frame the entrant as a competitive threat, they have low incentive to fight if the entrant reduce the number of unprofitable customers that come to the incumbents' doors. And these customers can be treated profitably by the incumbent, with its focus on doing *one job* very effectively. ## Lessons from Aravind Eye Hospitals Aravind Eye Hospitals is the prefect example of a focused factory. Its founder, Dr. Govindappa Venkataswamy (Dr. V), likened their operational model to that of MacDonalds — in terms of both scale and process-orientation. Aravind offers us several rich lessons on how to operationalize a focused factory. Some of these are: 1. Find the right disease to treat: Aravind meets all the requirements of the “ideal” disease checklist. Patients are able to identify problems with their vision, and attend an eye camp to be screened for cataract surgery. Surgical outcomes are visible after a single intervention. 2. Cross-subsidization equals competitive advantage: Aravind treats patients both rich and poor. The latter provides the volume that allows surgeons to gain a high level of proficiency, and this skill level attracts patients with the ability to pay. The wide variety of pathologies that an eye surgeon sees at Aravind has also made it an attractive training site for doctors from the US and Western Europe, providing a steady stream of free labor to Aravind. 3. Social behaviors are integral to service delivery: While their eye camps were a success in rural areas, Aravind noticed that many patients did not come to the main hospital after they were screened. They found that these patients had no previous experience in traveling independently to a large city to seek medical aid. In response, Aravind organized buses to carry both patients and their escorts to and fro, and provided simple living facilities in their main center. The conversion rates from screening to treatment went up dramatically. ## References The paradigm of intuitive, empirical and precision medicine, and the balloon angioplasty example, is from Clay Christensen’s work on disruptive innovation in healthcare, captured in his book, The Innovator’s Prescription. The section on “ideal” disease is my original contribution. Insights about Aravind's model are from an HBS case study: "The Aravind Eye Hospital, Madurai, India: In Service for Sight", V. Kasturi Rangan, Harvard Business School case study: April 1993 (Revised May 2009) *Photo credit:* [*Petri Heiskanen*](https://unsplash.com/@pheiskan?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/low-angle-photography-of-building-interior-vqO_1fUCNxg?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) # Common sense Soura Bhattacharyya | Jul 2, 2024 To run a business, what you need most is common sense. It is far more useful than any educational qualification. I define common sense as the ability to distill a viewpoint into its constituent assumptions (and beliefs), inferences and conclusions — laid out in straightforward language. Assumptions and beliefs are the trickiest part of the puzzle. They are best uncovered by repeatedly asking way asking why. Challenging them often open up new ways of doing business. I once saw a healthcare service firm's founders realize that they had the means to achieve their growth goals organically, once they examined assumptions underlying the following conclusion: 1. The only way to grow is to have more capacity. 2. The only way to increase capacity is to have more equipment, because existing equipment is utilized at over 85%. 3. Therefore, the only way to grow is to get more funds to purchase new equipment. They looked deeper, and found and found that: 1. Machines run for 14 hours a day. 2. Equipment utilization was calculated using 16 hours as the denominator. 3. They assumed that machines could only run during the day, and not at night. 4. This was based on the assumption that their services could only be delivered during the day, and not on a 24-hour basis Other services of a similar nature were being delivered by other firms on a 24-hour basis. When they re-set their assumption about how long they could run their machines, they realized that they could exceed their growth goals, without investing another rupee in equipment purchases. # Consent in Digital Health Soura Bhattacharyya | April 10, 2025 *This post was preceded by a less thorough, more geeky, and less boring one, available* [*here*](/readme/authorization-equals-consent)*. It is better to read this one first—till we take the time to merge them into a single thread.* *** The collection, storage and exchange of digital health data needs the consent of the patient—the data subject. As per the EU's General Data Protection Regulation (GDPR), consent has to be "explicit, informed, specific, freely given, and unambiguous". This position is echoed in India's Digital Data Protection Act, 2021. Legislation has shifted from data **ownership** to data **stewardship**. Data controllers and processors are custodians, and the **data subject is, unambiguously, the owner**. Consequently, data processing, especially in sensitive categories such as health and finance, needs consent. Effective consent management is more than legal compliance—it is a way to gain users' trust. It empowers patients to exercise granular control over their health data, allowing them to monitor who accesses their information and for what purposes. ## Consent and authorization When a patient *consents* to an entity's request to access their data—for a defined purpose and duration—then this action *authorizes* the system to permit that access. Conversely, the revocation of consent must translate to a denial of authorization. Thus, consent and authorization are two sides of the same coin. ## Challenges in consent management Implementing a comprehensive consent management system faces several challenges: * **Complexity:** Healthcare scenarios often involve layered and complex consent requirements, including consent for different data types, purposes, timeframes, and actors. * **Usability:** Interfaces for obtaining and managing consent must be patient-friendly, simple to understand, yet comprehensive in their coverage. * **Interoperability:** Consent management needs to interface with a variety healthcare information systems operated by different service providers. * **Compliance:** Consent logs must be **externally verifiable** by regulatory bodies without revealing the underlying health data. * **Proxies:** The system needs to accommodate consent provided by legal guardians and caregivers. ## Open-source authorization models as consent managers Open-source authorization models offer a powerful and cost-effective approach to address these challenges. Relationship-Based Access Control (ReBAC), exemplified by OpenFGA, allow for defining access based on the relationships between users and resources. In the context of consent, this can model the relationship between a patient and a healthcare practitioner they have granted access to, or the relationship between a patient and different categories of their health data. OpenFGA enables fast queries to determine if a user can perform an action on a resource. This can directly translate to checking if a practitioner has valid consent to access specific patient records. Access can be highly granular, based on factors such as the practitioner's attributes (`practitioner P is a general physician`), their relationships to other entities (`P is a member of clinic C`), and their relationship to the patient (`patient Q has an appointment with P`). Furthermore, the transparency of open-source allows for community review—shifting power from institutions to individuals. Finally, Adapting costs less than [building from scratch](#user-content-fn-1)[^1]. [^1]: Of course, nothing is ever built from scratch. As Carl Sagan said, "If you wish to make an apple pie from scratch, you must first invent the universe." # Authorization equals consent Soura Bhattacharyya | March 12, 2025 Consent is an essential component of any digital health system that connects patients with providers. While designing such a system, I went about looking for a open-source consent manager that could be used for health data. No such luck. Then it struck me—consent is nothing but authorization! After all, authorization lets us control who gets access to which resources, and for how long. Consent managers serve precisely the same function. And there are plenty of robust, capable, open-source authorization platforms. My favorite is [OpenFGA](https://openfga.dev/), which nests within the Cloud Native Computing Foundation (CNCF). ## Access control Consider how we manage access to a set of folders on Google Drive (or Dropbox or Sharepoint). As an owner, you can provide top-level access—to the parent folder—to anyone. They can be editors, commenters, or viewers. Or, you can provide more granular access—to sub-folders, or individual resources (documents). Finally, child resources inherit access rights from their parents. The use of such object-to-object relationship to manage access is called relationship-based access control, or ReBAC. More generally, a ReBAC is able to resolve the question: ``` Can user U perform an action A on object O? ``` Google's ReBAC is called Zanzibar. OpenFGA uses the same principles as Zanzibar. OpenFGA's ReBAC model can also uses relationships between users. A `supervisor` can be allowed to access all the resources that are available to the subordinate. In a healthcare context, this can be applied to a treating physician, and their immediate supervisor. Groups of users can also be managed collectively, and access can be controlled based on properties such as time[^1] or network address. For more on this, see OpenFGA's [modeling guide](https://openfga.dev/docs/modeling). ## Purpose limitation What about the purpose for which consent is being sought? I jumped into the "how" of access control before asking about the "why" of purpose. Here too, we can look to authorization for some ideas. OpenFGA's modelling guide presents the question about purpose as follows: ``` Why can user U perform an action A on object O? ``` The answer to this question has to be defined by the system designer. It can then be codified in the authorization model. ## Concluding thoughts Imagine a healthcare consent manager that is as flexible and adaptable as an amped up folder-sharing system, and where a single resource (or document) can belong to multiple folders—folders can be episodes of care, health facilities, or treatment history for a set of diseases. Or don't imagine it—build it with OpenFGA. [^1]: Technically, authorization based on properties such as time is attribute-based access control (ABAC). Attributes include relationships; ABAC is a superset that includes ReBAC. # Quality control > Control applies to processes, not people. Self-control applies to people. ## Quality philosophy At Lattice, we define quality in a holistic manner — not just in terms of features of a system, but in terms of its performance, usability, maintainability, reliability and security. A simple way to understand and measure quality is to ask: *how will this affect my customer?* The customer can be internal (a colleague), or external (a client or an end-user). This customer orientation leads us to the following **quality philosophy**: * Take no error (from my supplier) * Make no error (at my workstation) * Pass no error (to my customer) ## From philosophy to framework To provide structure to our quality philosophy, we first divide it into two categories: extrinsic and intrinsic. Extrinsic quality is visible when we examine a system from the “outside”. This is what a user sees. Intrinsic quality becomes apparent when we examine the content of our work. This is what a developer sees. Consider the following: a search feature in a web app does not yield expected results. This impacts extrinsic quality, and such deficiencies are measured by tracking bugs. Bugs are classified by source and severity, enabling us to measure quality at each workstation. Suppose the search feature worked as expected, but was implemented using a large number of nested loops (high cyclomatic complexity). This makes the code hard to understand and modify, impacting its intrinsic quality. We measure such deficiencies using automated code analysis tools. Finally, for us to label something as “unexpected”, we have to define what is expected. This is done through scope documents, use cases, navigable prototypes, and test procedures. Taken together, they constitute system specifications. ## Operationalizing the quality framework The quality framework is made operational via GitHub — the world’s most popular online code repository, built on top of the git version control system (git-vcs). We have been using GitHub to maintain our code and specifications since December 2017. For each project, we typically create three repositories[^1] — `control`, `frontend`, and `backend`. ### Managing specifications The `control` repository contains all the specifications. When a specification is created or updated, it is reviewed by project team members before it is queued for development. And any change in code can be traced back to the specification that triggered it. There is **two-way traceability** — from specification to code, and code to specification. The `control` repository also lists all the tasks, grouped in a parent-child structure. Parent tasks provide a high-level overview of project progress, and child tasks are used by individual contributors—technical architects, developers, designers and quality analysts—to track their work. Tasks are also tracked in GitHub’s project management system, with filters to monitor status and timeliness. ### Addressing errors The `control` repository logs any bug reports filed by the client, or by the Lattice QA team. If the client reports a bug, then a Quality Analyst reproduces the issue, and attaches images or videos of the error as proof. Codes changes to fix errors reference these bug reports. Each bug has a 4-level severity rating associated with it: * **Critical**: A bug that prevents the system from being used, such as failure of the login module, or creates a security vulnerability, such as an exposed encryption key. * **High**: A bug that affects key features, such as the inability to add a new user to the system. * **Medium**: A bug that allows invalid data to be added to the system. For example, suppose that 10-digit mobile numbers are required while creating a new user. If the system allows 8-digit numbers to be entered, then such a bug would be classified as a medium severity. * **Low**: Bugs that do not impede usability, such as incorrect font colors or minor typos. Bug resolution times vary based on severity, as follows: * Critical: 8 working hours * High: 16 working hours * Medium: 24 working hours * Low: 40 working hours Bug fixes are carried out during our business hours: 10 AM to 6 PM IST, Monday to Friday. ### Managing code The `frontend` and `backend` repositories contain code, build instructions, and scripts that automate deployment. Whenever code has to be added or updated, it is first added in a branch of the `main` codebase. Isolating the change protects production code, makes the change easier to evaluate, and enables us to connect specification and code at a granular level. This workflow is illustrated below.

**New code contribution: merging a branch after review**

Before the code change is merged, it is linked to a "ticket" in the form GitHub issue. This enables specifications changes to be linked to code changes. Finally, before it is merged, the new code undergoes an automated check that evaluates it on four parameters: security, reliability, maintainability, and duplications. We have zero tolerance for code with security issues—such code is flagged and sent for rework. The same happens if code does meet a pre-determined standard on the other three parameters. Real-time quality analysis enables us to fix quality issues during development, rather than after deployment—so that our team members “take no error”, “make no error”, and “pass no error”. ## Sustaining and improving quality Sustaining change, and improving upon it, is only possible when work standards are in place. Standards act as a step on the ladder of improvement. The quality system described thus far is defined in our work standards, which were first formalized two years after our inception. Since then, they have become a living collection, to which many employees have contributed. A work standard starts out as a work practice—one person trying something new. If their experiment is successful, they convert it to a work standard. It is then disseminated through the organization by the leadership team, which meets once a week to define the agenda, incorporate new learnings, and monitor implementation. The reverse also takes place—the management team examines process shortcomings, devises work practices, pilots it in a project, and then converts it into a work standard. The quality system is also integrated with Lattice’s performance measurement system. Quality is the [single largest parameter](#user-content-fn-2)[^2] used to measure individual and collective performance. *Photo credit:* [*Tolga Ulkan*](https://unsplash.com/@tolga__?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/yellow-and-brown-leaves-on-white-ceramic-tiles-9k36QqhA0cU?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) [^1]: A repository (repo) can be thought of as an access-controlled online folder that has an extensive change management system. Repos can contain code, images, videos, or documents — anything digital. [^2]: The other three parameters are timeliness, learning & growth, and self-directedness. # Managing projects Have you faced a situation where a project appeared to be in control for the first two-thirds, and then spiraled out of control close to the finish line? This has happened to us more times than we would like to remember. Our response has been to develop work practices that prevent some of these situations, and mitigate others. ## Definitions first Who is a manager? Someone who plans, and addresses deviations from the plan. Without plans, deviations cannot exist. As planning time decreases, and deviations decrease, so does managerial time. This was an important motivation for us—in our team, managers of one project are often workers on other projects. Thus, the less we have to manage, [the more we can work](#user-content-fn-1)[^1]. What is a project? A set of interconnected tasks that, once complete, achieves a goal. Thus, to manage (or supervise) a project, is to select a goal, plan to achieve it, and address deviations that arise on the way. ## Planning a project Our project planning process is divided into four steps. 1. List and categorize all the tasks that must be completed to reach the goal. 2. Sequence tasks in the order in which they must be performed. 3. Allocate tasks and estimate their duration, based on the resource[^2] who will perform them. 4. Schedule based on the resource’s availability and capacity. **When all four steps are complete, a project plan can be visualized as a Gantt chart.** ### List Though simple, a comprehensive list of tasks is essential — otherwise the project is sure to deviate. While listing tasks, we work from the finish to the start. This puts us in a delivery-centric mindset, and reduces the risk of missing a task. Error prevention also starts here. As we made more project plans, we built a master template. An exhaustive template only has to be trimmed down to suit a particular project. It is much easier to whittle down a list, than to remember what to add. This also applies to making a list for packing clothes for a trip. Make a 7-day-trip version first, and then trim it for a weekend trip. ### Categorize A task is categorized by the workstation that performs it, and the component[^3] that it belongs to. A component is a portion of the project that can be developed independently. For instance, a mobile app for primary healthcare may have the following components—user registration and login, screening, consultations and prescriptions. Design and development of such an app involves six workstations—scoping, system specifications, user interface design, backend coding, frontend coding, and final inspection[^4]. Tasks are thus labeled with both their workstation, and the component. And work flows from one workstation to another, for each component, until all components are complete, and ready for final assembly into a single app. ### Sequence Sequencing requires us to understand dependencies between tasks. There are 2 types of dependencies — workflow-driven, and resource-driven. Workflow-driven dependencies arise from the need to do work in a particular sequence — backend services are required for frontend application code to work. Resource-driven dependencies arise when the worker has to finish one task before starting the next. Once we label a task with its workstation and component, the workflow-driven dependencies become clear. Resource-driven dependencies are readily apparent—we use a software tool that totals up the workload on each member of our team, to ensure that resource-driven dependencies are accounted for. Recently, we developed a system to enable cross-project dependency checking. To deskill task sequencing, we create templates that provide workflow-based dependencies. ### Allocate tasks, estimate duration When tasks are performed manually[^5], task duration is intimately tied to allocation. The more capable a contributor, the lower the duration. Tasks are sufficiently granular so that they can be allocated to one individual. This brings in accountability. Two people cannot chop vegetables using the same knife. ### Schedule tasks Once we have estimated durations for each task, we add them up by contributor. The contributor who is the most heavily loaded, limits the rate at which work can be completed. This is the busy bee. For the project team to deliver at the highest rate possible, the busy bee must be kept fully occupied—though not overloaded! Hence, all other contributors’ schedules must be subordinate to the busy bee’s. Also, the busy bee’s schedule has to be protected by the entire project team. To do so, other team members have to treat any work flowing to the busy bee with the highest priority. Before finalizing the schedule, it is often useful to check if some of the busy bee’s tasks can be assigned to other team members. This is called load leveling. Once we make the schedule, we examine the critical path, i.e. the longest path that determines project duration. It must include all the tasks to which the busy bee is allocated. If not, the schedule is likely erroneous. A well-laid out schedule enables each contributor to see their own task sequence, along with immediate predecessors and successors. ### Add a buffer The final step of creating a project plan is to include a project buffer—a measure of uncertainty. Uncertainty has three drivers: 1. Task complexity: the harder each task, the greater the uncertainty. 2. Interdependence: the more intertwined the tasks, the greater the uncertainty. 3. Project duration: the longer the project, the more it amplifies the first two drivers. At Lattice, we use a simple heuristic to calculate the project buffer. We assign a score of 1, 2 or 3 — corresponding to low, medium or high — to complexity and interdependence. We then sum them up, and multiply the result by the project duration, in months, to arrive at the buffer duration, in days. Thus, a complex, medium-interdependence, two-month project has a buffer of 10 days. In contrast, a simple, low-interdependence project lasting a month has a buffer of 2 days. Often, clients view a project buffer as a place to “save time”. But deleting the buffer does not magically remove uncertainty. Project managers need the support of senior managers to protect project buffers. ## Tracking & resolving deviations Thus far, our focus was on creating a plan. Once we begin executing it, we have to check for deviations, and act to correct them. This represents the third and fourth steps of the PDCA loop—plan, do, check and act. ### Identifying deviations The project buffer is a single metric that reveals deviations. Suppose the project has progressed by 25%, but 50% of the buffer has been used up. This warns us of deviations that can result in late completion of the project. ### Sources of deviation The project planning process itself suggests the following sources of deviations: 1. Task missed 2. Task mis-sequenced 3. Task mis-allocated 4. Task duration higher than planned, because of any one of the following: 1. time taken to fix errors or defects 2. an erroneous estimate of task difficulty 3. an erroneous estimate of contributor’s capability 4. delays in starting or doing the work Only the last source of deviation is person-dependent; all others are process-related. Hence, managers are best served by improving processes. As process-related errors are eliminated, person-dependent errors shrink rapidly. A workplace that eliminates waste from its processes, provides an environment that encourages its workers to improve their performance. A waste-free environment encourages waste-free habits[^6]. The surest way to reduce process-related errors is through the use of work standards, which is a key weapon in Kaizen’s armory. Once we implement work standards, our PDCA loop transforms into an SDCA loop. Each time we work on a project, we standardize[^7] what we learn by updating our work standards. We must be aggressive in culling down work standards to only those that are necessary, else we run the risk of creating bureaucratic overhead. If a new work standard is not updated in 6 months from its date of creation, it should be consigned to the rubbish heap. No one is using it. Work standards provide a mechanism by which the lessons learnt by one project team can be shared with many. Learning from our own errors is experience. Learning from others’ errors is wisdom. ## Further reading In the next post, "[Finding the critical path](/readme/finding-the-critical-path)", we dive into how to identify the critical path in a project—a essential aspect of of scheduling tasks, and a diagnostic tool for analyzing deviations. *Photo credit:* [*Simon Gibson*](https://unsplash.com/@onedharma?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/red-metal-frame-under-white-sky-during-daytime-FT362qyhd58?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) [^1]: However, in organizations where "managing" is seen as the only work for some people, this motivation may not exist. [^2]: There are 3 types of resources — supplies, equipment and people. For most services businesses, like Lattice, resources equal people. [^3]: **At Lattice, we prefer to use “module” while referring to products and solutions, and “component” while referring to the process of assembling them. Modular products are enabled by componentized design and development. In casual conversation, though, I use these two terms interchangeably.** [^4]: We have a final inspection workstation today. We have to work towards eliminating it. [^5]: **Merely using a tool does not make a task automated. Software development is manual — a contributor’s capability determines the rate of work.** [^6]: **Just like a litter-free environment encourages us to throw trash in the trash can. Environments have a profound influence on our behavior — this has to be understood by managers and leaders to create any organizational change.** [^7]: **The term “standardize” is often misunderstood. It brings to mind monotonous, repetitive work. But doing the same thing is not standardization. Rather, to standardize is to transform fluctuating inputs into consistent output.** # Finding the critical path Soura Bhattacharyya | April 10, 2023 ## Motivation and overview One of the key analytical measures of a project is its critical path, or CP—the longest path from start to finish. Tasks on the CP have to be closely monitored; delays in the CP delay the entire project. The CP itself has to be monitored—complex projects have dynamic CPs. We have used several off-the-shelf project management tools, both with and without CP calculation. Those that did have it, did not perform to our satisfaction. We were left wondering—what's under the hood? Recently, we developed an in-house project management platform, [Feeta](https://www.thelattice.in/projects/feeta). One of its features is to calculate CP. It performed to our satisfaction, and handled tricky real-world scenarios with aplomb. At its heart lies the Bellman-Ford (BF) algorithm. This post presents our understanding of the BF algorithm. If you want a more thorough analytical grounding, please check out the [resources](#resources-for-self-study) mentioned at the end this post. That is where we started. This post introduces basic terms used in graph theory, and works through an example step-by-step, so that the iterative nature of the BF algorithm can be more clearly understood. Finally, we provide pseudocode and python code from other internet resources. ## Setup We start with a project that has tasks with durations and dependencies. There are multiple paths from start `s` to finish `f`. The longest path, or the critical path, is `{s,k,h,i,m,n,f}`, totalling 15 days.

Figure 1: task durations and connections

Graph theory can be applied to analyze such a diagram—each task is treated as a ***vertex***, and each dependency is an ***edge***. Projects can be thought of ***weighted, directed, acyclic graphs***, commonly abbreviated as weighted DAGs. ***Weights*** represent any numeric property of an edge; here, we use task duration. ***Directed*** graphs are unidirectional—we move only from predecessors to successors, from `s` to `a`; never the other way. And ***acyclic*** graphs do not have cycles, or loops. To analyze projects, we assign weights equal to the task duration to each of the edges, so that path length converts to project duration. To find the CP, we need an algorithm that finds the longest path. ### Inverting weights The Bellman-Ford algorithm searches for the shortest path in a graph. But the critical path is the longest. Therefore, we invert the signs of all weights, so that a task of weight (duration) `2` days is represented as `-2`. Consequently, the path with the highest negative value is selected as the shortest: the critical path. ### Assigning weights to edges Before we find the longest path, we have to assign weights to edges. If we assign the duration of task `v` to the edge `{v,w}` that connects to the successor `w`, figure 1 transforms into figure 2.

Task `a` is 2 days long, and is followed by task `b`. Thus, we set edge length `C(a,b)` equal to the duration of task `a`. We could also calculate `C(a,b)` by the difference in start dates: `startDiff = startDate(a)-startDate(b)` While convenient, the start-date-difference method is flawed, because it includes any slack between `a` and `b` as a part of the path length. This defeats the purpose of finding the longest path. However, startDiff is a useful parameter to optimize our calculations. Concretely, 1. If b is a task, then `C(a,b) = min (startDiff(a,b), Duration(a))` 2. If b is a milestone, then `C(a,b) = Duration(a)` This formula accommodates cases where a task finishes on the same day as its successor. In such cases, the duration is one day, but `startDiff` is zero. It also accommodates milestones that are achieved as soon as a task ends, including the project end milestone. ### Example

Figure 3: A sample gantt with four sequential tasks

In the example above, only path is the critical path. It is 1 + 4 + 1 = 6 days long, including weekends/ holidays. Holidays have been intentionally included. Once we calculate the project duration—7 calendar days—we can compare it to the critical path length of 6 calendar days, and infer that the critical path has one day of slack. As we can see, there is a day of slack between the third and fourth tasks. ### Bellman-Ford Algorithm #### Notation Before we move to the algorithm, let us formalize notation: `n` = number of vertices. In the context of a gantt, this is the number of tasks. `m` = number of edges. In the context of a gantt, this is the number of dependencies. `s` = source vertex, `f` = destination vertex (i.e. the starting and finishing tasks) `v` = any vertex `e` = any edge `L(i,v)` = minimum length of a path from s to v, where i represents the number of hops. `i ∈ {0, 1, 2, … n-1}`, because the longest possible path is one that touches all the vertices once. `C(v,w)` = path length between two vertices connected by an edge, v and w ### Loops Bellman-ford is an iterative algorithm, which examines all available next steps as it "walks" through the entire graph. It consists of two loops. #### Outer loop We iterate through an outer loop a maximum of n-1 times, because an acyclic path can, at most, pass through each vertex once (if it passed through the same vertex twice, it would become cyclic, i.e. it would have a loop). A path passing through all `n` vertices has `n-1` segments, or hops. In our example, `n=14`, hence there are a maximum of 13 outer loop iterations. However, because our graphs are sparse—most vertices have one or two inbound edges—we will need fewer that 13 iterations. #### Inner loop Within each outer loop, we examine all available next steps, and “take the next step” wherever we find that it is a shorter path to a vertex. “Taking the next step” consists of 2 actions—updating the distance to the vertex, and adding the new vertex to the array that stores the path. Hence, we execute the following inner loop: ``` for each edge (u, v) with weight w in edges do if distance[u] + w < distance[v] // is it faster to get to v via w? then distance[v] := distance[u] + w // update distance[v] predecessor{s, … ,u} := {s, … u, v} // predecessor array updated return distance, predecessor ``` ### Working example #### Base case, i=0 `i=0` means that there are zero segments, i.e. no hops—hence we can only get from s to s. Therefore, `L(0,s) = 0`, representing a path of zero length from the starting vertex to itself. Also, we set `L(0,v) = ∞` for all other vertices, because we cannot reach any of them in zero hops. Operationally, we can use a sufficiently large number instead of infinity, as long as it is guaranteed to always be larger than any task’s duration (in days). Thus, the distance array for the zeroth iteration is: ``` | iter | s | a | b | c | d | e | k | g | h | i | j | m | n | f | | ---- | - | - | - | - | - | - | - | - | - | - | - | - | - | - | | 0 | 0 | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ``` #### Iteration 1, i=1 Previously computed vertices in red, vertices computed in this iteration in yellow, and unchanged vertices in blue. Paths and path lengths: ``` sk: L(1,k) = 0 sa: L(1,a) = 0 ```

Distance array: ``` | iter | s | a | b | c | d | e | k | g | h | i | j | m | n | f | | ---- | - | - | - | - | - | - | - | - | - | - | - | - | - | - | | 1 | 0 | 0 | ∞ | ∞ | ∞ | ∞ | 0 | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ``` #### Iteration 2 Paths and path lengths: ``` skh: L(2,h) = -1 skg: L(2,g) = -1 sab: L(2,b) = -2 ``` ``` | iter | s | a | b | c | d | e | k | g | h | i | j | m | n | f | | ---- | - | - | -- | - | - | - | - | -- | -- | - | - | - | - | - | | 2 | 0 | 0 | -2 | ∞ | ∞ | ∞ | 0 | -1 | -1 | ∞ | ∞ | ∞ | ∞ | ∞ | ``` #### Iteration 3 Paths and path lengths: ``` skhi: -2 skgd: -1 sabc: -5 sabe: -5 ``` ``` | iter | s | a | b | c | d | e | k | g | h | i | j | m | n | f | | ---- | - | - | -- | -- | -- | -- | - | -- | -- | -- | - | - | - | - | | 3 | 0 | 0 | -2 | -5 | -2 | -5 | 0 | -1 | -1 | -2 | ∞ | ∞ | ∞ | ∞ | ``` #### Iteration 4 Paths and path lengths: ``` skhim: -5 skhij: -5 skgde: -3 sabcd: -7 sabef: -7 ``` ``` | iter | s | a | b | c | d | e | k | g | h | i | j | m | n | f | | ---- | - | - | -- | -- | -- | -- | - | -- | -- | -- | -- | -- | - | -- | | 4 | 0 | 0 | -2 | -5 | -7 | -8 | 0 | -1 | -1 | -2 | -5 | -5 | ∞ | -7 | ``` #### Iteration 5 Paths and path lengths: ``` skhimn: -12 skhijn: -12 skgdef: -5 sabcde: -8 sabef : -7: no change, reached finish in prior iteration ``` ``` | iter | s | a | b | c | d | e | k | g | h | i | j | m | n | f | | ---- | - | - | -- | -- | -- | -- | - | -- | -- | -- | -- | -- | --- | -- | | 5 | 0 | 0 | -2 | -5 | -7 | -8 | 0 | -1 | -1 | -2 | -5 | -5 | -12 | -7 | ``` #### Iteration 6 Paths and path lengths: ``` skhimnf: -15 skhijnf: -10 skgdef : -5: no change, reached finish sabcdef: -9 sabef : -7: no change, reached finish ``` Thus, the algorithm finds five paths from start to finish. The path with the greatest negative value, `skhimnf`, is the longest path, or the critical path. ### Iterations summarized Here is the distance array through all the iterations.

iter	s	a	b	c	d	e	k	g	h	i	j	m	n	f
iter	s	a	b	c	d	e	k	g	h	i	j	m	n	f
0	0	∞	∞	∞	∞	∞	∞	∞	∞	∞	∞	∞	∞	∞
1	0	0	∞	∞	∞	∞	0	∞	∞	∞	∞	∞	∞	∞
2	0	0	-2	∞	∞	∞	0	-1	-1	∞	∞	∞	∞	∞
3	0	0	-2	-5	-2	-5	0	-1	-1	-2	∞	∞	∞	∞
4	0	0	-2	-5	-7	-8	0	-1	-1	-2	-5	-5	∞	-7
5	0	0	-2	-5	-7	-8	0	-1	-1	-2	-5	-5	-12	-7
6	0	0	-2	-5	-7	-8	0	-1	-1	-2	-5	-5	-12	-15

The algorithm terminates in iteration 6 because all paths have reached the finish point.

BF algorithm computes all paths and path lengths

At the end of iteration 6, we also have all paths available as a set of arrays. ### Pseudocode Source: [Wikipedia](https://en.wikipedia.org/wiki/Bellman%E2%80%93Ford_algorithm) ``` function BellmanFord(list vertices, list edges, vertex source) is // This implementation takes in a graph, represented as // lists of vertices (represented as integers [0..n-1]) and edges, // and fills two arrays, distance and predecessor, holding // the shortest path from the source to each vertex distance := list of size n predecessor := list of size n // Step 1: initialize graph for each vertex v in vertices do distance[v] := inf // Initialize distance to all vertices to ∞ predecessor[v] := null // And having a null predecessor distance[source] := 0 // Distance from the source to itself is zero // Step 2: updated distance and predecessors repeatedly repeat V−1 times: // V = number of vertices (tasks) for each edge (u, v) with weight w in edges do if distance[u] + w < distance[v] then distance[v] := distance[u] + w // distance list updated predecessor[v] := u // predecessor list updated return distance, predecessor ``` ### Python implementation A python implementation is available in [Programiz.com](https://www.programiz.com/dsa/bellman-ford-algorithm); it does not print the path. You can [try out this code on Replit](https://replit.com/@SouraBhattacha2/BellmanFordAlgo#main.py), with the following inputs: ``` g = Graph(5) g.add_edge(0, 1, 5) g.add_edge(0, 2, 4) g.add_edge(1, 3, 3) g.add_edge(2, 1, 6) g.add_edge(3, 2, 2) g.bellman_ford(0) ``` The output is: ``` Vertex Distance from Source 0 0 1 5 2 4 3 8 4 inf ``` I use a free Replit account, so no guarantees that the workspace will always be available. ## Resources for self-study * [Algorithms: Design and Analysis, Part 2 | edX](https://learning.edx.org/course/course-v1:StanfordOnline+SOE-YCSALGORITHMS2+1T2020/home) > The Bellman-Ford Algorithm: This is a Stanford undergraduate course, available for free on edX. * [Algorithms, Part II | Coursera](https://in.coursera.org/learn/algorithms-part2#syllabus) > Shortest Paths: This is a Princeton undergraduate course, available for free on Coursera. It includes guidance for java implementation. *Photo credit:* [*Sed "Creatives" Sardar*](https://unsplash.com/@sedcreatives?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/a-sign-on-the-street-r-1EBbpJTFE?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) # The Jugaadathon playbook Sahil Mehta | September 14, 2014 > From 2014 to 2016, we organized medtech hackathons that helped build a community of over 2,000 technologists, clinicial practitioners, designers, and entrepreneurs. This work was done in partnership with the Consortium for Affordable Medical Technologies, or CAMTech, which was housed in the MGH Center for Global Health.\ > \ > We called this initiative, `Jugaad-a-thon`. This post summarizes our learnings about how the design and execution of such an initiative. ## What is the goal of a jugaad-a-thon? An interesting question to ask before doing an event like this is ‘Why are we doing this’? There is no right or wrong way, but here are two different schools of thought. 1. **The Generic jugaad-a-thon** – The idea behind this jugaad-a-thon is to get a community together and give them free space to come up with ideas posing solutions to varying topics. Usually this exercise works great for building up the ethos of hacking to solve problems. If you are lucky, a couple of teams may realize the worth of what they have done and continue on with their projects well past the jugaad-a-thon. An example would be a healthcare jugaad-a-thon for RMNCH similar to the one CAMTech organized in Bangalore. However you get such a broad idea of topics it is hard to clearly judge one solution versus another. Some examples of such jugaad-a-thons are the [MIT Grand Hackfest](https://www.youtube.com/watch?v=IO-V9OdBIjE) and the [CAMTech India Jugaad-a-thon](https://www.youtube.com/watch?v=A_4vPjTgYQ0). 2. **The Focused jugaad-a-thon** – These are typically smaller events, but much more result-oriented. Organizers pick a specific problem area, and all the teams work in that space. This generates multiple solutions to a single need statement, which helps judge which of those solutions are most feasible. A great example is a recent jugaad-a-thon held at MIT for developing a novel solution for breast pumps. ([MIT Breast Pump Jugaad-a-thon](http://www.boston.com/health/2014/09/21/mighty-mom-breast-pumping-toolbelt-wins-mit-hackathon/colHXp5XR0HHIpaaKDXcfM/story.html?utm_content=buffer2bd4b\&utm_medium=social\&utm_source=facebook.com\&utm_campaign=buffer%23share-modal)) Both these forms have their pros and cons, but it is important to choose beforehand. ## Community The most important aspect of jugaad-a-thon is community. The idea is to bring a diverse set of minds together and not hinder the innovation process. Once this happens, a community of free thinkers & doers is organically created. Since its inception in January 2014, the jugaad-a-thon community has grown to over a thousand people. As this community grows, the medtech innovation space in India will naturally grow with it. ## Finalize dates The first and most vital step of this process is to lock down the dates for the event. A three-day chunk from Friday to Sunday, typically works best. Try and pick a long weekend to increase participation. Concrete dates makes planning possible: marketing, mentors, vendors, venue, etc. ## Pick a theme/track It is important to pick a theme/track for the event. This allows you to gauge the kind of audience you would be looking for, and helps in finding the right mentors and sponsors. The identity of the event may also help in later fund-raising by attracting PR focused on the theme. ## Decide the size of your desired audience Once you have a theme, it will be easier to gauge the probable number of participants. A broad theme will usually mean a larger appeal and a bigger pool of participants, though this is harder to manage. The focused jugaad-a-thon approach makes a smaller event possible. Once you have a target participant pool in mind, decide on the number of mentors. A useful rule of thumb is 1 mentor for every 8 participants, or 2 teams, since teams are 4 people strong on average. Also decide if you would want the participants to pay for a token registration free, or free entry. In free events, 40-50% attrition rate between applications received and attendees is likely. If you are target and for 60 people, make sure you accept at least 100 registrations. ## Propose a budget Start working on a budget template. Below is a list of line items for a sample budget for a 3 day Jugaad-a-thon. This also serves as a checklist for everything that goes into the event.

Category	Sub Categories	Details
Pre Event Marketing	Marketing collateral	Logo
		Concept and theme
	Web Presence	Website
		Facebook Campaign
		Google adwords
	Physical Presence	Fliers
		Posters
		Banners
	Networking/Community outreach	Cold calls to relevant communities
Venue	Venue for 3 days	Overnight access allowed
	Catering	Breakfast, Lunch, Tea, Dinner per head costs
	IT Infrastructure	Cost of internet. Bandwith dependent on size of audience
	Venue setup	Tables, chairs, stage
		AV Equipment
	Marketing material at venue	Backdrop (size)
		Banners (size)
		Standees
Travel and accommodation	Hotel	Rooms for mentors, judges, speakers and the organizing team
		Dates
	Travel and logistics	Air and rail fare
		Airport pick up/drop offs
		Travel to and from event venue
Marketing Collateral	Event branding (establish rules for public display of sponsors' branding)	Backdrop
		Banners
		Standees
		Stickers
		Pens
		T-shirts
		Other goodies
	Event information	Program books (mentor bios, emergency contact information) and Notepads
		Lanyards/ID Tags
		Collateral information sheets (Judging sheets etc)
		Venue Signage
	Prizes	Certificates of merit/participation
		Trophies
		Prize money (keep cheques ready)
		Mementos (for mentors and judges)
		Mementos for volunteers/organizers
	Photographer and videographer	During event and post-production costs
Media presence	Media presence	Pre-event
		During event
		Post event
	Social Media	Twitter/facebook marketing during event/post event
Organizing costs	Cost of time of organizers
	Travel costs for organizers pre event
Event material for hackers	Stationary
	Electronics
	Hardware
	Items that may pertain to theme

## Find your sponsors Once you have a budget in mind, move forward and engage potential sponsors. Sponsors value such events for the following reasons. 1. Access to community 2. Brand exposure 3. Access to ideas/teams 4. Ability to present their own problem statements However, it is important to let the sponsors do all this without taking away from the community-based ethos of the event. Rules of engagement must be made clear to sponsors. ## Marketing Once you have your sponsors locked down, start your marketing campaign. This includes setting up a website, a registration platform, a social media campaign and a multi-campus campaign (physical print). This is probably the hardest part of the process, and special focus has to be given to medical campuses to encourage young clinicians to participate. In parallel, start designing & organizing your marketing collateral. Finalized print materials for in-event may require up to 4 weeks of lead time. If you want to have a program book, make sure you ask mentors for bios and photographs well in advance. A program book is particularly valuable when it identifies mentors' strengths, since it helps participants find the right guidance during the jugaad-a-thon. ## Travel and Logistics 1. **Travel** – Lock down on mentors/judges early so you can book air/rail travel for them. If possible, avoid honoraria. It takes away from the spirit of the event. Having their itinerary handy early is very helpful in organizing their accommodation and in-city travel. 2. **Hotel –** Try to find a hotel with good corporate rates and book early. Make sure the hotel has good airport/train station connectivity. 3. **In city travel –** Find a corporate taxi service. Organize airport pick up/drop offs through a dedicated point-of-contact; this is more than a full-time job. Ensure you have 3-4 cars at your disposal every day, for shuttling mentors and organizers from the hotel to the venue, and to take care of emergencies. ## Venue 1. **Complete control -** Make sure you find a venue over which you have complete control. The venue must have overnight access. If the venue belongs to an external agency, make sure you identify all the rules and regulations applicable as early as possible. 2. **IT infrastructure –** Plan for Internet connectivity (bandwidth dependant on size), AV equipment (Projectors/Mac compatible adapter/Microphones/extension cords). 3. **Catering –** Budget for catering according to estimated number of attendees. Due to high attrition this is a judgment call. A lot of people also leave in the evening so dinners usually don’t have as many people as lunch. 4. **Overnight security –** Make sure there is security overnight. Organizers also need to stay overnight to attend to any problems that may occur. One organizer per 25 participants is a reasonable ratio to have. 5. **Emergency services –** If you cannot arrange for emergency services at the venue make sure you have a protocol for this. Circulate nearby hospitals/emergency numbers/taxi services. ## Event structure This is totally dependent on the organizing team. The way we have structured previous jugaad-a-thons is listed below. 1. **Day 1 –** Day session of panel discussions followed by a technology showcase. The day ends in a social mixer session. This day can also integrate exposure to a clinical site, if accessible. 2. **Day 2 –** Day begins with a session by the organizers and sponsors explaining the format of the jugaad-a-thon. Keep this short; focus on hacking. The participants then participate in a pitching session where they pitch their ideas in 60 seconds. This is followed by team formation, and the teams then start hacking. The hacking continues all the way till afternoon, day 3. 3. **Day 3 –** Hacking ends after lunch and teams present what they have worked on over the last 24 hours. The format of presentations is usually a 3 minute pitch followed by 2 minutes for questions. The judges then deliberate, which takes about an hour. Winners are announced, mementos and prizes are handed out followed by a vote of thanks. Everyone disperses. ## Prepare your Mentors and Judges One of the challenges here is to prepare mentors for their interactions with teams. A mentor’s role is to guide a team rather than trying to force their own ideas onto them. However as the platform of jugaad-a-thons is fairly new, not many mentors will understand this, and may inadvertently hamper a team’s progress. There are also times where some mentors are overused and some are left without any team engagement. A simple way to get around this is to encourage mentors to initiate conversations with teams and guide them. Judging is often a much debated topic especially in larger diverse jugaad-a-thons. It is important to set judging criteria, with due emphasis on the progress a team has made over the past two days (the hacking quotient). Judges should not be a part of the hacking process to minimize bias. During the Q\&A session, judges should be respectful of the team members, especially given the gap in expertise. Criticism should be constructive. It is also possible to use the community, i.e. the audience of participants, to judge each other. While a bit technically complex, this model feeds into the idea of community-driven innovation. ## Post-event What do you do once the jugaad-a-thon is over? This is a question many jugaad-a-thon organizers still ask themselves. As an organizing team it is hard to keep in touch with every team post jugaad-a-thon, and many teams don’t continue with their ideas. One solution is to have a periodic check-in, 30 and 90 days apart, on team progress and growth. Prizes or access to a public platform helps promote this. Prizes can include access to incubators, grant applications, and consulting support, which may be more valuable than cash rewards. ## Media With the maker community growing rapidly around the country, there are several hack-a-thons taking place in IT, electronics and robotics. However, healthcare jugaad-a-thons are still something that are not clearly understood. You need to articulate the value proposition clearly and engage the media with a dedicated resource to promote the ethos of hacking healthcare. Jugaad is not a bad word. It is uniquely Indian. # If you want to type, then retype Soura Bhattacharyya | May 13, 2025 It is ironic that I am publishing this post on a site hosted via GitBook. Because it is about their direct competitor, [Retype](https://retype.com/). I have used GitBook to set up my [personal blog](https://soura.org), this site, and a product website ([neoport.org](https://www.neoport.org/)). The free plan works great for a single-contributor site, but paid tiers for collaboration were beyond my budget. Or beyond my faux middle-class sensibilities. So, when faced with the prospect of publishing a large project, I spent several weeks exploring alternatives for publishing static sites. My criteria were—in no particular order: 1. Inexpensive 2. Easy for me to understand and operate, i.e. designed primarily for a writer, not a coder 3. Ability to hide some pages, and password-protect others. 4. Easy to manage content via GitHub, where all of our documentation sits I chanced across Retype thanks to a Reddit post. Used it for our open-source platform, [Agni](https://agni.thelattice.in). Loved it. Here is why. ### Git all the way—with you in control Retype takes markdown content as-is, and builds a `.retype` html directory within your repository. It then creates a separate branch, which you publish via GitHub pages. You have full control over content at all times. If you already follow pull-request discipline, then garnering contributions from the entire team is simple. If you use a paid plan, then you save the license key as a repo secret. No need to share passwords. ### Build and run locally This is a huge bonus over GitBook. Retype can be built and run locally—a great way to review changes before publishing them, especially during major overhauls. Once changes are merged to the `main` branch, GitHub actions rebuilds and publishes the website. The local build feature is so useful that I we are adding Retype to a [complex internal project](https://www.thelattice.in/projects/ai-platform), just to have a better way to read through docs. ### Generous free-tier and pocket-friendly pricing * Websites up to 100 pages are free. * All the essential features, including css customization, are free. The paid tier gives you ability to control visibility of pages and sections. * You can test drive the paid plan locally, to see if it right for you. * Pricing is based on projects, not users. Yup, you read that correctly. * A single license, mapped to a sub-domain, is free for lifetime. Updates are limited to three years. ### Attention to detail Some of these configurations are paid. All of these configurations are examples of design done right: * Switch between different logos for dark versus light mode. On the [Agni](https://agni.thelattice.in) site, check out the top-left icon as you switch between dark and light mode. * Vary heading depths on the right-side navbar. The free plan is limited to the default of H2 to H4. * Specify language to beautify code snippets, show or hide line numbers, and add line-level highlights. * Use Octicons to spruce up buttons and side navigation. * Exercise granular control over the left side nav—sequence of items, grouping, open/ closed state. * Use markdown-like syntax to pull in UI elements like accordions and tabs. * If you need cards—something that GitBook provides by default—then create a one-time, customized CSS container. So, if you type, try [Retype](https://retype.com/). *Photo credit:* [*Arun Sharma*](https://unsplash.com/@arunwithideas?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/black-typewriter-rTAdnqmYS40?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) # API security October 14, 2022 | Anoop K Singh ## Common API vulnerabilities ### Distributed Denial of service API DDoS attacks are executed to overload an API service. Since each hacker sends normal traffic volumes, these attacks are difficult to detect. ### SQL Injections and Data Attacks With the right credentials, insiders and hackers can access any system or data. Examples include Data Extraction or Theft, Data Deletion or Manipulation, Data Injection, Malicious Code Injection, and Extreme Application Activity. ## API security best practices ### Authenticate One of the most crucial components of API security is authentication. Always use secure authentication techniques like JWT or OAuth to confirm user identity. Simple HTTP authentication should never be used as it sends fields without encryption. ### Use API gateways Always place an API behind a gateway. Since API gateways consolidate both security-related activities and useful business-related operations, this has various advantages. Rate limitation, barring malicious clients, are all characteristics of API gateways. ### Validate inputs Specify the acceptable inputs in your API documentation. Prior to doing any server-side data modification or writing data to the database, don’t forget to verify every input. ### Prevent improper entry attempts They can be: * Remote Code Execution (RCE) * SQL Injection * Cross-Site Scripting (XSS) Sending API keys or other sensitive data in the URL is not advised. Always use the Authorization header for them. ### Limit requests (Throttling) You may avoid DoS/brute-force attacks by limiting the number of queries sent. Unfortunately, DDoS assaults don’t respond well to this technique. ### Output data Only the relevant info should be returned. Take care not to return any delicate information, such as API keys or passwords. Remove the `x-powered-by` and `server` headers from your HTTP response. Potential hackers may receive information from them. *This blog first appeared on* [*Medium*](https://medium.com/lattice-what-is/most-commonly-known-api-vulnerabilities-6f3d69dde671)*, with the title "Most Commonly Known API Vulnerabilities And API Security Best Practices".* *Photo credit:* [*Arthur Mazi*](https://unsplash.com/@arthurbizkit?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) *on* [*Unsplash*](https://unsplash.com/photos/blue-sky-over-white-clouds-a8CxRWIu8yw?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) # Universal record identifier A universal record identifier, or URI, uniquely points to a data record. It is similar in structure to a website URL, and usually has the following format: `http://acmehealthcare.com/patient/nRJA4oMMLVA1UltryPiB` In this example, the issuing entity, `Acme Healthcare` is declared first, followed by the type of record—here, this record is for a `patient`. Finally, there is an identifier for the record, `nRJA4oMMLVA1UltryPiB`, which is unique to the Acme Healthcare system. Since the patient identifier is unique within the Acme Healthcare system, and only one `acmehealthcare.com` exists worldwide, the complete URI is globally unique—hence universal. Traditionally, URIs have been generated by centrally managed, always-online systems. In such systems, the server can easily ensure that two different URIs do not “collide”, i.e. they are unique. For example, servers can use timestamps as an input to an algorithm, and the serial nature of time ensures that the resultant URI is unique. However, offline-capable mobile apps are increasingly being used in public health initiatives. When a new record is created using such apps, URIs need to be assigned locally, on a distributed basis. In such systems, suitable algorithms have to be deployed to reduce the risk of URI collision, while being computationally efficient. Contemporary algorithms such as xxhash reduce this risk to one in ten million or lower. # Process improvement consulting Jan 2, 2015 This section showcases Lattice's first process consulting assignment, completed four months after our inception. The client was gracious enough to allow us to make the content publicly available. It started with a question posed by the medical superintendent of the hospital. He said, "We are considering expanding our outpatient department's size to help alleviate patient load. Do you think we can do this expansion with a constrained budget?" We went to the [*gemba*](#user-content-fn-1)[^1]*.* Using the Kaizen (Lean) methodology, we we were able to propose process changes that could increase peak OPD throughput by 25%, while limiting investment in new equipment to only $600. The recommendations are site-specific, but the principles are generalizable to hospitals even today—more than a decade later. {% content-ref url="/pages/xXUnsgQjiI8uqlLxx7KL" %} [Context and Objective](/process-improvement-consulting/context-and-objective) {% endcontent-ref %} {% content-ref url="/pages/Cs26D4DpVNVcio5D12Wv" %} [Observations](/process-improvement-consulting/observations) {% endcontent-ref %} {% content-ref url="/pages/PeIghV69sMXpsetBluuv" %} [Recommendations](/process-improvement-consulting/recommendations) {% endcontent-ref %} {% content-ref url="/pages/Fj3bkD5mDNJpqHowFV9D" %} [Conclusion](/process-improvement-consulting/conclusion) {% endcontent-ref %} {% content-ref url="/pages/m1v93fSexoTG8njZLzxZ" %} [Annexures](/process-improvement-consulting/annexures) {% endcontent-ref %} [^1]: Gemba is a Japanese term that means "place of work". Improvements come from the *gemba*, not from conference rooms. # Context and Objective ## Context Our client was a multi-specialty hospital that serves patients in a tribal belt in Assam. Most of its patients are of limited financial means, hence services are offered at minimal cost. There are no other healthcare facilities nearby, as a result of which patients sometimes travel for over 6 hours/ 200 km each way to receive outpatient care, in groups of up to ten to save on transport costs. The hospital is surrounded by jungles that are unsafe to travel through at night. There are no hotels or guest houses nearby. The hospital has accommodations only for IPD patients' families. Therefore, Outpatient Department (OPD) patients require comprehensive consultation on the same day—including lab tests, X-ray, USG and medication. Most patients want to leave by early afternoon—3 pm—so that they cross heavily forested areas before nightfall. The OPD today serves an average of 206 patients daily, with peaks of up to 400 patients a day in summer months (Apr-Aug). High patient load creates uncertain, long wait times of up to 5 hours, because of which patients worry about being able to leave for home on time. These worries are magnified when some members of a group are delayed, while others are done. Hence, there is need to bring predictability in OPD operations, and deliver services within a defined time period. ## Objective Reduce waiting time for patients by minimizing non-physician time. # Observations ## Observer and methods One consultant from Lattice Innovations observed OPD workflow from December 3-5, 2014. Patient throughput time and stage-wise flow was measured on December 4, 2014, when the OPD had a load of 168 patients. Individual workstations were observed on December 3 and 5. Electronic records of all OPD visits from December 1 to 6, totaling 1,123, or 187 per day, were also analyzed. ### Current Workflow The complete OPD workflow (pathway) consists of twelve steps, as illustrated below.

Figure 1: OPD Workflow. Slow-track patients follow all steps; Fast-track patients follow those in yellow.

Patients follow two different pathways, or tracks, based on their healthcare needs. “Slow-track” patients follow all twelve steps, since their condition requires a full workup, with laboratory and/ or radiology investigations. “Fast-track” patients follow the six steps in yellow; they directly receive a prescription and collect medicines. Across the sample of 1,123 OPD visits from Dec 1 to 6, 46% of all visits were fast-track. ### Current Throughput Times An analysis of Electronic Records for December 4 shows the following:

Figure 2: Average throughput times across the day on Dec 4, split by fast and slow tracks

As evident above, average throughput times are particularly high in early hours. The registration desk opens at 8 am, and doctors report to the OPD at 9 am. Thus, patients arriving at or before 8 am wait for at least an hour. While the lowest throughput time for fast-track patient was 12 minutes, the average was 136 minutes. Their wait times were significantly increased by slow-track patients. On December 4, maximum throughput time for a slow-track patient was 346 minutes (5 hr 46 min), and that for a fast-track patient was 248 minutes (4 hr 8 min). ### Wait Time and Value-Added Time The figure below uses the "journey" of a slow-track patient on Dec 4, to illustrate the high proportion of wait time when compared with value-added time. Value-added time is the time when hospital staff performed activities directly related to diagnosis or treatment.

Figure 3: Patient journey - value-added sections in green, balance in red.

### Patient Load across the Day When we analyze patient registration of all 1,123 OPD visits from Dec 1 to 6, the variation in throughput time through the day is evident. 75% of all patients are registered by 11 am—the first 2 hours of OPD operation. The balance 25% patients are spread across the remaining 5 hours (11 am to 4 pm). This skewed load places strain on service delivery.

Figure 4: Patient load over time, in 15 minute increments, for 1,123 OPD visits

### Workstation-wise Load and Capacity To better understand OPD workflow, individual workstations were observed on Dec 3 and 5. Based on these observations, we calculated the time taken by each workstation counter to serve a patient. The data is reported in seconds.

S. No	Workstation	time per patient, s
1	Registration	120
2	Vital signs	58
3	Consultation	146
4	Investigation data entry	60
5	Investigation billing	90
6	Pathology lab	105
7	X-ray	519
8	USG	insufficient data
9	Prescription	146
10	Pharmacy data entry	60
11	Pharmacy billing	90
12	Pharmacy dispensing	224

Some workstations have more than one counter. For instance, the pharmacy has a total of 4 counters, at which tasks 4, 9, 10, 12 are carried out (incidentally, task 11, pharmacy billing, is *not* carried out at a pharmacy counter). In contrast, the X-ray workstation has a single counter. # Recommendations ## Separate fast-track and slow-track patients Separate slow-track and fast-track patients should be separated into two different "lines" or patient pathways, so that patients who only require a single consultation are not slowed down by those who require a full laboratory/ radiology workup. 54% of all patients follow the slow-track—rounded up to 60% hereon. Of them, about 75% undergo Lab tests, 40% undergo a USG scan, and 25% undergo an X-Ray. This is illustrated in Annexure 1. ## Optimize physician load A single patient consultation is completed in 246 seconds, or 2.5 minutes, based on the average of 58 observations on December 3. Thus, it takes 2.5 minutes of a doctor’s time to serve a fast-track patient, and 5 minutes to serve a slow-track patient—assuming that the first consultation and subsequent diagnosis & prescription take an equal amount of time. On a peak day with 400 OPD patients, “physician time” required is: {% code overflow="wrap" %} ``` 60% slow-track x 400 pts x 5 min + 40% fast-track x 400 pts x 2.5 min = 1200 minutes + 400 minutes = 1600 minutes ``` {% endcode %} OPD hours are from 9 am to 4 pm: 7 hours, or 420 minutes. Thus, 1600/ 420 ≈ 4 doctors are required to serve all patients. The cycle time, or rate of operation of all other workstations, have to be set based on Physician capacity. The target cycle times are: * The fast-track should be capable of serving 24 patients an hour, or one patient in 150s. * The slow-track should be capable of serving 36 patients an hour, or one patient in 100s. * Common workstations the precede the physician workstation—registration and vitals—should be able to serve 24 + 36 = 60 patients per hour, or one patient every 60s. Both registration and vitals workstations operate faster than the target cycle time of 60 seconds. Each registration counter is able to process a patient every 120 seconds, and with three registration counters operating in tandem, the cycle time is 40 seconds. The single workstation where vitals are measured operates at 58s per patient. Physician load leveling Fast-track patients should be assigned to a separate line, to speed them through the process. The following pattern of assignment is recommended so that load—in terms of time—is leveled across all physicians:

Figure 5: Physician allocation 3:1 between slow-track and fast-track

The cells indicate the number of patients seen by the end of each hour. For Physicians 2, 3 and 4, the first hour's output is 24 patients since they see both fast and slow track patients at that time. By the second hour, sufficient patients have their lab tests with them to return for the second consultation (diagnosis/ prescription), at an average throughput of 12 patients/ hour. The hour-long lunch break may be halved for the physicians to step out for in pairs. With this configuration, the total OPD capacity is 456 patients/ day—25% higher than the current maximum of 400 patients/ day, and more t. Modify the OPD coordinator's role In the system described above, the OPD coordinator's role has to change. Currently, three OPD coordinators perform the following tasks: 1. Check which physician's queue is empty, 2. Announce a patient's name on the PA - based on OPD visit cards available with them, 3. Direct patients to physician, and 4. Keep the queue of patients away from the doctor's desk. To implement the flow-balancing for physicians, their role will have to change to that a "flow controller". This will require them to perform the following tasks: 1. Use registration data to call patients as per their order of arrival 2. Anticipate which patients are in the fast track, and which are in the slow track. 3. Assign fast-track patients to a single doctor, the balance equally across the rest of the doctors. 4. Receive patient investigation reports from Lab/ X-Ray - so that patients do not have to wait outside the Lab/ X-Ray room 5. Assign slow-track patients to doctors for their second consultation (diagnosis/ prescription) once their investigation results are available Such a workflow requires IT support. A single screen that enables the OPD coordinators to perform these tasks is shown in [Annexure 2](/process-improvement-consulting/annexures#annexure-2-opd-coordinator-screen). Reorganize Pharmacy Operations to Support 2 Tracks Pharmacy operations is currently split across 2 workstations, in 3 steps. A patient has to queue up thrice to get a single prescription fulfilled.

Figure 6: OPD Layout, with pharmacy operations highlighted

### Current Workflow The steps are: 1. Data entry of medicines - transcription of the physician's prescription - 1 of 4 counter. 2. Payment - 1 of 4 counters of the registration desk, the only location where cash is collected. This counter is shared between all OPD service billing - Pharmacy, Radiology and Laboratory. 3. Dispensing of medicines - at the remaining 3 counters at the Pharmacy. In order to streamline Pharmacy operations, date entry, billing, and dispensing should be organized as a single set of counters. This will provide the added benefit of increasing checks on billing within the process - between pharmacy and registration staff - and will improve ensure compliance with financial guidelines. The 3 steps of Pharmacy operations serve patients at varying rates: 1. Data entry: 60s per patient per counter 2. Billing: 90s per patient per counter 3. Dispensing: 224s per patient per counter ### Proposed Design The target time for the fast track is 150s per patient, and that for the slow track is 100s per patient. To meet these target cycle times, the following design is proposed for Pharmacy operations:

Figure 7: Pharmacy Operations - Fast-track in Blue, Slow-track in Red

Since the fast-track counter has 20% more capacity than required, it can also serve IPD patients. ## Streamline Laboratory Operations 75% of all slow-track patients avail of laboratory services, which are composed of 6 types, as shown below. The table also has data about preparation time, testing time and total time. When total time is multiplied by load—the percentage of slow-track patients by test type—we arrive at the cycle time for each test type. This is stated in the last column. All values are in seconds.

Figure 8: Lab operations load and cycle time

The precursor to sample prep and test is blood sample collection, required for all test types except Urinalysis. This takes 120s per patient. Two counters operate in tandem, hence cycle time is 60s. \ Once test results are available, the last step is data entry (reports). This takes 45s per patient. ### Current Bottleneck - Biochemistry Slow-track target cycle time is 100s. Biochemistry does not meet this target. Also, since 75% of all Biochemistry tests are performed in tandem with one or more other test types, lab technicians have to wait for biochemistry reports before they can hand out results. ### Solution - Centrifuges In order to reduce cycle time for Biochemistry in a cost-effective manner, preparation time should be addressed. The only preparation required for blood-based tests is centrifuging. Lab-grade centrifuges are currently priced within Rs. 20,000 each. The lab has two centrifuges, one with a capacity of 8 samples and a set time of five minutes, and the other with a capacity of 16 samples and a set time of ten minutes. The duration of centrifuging varies based on the number of test types a single sample of blood has to be split into—five minutes for single test-type, and ten minutes for two or more test-types. In order to simplify and standardize centrifuging , we recommend that 2 additional centrifuges, of capacity 16 samples with 10 minute set time, be procured. Each centrifuge should be run every 4 minutes—without waiting for a full batch of 16 samples. Local efficiency is not the goal; global efficiency is. Running four partially-loaded centrifuges will reduce preparation cycle time to 30 seconds, which in turn will reduce biochemistry cycle time to 95s. This process change will also eliminate the need to split samples based on the number of test types, reducing error and re-work. Streamline X-Ray Operations Since 25% of all slow-track patients avail of X-Ray facilities, the cycle time required at this workstation is 100s/ 25% = 400s. Currently, the X-Ray workstation serves one patient every 519s. However, this observation was made on a day with two X-Ray technicians; three technicians are allocated to this workstation. If the third person assists patients in changing their attire, then cycle time can be reduced to only imaging time—which ranged from 180s to 300s. This is well within the target of 400s. Assisting patients to change their attire is not a technical task. Thus, with three x-ray technicians, it is possible to give off-cover, attend to some IPD requirements, and still perform within the target cycle time. # Conclusion We recommend that OPD operations are reconfigured so that physician time available is the only constraint, since the physician is the scarcest resource. Physicians at the hospital work with a high degree of individual efficiency. With operational changes in other supporting areas, their full capacity can be realized, with a consequent increase in OPD capacity by 25% and a reduction in wait times for patients. Investment needed in new equipment is limited to the purchase of two centrifuges. # Annexures Annexure 1: Overlaps across lab and radiology services Of 1,123 ODP visits analyzed, 465 visits, or 41%, availed of Lab investigations. 250 visits did no avail of any other investigations, 136 also had a USG exam, 70 also have an X-Ray, and 9 visits required all three - Lab, X-Ray and USG. This is illustrated in the Venn digram below.

Venn-diagram of overlap across the 3 investigation services—Lab, X-Ray, and USG.

The union of all three circles totals to 603—the number of visits where at least one investigative service was required. By definition, this equals the number of slow-track visits. The balance 520 were fast-track visits. ## Annexure 2: OPD coordinator screen

Red is used for slow-track, and blue for fast-track. The elements of the screen, from left to right, are: * The topmost line shows summary statistics and time. * The table on the top left shows patients who are yet to be seen by a Physician. These patients are assigned to a physician in the bottom right hand corner. A drag and drop interface is recommended for ease of use. * The table on the top mid shows slow-track patients who have already undergone investigations fully, and are awaiting the second (diagnosis/ prescription) consultation. * The table on the top right shows slow-track patients whose investigations are due for completion. * Finally, the bottom left corner shows physician-wise statistics. Based on current patient load and historical data, columns for patient allocation targets can also be added to the table, so it is easier for the OPD coordinator to assign patients. * S-1 is slow-track consultation * S-2 is slow-track diagnosis/ prescription * F is fast-track