What Mandatory AI Disclosure Rules Means for Healthcare Providers in Europe

Direct answer: Healthcare providers across Europe now operate under a legal requirement that any chatbot or interactive AI system talking to a patient must clearly disclose that the patient is talking to an AI, not a human. This isn't a UX suggestion anymore — it's a compliance obligation, and for healthcare specifically it touches everything from intake bots to symptom triage widgets to appointment assistants. The practical fix is architectural: disclosure has to be built into the conversation flow itself, logged, and testable, not left to a one-line banner someone added after launch.

The trend is straightforward and it's now law-adjacent rather than best-practice-adjacent: chatbots and interactive AI systems are legally required to disclose that users are talking to AI, according to Digital Strategy EC, Aug 2026. For a hospital group, a clinic network, a telehealth platform, or a diagnostics provider running any kind of conversational interface on their website or app, this closes off the option of ambiguity. Patients interacting with a symptom checker, a booking assistant, or a post-discharge follow-up bot must be told, in a way that's clear and hard to miss, that they are not speaking with clinical staff. We don't have a precise figure on how many healthcare organizations in Europe currently have compliant disclosure in place versus how many are running bots with no disclosure at all — that number isn't publicly available for this specific angle — but the general pattern across regulated industries adopting new disclosure rules is that a meaningful share of existing deployments were built before the rule existed and now need retrofitting. Healthcare is not exempt from that lag, and arguably has less room for error given how sensitive the subject matter is.

Why now, and why this isn't just another EU tech rule

It's tempting to file this next to cookie banners and treat it as background noise that developers quietly comply with and everyone else ignores. That would be a mistake for healthcare specifically. Disclosure rules for AI systems tend to arrive as part of a wider push toward transparency in automated decision-making, and healthcare sits at the intersection of two things regulators care about most: automated systems making judgment calls, and vulnerable people relying on those judgments. A rule that started as a general digital-services requirement for chatbots doesn't stay general for long once health data and patient safety enter the picture.

There's also a timing dimension worth naming plainly. Providers who built conversational tools over the past few years did so in an environment where "sounds helpful, ship it" was often good enough. The tools worked, patients used them, and nobody asked hard questions about whether the patient understood what they were talking to. That environment has changed. Aug 2026 marks the point where the assumption flips: the default is now that a provider must prove disclosure happened, not that a patient must prove they were misled. That's a meaningfully different bar, and it changes what "compliant" actually looks like in code, not just in policy language.

What the disclosure requirement actually covers

The rule targets a specific interaction pattern: any system where a user might reasonably believe they are talking to a person, when in fact they are talking to an AI. That's a broad net for healthcare providers, because conversational interfaces have spread well past the obvious "chat with us" widget in the corner of a website.

Where it shows up in a typical healthcare stack

• Patient intake and pre-visit questionnaires that use conversational UI instead of static forms
• Symptom triage tools that ask follow-up questions and suggest next steps
• Appointment scheduling assistants that handle rescheduling, cancellations, and reminders
• Post-treatment or medication-adherence check-in bots
• General "ask us anything" support widgets on a provider's website

Each of these needs to make the AI nature of the interaction obvious at the point of first contact, and arguably again at points where a patient might forget or reasonably assume they've been escalated to a human. The requirement isn't satisfied by a terms-of-service clause buried in a privacy policy — it needs to be present in the interaction itself.

It's worth being explicit about what's not covered, too, because overcorrecting wastes engineering time that could go toward the parts that actually matter. A static FAQ page that answers common questions without any back-and-forth dialogue isn't the same category as a chatbot, even if the content was originally generated with AI assistance. The line the rule draws is around interactivity and the reasonable impression of talking to a person — not around whether AI touched the content anywhere in the pipeline. Providers who understand that distinction can focus their compliance effort on the handful of genuinely conversational tools rather than auditing every piece of AI-assisted content on the site.

Where the ambiguity actually lives

The harder judgment calls show up in hybrid tools — a scheduling widget that starts as a simple form but occasionally asks a clarifying follow-up question, or a support widget that begins with canned responses and escalates into a more free-form exchange. These blended tools are exactly where providers get caught out, because nobody built them with disclosure in mind from day one; they grew incrementally, and the conversational behavior crept in gradually until the tool became indistinguishable, from the patient's perspective, from a real conversation. An audit needs to catch these, not just the obviously bot-branded tools.

Why this matters more for healthcare providers than for most other sectors

Disclosure rules for AI chat interfaces apply broadly, but the stakes for healthcare providers are structurally different from, say, a retail chatbot answering shipping questions. Patients bring health anxiety, urgency, and a baseline assumption of clinical authority to these conversations that doesn't exist in a typical customer service exchange. If someone believes they're describing symptoms to a nurse when they're actually talking to a model, the trust dynamics — and the liability exposure — change immediately.

There's also a second-order effect specific to European healthcare providers: regulators overseeing health data and patient safety tend to move in the same direction as consumer-protection regulators, often faster once one of them has set a precedent. A disclosure rule that starts as a general digital-services requirement has a track record of getting layered with sector-specific expectations for healthcare — audit trails, documented escalation paths to human clinicians, and stricter language requirements for anything touching diagnosis or triage. Providers that treat this Aug 2026 rule as the ceiling rather than the floor are better positioned when that layering happens.

For providers running multilingual patient bases — common across most of Europe — there's a practical wrinkle too: disclosure has to be understandable in the patient's language, not just present in whatever language the interface was originally built in. A generic English disclaimer buried at the bottom of a chat window doesn't meet the spirit of a rule meant to make sure patients actually understand who or what they're talking to.

There's a reputational angle here too, separate from the strict legal one. Healthcare is one of the few sectors where a single bad story about a patient being misled by a bot travels fast and sticks. A provider that gets ahead of this — rolling out disclosure cleanly, before it becomes a story — is making a quiet but real investment in patient trust that compounds over time. Providers that wait until a complaint or a regulator inquiry forces the issue end up doing the same engineering work under worse conditions, with less room to think carefully about tone and patient experience.

What changes in practice for a provider's website or app

This is where the requirement stops being a legal talking point and becomes an engineering task. Three things typically need to change.

1. The conversation flow itself

Disclosure needs to happen at the first meaningful exchange, not just on page load. A modal that flashes for two seconds and disappears doesn't hold up well against a rule meant to protect patients who may be distracted, upset, or in a hurry. The AI identity needs to be reiterated in a way that's persistent — a visible label on the chat interface itself ("AI Assistant"), not just a one-time popup.

2. Logging and auditability

If a regulator or a patient later asks "was I told this was AI," the provider needs to be able to show, per conversation, that disclosure was rendered and, ideally, acknowledged. That means the disclosure event needs to be a logged part of the conversation record, not a static frontend string that leaves no trace.

3. Escalation paths

Once disclosure is explicit, patients will more often ask to speak to a human — which is a good outcome for trust, but only works if there's a real, working handoff path. A bot that discloses it's an AI and then has no mechanism to route a patient to a clinician or staff member when asked creates a worse experience than no disclosure at all.

None of this is a copy change. It's a rebuild of how the conversational layer talks to the rest of the patient-facing system, which is exactly the kind of cross-cutting work that belongs in a proper Custom Software Development engagement rather than a quick patch by whoever manages the website's CMS. Retrofitting disclosure, logging, and escalation into an existing bot architecture — especially one built on a vendor's off-the-shelf widget — is often more involved than building it right the first time, because the integration points with EHR systems, scheduling backends, and identity verification all need to be touched.

The vendor-widget complication

A lot of healthcare providers didn't build their chatbot in-house — they licensed a widget from a scheduling vendor or a support-desk platform and embedded it with a script tag. That's a perfectly reasonable way to ship a feature quickly, but it creates a specific compliance problem: the provider is legally responsible for what the patient sees, while the actual conversation logic, and often the logging, lives inside a third party's system that the provider doesn't fully control. Fixing disclosure in that setup means either working with the vendor to expose the configuration needed, wrapping the widget with a layer you do control, or in some cases concluding that a custom-built conversational layer is the more durable answer given how central these tools have become to patient interaction. None of those paths is instant, which is exactly why providers who start this work now, ahead of any enforcement pressure, end up in a better position than those who wait.

How to think about rollout without breaking existing patient trust

Healthcare providers can't treat this as a one-week sprint, because a badly worded or jarring disclosure can do its own damage to patient confidence — especially for anyone already anxious about a health issue. A few practical principles help:

• Test the language with actual patients, not just legal. A disclosure that's legally sufficient but reads as cold or alarming will hurt engagement with tools that are otherwise genuinely useful, like medication reminders or triage assistants.
• Separate low-stakes and high-stakes bots. A scheduling assistant and a symptom-triage tool don't need identical disclosure treatment — the triage tool warrants more prominent, repeated disclosure given the higher consequence of confusion.
• Don't let compliance work stall unrelated roadmap items. Providers sometimes freeze all chatbot development while compliance gets sorted. That's usually the wrong call — disclosure can be added incrementally to a well-architected conversational layer without pausing everything else.
• Treat structured content and schema the same way you treat conversational content. If a provider is exposing FAQ or symptom-information content to search engines and AI answer engines alongside the chatbot, the same clarity principle applies to how that content is marked up — see our comparison of JSON-LD vs Microdata vs RDFa for how structured data choices affect how clearly that information is represented to both users and machines.

Getting the rollout sequence right matters as much as getting the wording right. Providers who tackle every tool simultaneously tend to burn out their compliance and engineering capacity on low-value work — polishing disclosure copy for a rarely-used feedback bot while a heavily trafficked triage tool sits unfixed. Sequencing by patient volume and stakes, not by which team happens to be available first, produces a better outcome faster.

There's also a broader pattern worth noting: as more digital interactions carry disclosure, verification, and trust requirements, providers that already have solid fraud-prevention and identity-verification instincts adapt faster. Much of what applies to protecting a transaction from being misrepresented — a lesson well covered in Ecommerce Fraud Prevention: Protecting Your Store From Chargebacks — carries over conceptually to making sure a patient-facing interaction is honestly represented. The domains are different, but the underlying discipline of "make sure the other party knows exactly what they're dealing with" is the same.

And for providers running international patient populations or cross-border referral networks, it's worth watching how disclosure and trust regulations evolve in tandem with broader geopolitical and trade shifts — the kind of environment discussed in The 2026 US-China Trade Truce: Inside a Fragile Reset After the Trump-Xi Summit, where regulatory reset points in one region tend to ripple into how other regions calibrate their own digital and data rules.

What the audit process should actually look like

Before any code changes happen, providers need an honest inventory of every place an AI system talks to a patient. This sounds obvious, but in practice most healthcare organizations don't have a single list — the chatbot lives with the marketing team, the triage tool lives with clinical operations, and the medication-reminder system was set up by a completely separate vendor relationship years ago. Nobody owns the full picture.

A workable audit walks through every patient touchpoint — website, patient portal, mobile app, and any third-party booking or telehealth integration — and asks three questions for each conversational element: does it currently disclose AI use, is that disclosure persistent and understandable, and is there a working path to a human if the patient asks for one. Tools that fail any of those three checks go on the fix list, ranked by how high-stakes the interaction is. A symptom-triage tool with no disclosure is a different priority than a reminder bot with no disclosure, even though both technically need fixing.

This audit is also the moment to catch the hybrid, half-conversational tools mentioned earlier — the ones that don't look like a "real" chatbot but behave like one once a patient starts interacting with them. Skipping this step and jumping straight to fixing the obviously-branded chatbot is the single most common way providers end up with a compliance gap they didn't know they had.

What this kind of work typically falls under

Retrofitting disclosure, logging, and human-escalation paths into a patient-facing conversational system is scoped work, and the right tier depends on how much of the existing stack needs to change.

Tier	Typical scope for this work
Essential ($1,000)	Adding compliant disclosure UI and copy to a single existing chatbot or form flow, no backend logging changes
Growth ($2,000)	Disclosure across multiple patient-facing tools, conversation logging, and a basic human-escalation path
Enterprise ($4,000+)	Full audit-ready logging, multilingual disclosure, EHR/scheduling integration, and escalation routing across a provider network

Key Takeaways

• Chatbots and interactive AI systems talking to patients in Europe must now clearly disclose they are AI, per Digital Strategy EC, Aug 2026.
• Disclosure needs to live inside the conversation flow itself — persistent, understandable, and logged — not just in a policy document.
• Healthcare carries higher stakes than most sectors because patients assume clinical authority in these conversations.
• Retrofitting disclosure into an existing bot often requires touching scheduling, EHR, and identity systems, which is real engineering work.
• A working human-escalation path is not optional once disclosure makes patients aware they can ask for one.
• Multilingual, patient-tested disclosure language protects trust better than a generic legal disclaimer.

Getting disclosure right without breaking the patient experience you've already built takes more than a copy edit — it usually means rethinking how the conversational layer connects to the rest of your systems. If you want help figuring out where to start, book a meeting with our team.

Frequently Asked Questions

What does "AI disclosure" actually mean for a healthcare chatbot?

It means the patient must be told, clearly and at the point of interaction, that they are communicating with an AI system rather than a human staff member. This applies to intake bots, triage tools, scheduling assistants, and any other conversational interface a provider runs.

Does this rule apply to every type of chatbot a clinic uses?

It applies to any interactive AI system where a user could reasonably believe they're talking to a person. Simple static FAQ widgets that don't simulate conversation are a different case, but anything with back-and-forth dialogue, including symptom checkers and appointment assistants, is covered.

Is a small pop-up disclaimer enough to comply?

A brief pop-up that disappears quickly is unlikely to meet the spirit of a rule meant to ensure patients genuinely understand who they're talking to. Persistent, visible labeling within the chat interface itself is a safer approach.

What happens if a healthcare provider doesn't disclose AI use?

Non-compliance risk depends on how enforcement develops under the rule, but the more immediate risk for healthcare specifically is patient trust and potential liability if a patient makes a health decision believing they spoke to clinical staff. Providers shouldn't wait for enforcement patterns before fixing this.

Does this rule only affect chatbots, or does it cover other AI tools too?

The Aug 2026 requirement as described centers on chatbots and interactive AI systems — anything conversational. Non-interactive AI uses, like backend scheduling optimization or claims processing, aren't the same category, though providers should stay alert as scope tends to expand over time.

How does this affect telehealth platforms specifically?

Telehealth platforms often rely heavily on conversational interfaces for intake and triage before a human clinician joins, which puts them squarely in scope. These platforms need disclosure at every AI-driven step, not just the initial chat window.

Do symptom-checker tools need special treatment under this rule?

Yes — symptom checkers carry higher stakes because patients may be describing urgent or frightening symptoms and could misread the tool's authority. Disclosure should be more prominent and possibly repeated compared to a low-stakes scheduling bot.

What counts as "clear" disclosure language?

Clear generally means plain, non-technical language stated at the first meaningful exchange and understandable in the patient's own language, not legal phrasing buried in fine print. It should be obvious without the patient having to search for it.

Can we use the same disclosure wording across all our bots?

You can use consistent baseline wording, but higher-stakes tools like triage assistants likely warrant more explicit, repeated disclosure than something like an appointment-reminder bot. Uniform minimum wording plus contextual reinforcement is a reasonable approach.

Does disclosure need to be logged somewhere?

It's a strong practice to log that disclosure was rendered as part of each conversation record, so the provider can demonstrate compliance if questioned. A frontend-only disclaimer with no backend trace is harder to prove after the fact.

What's the difference between disclosure and consent?

Disclosure tells the patient they're talking to an AI; consent would involve the patient agreeing to proceed under those terms. The current requirement is about disclosure — making the fact known — rather than requiring an explicit opt-in click, though some providers may choose to add consent steps for extra assurance.

How much does it cost to add compliant disclosure to an existing chatbot?

For a single existing chatbot needing UI and copy changes without backend logging, this typically falls under an Essential-tier engagement around $1,000. More complex setups involving logging and escalation cost more, as outlined in the pricing table above.

How long does this kind of retrofit usually take?

Timeline depends on how many patient-facing tools are affected and whether backend logging and escalation paths need to be built. A single-bot disclosure update can be quick; a provider-wide rollout with logging and multilingual support is a longer, phased project.

Do we need to rebuild our chatbot from scratch?

Not usually. Most providers can add disclosure, logging, and escalation into their existing conversational architecture without a full rebuild, provided the underlying system is flexible enough to support new integration points.

What if our chatbot is a third-party vendor widget?

Vendor widgets can be harder to modify directly, so compliance may require configuration changes on the vendor's side, a wrapper layer you control, or a broader case for building a custom conversational layer that gives you full control over disclosure and logging.

Does multilingual disclosure matter for a single-country provider?

If your patient base includes non-native speakers of the primary local language — common in most European healthcare systems — yes. Disclosure only works if patients actually understand it, regardless of which language they're most comfortable in.

What's a human-escalation path and why does it matter here?

It's the mechanism that lets a patient who's just been told they're talking to an AI actually reach a human when they ask to. Disclosure without a working escalation path can undermine trust rather than build it, since patients may feel stuck talking to a bot they didn't choose.

Does this apply to internal staff-facing tools too?

The disclosure requirement as described is about user-facing interactions, meaning patients or the public. Internal staff tools used by clinicians or administrators aren't the same category, though good practice still favors transparency about AI involvement in any tool.

How does this interact with GDPR or other data protection rules?

Disclosure about AI use is a separate concern from data protection, but they often intersect — a compliant conversational system should be transparent about both the fact that it's AI and how patient data from the conversation is used and stored.

Should our disclosure mention what the AI can and can't do?

It's good practice to be clear that the AI assistant isn't a substitute for clinical judgment, especially for symptom-related tools, in addition to disclosing that it's AI at all. Combining both messages reduces the risk of a patient over-trusting the tool.

What happens to bots we built years ago with no disclosure at all?

Those need retrofitting as a priority, since they were built before this expectation existed and are now the highest-risk category. An audit of every patient-facing conversational tool is a reasonable first step before deciding what to fix first.

Is voice-based AI (like phone triage lines) covered by this too?

Interactive voice systems that simulate conversation raise the same disclosure logic as text chatbots — a patient shouldn't be left assuming they're speaking to a person if they're not. Providers running AI-driven phone systems should apply the same disclosure principles even though the described rule centers on chat interfaces.

Who is responsible for enforcing this within a healthcare organization?

Typically it becomes a shared responsibility between compliance/legal teams who interpret the requirement and the technical team that implements it in the actual product. Neither side alone tends to get it right without the other.

Can we phase this rollout, or does everything need to change at once?

Phasing is generally sensible — prioritize the highest-stakes and highest-traffic tools first, such as symptom triage, before moving to lower-risk tools like appointment reminders. A phased approach also reduces the risk of disrupting patient experience all at once.

Does this rule apply to providers outside the EU serving European patients?

Rules framed around protecting users in a region often extend to any organization serving patients located there, not just organizations headquartered there. Providers with a European patient base should assume this applies to them regardless of where they're incorporated.

What's the risk of over-disclosing and annoying patients?

Excessive or repetitive disclosure can feel intrusive, especially in low-stakes interactions like a simple reminder bot. The goal is clarity, not friction — disclosure once at the start of an interaction, reinforced with a persistent visual label, is usually sufficient outside high-stakes contexts.

How do we test whether our disclosure actually works?

User testing with real or representative patients is the most reliable method — ask them afterward whether they knew they were talking to an AI. If a meaningful share didn't realize it, the disclosure needs to be more prominent or worded more plainly.

Does this affect how we design our website's live chat widget?

Yes — any live chat widget that sometimes routes to AI and sometimes to a human needs to make clear which one the patient is currently talking to, and switch that indicator accurately when a handoff happens. A static "chat with us" label that doesn't distinguish AI from human staff no longer meets the bar.

What documentation should we keep to show compliance?

Records showing that disclosure copy was reviewed, when it was deployed, and logs showing it was rendered to patients during conversations are the core pieces. Screenshots and version history of the disclosure UI over time also help demonstrate a good-faith compliance effort.

Should our marketing pages also mention that our chatbot is AI-powered?

It's reasonable and often helpful to mention AI-powered features on marketing or service pages, but that doesn't substitute for disclosure within the actual conversation itself. Both together give the clearest overall picture to patients.

Does this rule affect chatbots used only by clinicians, not patients?

As framed, the requirement centers on interactions with users like patients rather than internal clinical staff using a tool. Still, transparency about AI involvement in clinical decision-support tools is good practice regardless of the audience.

What if a patient asks the bot directly "are you a real person?"

The bot should answer honestly and immediately, which is a natural extension of upfront disclosure rather than a separate rule. A system that dodges or gives an ambiguous answer to a direct question undermines the entire point of disclosure.

Can AI disclosure be handled entirely through a banner on the website?

A general website banner isn't a substitute for disclosure within the specific chat interaction itself, since patients may land directly on a chat widget without seeing the banner first. Disclosure needs to travel with the interaction, not just live on the page around it.

How does this affect appointment reminder bots specifically?

Even low-stakes tools like appointment reminders fall under the disclosure requirement if they're interactive, though the disclosure treatment can be lighter than for higher-stakes tools like triage. A brief, clear label is usually sufficient here.

What's the biggest technical mistake providers make when retrofitting disclosure?

Treating it as a frontend-only copy change instead of touching the logging and escalation logic behind it. That approach looks compliant on the surface but leaves no audit trail and no real path to a human when patients ask for one.

Does this rule require us to disclose which AI model or vendor we use?

No, the requirement described is about disclosing that the interaction is with AI at all, not which specific model or vendor powers it. Some providers choose to share that detail for transparency, but it isn't the core obligation here.

How do we handle disclosure for a bot that sometimes escalates to a human mid-conversation?

The interface should clearly indicate the moment a human joins the conversation, so the patient isn't left assuming they're still talking to the AI. This is one of the more technically involved parts of a compliant rebuild, since it requires real-time status changes in the chat UI.

Should we involve our compliance or legal team before making any changes?

Yes — legal or compliance should review the specific wording and rollout plan, since interpretation of exact requirements can evolve, while the technical team handles implementation. Coordinating both from the start avoids rework later.

Is there a risk in waiting to address this until enforcement actions start appearing?

Waiting increases risk in a sector like healthcare where patient trust and safety perception matter more than in most industries, even before formal enforcement patterns emerge. Providers who fix this proactively are also better positioned if the rule gets tightened or expanded later.

Does this apply to AI used for translating patient communications?

If a translation tool is presented as an interactive assistant that a patient converses with, disclosure principles likely apply the same way. Pure background translation of static text without a conversational interface is a different, lower-risk case.

What's the relationship between this rule and AI transparency in general?

This disclosure requirement is a specific, concrete instance of a broader push toward AI transparency in digital services across Europe. Healthcare providers should expect more transparency-related expectations to follow rather than treating this as an isolated one-time fix.

Can smaller clinics ignore this if they only have a basic chatbot?

Clinic size doesn't change the underlying obligation — if the tool is interactive and patient-facing, disclosure principles apply regardless of how simple or advanced the bot is. Smaller providers may just have a smaller, faster fix to implement.

How does this affect providers running chatbots in multiple European countries?

Providers operating across borders should plan for disclosure that's consistent in principle but localized in language and phrasing for each patient population. A single English-only disclosure line isn't adequate for a multi-country patient base.

What role does structured data and schema markup play here?

While schema markup itself isn't about chatbot disclosure, providers publishing patient-facing FAQ or symptom information should apply the same clarity standard to how that content is structured and presented, which is where choices like those covered in our JSON-LD vs Microdata comparison become relevant.

Should our AI disclosure be tested with patients who have low digital literacy?

Yes — testing disclosure with a range of patients, including those less comfortable with digital tools, helps ensure the message is actually understood rather than just technically present. This is especially relevant for healthcare given the broad range of patients providers serve.

What's the first step a provider should take this month?

Audit every patient-facing conversational tool currently live — chatbots, triage tools, scheduling assistants — and note which ones lack clear, persistent AI disclosure. That audit becomes the basis for a prioritized fix list.

Does adding disclosure slow down the patient experience?

Done well, disclosure adds a brief, clear label rather than an extra step the patient has to click through, so it shouldn't meaningfully slow the interaction. Poorly implemented disclosure — like a forced consent screen — can add friction that isn't strictly required.

How do we budget for this if we run several different patient-facing tools?

Scope each tool separately since a simple scheduling bot and a full clinical triage system have very different complexity, then map each against the pricing tiers — Essential for single-tool fixes, Growth for multi-tool rollouts with logging, and Enterprise for full audit-ready, multilingual implementations.

Will this requirement get stricter over time for healthcare specifically?

Based on how similar transparency rules have evolved in other regulated sectors, it's reasonable to expect healthcare-specific refinements — stricter language standards or mandatory escalation requirements — to follow. Building disclosure into your architecture properly now reduces the cost of adapting later.

Where should we start if we want expert help implementing this?

Start with an audit of your current patient-facing conversational tools, then bring in a technical partner experienced in healthcare-grade software to plan the disclosure, logging, and escalation rebuild. Our team works through exactly this kind of scoped Custom Software Development engagement for healthcare providers navigating new compliance requirements.