Medication management software for patients and care teams

Medication management software for patients and care teams

AddMed is medication management software with two sides that have to work as one. Patients get a mobile app that handles their schedule, reminds them when a dose is due, and lets them log what they took. Their care team gets a clinical dashboard that reads those logs and turns them into an adherence picture worth acting on. A HIPAA-built layer with bidirectional HL7/FHIR EMR sync keeps both sides on the same medication list, so neither the patient nor the clinician is working from stale data.

We built it for the healthtech practice at Idealogic, for the people who live with long-term medication and the clinicians responsible for them. Most of those patients are older, and plenty aren't comfortable with phones. That shaped the product from the first screen.

What makes AddMed different is the loop it closes. A typical app reminds and stops. AddMed adapts to how a patient responds, records what actually happened, and lets the care team see it. The signal a clinician needs, who is falling behind and when, finally lives somewhere they can reach it.

Why medication adherence is a system problem, not a reminder problem

Roughly half of patients with chronic conditions don't take their medication as prescribed. The cost of that lands on patients first and on the health system after, in avoidable admissions and worse outcomes. It's one of the more expensive unsolved problems in care, and here's the part most apps miss: it doesn't yield to a louder notification.

Plain reminder apps prove the point. They lift adherence for a week or two, then people stop opening them. The behaviour they're fighting is human, not technical, and a fixed alarm at 9am doesn't bend to a real life. Sustained adherence needs a system that adapts to the patient instead of asking the patient to adapt to it.

There is a second gap, on the clinical side. Between appointments, a care team has almost no view of whether a patient is keeping up. By the time a problem surfaces at the next visit, weeks of missed doses may have already done their damage. Adherence data that never reaches a clinician is data that cannot help anyone.

Then there is the data itself, scattered across the pharmacy, the patient's own habits, and the electronic medical record. None of those talk to each other by default. For the product to be useful, it had to pull a medication schedule out of an EMR, keep it current as orders change, and hold up under HIPAA and GDPR while doing so. The standards vary by institution. Some expose HL7, some FHIR, some only a proprietary API, so the integration could not assume one shape. Getting that foundation right mattered more than any single feature on top of it.

What we built: a patient app and a clinical adherence dashboard

AddMed is one platform with two surfaces and an integration layer between them. The patient side carries adaptive reminders, dose logging, and an interface built to be usable by people who don't think of themselves as app users. The clinical side carries adherence heatmaps, configurable alert thresholds, and predictive analytics that flag patients before their adherence falls off. The EMR-sync layer keeps the medication list identical on both ends.

The two sides were designed together rather than bolted into a bundle. An alert a clinician sets on the dashboard changes what a patient experiences on their phone, and a dose a patient logs changes what the clinician sees. That shared spine is why AddMed reads as one product instead of two apps that happen to share a login. It is also why our SaaS development and custom software development teams kept the patient experience and the clinical workflow in the same conversation from the start.

Designing the patient app for adherence, not just reminders

The patient app had one job before any other: be usable by the person actually holding the phone. For AddMed that person is often elderly, sometimes managing a condition that makes screens harder, and rarely a confident app user. So the design leans on large typography, high contrast, voice-assisted reminders, and the fewest interaction steps we could get away with. Logging a dose is a single obvious tap, not a path through menus.

Reminders are where most apps quietly fail, and where we spent the most thought. A fixed schedule treats every patient the same and loses them within weeks. AddMed watches how a person responds and shifts its timing to match, so the prompt arrives when it has a real chance of working rather than when a default said it should. The app nudges; it doesn't nag.

Adherence for chronic-condition patients

Chronic illness is the hard case, and the one that matters most. A patient on several long-term medications has multiple schedules to keep straight, and adherence on any of them can erode so gradually that no one notices until something goes wrong. The adaptive timing and the low-friction logging are aimed squarely at that reality: keep the daily routine simple enough to sustain, and capture enough signal that a slip shows up early instead of at the next appointment.

HL7/FHIR EMR integration and bidirectional sync

The integration layer is the part of AddMed that most medication apps skip, and the reason it works as clinical software rather than a standalone tracker. Instead of asking anyone to retype a regimen, AddMed pulls medication schedules straight from the electronic medical record over HL7 v2 and FHIR R4, the interoperability standard most modern health systems expose. As good EHR integration software should, it treats the record as the source of truth and stays in step with it.

The sync runs in both directions, which is the harder and more useful half. When a clinician updates a medication order in the EMR, that change reaches the patient's app. When something changes on the app side, it flows back to the record. Neither side drifts out of date, and no one reconciles two lists by hand.

Two-way movement of patient-health data is also where the risk concentrates, so the engineering underneath is deliberate. Writes are idempotent, so a retried message cannot double-apply an order. Every exchange is logged for audit. The sync is queued rather than fire-and-forget, so a downstream system being briefly unavailable does not lose a change. Those patterns are covered in more depth in our note on EHR integration. The standards choice that drives them, and why it decides what you can integrate with, is the subject of the difference between an EHR and an EMR.

We built the integration to meet diverse systems of record on their own terms, including the major platforms a care setting is likely to run, such as Epic, Cerner (now Oracle Health), and regional systems. Where a legacy system only exposes a proprietary API, it sits behind an adapter so the rest of the platform never has to care.

Building HIPAA-compliant medication software

A medication platform handles some of the most sensitive data there is, so compliance could not be a layer added at the end. AddMed ran its pilot deployments under both HIPAA and GDPR and came through with zero data incidents, including on the bidirectional sync path where personal health data moves between the app and clinical systems. That record came from designing the safeguards in, not from a checklist at launch.

In practice, HIPAA-compliant app development on AddMed meant a specific set of controls built into the core. Personal health data is encrypted in transit and at rest. Access is role-based and follows minimum-necessary, so a patient, a clinician, and an administrator each see only what their role requires. Every meaningful action is written to an audit log. Personal health data is deliberately kept out of push notifications, because a lock-screen preview is a leak waiting to happen.

It's worth being precise about what compliance here is and isn't, because the term gets thrown around loosely. HIPAA doesn't issue a certificate a product can hold up; the Security Rule is a set of safeguards to implement, not a badge to earn. What counts is that those safeguards are real and built into the system, and that the same care extends to the work our AI integration brought into the clinical dashboard. We approach every regulated build this way, and AddMed is one example of it. More of how we think about it lives in our note on HIPAA-compliant software development.

Results, and where medication management software goes next

AddMed is live in clinical pilots, with patients on one side and their care teams on the other, running on a single platform rather than a patchwork of disconnected tools. The bidirectional HL7/FHIR sync removed the manual re-entry that usually sits between an app and an EMR, so a medication change happens once and shows up everywhere. The HIPAA and GDPR pilots ran without a data incident. And the patients the app was hardest to win, the older ones, the ones less comfortable with phones, kept using it, because the accessibility work and the adaptive timing made it worth keeping.

The shape of the product is what carries it forward. Because the two sides share one spine and the integration layer already speaks the standards a health system runs on, AddMed extends to new conditions and new care settings without a rebuild each time. That is the argument for building medication management software this way from the start: get the patient experience, the clinical view, and the EMR integration right together, and the platform keeps paying it back.