Define the healthcare workflow before choosing a model
Healthcare AI development starts with a specific task, its users, and the consequence of a wrong output. Drafting a note for clinician review, organizing administrative messages, and prioritizing an imaging worklist have different evidence and operating requirements. A successful demonstration does not establish that a system is ready to influence patient care.
This is an engineering planning guide for teams working with accountable clinical, privacy, security, and regulatory owners. It does not provide a diagnosis or claim a verified clinical result. Set the intended use and review responsibilities before collecting data, selecting a model, or promising a delivery date.
Write an intended-use and responsibility record
Describe who uses the system, which population and setting it covers, the inputs it receives, the output it produces, and the action that output may inform. Identify excluded uses. A documentation assistant that produces a draft for review should not quietly become a tool that autonomously recommends treatment.
Assign owners for clinical evaluation, data access, information security, integration, release approval, and incident response. Record the expected human review and what happens when evidence is missing or the model cannot produce a reliable output. Include a manual workflow that remains available if the service is paused.
Review this record when the product changes. New patient groups, new input types, a different action, or a changed degree of automation can require a new assessment. Keep the actual operating workflow aligned with the stated purpose rather than relying on a disclaimer that users do not see.
Distinguish workflow types and their evaluation needs
- Administrative support: assess routing accuracy, missing information, review effort, access boundaries, and handling of sensitive messages.
- Documentation assistance: assess omitted facts, invented statements, incorrect negation, attribution, and the time required for a clinician to correct a draft.
- Predictive or imaging support: define the clinical task, reference standard, operating threshold, population, setting, and consequences of false positives and false negatives.
Do not transfer a benchmark result between these categories. A model that performs well on an exam-style dataset may still produce incomplete notes or fail on local imaging equipment. Define the complete system boundary, including preprocessing, retrieved information, user interface, and clinician interaction.
Understand regulatory context without assuming a pathway
The FDA AI-enabled medical-device list identifies devices authorized for marketing in the United States and links public device records. The FDA notes that the list is not comprehensive. It is a reference for specific devices, not an endorsement of every AI application used in healthcare.
For a proposed product, have the responsible regulatory owner assess intended use and applicable jurisdiction. Do not infer a universal authorization pathway from the word AI or from the use of a familiar model. Preserve the assessment and its assumptions. Engineering milestones should reflect any required evidence and review rather than treating authorization as a final paperwork step.
The FDA's Good Machine Learning Practice overview points to the January 2025 IMDRF guiding principles and lifecycle considerations. Use current primary guidance with the relevant owners when planning development and change management. This guide does not claim TensorBlue regulatory certification or device authorization.
Map patient-data flows and access
Document where data originates, which systems receive it, which people and services can access it, and how it is retained or deleted. Include development datasets, annotation tools, model endpoints, logs, backups, support tickets, and evaluation exports. A protected production database does not protect a copied dataset on a developer workstation.
The HHS Security Rule overview describes administrative, physical, and technical safeguards for electronic protected health information maintained by covered entities or business associates. Apply the relevant requirements through the responsible organization's assessment and processes. Selecting a cloud product or enabling encryption alone does not establish complete compliance.
Use least-privilege access and approved data-handling procedures. Keep sensitive payloads out of ordinary application logs, and define controlled access when detailed traces are necessary for investigation. Record vendor responsibilities and applicable agreements. Test access revocation, backup recovery, and deletion behavior rather than relying only on architecture diagrams.
Prepare data with the clinical task in mind
Define the reference labels and who can resolve ambiguous examples. Preserve provenance, timestamps, units, and the context needed to interpret the input. A laboratory value without its unit or an old observation without its time may be misleading even when the data is syntactically valid.
Check missingness, duplicates, label consistency, and whether information available during training would actually be available at the decision time. Split datasets to avoid the same patient's closely related records leaking across training and evaluation. Consider site and time separation when the deployment will encounter new facilities or changing practices.
Review representation across clinically relevant groups and operating conditions. Record exclusions and sample sizes. A dataset's overall size does not establish that it covers rare conditions, different devices, or important patient groups. Data access and evaluation design should be reviewed before the team commits to a training plan.
Measure more than overall accuracy
Choose metrics with the clinical owner for the actual task. For a detection task, sensitivity and specificity at the selected threshold, predictive values, calibration, and error costs may all matter. Review uncertainty and subgroup or site results alongside aggregate performance. Compare with an appropriate baseline under the same conditions.
A hypothetical illustration shows why accuracy alone can mislead: in 1,000 examples containing 10 positive cases, a system that labels every example negative is correct on 990 examples, or 99%. It detects none of the positive cases, so sensitivity is 0%. This is arithmetic for understanding a metric, not a clinical study or a model benchmark.
For documentation, assess whether clinically important information is preserved and whether unsupported statements appear. Include human correction effort and disagreement handling. A fluent note is not evidence that it is complete or correct. Keep test examples separate from repeated prompt or model tuning.
Test the human workflow
Evaluate how users interpret outputs, inspect supporting information, correct mistakes, and escalate uncertainty. Make the system's role visible in the interface. A warning that is ignored or an alert queue that exceeds staff capacity can undermine a technically strong model.
Begin with a bounded evaluation that does not silently introduce new automated patient-care decisions. Define observation and stopping conditions with the clinical owner. Record overrides and investigate why they occur. Offline evaluation, usability testing, and monitored use answer different questions; no single stage replaces the others.
Integrate with the EHR through an explicit contract
The HL7 FHIR overview describes a standard for exchanging healthcare information, including resources, references, capability statements, and profiles. Agree on the version and implementation details supported by the actual EHR. Standards support does not guarantee that every resource, operation, or workflow is available.
Test patient and encounter identity, terminology mapping, units, timezones, provenance, authorization, and partial responses. Define idempotency and reconciliation for writes so retries cannot create duplicate records. Decide who approves a generated note before it enters the record and how corrections are attributed.
Use an approved test environment and representative fixtures. Exercise network failures, stale data, missing fields, and permission changes. Keep the clinical workflow usable when the integration is unavailable, and ensure recovery does not replay obsolete actions as if they were current.
Release, monitor, and control changes
Version model artifacts, preprocessing, prompts, retrieval configuration, dependencies, and integration contracts. Preserve the evaluation evidence and approval record for each release. Define a rollback target, compatible dependencies, and a manual fallback before launch.
Monitor service failures and data freshness separately from task quality. Some outcomes or reviewed labels arrive later than predictions; make that delay visible. Assign alert owners and document incident handling. Changes in input data, model providers, or clinical workflows should trigger an appropriate re-evaluation rather than an unreviewed automatic update.
Budget from evidence and dependencies
Estimate discovery, data preparation, annotation, evaluation, integration, security work, infrastructure, and ongoing review separately. Clinical evidence needs and institutional approvals can affect the schedule substantially. Use stage gates and explicit dependencies instead of a universal number of weeks or a guaranteed return.
Measure operational benefits such as review time or queue handling against a documented baseline. Distinguish released staff capacity from cash savings and keep patient-outcome claims separate from administrative improvements. Include ongoing model monitoring, corrections, vendor costs, and integration maintenance in the operating budget.
Healthcare AI delivery checklist
- Intended use, excluded uses, users, setting, and responsible owners are documented.
- Data access and vendor flows have an approved handling plan.
- Reference labels, held-out evaluation, meaningful metrics, and limitations are recorded.
- Human review, correction, escalation, and fallback workflows are tested.
- EHR contracts and failure/recovery paths are verified.
- Release approval, monitoring, change control, and incident ownership are in place.
For engineering context, explore our AI development guide, healthcare AI service, and application monitoring. Bring the intended workflow, available data, integration constraints, and required evaluation owners to an scoping discussion. The resulting plan should make clear what evidence is still required before deployment.