From Sticky Notes to Structured Medicine

How an informal feline-care annotation system evolved into structured clinical data

Cats in the City | TANDEM Cat® Clinical Grooming
Practice-based health informatics paper
Draft for publication | August 2026

Abstract

Background. Clinically consequential information often begins outside formal software: on sticky notes, in staff memory, in handwritten instructions, and in brief warnings added to a client profile. In a high-volume feline-care setting, those fragments can contain information about medical risk, behavioral triggers, medication preparation, room placement, handling accommodations, service restrictions, and successful ways of helping an individual cat participate in care. Cats in the City and TANDEM Cat® Clinical Grooming developed such an informal annotation system over years of practice. What began as memory support gradually became an icon registry, an appointment-level run-card system, and a structured data program.

Methods. This paper describes that evolution as a practice-based health informatics case study. It draws on two internal sources: a 183-page legacy Custom Animal Icons report containing 2,275 visible icon rows representing approximately 1,737 cat profiles, and a pilot structured extraction of 100 grooming run cards from six service dates in June 2026. The extraction model retained raw notes, normalized categories, source provenance, confidence or review flags, and the distinction between printed booking information and handwritten current care plans.

Results. In the historical icon registry, 90.2% of visible rows contained narrative notes, 24.4% of approximate cat profiles carried more than one icon, and four categories - Medical Alert, Important, Caution Cat, and Senior Cat - accounted for 74.0% of visible records. The run-card pilot produced 471 normalized service lines from 100 appointments. All 89 full-grooming cards contained a handwritten current plan. Those plans averaged 2.91 structured elements per appointment; 52 contained at least three elements, and 45 were materially more detailed than the printed booking under a conservative comparison rule. The cards also captured medical alerts, handling cautions, medication information, household dependencies, staffing assignments, transportation needs, and review exceptions.

Discussion. The system evolved through a recognizable informatics pathway: handwritten notes, icons, structured icons, run cards, a knowledge base, research datasets, published scales and case definitions, and prospective studies. Its value lies not in replacing narrative judgment with checkboxes, but in linking narrative context to consistent fields, dates, sources, and outcomes. An icon says where to look. A note explains why. A run card records what the team intends to do today. An outcome record will show whether the plan worked.

Conclusion. Informal annotations are not failed data. They are often the first draft of a data model. Documenting how that model emerged preserves institutional knowledge, supports safer and more consistent care, and creates a defensible pathway from practical observation to research-ready evidence.

Keywords: feline grooming; health informatics; structured documentation; practice-based evidence; clinical knowledge; data provenance; trauma-informed care; learning system

Scope note. In this paper, structured medicine means the disciplined capture of observations, risks, accommodations, and care decisions in a form that can be reviewed, searched, and studied. Grooming records do not replace veterinary diagnosis or treatment.

1. The information that formal systems miss

Care organizations rarely begin with a data model. They begin with a problem.

A cat cannot safely be placed on the side because body position worsens breathing. Another cat becomes reactive when placed in a cubby but remains readable in an open room. A senior cat requires a low-traffic room with a window. A cat tolerates clipping but becomes overwhelmed during drying. Another requires gabapentin before grooming, must not receive an oral flush, or should not be separated from a bonded household cat.

A staff member notices the pattern and writes it down.

The note may be brief, colloquial, incomplete, and highly local. It may be attached to a profile because no formal field exists for the observation. Yet it can carry more operationally important information than the appointment label itself. It may identify:

• the condition or vulnerability;
• the context in which it matters;
• the trigger;
• the cat's observable response;
• the accommodation that has worked;
• the staff member and date associated with the observation;
• whether the instruction applies to grooming, boarding, medication, transport, or several settings.

This is how many information systems actually begin. Before there is a taxonomy, there is a sentence. Before there is a field, there is a workaround. Before there is a protocol, there is a repeated observation that one person remembers and another person needs to know.

Most organizations preserve the final software configuration but lose the history of how it emerged. The sticky notes disappear. The original meanings of categories become unclear. Staff know that a warning icon exists, but not why that category was created or what kinds of observations belong within it. The result is a mature-looking system with no documented provenance.

Cats in the City followed a different path, although not initially by design. Its historical notes, icons, and run cards have been retained long enough to reconstruct how an informal care language became a structured clinical knowledge system.

Sticky notes were not the opposite of data. They were the first draft of the data model.

2. A practice setting large enough to require memory outside the individual

Cats in the City and TANDEM Cat® Clinical Grooming operate a feline-only care system that reports approximately 7,000 feline grooming appointments annually.[3] At that scale, a safe care model cannot depend on one person's memory of one cat.

The operational question is not simply whether a team member knows that a cat has kidney disease, arthritis, a heart murmur, a history of biting, or a strong fear response. The team also needs to know what that information changes today:

• Should the cat be first or last?
• Is veterinary authorization current?
• Was calming medication required, and when was it given?
• Is lateral positioning contraindicated?
• Should the cat avoid a cubby, customer-facing room, or high-traffic hallway?
• Is a particular dryer, shampoo, room, handler, or grooming sequence required?
• Does the plan depend on what happens with another cat from the same household?
• Are there services that must not be substituted or added?
• What happened the last time the team used this plan?

Traditional appointment software captures a date, time, service, price, and client record. Those fields are necessary, but they do not fully represent the care problem. The organization therefore developed an additional layer of documentation around the appointment system.

That layer evolved in stages.

3. The evolution from annotation to evidence

Figure 1. The Cats in the City informatics pathway

The stages are cumulative rather than substitutive. The later system should not erase the earlier one. The raw note remains important because it preserves nuance and provenance. The structured field makes the observation searchable. The run card places it in the context of a specific encounter. The outcome tells the organization whether the accommodation was effective.

This creates a learning loop:

observe → annotate → classify → plan → perform → record outcome → analyze → revise

That loop is the central informatics achievement. Data is not collected only for retrospective reporting. It is produced during care, returned to the point of care, and used to improve the next decision.

4. Handwritten notes: the origin of the ontology

The earliest layer was informal narrative. Notes were created because staff repeatedly encountered information that did not fit the available software fields.

The language was practical rather than standardized. One person might write fearful, another spicy, another launches at the window, and another fine once out of the carrier. These phrases are not equivalent. They point to different contexts and mechanisms:

• generalized fear;
• visually triggered reactivity;
• carrier-specific escalation;
• restraint sensitivity;
• medication-specific aggression;
• separation distress;
• dryer sensitivity;
• respiratory stress;
• difficulty with transitions rather than with grooming itself.

A conventional cleanup process might flatten all of these notes into one field: behavioral caution. That would make the data cleaner and the care plan less accurate.

The better approach is hybrid documentation. Preserve the original note, then add structured concepts around it.

Table 1. What one informal note may contain

An informal note is therefore not merely text. It is a compressed event model. The informatics task is to expose that model without pretending that every phrase is equally certain or clinically verified.

5. Icons: compression for fast operational recognition

Icons were the next stage because staff needed to see high-priority information before opening and interpreting a long profile.

An icon is a form of information compression. It converts a complex set of possible concerns into an immediate visual signal: Medical Alert, Important, Caution Cat, Senior Cat, Meds, Room Preference, No Treats, Sensitive to Drying, or another operational category.

This solved a real workflow problem. A team member scanning a schedule could identify which profiles required closer review. The icon did not need to contain the whole care plan. Its job was to say: look here before proceeding.

Over time, however, the icon inventory became a registry. By October 2025, a legacy report contained 2,333 icons on its totals page and 2,275 visible detail rows across 183 pages. The structured extraction represented approximately 1,737 cat profiles and 1,596 owner names using exact owner-name plus animal-name pairs as an approximate identity key.[1]

Four categories accounted for 74.0% of visible records:

• Medical Alert: 536 visible rows
• Important: 509
• Caution Cat: 392
• Senior Cat: 247

The concentration matters. It shows that the icon system was not primarily decorative or administrative. Its dominant purpose was to make medical complexity, handling risk, senior needs, and care-critical instructions visible before service began.

The notes were the deeper layer. Narrative text was present on 90.2% of visible rows, including nearly every Medical Alert and Important record. The icon pointed to the problem; the note carried the mechanism, history, instruction, or accommodation.[1]

6. Structured icons: the moment the registry became analyzable

The icon report was useful to staff as a printed human-readable document, but it was not yet a research dataset. The transition occurred when each visible row was represented as a structured record containing:

• animal name;
• owner name;
• breed as printed;
• normalized icon category;
• original note;
• raw icon text;
• source page;
• creation and edit information;
• review status.

This step changed what questions could be asked.

Instead of reading profiles one by one, the organization could measure category frequency, note coverage, data quality, and multi-icon complexity. It could identify that 423 approximate cat profiles, or 24.4%, carried two or more icon records. Of those, 106 carried three or four.[1]

The combinations were clinically and operationally meaningful. Medical Alert frequently co-occurred with Senior Cat, Important, Meds, or No Treats. Caution Cat frequently co-occurred with Important or Medical Alert. These combinations demonstrated that risks do not arrive one at a time. A senior cat may also require medication, a particular room, a handling accommodation, and a service restriction.

The extraction also made uncertainty visible:

• The totals page exceeded visible detail rows by 58.
• One hundred fifty visible rows required review.
• Some category glyphs were clipped or unrecoverable.
• PDF font substitution introduced corrupted characters.
• No durable animal ID or location field was present in the report.
• Creation dates represented record creation, not necessarily the date of the underlying care event.

These are not reasons to dismiss the dataset. They are reasons to govern it. A credible informatics system records where the data came from, what was interpreted, what remains uncertain, and what should not be inferred.

Raw note = evidence. Structured field = interpretation. Review flag = honesty about the distance between them.

7. Run cards: the bridge from historical profile to today's care plan

Icons describe persistent or recurring information. They do not fully answer the encounter-level question: What are we doing with this cat today?

The run card emerged as the operational bridge.

A run card combines printed appointment information with handwritten care planning. It can include the booked service, the team's current plan, medication timing, medical and behavioral cautions, quote range, treats, transport, household pairing, pickup instructions, and assigned roles across grooming, handling, bathing, and drying.

The first combined structured run-card pilot contained 100 cards from six service dates in June 2026:[2]

• 89 full-grooming appointments;
• 11 a la carte appointments;
• 92 unique client households;
• 471 normalized service lines;
• 105 daily-assignment rows;
• 73 review-queue items across 56 appointments;
• 40 cats age 10 or older;
• 43 cards with medical-alert indicators;
• 37 cards with handling-caution indicators.

The printed booking and the handwritten care plan were intentionally stored separately. That distinction revealed a central finding.

All 89 full-grooming cards contained a handwritten current plan. Those plans generated 259 normalized encounter elements and averaged 2.91 elements per full-groom appointment. Fifty-two cards contained at least three handwritten plan elements. Under a conservative rule - no more than two printed booking lines and at least three handwritten current-plan elements - 45 of the 89 full-grooming cards were materially more detailed than the booking record.[2]

The printed line might say Shorten Coat / Haircut. The handwritten plan might specify a teddy bear cut, preserved tail, sanitary level, paw-pad trim, mane treatment, degreasing, flea intervention, product restriction, or a conditional plan based on what the team finds.

The difference is not clerical. It is where clinical reasoning becomes visible.

Table 2. The distinct jobs of the booking record and the run card

The run-card pilot also exposed why structured extraction must remain human-reviewed. Medication timing could conflict across notes. A weight could be missing or invalid. A schedule row might not have a matching card. Pair numbering could differ between the card and assignment grid. A quote could be overwritten. These exceptions are operational data in their own right. They identify where the workflow needs verification, not merely where an OCR system made a mistake.

8. From records to a knowledge base

A spreadsheet is not yet a knowledge base. The next stage requires durable links among the layers.

A longitudinal feline-care record should be able to connect:

1. Cat identity - stable animal ID, household ID, breed, sex, age, coat type.
2. Historical annotations - icons, narrative notes, status, date, author, source, review date.
3. Encounter context - date, location, appointment type, staff, transport, household pairing.
4. Assessment findings - coat, skin, claws, mobility, medical considerations, behavioral presentation.
5. Care plan - selected techniques, restrictions, accommodations, products, medication preparation.
6. Actions completed - what was actually performed rather than merely planned.
7. Outcome - completion status, modifications, escalation, tolerance, findings, follow-up interval.
8. Evidence objects - photographs, reports, scales, measurements, and linked source documents.
9. Provenance - who recorded or interpreted each element, when, and from which source.

This architecture makes the record useful across time. A future team member could see not only that a caution icon exists, but when it first appeared, whether it remains active, what triggered it, what accommodations were tried, and how the cat responded across later visits.

The essential design principle is that the knowledge base should preserve both state and event.

• A state is an ongoing fact or flag: kidney disease, senior status, no treats, room preference.
• An event is something that occurred at a point in time: gabapentin given at 9:00 AM, panting during drying, lion cut completed, appointment deferred, embedded claw discovered.

Without that distinction, historical notes become permanent even after circumstances change, and encounter-specific observations are mistakenly treated as timeless traits.

9. A learning care system rather than a static archive

The goal is not to build a larger filing cabinet. It is to build a system in which care generates evidence and evidence improves care.

In a static archive, records accumulate. In a learning care system, they are analyzed and returned to practice.

The system could eventually answer questions such as:

• Which accommodations are most often associated with successful completion for visually triggered cats?
• Which cats tolerate clipping but become distressed during drying?
• When does gabapentin first become necessary in a cat's longitudinal history?
• Which combinations of age, coat condition, mobility limits, and grooming interval precede intensive reset care?
• Which service plans are most often modified after hands-on assessment?
• How frequently do historic caution icons remain relevant after repeated trauma-informed visits?
• What staffing or appointment duration is associated with particular care profiles?
• Which findings co-occur often enough to justify a formal case definition or scale?

These questions require outcomes. A future record should therefore distinguish:

• planned service;
• completed service;
• modified service;
• deferred or declined service;
• reason for modification;
• observable comfort or escalation markers;
• immediate aftercare findings;
• recommended return interval;
• later follow-up.

Without outcomes, the system can describe complexity. With outcomes, it can evaluate care.

10. From knowledge base to research dataset

Operational data becomes research-ready only after additional discipline is added.

A research dataset needs stable identifiers, explicit inclusion criteria, variable definitions, missing-data rules, versioned taxonomies, de-identification procedures, and a clear distinction among owner report, staff observation, veterinary documentation, and model-derived inference.

The historical icon and run-card datasets already contain several foundations:

• source page and file provenance;
• raw and normalized text;
• category labels;
• dates and authors where available;
• review flags;
• separation of printed and handwritten content;
• appointment-level linkage;
• structured service concepts;
• documentation of exceptions rather than silent repair.

The next steps are to add:

• durable animal, household, and encounter IDs;
• location;
• active, historical, or resolved status;
• observation context;
• severity or confidence;
• intervention and outcome fields;
• standardized follow-up periods;
• controlled vocabularies with version history;
• inter-rater checks for scales and observational coding.

This is where a practice database can support descriptive studies, longitudinal cohorts, validation work, and prospective protocols.

11. What scale changes at 2,000, 5,000, and 10,000 encounters

Large numbers do not automatically create valid science. Inconsistent definitions repeated 10,000 times remain inconsistent. The value of scale appears only when the data model, provenance, outcome capture, and quality controls mature with the case count.

Around 2,000 consistently structured encounters

The organization can establish a reliable descriptive baseline:

• frequency of common observations, conditions, accommodations, and service modifications;
• common combinations of medical, behavioral, and coat-related factors;
• missingness and documentation reliability;
• taxonomy refinement;
• early inter-rater agreement testing;
• operational distributions for appointment duration, staffing, pricing, and completion status.

This is the stage at which the system can determine whether its categories are understandable, consistently applied, and worth keeping.

Around 5,000 encounters

The dataset can support more meaningful subgroup and longitudinal analysis:

• comparisons by age, breed group, coat type, medical status, or grooming interval;
• transitions from one care state to another;
• multivariable models of service complexity or modification;
• analysis of which accommodations are associated with completion or reduced escalation;
• better estimates for staffing and appointment design;
• derivation of candidate scoring systems.

At this scale, the organization can begin separating patterns that are common across the population from those driven by one staff member, one location, or one short period.

Around 10,000 encounters and beyond

A mature dataset can become a reference population for specialized feline grooming care:

• analysis of less common conditions and event combinations;
• model development with separate training and validation samples;
• prospective cohort design based on stable retrospective findings;
• validation of scales, thresholds, and case definitions;
• benchmarking across time, locations, and potentially external partners;
• stronger estimates of how care needs change across age and repeated visits.

The durable asset is not a particular AI model. Models will change. A governed longitudinal dataset built from years of consistent feline-care observations is difficult to reproduce and becomes more useful with every properly documented encounter.

12. Published scales and formal case definitions

Repeated observations often reveal that the team is already applying an implicit scale.

Staff may distinguish mild coat compression from severe entrapment, ordinary sound sensitivity from escalating auditory distress, or routine matting from a condition that changes movement and body use. At first, those distinctions live in expert judgment and informal language. Structured data makes it possible to identify the repeated dimensions, define levels, test agreement, and publish the resulting tool.

The pathway is:

1. repeated observation;
2. informal descriptive language;
3. recurring annotation or icon;
4. structured variables;
5. candidate thresholds;
6. retrospective testing;
7. formal scale or case definition;
8. publication and external critique;
9. prospective validation.

Within the TANDEM Cat® system, this pathway supports the development of formal tools such as matting-severity, sound-sensitivity, coat-condition, and condition-based care measures. The publication status of individual tools may differ, but the informatics logic is the same: a scale should be traceable to observed patterns, explicit definitions, and testable outcomes rather than introduced as an unsupported label.

13. Prospective studies: the final transition

Retrospective records reveal what the organization happened to document. Prospective studies define in advance what must be observed and how it will be measured.

A prospective study might predefine:

• eligibility criteria;
• baseline coat, skin, claw, mobility, and behavior measures;
• medication and preparation status;
• standardized intervention steps;
• reasons for modification or stopping;
• immediate comfort and completion outcomes;
• follow-up interval;
• recurrence, maintenance, or quality-of-life outcomes;
• analysis plan and handling of missing data.

The historical database makes those studies possible because it shows which variables recur, which are feasible to collect, where ambiguity is common, and which questions matter enough to investigate.

This is an important reversal. The early notes were created because the formal system lacked fields. The mature system uses the accumulated notes to decide which fields a future study must contain.

14. Why documenting the evolution matters

Most clinics do not preserve the history of their information architecture.

They may adopt a new software platform, create a warning icon, or launch a form without documenting which repeated care failures or observations led to the change. Years later, staff inherit categories without shared definitions. The organization can count the labels but cannot explain their origin.

Documenting the progression from handwritten notes to icons, structured icons, run cards, a knowledge base, research datasets, scales, and prospective studies does several things:

• preserves the provenance of clinical concepts;
• honors the staff observations that created the system;
• distinguishes organic field knowledge from arbitrary software design;
• allows obsolete categories to be revised without losing history;
• creates a transparent chain from practical problem to formal measure;
• shows external reviewers how definitions emerged;
• makes the system teachable to new staff and reproducible across locations.

It also tells a more accurate story about innovation. The structured dataset did not appear because someone decided to collect data. It appeared because the organization repeatedly needed to solve the same care problem, wrote down what mattered, recognized patterns, and eventually made those patterns computable.

15. Data governance and safety

The more useful the knowledge base becomes, the more carefully it must be governed.

A responsible system should include:

• stable identifiers rather than names as database keys;
• role-based access to identifiable records;
• de-identification for analysis and publication;
• retention of original text alongside normalized interpretations;
• dates, authors, sources, and edit history;
• active, historical, resolved, and unverified statuses;
• a versioned category dictionary;
• routine review of stale or contradictory instructions;
• human verification of medication and high-risk care instructions;
• separation of operational recommendations from veterinary diagnosis;
• documented rules for automated extraction and model-assisted coding;
• an exception queue rather than silent guessing.

Automation should route attention, not erase judgment. A model may suggest that a note describes drying sensitivity or medication-required grooming. A trained person should confirm the interpretation before it becomes an active care instruction.

16. Limitations

This paper describes the evolution and current architecture of an internal care-data system. It does not establish clinical efficacy or causal relationships.

The historical icon report was a legacy PDF rather than a direct database export. The totals page and visible detail rows differed by 58 records. Some text contained font-substitution artifacts, some icon labels were clipped, and the report lacked stable IDs and location. The approximate cat count relies on exact owner and animal names and should not be treated as a definitive feline census.[1]

Icon records are annotations, not necessarily diagnoses. Notes may reflect owner report, staff observation, veterinary documentation, or a mixture. Record-creation dates do not necessarily equal care-event dates. Historical flags may also be stale unless an active or resolved status is added.

The run-card dataset contains 100 cards from six service dates and is a process pilot rather than a representative sample of all Cats in the City appointments. It captures planned care more consistently than completed outcomes. Handwriting interpretation introduces uncertainty, and review items must be checked against the original card and source system before direct care use.[2]

These limitations are part of the informatics finding. They show exactly what the next-generation system must improve.

17. Conclusion

The history of the Cats in the City and TANDEM Cat® documentation system is not a story about replacing paper with software. It is a story about making practical knowledge durable.

Handwritten notes preserved observations that did not fit the available system. Icons made urgent information visible. Structured icon extraction converted a legacy registry into analyzable data. Run cards connected persistent history to encounter-level decisions. A knowledge base can link those decisions to outcomes across time. Research datasets can test the patterns. Published scales can formalize the concepts. Prospective studies can determine whether the resulting care models are reliable, reproducible, and associated with better outcomes.

Most clinics never document that evolution. Doing so matters because the evolution itself is evidence. It shows how a clinical vocabulary was formed, why particular variables exist, and where the organization still needs more precise definitions.

The central lesson is simple:

An icon says where to look. A note says why. A run card says what to do today. An outcome says whether it worked.

The move from sticky notes to structured medicine is therefore not a rejection of informal knowledge. It is the disciplined preservation of that knowledge so it can be shared, audited, improved, and studied.

Internal data sources

1. Cats in the City. Custom Animal Icons: Structured Data Findings and Operational Implications. Internal working report prepared August 5, 2026, based on a 183-page Gingr Custom Animal Icons report created October 24, 2025.
2. Cats in the City and TANDEM Cat® Clinical Grooming. Combined Run Card Analysis and Structured Extraction. Internal dataset containing 100 run cards and four daily assignment grids from June 12, 21, 25, 26, 27, and 28, 2026.
3. Cats in the City. Organization-reported annual grooming volume, 2026. Used only to describe operational scale; no annual census was independently audited for this paper.

Publication and ethics note

This is a descriptive, practice-based informatics paper using aggregate operational findings. Identifiable client information is excluded from the publication draft. Individual records may contain sensitive client and feline health information and should remain access-controlled. A formal ethics, consent, and data-governance review should be completed before journal submission, external data sharing, or prospective research enrollment.