Buying AI software development for healthcare

Imagine a referral team receives requests through an approved hospital integration. Staff need to see which referral is waiting for documents, contact the sending unit and record that the administrative task is complete. The new queue displays existing status and routing information. It does not diagnose, recommend treatment, calculate clinical priority or decide whether a patient receives care.

That boundary belongs in the specification, permissions and interface. A generated suggestion that appears to rank patients can change how the tool is used even when the original request said “administration.” The clinical owner reviews the intended use, foreseeable use and any proposed change in decision support. Do not infer a regulatory classification from the word administrative.

Use the current MDCG software qualification and classification guidance with a competent regulatory specialist where device questions arise. The guidance is a reference for their assessment, not a Taiga qualification decision. Any diagnostic, treatment or prioritization feature needs its own approved scope and appropriate evaluation before a buying guide’s example can be extended to it.

Define the approved integration, status meanings, source of truth and responsible staff group. Specify what the queue shows when its upstream system is unavailable, a message arrives twice, a referral changes department or a user’s access is revoked. An interface that keeps showing old information without a visible stale state can create an operational hazard.

For a new project, Taiga prepares the required setup document set for review and publication. For an existing application, import can derive code-cited reality documents and findings. In either case, the clinical service owner checks the workflow against actual practice. A generated user flow and DPIA structure organize review; they are not a clinical validation or an approved privacy assessment.

Start with synthetic referrals. Acceptance cases should cover cross-patient and cross-unit access, duplicate integration messages, incomplete records, referral reassignment, cancellation, local time changes and a disconnected upstream system. Have the integration owner verify the expected behavior independently of the generated tests. Include accessible keyboard use and a clear distinction between administrative status and clinical advice.

Review the initiative plan, implementation, repository checks and pull request. Release through the configured pipeline and verify the running version against the approved interface contract. Exercise the downtime procedure with the service team: how work continues, where outstanding tasks are recorded and how they are reconciled when the queue returns. A browser availability signal does not test that whole process.

The healthcare provider’s clinical owner defines permitted use, workflow safety and the circumstances in which staff must use another route. The privacy lead determines the purposes, legal basis, access rules and assessments required for patient data. A competent regulatory specialist evaluates device-related questions. Taiga’s generated documents do not transfer these judgments.

Engineering reviewers assess integration behavior, authorization, test coverage and generated output before production use. The named runtime operator handles deployment, observability, recovery and incident escalation under the agreed hosting arrangement. Taiga operates the platform and supplies the documented workflow and contracted service. Spell out any additional operational work instead of inferring it from the word Operate.

For the referral queue, name who detects a missing message, who confirms whether the referral reached the receiving team, who contacts clinical staff when the queue is unavailable, who may inspect patient records during support and who authorizes a release. An engineer should not need unrestricted patient-data access to investigate every interface failure.

Taiga’s published platform terms locate the managed platform on AWS in Frankfurt and model inference through Amazon Bedrock in EU regions. That describes the platform, not every system it helps build. The application’s database, backups, logs, integrations and support access need their own approved data-flow record. An EU platform region does not decide whether a particular upload or deployment is permitted.

Before connecting a repository, identify which files the service may read and remove credentials and data extracts that do not belong in development. Start the example with synthetic records. Decide what may enter project documents, conversations, source code, test fixtures and browser telemetry. A pseudonymous identifier can still be personal data; removing a name is not the whole assessment.

Review the current subprocessor list and data processing agreement alongside the platform privacy statement. Ask about access, retention, export, deletion and changes to processing locations for the agreed scope. Confirm the customer runtime separately: who holds the cloud account, who can read production data, where backups land and who answers an incident at night.

The EDPB identifies health data as a special category of personal data under GDPR Article 9. Your privacy team must determine the applicable conditions and safeguards for the actual processing, including relevant national rules. A referral status or identifier can reveal health information even when a diagnosis is absent. Do not upload a production extract merely because the development environment is in the EU.

Request the data processing agreement, subprocessor list, processing and support-access locations, retention and deletion arrangements, incident terms and available security assurance. Map project documents, source repository, test fixtures, application database, operational logs and browser signals as separate destinations. Decide which must contain no patient details and verify the implemented behavior.

Keep a reviewed intended-use statement, workflow and data-flow records, access tests, integration contract tests, failure cases, approvals, release record and downtime runbook. Use the evidence hub to distinguish Taiga’s public research and reference implementation from customer or clinical proof. The one-spec/six-systems study found outputs that were unsafe to deploy despite passing tests; its lesson is the need for independent review, not a healthcare performance claim.

Taiga’s capability reference documents new-project setup, codebase import, queued initiatives, maintenance findings, deployment records and configured monitoring. A setup document can structure the questions; it does not prove that the answers are correct. Repository findings and policy assessments cover their implemented scope. A passing scan is not a certificate, and an unconfigured signal is not a healthy system.

The published vendor comparison states Taiga’s current assurance and identity limitations, including no third-party penetration test and no SAML or SCIM provisioning. Microsoft Entra ID federation is documented, with an owner recovery exception to required SSO. Compare those specifics with your mandatory procurement requirements before enabling Taiga. Do not substitute a roadmap promise for evidence your policy requires now.

Taiga mirrors connected GitHub deployment records; the configured pipeline performs deployment and environment approvals. Its URL checks need configuration and browser signals need the beacon. Those capabilities do not establish a managed on-call service, full infrastructure observability or autonomous rollback. Agree those operating duties explicitly.

Bring one bounded workflow, an accountable business owner, an engineering reviewer and the applicable policies. Identify the repository or new-project scope, permitted data, required identity controls, deployment environments and the named production operator. Decide who can publish documents, approve plans, review pull requests and authorize releases before work begins.

Use the first review to examine a real change from intent to published documents, plan, pull request, checks and release record. Include a failed acceptance case and show how the work is corrected and checked again. The buying decision should turn on evidence your team can inspect, the responsibilities it can staff and the contract it can accept.

The signed Order Form defines service scope and hosting responsibilities. Compare the published pricing with the internal review, integration, testing and operating work you retain. Record the exit plan as part of the purchase: how your team obtains the repository and documents, removes vendor access and continues maintaining the service.