Humanizing Healthcare

What does humanizing healthcare mean for software?

Humanizing healthcare in software means designing clinical and patient tools so they reduce time spent on screens and paperwork, communicate in plain and accessible language, and fit the way care is actually delivered. Success is measured by less clerical work for clinicians and fewer barriers for patients, not by feature count.

The phrase covers two audiences. For clinicians, the target is documentation, inbox and alert load. For patients, it is how easy the tools are to understand and use, in their language and on their devices.

Both depend on choices made long before launch: what data is collected, who enters it, which messages are sent and what each screen asks a person to do.

Why is burden a policy issue, not only a design one?

Burden is a policy issue because federal agencies have named EHR and administrative load as a problem and asked technology makers to fix it. These sources set out the case and the direction.

• HHS burden strategy: Section 4001 of the 21st Century Cures Act required HHS to plan how to reduce regulatory and administrative burden from health IT. The final strategy, released in February 2020, set three goals: less effort to record information during care, less effort to meet reporting requirements, and better EHR functionality and ease of use.
• Clinician wellbeing: The US Surgeon General has called on health technology companies to design around the needs of clinicians, care teams and patients, and on insurers to cut prior authorization and documentation work.
• Documentation rules: Since 1 January 2021, Medicare lets practitioners choose the level of an office or outpatient E/M visit by medical decision making or by total time on the date of the visit, so history and exam elements no longer set the visit level.
• Accessibility: Under 45 CFR 84.84, recipients of HHS federal financial assistance must make web content and mobile apps meet WCAG 2.1 Level AA, by 11 May 2027 for those with 15 or more employees and 10 May 2028 for smaller ones.
• Language access: Federal civil rights rules expect covered health programs to give people with limited English proficiency meaningful access, which reaches digital front doors as well as the front desk.

Taken together, these sources move burden from a matter of taste to a design requirement. A product that adds clicks, ignores accessibility or speaks only English works against both federal policy and its own users.

Where does software add work for clinicians?

Software adds work for clinicians when it makes them enter data twice, read messages that are not theirs, or answer alerts that do not change care. This list names the usual sources.

• Duplicate entry: Intake data typed by staff is re-asked by the clinician because the form and the EHR do not share fields.
• Note bloat: Templates pull in every result and prior note, so notes get longer and harder to read.
• Inbox load: Patient messages, results and refill requests all land with the physician, even when a nurse or pharmacist could handle them.
• Alert overload: Interruptive alerts fire for low-value rules, and clinicians learn to dismiss them without reading.
• Login friction: Separate logins for each tool, with short timeouts, cost time at every switch.
• Off-workflow apps: A third-party app opens in a new window instead of launching in context with SMART on FHIR, so the clinician searches for the patient again.

Which design choices give clinicians time back?

The choices that give time back remove a task or move it to the right person. Making a screen faster helps less than removing the need to visit it.

• Capture once: Collect structured intake data from the patient or staff once and write it to the record, so the clinician reviews rather than retypes.
• Route by role: Send each inbox item to the team member licensed and trained to act on it, with escalation rules for exceptions.
• Interrupt rarely: Reserve interruptive alerts for high-risk situations and show the rest as passive guidance, then retire rules with high override rates.
• Launch in context: Use SMART on FHIR so outside tools open with the patient and user already selected.
• Document to the rule: Build note templates around medical decision making or time, the factors that set the E/M level, instead of long checklists.
• Draft with review: Where AI drafts notes or replies, make editing easy and keep the clinician's sign-off as the final step.

Each choice needs a clinical owner. A routing rule or alert change that nobody owns can drift back to the old pattern over later releases.

Patient tools people can actually use

Patient tools work when people can read them, reach them and act on them without help. Plain language, accessibility and language access cover most of that ground.

AHRQ's health literacy guidance recommends treating every patient as someone who may struggle with health information. In software, that means short sentences, common words, one task per screen and instructions that say what to do next. The teach-back method used in clinics has a digital parallel: ask the patient to confirm the key step in their own words or choices.

Accessibility is part of the same work. WCAG 2.1 AA covers contrast, text resizing, keyboard access, screen reader labels and error messages, all of which also help users on small phones or in poor light. Designing to WCAG 2.2 AA covers 2.1 as well.

Language access needs more than a translate button. Translated content should be reviewed by qualified translators, forms should accept names and addresses in many formats, and the patient's preferred language should drive messages and reminders.

Respect patient time as well. Pre-fill what the organization already knows, let patients save and return to long forms, and send only the reminders and surveys that lead to an action.

How do you know a change reduced burden?

You know a change reduced burden when measured time, steps or errors fall for the people affected, compared with a baseline taken before the change. Surveys help, but they should sit beside usage data, not replace it.

• Clinician time: Use EHR usage analytics or audit log metadata to compare time in notes, inbox and after-hours work before and after the change.
• Alert response: Track how often each alert fires, how often it is overridden and whether the advised action follows.
• Patient completion: Measure how many patients finish a form or task, where they stop and how many call for help.
• Accessibility checks: Run automated checks and manual screen reader tests on each release of patient-facing flows.
• Qualitative signal: Run short, regular interviews with a few clinicians and patients to explain what the numbers show.

Running a burden review in five steps

A burden review is a short, structured study of one workflow that ends in a ranked list of changes. Five steps keep it focused and repeatable.

• 1. Pick one workflow: Choose a specific flow, such as new patient intake or refill requests, rather than "the EHR" as a whole.
• 2. Observe and log: Watch the work in person or by screen recording with consent, and count the screens, clicks, re-entered fields and handoffs.
• 3. Pull the baseline: Add usage analytics, alert data and patient completion rates for the same flow so the observation has numbers behind it.
• 4. Rank the fixes: Sort candidate changes by the work they remove and the effort they take, and mark which need a policy or staffing decision rather than code.
• 5. Change and re-measure: Ship the top changes, then repeat the baseline measures on the same flow and share the result with the people who do the work.

Running the review with the clinicians and staff who do the work matters as much as the method. They know which steps exist for a real reason and which survive only because nobody removed them.

Where burden reduction projects fall short

Burden reduction projects fall short when they shift work instead of removing it or when nobody keeps measuring. This failure-point list helps catch that early.

• Work moved, not removed: A new portal form saves clinician time but doubles the work for front-desk staff who clean up its data.
• Pilot-only wins: A change works in one clinic but is never adapted to others with different staffing.
• Accessibility as an audit: Teams fix issues once before a deadline, then new releases reintroduce them.
• AI drafts without review time: Drafts arrive faster than clinicians can check them, and review becomes a new queue.
• No baseline: The team cannot show any gain because it never measured the starting point.

How Agnotic can help

Reducing burden starts with deciding which tasks to remove and who owns each change, which is a leadership question before it is an engineering one. Agnotic Technologies provides fractional CTO leadership that sets those priorities with the client's clinical and product teams and builds a measurement baseline first.

Agnotic's engineers then build the changes: structured intake that writes to the EHR, role-based inbox routing, SMART on FHIR launches, plain-language and WCAG 2.1 AA patient flows, and dashboards that show whether time and steps actually fell.

Sources

• HHS and ONC: Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs (2020)
• CMS: Office and outpatient E/M visits fact sheet
• Federal Register: Section 504 web and mobile accessibility compliance date extension (May 2026)
• W3C: Web Content Accessibility Guidelines 2.1