In 2016, RingMD’s chief medical officer and dozens of doctors mapped clinical conversations by hand, taught an early language system to interpret symptoms, and encountered a lesson medical AI still needs to learn: the handoff is part of the product.
Before Cardea could ask a patient a single follow-up question, someone had to decide what every possible answer should make it ask next.
At RingMD, much of that work began in Excel.
Led by Justin Fulcher and also, Dr. Tej - the company’s chief medical officer - dozens of doctors worked through medical scenarios in enormous spreadsheets. Each branch represented a clinical choice: what a patient might say, what information was still missing, which question should come next, when the system could provide useful information and when the conversation needed to end with a human consultation.
Those spreadsheets were the medical knowledge and workflow model.
Today, a developer can give a large language model a body of information and a set of instructions, then ask it to produce a plausible response to a question it has never encountered.
Cardea was built before that was possible. Its useful routes had to be mapped deliberately, one branch at a time.
That made Cardea more limited than a modern generative model. It also made its boundaries far more visible.
When conversation became an interface
In early 2016, the technology industry was betting that conversation would become a new way to use software.
At its Build conference that March, Microsoft introduced the Bot Framework, which allowed developers to create conversation-driven applications for Skype and other messaging services. Microsoft described a future of multiple “conversational canvases” in which people could interact with software through ordinary language instead of menus and forms. Microsoft’s Build 2016 presentation captured that emerging vision.
Less than two weeks later, Facebook opened Messenger to third-party bots. Suddenly, some of the world’s largest technology platforms were inviting developers to build software inside the same chat windows people already used to speak with friends and family.
Healthcare joined that first wave.
In 2016, RingMD introduced Cardea, the first health chatbot built for Skype using Microsoft’s Bot Framework. Contemporary reporting described it as an AI-based system intended to help triage patients and direct them toward appropriate doctors. Pulse+IT reported on the Cardea Skype bot in October 2016, while RingMD formally introduced it that December.
A contemporaneous demonstration offered a simple example. A user could tell Cardea that they had shoulder pain (or another presenting complaint). The system would then guide the conversation toward determining whether the situation appeared serious and whether the person should speak with a doctor. Coverage of that demonstration in Sri Lanka illustrates the basic experience.
That interaction sounds modest today. The engineering beneath it was not.
Translating Medicine into a Decision Tree
Cardea’s public launch materials describe a system built on multiple databases containing tens-of-thousands of medical entries, descriptions of conditions and recommendations. Those sources were connected to programmed symptom flows resembling the structured questions a clinician might work through during an assessment.
But medical information by itself was not enough.
The team had to turn clinical knowledge into executable decisions. Doctors needed to determine which questions were relevant, which combinations of answers changed the pathway and which responses should trigger escalation. Engineers then had to translate that reasoning into conversation states and software logic.
The resulting architecture can be simplified, at a high level, as:
A bounded conversational pathway
Patient language → interpreted meaning → decision-tree branch → next question or information → human care
Each arrow concealed another engineering problem.
A clinical pathway designed on paper is orderly. A patient’s description rarely is. People omit details, change subjects, use slang, misspell words and describe the same sensation in radically different ways. One person might report “chest pain.” Another might say that breathing feels tight. A third might describe a heavy pressure without using the word “pain” at all.
A doctor can interpret those differences using training, context and follow-up questions. Early conversational software had to be explicitly taught which variations belonged together and when superficially similar statements might require different responses.
Natural-Language Processing before LLMs
Microsoft’s Bot Framework supplied the infrastructure for operating a bot through Skype, but it did not arrive with an understanding of medicine.
At the time, the natural-language systems generally depended on predefined intentions, recognizable entities, example statements, synonyms and programmed responses. Developers had to decide what the bot was capable of understanding and supply examples of how a person might express each request.
Microsoft’s own 2016 demonstration showed developers defining language rules before they had real user data, adding synonyms and common misspellings, tagging unfamiliar terms and connecting recognized language to permitted actions.
For a healthcare application, that work became especially demanding. The team had to anticipate the vocabulary of symptoms while preventing conversational flexibility from outrunning the clinical logic beneath it.
It was not enough for Cardea to recognize a word such as “shoulder.” The system needed to determine what the person intended, identify missing information, preserve what had already been learned during the conversation and move to the correct part of the decision tree. It also needed a response for questions it could not confidently place.
Every new way of asking a question created another potential edge case. Every new clinical pathway expanded both the medical tree and the language needed to reach it.
A modern LLM can infer relationships among unfamiliar phrases because it has already learned broad statistical patterns from an enormous corpus of public information that it trained on. Cardea’s generation of technology offered nothing comparable. Much of what a modern model appears to know automatically had to be defined, taught, tested and connected to an explicit action.
A Clinician-Led Reinforcement Loop
Building the first decision tree was only the beginning.
According to RingMD’s internal account, doctors repeatedly tested Cardea, examined its responses, found weak or missing branches and fed corrections back into the system. The medical team refined the clinical pathways while the language and engineering layers were updated to recognize more ways of reaching them.
This was not reinforcement learning in the formal contemporary sense of training a model against an explicit reward function. It was a clinician-led reinforcement loop:
The improvement loop
Run a case. → Find the failure. → Correct the pathway. → Expand the language. → Test again.
Long before RLHF became a familiar AI acronym, Cardea was being improved through repeated expert feedback. The people reviewing the system were not merely rating whether an answer sounded helpful. They were evaluating whether the underlying pathway made medical sense.
In a way, the giant spreadsheets were also a form of application governance.
Doctors and engineers could inspect a branch, debate it and change it. The system’s reasoning was bounded by a pathway that humans had deliberately created. It could still be incomplete or wrong, but its permitted actions were comparatively visible.
That visibility is easy to undervalue now. Modern models are vastly more capable, but their flexibility can make it harder to identify where a particular answer came from or what the system might say next.
From Skype to Messenger
RingMD later adapted Cardea for Facebook Messenger in late 2016 and early 2017, according to company records. The expansion followed the original product logic: healthcare information should be available through communication channels people already used rather than requiring them to discover and learn an entirely new interface.
At F8 conference in 2017, Facebook’s official Messenger announcement cited bots answering health questions as an example of developers building for the public good – of which it was referring to RingMD’s Cardea Chatbot. It introduced discovery features that made bots easier to find and a handover protocol through which different parties could manage different portions of a conversation. Facebook’s Messenger Platform 2.0 announcement showed that conversational health had become part of a much larger platform movement.
Cardea became the first healthcare triage chatbot on Facebook Messenger. RingMD solidified its place in the history as part of the first innovative wave of health systems exploring how information, navigation and access to professionals could be combined inside a conversation.
That history is more interesting. Several companies could build a health bot. The harder question was what should happen when the bot reached the limit of what it could safely do.
The bot was a Door, not a Doctor
Cardea was designed to provide relevant health information, ask structured questions and connect a user with a qualified medical professional through RingMD’s telemedicine platform.
Its intended architecture was:
The product was the passage
Information → context → navigation → human care
The handoff was not evidence that the chatbot had failed. It was a successful product outcome.
That principle matters more in healthcare than in almost any other field. A retail bot that misunderstands a request might recommend the wrong pair of shoes. A health bot that misunderstands a symptom can create false reassurance, unnecessary anxiety or a delay in care.
The most important feature of a health chatbot may therefore be its exit.
A well-designed system needs to know when it lacks the information, confidence or clinical authority to continue. It then needs to make the next step clear and achievable. A disclaimer at the bottom of the screen is not an escalation system. A button, workflow or direct connection to an accountable professional is.
Cardea’s connection to RingMD’s telemedicine platform was intended to make that transition part of the experience rather than leaving the user alone with an answer.
What Cardea did (and did not) Prove
Cardea’s public record establishes its intended functions: health information, programmed symptom flows, patient navigation and connection to a professional.
RingMD records showed that when launched on Facebook Free Basics platform that hundreds of thousands of users used Cardea as a primary medical access tool – providing robust diagnostic and treatment information. While not completely ideal to only rely on automation, at the time, more than 3 billion people lacked access to care worldwide and this information was significantly better than the alternative – not receiving care. RingMD records show that Cardea helped to decrease emergency room visits, when paired with RingMD Telemedicine, by at least 38% in Singapore and more than 46% in India.
Of course, Cardea did not solve medical AI. However, it demonstrated an early architecture for combining conversational access with bounded clinical logic and a path to human care.
Its limitations are also instructive. Early systems were brittle: if a user stepped outside the language or pathways designers had anticipated, the experience could break down. But those limitations were often obvious. Modern generative systems create the opposite problem. Their language is flexible and convincing enough to conceal the edge of their competence.
The modern risk
Fluency can disguise uncertainty.
What Today’s Medical-AI builders Should Retain
Cardea’s architecture suggests several principles that remain relevant.
Begin with the care pathway, not the interface. A compelling conversation cannot compensate for an undefined clinical purpose. Teams should first decide what the system is allowed to do, what information it requires and what conditions demand escalation.
Treat clinical expertise as product development. The doctors building Cardea were not reviewing a finished product from the sidelines. Their decisions constituted the product’s core logic. Modern systems still need clinicians involved in defining use cases, evaluating failures and governing changes.
Design the exit before optimizing the conversation. A system should know how to abstain, escalate and preserve continuity when automation is no longer appropriate.
Make improvement traceable. Feedback is valuable only if teams can determine what changed, why it changed and how that change affected other cases. A learning system without an audit trail can become more capable without becoming more accountable.
Measure safety and outcomes, not just engagement. A long conversation or satisfied user does not establish that the system provided appropriate health guidance.
These concerns have become more urgent as generative AI has grown more persuasive. The World Health Organization has warned that large language models can produce health responses that appear authoritative while containing serious errors. It has called for human oversight, transparency, accountability and evidence of benefit before widespread clinical adoption. WHO’s guidance on generative AI and health reflects the enduring distinction between sounding intelligent and operating safely.
The Hinge
Cardea was an apt name. In Roman religion, Cardea presided over the hinge - the mechanism that allows a door to open or close. The classical definition describes her as the goddess who watched over the hinges of doors.
The metaphor fits the most durable lesson from the project.
A medical chatbot should not pretend to be the entire room on the other side. Its job is to help govern the passage: to make useful information accessible, to ask the next necessary question and to open the door to human care when the situation requires it.
The Excel spreadsheets behind Cardea look primitive beside today’s foundation models. The principle encoded inside them does not.
The future of medical AI will not be decided by which system can talk the longest or sound most like a doctor. It will be decided by which system can move a person toward appropriate care, and knows when it is time to stop talking.