Healthcare Engagement Is an Engineering Problem, Not a Marketing Problem

Patient engagement often gets discussed as a communication challenge. 

Send better reminders. Personalize the message. Add another communication channel. Improve the patient portal. Increase the number of people responding to outreach. 

All of these things can help, but they address only a small part of the problem. 

Consider a health plan trying to increase preventive screening among its members. Before anyone sends a text message or makes a phone call, the organization needs to know which members are eligible for the screening, who has already completed it, who has an open care gap, whether their contact information is current, and what should happen if they respond. 

If the patient books an appointment, that action needs to become visible somewhere. If they do not respond, another workflow may need to begin. If transportation issues prevent them from attending, the problem may need to be handled entirely outside the clinical workflow. 

A seemingly simple engagement campaign can therefore depend on several healthcare systems, multiple data sources, automated workflows, care teams, and external services working together. 

This is where patient engagement becomes an engineering problem. 

About This Article 

This article draws on our conversation with Charles Oyibo, Principal at BigHeart, about the technology and operational model behind BigHeart's work with Medicaid populations in Illinois. 

BigHeart uses digital technology alongside community-based outreach to help healthcare organizations reach members, identify gaps in care, and encourage activities such as annual health assessments, preventive screenings, physician visits, and health monitoring. Touch4IT has worked with BigHeart for more than six years, helping to develop and evolve the technology that supports these healthcare operations. 

During our conversation, Charles described how engagement depends on much more than communication. BigHeart combines healthcare data integrations, automated campaigns, human outreach, healthcare services, social services, and analytics to support the patient journey. 

This article examines the engineering behind that process and why healthcare organizations often underestimate its complexity. 

🎙️ Listen to the full conversation with Charles Oyibo here 

A Text Message Is Usually the End of a Much Longer Process 

Imagine a patient receives a message that they are overdue for a preventive screening. 

From the patient's perspective, the interaction begins with that message. From the healthcare organization's perspective, the process began much earlier. 

The organization first needs reliable information about the patient. It may need to establish insurance eligibility, understand the patient's health history, and identify whether a relevant care gap exists. It needs rules for deciding which patients should receive outreach and when. Once outreach begins, responses need to be captured, and appropriate actions triggered. 

Charles described several external systems that feed information into BigHeart, including insurance eligibility data, health history, diagnoses, care gaps, admissions, and discharge and transfer information. Together, these sources provide the context required to determine when an intervention may be appropriate. 

ADT data provides a particularly useful example. 

When a patient moves between healthcare settings, such as leaving an emergency department and returning home, that event can create a need for follow-up. The value of receiving the data comes from what the healthcare organization can do with it. The system needs to recognize the event, connect it to the correct patient, and make the information useful to the people responsible for the next stage of care. 

This is the part of patient engagement that patients rarely see. Before a communication can be relevant, the technology needs sufficient context to understand why it should happen in the first place. See more in our article on The 5 Components of Modern Patient Engagement Platform. 

Care Gaps Turn Healthcare Data Into Work 

Healthcare organizations accumulate enormous amounts of data. Engagement becomes useful when that information can be translated into something somebody can act on. 

Care gaps are a good example. 

A patient may be overdue for a mammogram, annual physical examination, or another preventive service. Identifying that gap creates a specific task for the healthcare organization: reach the patient and help them complete the appropriate activity. 

Charles described this as an important part of BigHeart's work with Medicaid members in Illinois. The program involves reaching members and helping identify gaps that may require screenings, examinations, referrals, or other healthcare activities. 

At small scale, some of this can be managed manually. At population scale, the software has to do considerably more of the organizational work. 

It needs to process information from different sources, determine which patients require attention, and support teams responsible for contacting them. Once an intervention takes place, the result needs to be recorded so the same workflow does not continue indefinitely. 

The engineering challenge therefore extends beyond storing patient information. The platform has to turn that information into operational workflows that healthcare teams can use. In our article, What Large-Scale Patient Engagement Really Looks Like, you can learn more about this issue. 

Engagement Requires More Than Automation 

Automation is an obvious part of solving this problem at scale, but healthcare populations do not behave uniformly. 

Some people respond to SMS. Others are easier to reach by phone. Some may require repeated attempts before responding at all. 

The Illinois Medicaid example goes further. Charles described an outreach model that uses SMS, phone calls, and in-person contact, including visits to recipients when necessary. BigHeart also uses Community Engagement Specialists together with automated outreach campaigns. 

Supporting this type of operation creates a different set of software requirements than running a conventional marketing campaign. 

The platform needs to help determine which outreach method to use, maintain a history of previous interactions, provide staff with enough context to understand why they are contacting the patient, and capture what happened during the interaction. 

A useful engagement system also needs to accommodate situations where the next step changes during the conversation. A patient may need an appointment, a referral, additional healthcare information, or assistance with a problem that prevents them from receiving care. 

Automation makes the operation manageable. Human intervention handles situations where a predefined digital journey is insufficient. 

The Workflow Does Not End When the Patient Responds 

Response rates are useful, but they provide an incomplete picture of healthcare engagement. 

A patient who responded to a message about an overdue screening has not yet completed it. A member agreeing to schedule an annual examination has not yet attended it. 

The operational workflow has to continue beyond the initial response. 

This is particularly important because the economic rationale behind many engagement programs depends on healthcare activities eventually taking place. 

Charles explained that BigHeart's Illinois Medicaid arrangement includes preventive activities such as health assessments, identifying care gaps, and making appropriate referrals. When an engagement eventually leads to a physician visit, that visit can become a reimbursable claims activity. 

For the software supporting these programs, that means engagement cannot be measured only at the point of communication. 

Healthcare organizations need to understand what happened afterward. 

Was the patient reached? Did they agree to an intervention? Was the appointment scheduled? Was the healthcare service ultimately delivered? Does another action need to follow? 

Connecting these events is one reason healthcare engagement software becomes considerably more complex as programs mature. 

Healthcare Problems Often Continue Outside the Healthcare System 

There is another complication that conventional engagement software can easily miss. Sometimes the patient wants to take the recommended action but cannot. 

Charles discussed BigHeart's ability to connect healthcare services with social services addressing factors such as housing and transportation. These social determinants can have a significant relationship with healthcare outcomes. 

Transportation provides an obvious example. Identifying an open care gap and successfully scheduling an appointment does little good if the patient has no practical way to reach the provider. 

For the platform, this means the workflow may need to move beyond clinical information and healthcare providers. The system may need to support referrals to community organizations or social services and allow care teams to coordinate activities across organizations that operate very differently from hospitals or health plans. 

This considerably expands the technical scope of engagement. The patient's healthcare journey does not necessarily follow the boundaries of the healthcare organization's existing software. 

Reporting and Analytics Close the Feedback Loop 

Healthcare engagement programs generate plenty of activity. Patients receive messages, care teams make calls, referrals are created, appointments are scheduled, and services are delivered. The challenge is connecting those activities well enough to understand what is actually working. 

Charles identified reporting and analytics as one of the five core capabilities behind BigHeart's approach. The purpose is to generate insights that can improve how services are delivered in the future. 

For an engineering team, this requires thinking about measurement from the beginning. If outreach happens in one system, appointments are managed elsewhere, and clinical outcomes come from another data source. Simply producing a reliable picture of the patient journey can become difficult. 

Basic communication metrics such as messages sent or calls completed provide some operational visibility, but healthcare organizations ultimately care about what those interactions produce. They may want to understand how many members completed an annual health assessment, whether identified care gaps resulted in referrals, which populations remain difficult to reach, or which outreach methods are producing the strongest response. 

The answers can then influence future workflows. If one group consistently responds to SMS while another requires telephone or in-person outreach, the organization can adjust its engagement strategy accordingly. If patients repeatedly begin a process but fail to complete the next step, that may reveal a problem in the workflow rather than a lack of willingness to engage. 

This creates a continuous feedback process in which healthcare data informs an intervention, the intervention produces an outcome, and the resulting information helps improve the next intervention. 

What Engineers Actually Have to Build 

Once healthcare engagement is viewed as an operational process, the technical requirements become much clearer. 

A production platform may need to ingest information from EHRs, eligibility systems, ADT feeds, and other external sources. It needs to reconcile that information with existing patient records and determine whether something has changed that requires action. 

It then needs a reliable way to represent the patient's current situation. A person may have several open care gaps, an incomplete referral, previous unsuccessful outreach attempts, and a recent hospital discharge simultaneously. The software has to make this information usable without overwhelming the people responsible for acting on it. 

Workflow logic determines what happens next. Some events might trigger automated outreach. Others may create work for a Community Engagement Specialist or another member of the care team. Different workflows may require different escalation rules, communication channels, and follow-up periods. 

Communication history also matters. Staff contacting a patient need to know what has already happened. Without that context, patients may receive duplicate messages or repeated calls from people who lack visibility into prior interactions. 

Then there are exceptions. 

Healthcare workflows rarely progress exactly as designed. Contact details may be incorrect. Eligibility may change. A patient may decline an intervention. A referral may never be completed. An external system may return incomplete information. A care manager may discover a social issue that changes what needs to happen next. 

Good healthcare software has to accommodate these situations rather than assuming that every patient will follow the same predefined sequence. 

Finally, all of this has to be captured in a form that supports reporting, auditing, and continuous improvement. 

This is why engineering patient engagement functionality requires much more than connecting a messaging provider to a patient database. The difficult work sits in maintaining reliable patient context while coordinating actions across systems, people, and organizations. 

Scale Changes the Engineering Requirements 

The Illinois Medicaid program described by Charles involves outreach to more than half a million recipients. At that size, even relatively small inefficiencies become significant. 

Suppose a workflow produces unnecessary manual work for only five percent of members. Across a population of 500,000 people, that could create tens of thousands of cases requiring additional attention. 

The same principle applies to data quality, duplicate records, failed integrations, and poorly designed outreach logic. Problems that are manageable during a pilot can become operational bottlenecks once a platform is supporting a large population. 

Scale also changes how organizations need to prioritize work. 

A care team cannot review the complete history of hundreds of thousands of patients and independently decide who should be contacted every morning. The platform has to help narrow that population into manageable groups based on the information available and the healthcare activities that need attention. 

Charles's description of BigHeart's model shows how several capabilities contribute to that process. External integrations provide information about eligibility, health history, diagnoses, and care gaps. Automated campaigns support outreach, while Community Engagement Specialists provide human intervention where needed. Reporting, in turn, helps the organization understand the results and improve future programs. 

As the population grows, the quality of these connections becomes increasingly important. Scaling the number of patients without scaling the underlying workflows simply transfers the complexity to healthcare staff. 

What Healthcare Product Teams Should Consider Before Building Engagement Functionality 

For healthcare product teams, the first questions should focus on the healthcare process the technology needs to support. 

What information determines that a patient requires intervention? Where does that information come from? How quickly does it need to become available? Who is responsible for acting on it? 

The team also needs to understand what a successful intervention looks like. If the objective is completing an annual health assessment, the workflow should be designed around that outcome. If the objective is to support a patient after discharge, the relevant events, people, and systems will differ. 

Communication channels should follow those requirements. SMS may work well for one population and poorly for another. Some programs may require telephone outreach, while difficult-to-reach populations may need community-based or in-person engagement. Charles's description of the Illinois program demonstrates why several channels may need to coexist within the same operation. 

Product teams should also map what happens after the patient responds. This is often where the complexity begins. A response can lead to scheduling, referral, telehealth, clinical services, social support, or additional outreach. Each path can introduce another system or organization into the workflow. 

Finally, teams need to decide how success will be measured before development begins. If the platform cannot link engagement activities to subsequent patient actions, it becomes difficult to determine whether the functionality is improving healthcare delivery or merely generating more communication. 

These questions influence architecture, integrations, data models, and workflow design. Addressing them early can prevent engagement functionality from becoming a collection of disconnected features that become increasingly difficult to operate as the product grows. 

From Patient Outreach to Healthcare Operations 

The most useful lesson from BigHeart's model is how closely patient engagement becomes connected with healthcare operations. 

Charles described an ecosystem that combines digital programs, telehealth, EHR functionality, healthcare integrations, automated outreach, Community Engagement Specialists, social services, and analytics. The Illinois Medicaid program then applies these capabilities to a concrete objective: reaching a difficult-to-engage population and helping members take preventive healthcare actions. 

That requires technology to maintain context throughout a patient journey that may involve multiple organizations and numerous individual interactions. 

A message can initiate the journey, but the value comes from everything that follows: identifying the appropriate action, helping the patient complete it, coordinating any additional services, and learning from the result. 

For engineering and product teams, this provides a more useful way to think about healthcare engagement. Start with the healthcare outcome and work backward through the people, workflows, data, and systems required to achieve it. 

Final Thoughts 

Healthcare organizations have good reasons to invest in engagement. Charles described the economic rationale in the Illinois Medicaid context as encouraging preventive activities to address health problems earlier and reduce the burden of chronic illness. For payers and providers, reaching patients and helping them take appropriate action can therefore have both clinical and economic value. 

Delivering that consistently requires considerable technical infrastructure. Patient information has to arrive from external systems, care gaps have to become actionable workflows, outreach needs to be coordinated across channels, staff needs the right context, and results have to feed back into future decisions. 

The quality of the communication still matters. A badly written message will not suddenly become effective because the architecture behind it is sophisticated. But communication can only work with the information and operational capabilities available to it. 

For healthcare product teams building engagement functionality, much of the difficult work therefore happens long before a patient receives the first message and continues long after they respond. 

Building Healthcare Engagement Technology? 

Touch4IT has worked alongside BigHeart for more than six years, developing technology that supports healthcare operations including patient engagement, care management, telehealth, EHR functionality, integrations, and analytics. 

We work with healthcare product and engineering teams when these workflows become more complex and require reliable software that can operate across patients, care teams, and external healthcare systems. 

If you are building or scaling healthcare engagement functionality, talk to Jan, our healthcare lead.   

FAQs 

What technology is used for patient engagement? 

Patient engagement technology can include patient portals, messaging systems, telehealth, care management software, workflow automation, EHR integrations, and analytics. More advanced platforms also use healthcare data such as eligibility information, care gaps, and hospital admission and discharge events to determine when patients may need intervention. 

Why is patient engagement an engineering challenge? 

Effective patient engagement requires healthcare data to be converted into reliable operational workflows. Software may need to identify care gaps, determine which patients require attention, initiate outreach, support care teams, track subsequent actions, and integrate information from multiple healthcare systems. 

How does healthcare data improve patient engagement? 

Healthcare data provides context for deciding when and why to contact a patient. Information about eligibility, diagnoses, care gaps, previous interactions, or recent hospital visits can help healthcare organizations make outreach more relevant and timely. 

What role does automation play in patient engagement? 

Automation can help healthcare organizations manage large patient populations by triggering outreach, creating tasks and coordinating workflows. Human involvement remains important for patients who require additional support, repeated outreach or help resolving more complex healthcare and social needs. 

How should healthcare organizations measure patient engagement? 

Communication metrics such as messages sent and calls completed provide operational information, but organizations should also measure what happens afterward. Depending on the program, this may include completed assessments, appointments, referrals, preventive screenings, the closure of care gaps, and other healthcare actions. 

How does patient engagement technology integrate with EHRs and other healthcare systems? 

Patient engagement platforms can exchange information with EHRs, eligibility systems, ADT feeds, and other healthcare data sources. These integrations provide the clinical and operational context needed to identify patients who require attention and to coordinate appropriate workflows.