AI in Healthcare in 2026: Use Cases, Data Science & Risks

Quick answer: AI in healthcare uses predictive models, language systems, and other computational tools to support clinical and operational work. Data science provides the methods for deciding whether those tools are useful: preparing data, testing hypotheses, evaluating predictions, and measuring outcomes. A successful implementation needs both, plus a clearly defined workflow, appropriate human oversight, and evidence relevant to the people who will use it.

This guide connects healthcare AI applications with the data science and engineering required to make them reliable. It covers documentation, diagnostics, treatment support, research, remote monitoring, public health, and hospital operations, followed by a practical implementation framework for healthcare CTOs, product leaders, and engineering teams.

Evidence reviewed: September 20, 2026. Statistics below retain their actual observation periods. Research findings, vendor descriptions, and our recommended implementation practices are identified separately. This is an engineering and procurement guide, not medical advice or a product-specific legal assessment.

What is the relationship between AI and data science in healthcare?

Data science in healthcare combines statistics, programming, experimentation, and domain knowledge to answer questions using health-related data. Those questions may involve patient outcomes, demand for appointments, treatment response, research results, or the reliability of an existing model. Not every data science project needs artificial intelligence, and not every useful improvement requires a new model.

For this guide, distinguish the following four layers when defining a project. They describe different responsibilities, not competing technologies.

A hospital trying to reduce missed appointments might start with a basic scheduling analysis, then test a prediction model, and only later automate outreach. The model is not the entire intervention: the contact process, available appointment capacity, and patient response still determine whether the change helps. For a broader conceptual comparison, see data science versus artificial intelligence.

Healthcare AI in 2026: what the evidence actually measures

A useful adoption statistic identifies the technology, population, and year being measured. A hospital reporting an EHR risk score is not the same as a physician regularly using a generative AI assistant, and neither measure establishes improved clinical outcomes.

The hospital survey used responses from 2,253 nonfederal acute care hospitals in its 2024 sample. The AMA report was fielded in January–February 2026 and measures physician self-report. These sources answer different questions, so combining their percentages into one adoption trend would be misleading.

For additional background, see the healthcare AI statistics guide. For an implementation decision, prioritize evidence about the specific workflow, patient population, and deployment setting over a market-size forecast.

Eight applications of AI and data science in healthcare

The following applications preserve the distinction between a plausible use case and a demonstrated clinical benefit. Examples of software functionality are not recommendations to deploy a particular product without local evaluation.

1. Ambient clinical documentation and medical scribes

Ambient documentation systems turn a clinical conversation into a draft note for review. Current product examples include Microsoft Dragon Copilot and Abridge. Their public pages describe clinical documentation capabilities; those descriptions do not independently prove accuracy, return on investment, or suitability for a particular specialty.

The April 2026 JAMA study included 8,581 clinicians across five US academic health systems. Adoption was largely opt-in, and after-hours EHR time did not change significantly. Its observational design limits causal interpretation.

Implementation priorities: Define how recording is disclosed and consent obtained where required; restrict audio retention; identify speakers reliably; and present the draft beside its clinical context. Test omissions, medication errors, speaker confusion, and unsupported statements. Require the appropriate clinician to review the note before it becomes an approved part of the record.

2. Medical imaging, diagnostic support, and risk prediction

Medical imaging and other clinical software functions have product-specific regulatory pathways. The FDA’s AI-enabled medical-device list provides links to authorized devices and their regulatory records. It is not comprehensive and should not be treated as a count of every healthcare AI system, a utilization survey, or proof that all products have the same clinical evidence.

When evaluating a diagnostic tool, start with its intended use. Identify the supported modality, patient population, disease or finding, and role in the workflow. A system designed to prioritize an imaging worklist is not automatically authorized to make an independent diagnosis. A predictive score also needs evaluation at the threshold where people will actually act on it.

Implementation priorities: Request evidence relevant to the deployment site, including missed cases and false positives. Check whether acquisition devices, patient demographics, and clinical practice differ from the validation setting. Keep the output connected to an accountable response pathway rather than creating an alert nobody is responsible for reviewing. The FDA’s good machine learning practice overview places AI-device development in a whole-life-cycle context.

3. Precision medicine and treatment decision support

Precision medicine uses patient-specific information to inform treatment. In oncology, NCI explains how biomarker testing can help identify treatments associated with particular biological features. Such testing does not always identify an effective treatment, and precision medicine is not synonymous with AI: established laboratory tests and clinical interpretation also play essential roles.

For an AI-supported treatment workflow, define what the software is permitted to do. It might organize relevant records or surface evidence for a specialist, rather than autonomously select treatment. Do not describe a generated recommendation as clinically validated merely because it incorporates genomic data or resembles an expert’s explanation.

Implementation priorities: Preserve the source and date of each result, distinguish missing information from normal findings, and show the basis for recommendations. Assess how the workflow handles contraindications, conflicting results, and uncertain evidence. Clinical specialists should establish the action boundaries and validation requirements before the development team selects a model.

4. AI agents for administrative and care-coordination workflows

Agentic software can combine retrieval, document preparation, and API calls into a multi-step workflow. Consider an illustrative prior-authorization process: retrieve permitted records, identify missing documentation, draft a submission, request staff approval, and track the response. The useful capability is controlled coordination, not unrestricted autonomy.

For a healthcare implementation, we recommend explicit boundaries around actions affecting treatment, coverage, or the legal medical record. Separate preparation from approval; give tools narrowly scoped permissions; and ensure a failed retry cannot submit duplicate requests. WHO’s guidance on large multi-modal models in health provides a health-specific governance reference for assessing such systems.

Implementation priorities: Record which tool was called, which evidence was used, who approved the action, and whether the receiving system accepted it. Provide a manual fallback and an escalation route. Our agentic AI frameworks guide discusses orchestration approaches; framework selection does not replace workflow safety design.

5. Drug discovery and clinical-trial support

Drug discovery combines data-intensive questions: which biological targets merit investigation, which candidates to prioritize, and how to make experiment results comparable. Potential AI and data science work includes candidate ranking, experiment analysis, document extraction, and identifying records that may meet trial eligibility criteria. Each task needs its own evaluation rather than a single claim that AI makes drug development faster.

Keep candidate discovery separate from clinical development and approval. The National Cancer Institute’s explanation of clinical trials distinguishes phases that investigate safety, treatment activity, comparative performance, and longer-term outcomes. A shorter early research step does not establish that the full development process has been shortened by the same amount.

Implementation priorities: Version datasets and feature definitions, preserve experiment provenance, and make computational runs reproducible. Trial-support software should make its eligibility reasoning reviewable and leave enrollment decisions with the authorized research team. Use generative AI capabilities for well-defined tasks, not as a substitute for trial protocols or safety evaluation.

6. Remote patient monitoring and connected devices

Remote monitoring connects device readings with a clinical response process. An engineering team should distinguish the measurement device, the analytics applied to its output, and the staff responsible for responding. A wearable’s consumer feature is not automatically a validated medical measurement.

The FDA’s warning about glucose-measuring smartwatch and ring claims illustrates that distinction. Unsupported claims that a watch directly measures glucose should not be confused with displaying readings from an authorized glucose-monitoring device. Evaluate the specific product and intended use, not the category label “AI wearable.”

Implementation priorities: Test timestamp handling, missing readings, connection loss, and duplicate events. Establish what happens outside staffed hours and when a patient cannot be reached. Measure false alerts and response workload alongside predictive performance. On-device processing may suit some requirements, but deployment location alone does not establish safety or privacy compliance.

7. Public health and population analytics

Data science in healthcare also operates at population level. The CDC Center for Forecasting and Outbreak Analytics uses forecasting, modeling, and analytics to support preparation for and response to health threats. This is a distinct application from generating clinical notes or interpreting an individual patient’s scan.

For a population-health project, define the question precisely: expected service demand, geographic variation in access, or an emerging change in disease patterns. Then identify which groups are missing from the data and how reporting delays could affect the analysis. A forecast should support a decision with stated uncertainty, not imply certainty about an outbreak.

Implementation priorities: Track data revisions, represent uncertainty, and separate reporting changes from genuine changes in incidence. In care-gap analysis, investigate whether an apparent absence of care reflects missing records rather than a patient’s actual history.

8. Hospital operations, scheduling, and revenue-cycle analytics

Operational applications include analyzing appointment availability, forecasting resource demand, identifying inventory exceptions, and organizing claims-review work. They extend the data science article’s emphasis on scheduling and resource allocation while keeping financial and clinical outcomes distinct.

Start with a decision your organization can actually change. An appointment forecast has little practical value if nobody can adjust capacity or outreach. A claims classifier should prioritize human review rather than manufacture clinical justification. Even non-diagnostic automation can affect access to care and deserves scrutiny.

Implementation priorities: Compare the proposed approach with existing rules or simple statistical baselines. Measure completed work, correction rates, waiting times, and effects on different patient groups. Treat revenue recovery and staff time as separate outcomes, and do not count faster processing as a cash saving unless the organization can realize that saving.

The data foundation: what healthcare data science needs before modeling

For an implementation assessment, review the data path before selecting the model. The following checklist is our recommended starting point, not a claim that every project needs every data source.

Patient identity, provenance, and clinical meaning

Document where each field originates, how patient records are matched, and which system is authoritative. Check dates, units, coding conventions, and the difference between an absent observation and a documented negative finding. For text, retain the author, encounter context, and version where appropriate. For repeated measurements, define how corrections and late-arriving records are handled.

Use only the modalities necessary for the intended task. Combining notes, imaging, laboratory results, and wearable streams can add information, but it also introduces more integration and validation work. A well-scoped single-modality system may be the more appropriate first implementation.

Reliable labels, baselines, and evaluation splits

Have clinical or operational experts define what the target outcome means. For a prediction, use only information available at the moment the prediction would be made. A feature entered after an adverse event cannot legitimately help predict that earlier event. Keep repeated records from the same patient from crossing evaluation boundaries in ways that inflate performance.

Our recommended evaluation plan includes a simple baseline, a separately held-out test set, and checks across relevant sites, periods, and patient groups. Report uncertainty and data limitations. When performance depends on a decision threshold, assess both the benefit of finding a case and the workload created by incorrect alerts.

Purpose limitation and controlled access

Decide which data is necessary for the task, who can access it, how long it will be retained, and whether it can be reused for training. Include derived datasets, embeddings, logs, transcripts, and backups in that review. Technical transformation should not be mistaken for a legal permission to reuse health information.

For HIPAA de-identification, HHS describes Expert Determination and Safe Harbor as the two routes. Removing a patient’s name alone is not equivalent to meeting either route. Apply the relevant privacy assessment to the whole dataset and intended use, not just the most obvious identifier columns.

What do data scientists do in healthcare?

Data scientists connect the clinical or operational question with an evaluable analytical approach. Their contribution includes hypothesis design, data investigation, model development, experimentation, and interpretation. The role does not replace a clinician, a data engineer, or a regulatory lead.

For planning purposes, assign responsibilities explicitly. This suggested division avoids making one data scientist accountable for every aspect of a healthcare AI deployment.

In a small project, people may cover several roles. Keep the responsibilities visible nonetheless. A model cannot move into a clinical workflow merely because its developer considers its metrics satisfactory; the organization needs an agreed release decision and accountable owners.

A five-stage framework for healthcare AI implementation maturity

This is an editorial planning framework, not a validated maturity index or a survey of where healthcare organizations currently sit. It preserves the progression from isolated experiments to integrated operations without assigning unsupported adoption percentages or financial multipliers.

The final stage is not the goal for every organization or use case. A supervised diagnostic tool may appropriately remain constrained. Maturity means demonstrated control and usefulness, not the largest possible number of autonomous actions.

Healthcare AI architecture: connect the data, model, and workflow

Use the following reference approach as an engineering checklist. It is a suggested design pattern rather than a mandatory stack. The NIST AI Risk Management Framework offers a voluntary structure for organizing risk work; it does not certify an application or replace healthcare-specific requirements.

Interoperability without assuming FHIR solves everything

HL7 FHIR defines resources and exchange approaches for health information. Confirm the version, implementation guide, supported resources, authorization model, and write permissions exposed by the actual counterpart system. A standard interface still needs testing against local terminology, patient matching, units, and workflow behavior.

Do not infer that every healthcare AI integration is legally required to use FHIR. The applicable interface depends on the product, organization, exchange program, and contract. The FHIR security guidance also makes clear that interoperability and security are separate implementation concerns.

Separate read access, model execution, and write access

For a clinical assistant, we recommend separate permission boundaries for retrieving records, generating an output, and writing an approved change. Keep credentials outside prompts. Apply access checks to retrieval and tool calls, not just the user interface. An assistant should not gain broader access because an instruction appears in a retrieved document.

Specify provider-side retention and training permissions before sending sensitive data to a model service. Include tracing, error logs, and support access in the review. Test failure paths using representative but appropriately protected test data rather than casually copying production patient records into development tools.

Make review meaningful and failure recoverable

Place relevant source information beside the output so a reviewer can assess it. A generic approval button is insufficient when the reviewer cannot reconstruct the basis of a recommendation. For multi-step workflows, use durable state, duplicate-action protection, timeouts, bounded retries, and a documented manual fallback.

Retain enough information to investigate an incident: data version, model and prompt version, tool result, action, and responsible reviewer. Balance that requirement with access restrictions and retention limits; observability should not become an uncontrolled second copy of the patient record.

Keep models and data changes under control

Define when a new model, prompt, retrieval source, data mapping, or vendor release requires re-evaluation. Test the complete user workflow rather than the model in isolation. Monitor data quality, output quality, overrides, and unexpected downstream actions. Include a rollback procedure that restores a usable clinical or operational workflow.

Federated learning, local inference, and explainability tools are options to assess against a specific problem, not universal safeguards. Do not treat distributed training as proof that privacy risk has disappeared, or a plausible explanation as proof that a prediction is correct. WHO’s health AI governance guidance is a useful reference for examining these limitations.

Benefits and ROI: measure value without ignoring risk

The potential benefits of healthcare data science include better-supported decisions, earlier identification of cases requiring attention, reduced repetitive work, improved resource planning, and more reproducible research. Treat each as a hypothesis to test. Model accuracy alone does not demonstrate better patient outcomes or lower total cost.

For an operational business case, use a defined measurement period and compare realized incremental benefits with the full cost of implementation and operation. Our recommended calculation is:

ROI = (realized incremental benefit − total attributable cost) ÷ total attributable cost.

Distinguish cash savings, usable staff capacity, service quality, and clinical outcomes. Minutes released from documentation are not automatically payroll savings. Better care may justify an investment even when it does not produce a short-term financial return; present those outcomes separately rather than forcing them into an unsupported dollar estimate.

Include integration, licenses, inference, storage, clinician review, security work, evaluation, training, support, and incident handling in the cost model. Predefine success and stop criteria before the pilot. Where feasible, compare with a suitable concurrent control or staged rollout rather than crediting every before-and-after improvement to AI.

Healthcare AI regulation and privacy: US and EU considerations

The following is a scoped overview of official materials reviewed for this article, not a compliance checklist for every product. Intended use, deployment setting, organization type, jurisdiction, and contractual role determine which obligations apply. Obtain product-specific clinical, privacy, and regulatory review before deployment.

FDA: not every healthcare AI function is a medical device

The FDA’s January 2026 Clinical Decision Support Software guidance explains when certain CDS functions fall outside the device definition. The statutory exclusion has four criteria, including enabling a healthcare professional to independently review the basis of recommendations. Adding human review alone does not establish that an application meets all the criteria.

Assess the actual function and claims rather than calling all diagnostic support, risk scoring, or administrative software “SaMD.” For a regulated AI-enabled device, the FDA’s final PCCP guidance describes a route for specified, prospectively reviewed changes. A predetermined change control plan is not unrestricted permission to retrain or replace a model without assessing whether the change is covered.

HIPAA: contracts, safeguards, and permitted data use

HIPAA applies to covered entities and relevant business associates, not automatically to every consumer health application. For cloud services handling electronic protected health information, HHS explains the need for an appropriate business associate agreement and safeguards. A vendor’s willingness to sign a BAA is not, by itself, evidence that the entire application is compliant.

The same HHS guidance permits overseas cloud processing or storage when applicable requirements are met and calls for geographic risks to be assessed. HIPAA therefore does not create a general rule that patient data must remain inside its originating US state. Specific state laws, other obligations, and contractual restrictions still require separate review.

Keep proposed requirements distinct from enacted ones. The cited HIPAA Security Rule NPRM is a proposal, and HHS states on that page that the current rule remains in effect during its rulemaking. Do not use the proposal as evidence that new AI-specific de-identification rules or every proposed safeguard have already become binding.

Interoperability: HTI-1 and CMS have defined scopes

HTI-1 updates the health IT certification program, including transparency requirements for predictive algorithms within certified health IT. Its scope should not be rewritten as a universal requirement that every AI system accessing EHR data must use FHIR.

The CMS Interoperability and Prior Authorization Final Rule applies to specified payer categories. Its operational requirements generally began in 2026, while its API requirements generally apply from January 1, 2027, with details depending on the payer and provision. An API obligation is not authorization for an AI agent to make unrestricted clinical or coverage decisions.

GDPR: EU hosting is not automatic compliance

Under the GDPR, health data receives special-category protection. Determine an applicable legal basis and Article 9 condition, define controller and processor responsibilities, and assess whether a data protection impact assessment is required. International transfers, access, retention, and secondary uses need their own review. Hosting in the EU, using a European supplier, or pseudonymizing identifiers does not automatically satisfy these obligations.

EU AI Act: apply the correct classification and timeline

The European Commission’s current implementation page states that the AI Act became generally applicable on August 2, 2026, with exceptions. Following the AI Omnibus changes, it lists December 2, 2027 for specified Annex III high-risk use cases and August 2, 2028 for high-risk AI embedded in regulated products under Annex I.

Healthcare AI is not automatically one uniform high-risk category. Assess the product’s function, classification, and applicable transition provisions. The AI Act timeline does not suspend separate medical-device or data-protection obligations. Use the adopted legal text and current official guidance with your regulatory lead rather than treating August 2026 as one deadline for every healthcare AI system.

Build, buy, or partner for healthcare AI?

Choose an operating model after defining intended use, integration needs, and evidence requirements. The comparison below is an editorial procurement framework, not a forecast of universal prices or delivery times.

These approaches can be combined. An organization might purchase a documentation product while building an internal analytics layer or using external engineers to connect existing systems. Ask where data is processed, what evidence can be inspected, how changes are announced, and what happens when the contract ends.

Buying software does not eliminate your organization’s responsibilities, and hiring a development partner does not automatically make that partner the medical-device manufacturer or clinical decision-maker. Define the roles explicitly in the project and contracting process.

A practical path from idea to a controlled deployment

Use this six-step roadmap as a proposed implementation sequence. Progress should depend on evidence and approvals, not a generic promise that every healthcare AI project can reach production in a fixed number of weeks.

1. Define one decision and its boundaries

Identify the user, task, intended population, and system of record. Specify whether the output is a draft, a prediction, a recommendation, or an action. List prohibited actions, foreseeable harm, and the person accountable for accepting the workflow.

2. Check data access and feasibility

Inventory data sources and permitted uses. Inspect a representative sample, document missingness, and verify that the intended signal is available when needed. Decide whether the priority is data preparation, an analytical baseline, a purchased capability, or a new model.

3. Establish the evidence and regulatory plan

Agree on success metrics, balancing measures, evaluation populations, and failure thresholds. Determine the applicable privacy and product requirements. Plan the clinical or operational review before code and vendor choices make the workflow difficult to change.

4. Evaluate offline and test the integration safely

Compare performance with the baseline and examine errors with domain experts. Where appropriate and authorized, test prospectively in a silent mode that does not influence care. Exercise interface failures, access controls, and rollback procedures before broad user access.

5. Run a supervised pilot

Train a bounded user group and provide a direct route for reporting problems. Measure review burden, work completed, user corrections, and unintended effects. Restrict changes during the measurement period so results can be interpreted.

6. Scale only with an operating plan

Expand after agreed acceptance criteria are met. Assign monitoring, incident response, retraining or update review, and support ownership. Reassess performance when moving to a new site, population, device, or workflow rather than assuming the first pilot generalizes.

Common failure modes to address before launch

Confusing prediction with benefit. A higher model score does not show that a clinical intervention helped. Tie evaluation to the action taken and the outcome that matters.

Ignoring unequal data coverage. Test relevant patient groups and investigate differences. A single overall accuracy value can hide a subgroup for which the workflow is unsuitable.

Treating generated text as verified evidence. Provide source context and evaluate unsupported statements. Retrieval helps supply context but is not a guarantee that a generated answer is correct.

Allowing ungoverned tool use. Give staff a clear policy and an approved route for useful tools. Review recording, retention, training use, and access before patient information enters an external service.

Underfunding integration and maintenance. Reserve time for data mappings, user training, clinical review, software updates, and incident handling. A successful demonstration is only one part of an operating system.

Automating a workflow that cannot absorb the output. Before creating more alerts, drafts, or referrals, confirm who will process them. More output is not necessarily better care or more efficient work.

How Uvik Software can support healthcare data and AI projects

Uvik Software offers data science consulting for use-case assessment, modeling, experimentation, and evaluation. Its published service scope includes feasibility reviews, embedded consulting, prototypes, and review of existing models. For language-model workflows, generative AI consulting is a related starting point.

A relevant first-party example is the published drug-discovery experiment pipeline case study for Recursion. Uvik Software describes work on orchestration, feature definitions, and training-data delivery. This is an engineering case study, not evidence that a therapy became safer, more effective, or approved because of the implementation.

When discussing a healthcare engagement, define the clinical owner, data-access constraints, evaluation responsibilities, required contractual arrangements, and handover expectations. Review comparable case studies and pricing information, then request a scope appropriate to the actual system. A development service description should not be interpreted as blanket HIPAA certification or regulatory approval for the resulting product.

Discuss your healthcare data science or AI implementation with Uvik Software.

Conclusion

AI and data science in healthcare are most useful when they answer a specific clinical, research, or operational question and fit an accountable workflow. Data science establishes what can be learned from the data; engineering makes the capability usable; clinical and governance teams determine whether it is appropriate to deploy.

Start with the decision and the evidence required to support it. Build reliable data flows, test the complete workflow, and preserve the ability to review, correct, and stop the system. The goal is not maximum automation. It is a measurable improvement that the organization can operate responsibly.

Sources and evidence notes

Primary research, official guidance, and technical standards support the factual updates in this guide. Product pages describe vendor capabilities only. Implementation tables and checklists are editorial recommendations, not measured industry rankings or regulatory certification criteria.

1. ONC: Hospital Trends in the Use, Evaluation, and Governance of Predictive AI, 2023–2024. Government survey; published 2025; observation years 2023–2024.
2. American Medical Association: Physician AI Sentiment Report, 2026. Original survey; fieldwork January 15–February 2, 2026; adoption chart on printed page 5.
3. Rotenstein et al.: Changes in Clinician Time Expenditure and Visit Quantity With Adoption of Artificial Intelligence–Powered Scribes. JAMA, published April 1, 2026; DOI: 10.1001/jama.2026.2253.
4. FDA: Artificial Intelligence-Enabled Medical Devices. Official, periodically updated list; not a comprehensive inventory of all AI-enabled devices.
5. Microsoft: Dragon Copilot. First-party product description; not an independent clinical evaluation.
6. Abridge: Clinical AI documentation platform. First-party product description; not an independent clinical evaluation.
7. National Cancer Institute: Biomarker Testing for Cancer Treatment. Clinical explanation of biomarker-guided treatment and its limitations.
8. National Cancer Institute: How Do Clinical Trials Work?. Clinical-trial phases, eligibility, and evaluation; updated November 8, 2024.
9. FDA: Safety Communication on Smartwatches and Smart Rings Claiming to Measure Blood Glucose. Distinguishes unsupported noninvasive measurement claims from authorized glucose-monitoring devices.
10. CDC: About the Center for Forecasting and Outbreak Analytics. Public-health forecasting and outbreak analytics.
11. FDA: Good Machine Learning Practice for Medical Device Development. Overview linking the January 2025 IMDRF principles for the medical-device life cycle.
12. WHO: Ethics and Governance of Artificial Intelligence for Health—Guidance on Large Multi-Modal Models. 2024 health-specific governance guidance; not a product authorization.
13. NIST: AI Risk Management Framework. Voluntary risk-management framework; not a certification or substitute for applicable law.
14. HL7: FHIR Overview. Technical interoperability specification.
15. HL7: FHIR Security and Privacy. Security considerations for implementers.
16. FDA: Clinical Decision Support Software. Final guidance, January 2026.
17. FDA: Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions. Final guidance, August 2025.
18. HHS: Guidance on HIPAA and Cloud Computing. Business-associate responsibilities and geographically distributed cloud processing.
19. HHS: Guidance Regarding Methods for De-identification of Protected Health Information. Expert Determination and Safe Harbor.
20. HHS: HIPAA Security Rule Notice of Proposed Rulemaking. Proposal announced December 27, 2024; the cited document is not a final rule.
21. ONC: HTI-1 Final Rule. Certification, algorithm transparency, and information-sharing requirements.
22. CMS: Interoperability and Prior Authorization Final Rule, CMS-0057-F. Scope-specific operational and API implementation dates.
23. European Union: General Data Protection Regulation. Regulation (EU) 2016/679; in particular Articles 6, 9, 28, 35, and Chapter V.
24. European Commission: AI Act—Current Implementation Timeline. Commission page updated August 3, 2026; consulted September 20, 2026.