Healthcare SaaS: a grounded, permission-aware AI assistant and its connector layer

What the work involved

The assistant was only as good as what it could read, and what it was allowed to read. It was built on Amazon Q Business as a grounded knowledge engine for the company’s engineering, QA, product, and support teams, indexing six enterprise sources. Two of those, Confluence and SharePoint, used native connectors. The harder sources needed custom ones, and that was our work, along with everything required to carry the assistant into the tools people already used and to keep the whole thing within the constraints a healthcare company operates under.

The grounded knowledge layer and its connectors

The native connectors covered documentation and knowledge-base content. The system that mattered most to engineers was Azure DevOps, where specs, work items, and history all lived, and that needed a custom ingestion connector. We built it as the base the client’s team would tune to their environment.

The connector pulled work items and repository content into the index on an incremental schedule, but the substance was in three places that are easy to underestimate. Access mapping: ADO security groups had to resolve to the company’s identity provider so that document-level permissions survived ingestion intact. Scrubbing: ADO work items and code comments are full of connection strings, tokens, and stray secrets, so the ingestion path redacted those patterns before anything reached the index, rather than trusting a downstream filter to catch them. Operability: scheduled incremental syncs, monitoring, and alerting, so the client’s team could see the pipeline running and know when it didn’t. We delivered the same base-connector treatment for the team’s test-management system, so test cases and results became searchable alongside everything else.

Carrying the assistant into the tools people already use

Adoption depended on reaching people where they already worked. This company lived in Microsoft 365 and in their IDEs, so the assistant had to be available there rather than in a separate web app.

That bridge went through several versions before it settled. It started as middleware connecting Copilot Studio to Amazon Q Business, then became a live Microsoft 365 Copilot to Q Business connector, and finally was rebuilt as a standards-based MCP (Model Context Protocol) server. The MCP step was the one that paid off: instead of a point-to-point integration tied to one tool, it exposed the grounded knowledge layer to any MCP-compatible client. An engineer could now ask their coding assistant (GitHub Copilot in Visual Studio, or Claude Code in VS Code) to look up a work item or the constraints on a module, and get an answer drawn from the indexed documentation, work items, and test cases, with citations back to the source, all under the same identity and access model as the web assistant. We shipped configuration guides for each editor, so the client could roll it out on their own.

Permissions and grounding were the hard part

Two properties were non-negotiable, and both required overriding the default behavior of a general-purpose model.

Grounding came first. In a clinical, regulated domain the assistant could not be allowed to improvise, so it was configured to answer only from indexed content, with no direct-to-model queries and no fallback to the model’s own knowledge, hallucination mitigation turned on, and a citation required for every claim. If the answer was not in the indexed sources, the assistant said so.

Permissions were enforced end to end. Every connector crawled access-control data as a hard requirement, and the custom connectors mapped each source’s native permissions onto the company’s identity groups, so that filtering happened at the document level. The test we held it to was simple: two people with different group memberships ask the same question and get different, correct result sets.

Access had to be respected end to end: the assistant could only reflect what the person asking was already entitled to see, and only say what the sources actually supported.

On top of that sat topic guardrails for the things a healthcare assistant must never leak: protected health information, credentials, and informal notes standing in for approved release process. The connector-level scrubbing and the guardrails were deliberately redundant, a defense in depth on the assumption that one layer will eventually miss something.

Setup the client’s own team could run

The client’s team had to be able to operate the connector layer themselves, so the documentation was as much the deliverable as the code. Alongside it we wrote the implementation playbook the client’s engineering, DevOps, and IT teams worked from to stand the system up, phase by phase, at their own pace.

That meant documenting the unglamorous prerequisites that decide whether any of this works: the network and identity foundations, identity-provider federation and group sync, service accounts and secret storage done properly rather than with personal tokens, the scoping decisions that keep the index useful rather than bloated, the connector configuration and access mapping, the guardrail and relevance settings, and a validation pass to confirm permissions actually held. The editor-side MCP setup guides and the identity app-registration changes IT needed to make were part of the same package. The goal throughout was that the client could deploy, verify, and extend without us.

The Power Platform release-cargo cleanup flow

Separately, we built an automation for a recurring operational drag around releases. Work items were supposed to be tagged with the release they shipped in, but the tagging drifted: every release left a couple of dozen items mis-tagged, and someone had to chase them down by hand before the release-night work could close out.

We built it as a deterministic Power Platform automation in the client’s Microsoft 365 tenant: Copilot Studio agent flows with no model in the loop, since the task is rule-based and needed the same predictable result every time. A scheduled worker flow (also runnable on demand) queried Azure DevOps for the mis-tagged items, grouped them by the responsible scrum master, sent each one a targeted reminder in Microsoft Teams, and logged every run to a SharePoint list for an audit trail. A second flow sent a consolidated deadline summary later in the day. It used only native Power Platform connectors (Excel Online, Azure DevOps, Microsoft Teams, SharePoint) with read-only access to the work-item system, so it could clean up a release without being able to change one. We co-built it with the internal owner and handed it over as theirs.

How it ran

We worked inside the delivery team, against the client’s real systems and their real access model. That kept the integration honest: identity mapping, scrubbing, and permission filtering all had to hold up against production data and live permissions.

The handover

When the connectors were live and feeding the assistant, the editor integrations were configured, and the cleanup flow was running, the work was tech-transferred to the client’s engineers as base connectors, configuration, runbooks, and playbooks they own. It is in production, and the client’s team extends it from here.