Key Takeaways:

• FDA authorized the first robot that draws blood without hands-on help. Vitestro’s Aletta received De Novo authorization on August 19, 2026, for adults in outpatient settings under the oversight of a trained phlebotomist, who can supervise up to three devices at once.
• The success rate has a denominator. Aletta succeeded on the first stick 94.5% of the time when it found a suitable vein, but it declined about 6% of patients in its trial, and counting them, overall collection success was 88.5%. Knowing when not to act is part of what made it authorizable.
• Most of the software opportunity sits around the robot. Supervisor apps, EHR and lab integrations, and operations tools all matter, and software that controls the robot, raises alarms, or prioritizes alerts across devices is regulated device software, so draw that line before you design.

On August 19, 2026, FDA authorized the Aletta, a robot from Dutch company Vitestro and the first standalone device that can draw blood from a patient’s arm without hands-on operator intervention. It finds a vein with near-infrared light and Doppler ultrasound, then handles the rest of the procedure itself, from applying the tourniquet to placing the bandage, while a trained phlebotomist starts each session and stays available to step in.

For healthcare app developers, the authorization marks a shift. Autonomous software in medicine has mostly interpreted data and supported decisions, and Aletta performs a physical procedure on a patient. It also shows how FDA approaches that kind of autonomy: a narrow intended use, human supervision, layered safety controls, and clinical evidence that accounts for the cases where the device declines to act.

This guide covers what FDA authorized, what the clinical evidence shows, how autonomous phlebotomy software works, the regulatory path for clinical robotics, where app developers fit, and the integration, HIPAA, workflow, and cost questions hospitals and builders will face.

What FDA Authorized, and What It Didn’t

FDA granted Vitestro marketing authorization through the De Novo pathway, which covers low- to moderate-risk devices of a new type with no legally marketed predicate. Along with the authorization, FDA established special controls covering labeling, performance testing, and clinical testing. That creates a new device classification, so the next company to build a comparable robot can pursue a 510(k) with Aletta as its predicate.

The authorization is deliberately narrow. According to FDA’s announcement, Aletta is authorized for adults in outpatient settings under the oversight of a supervisor trained in phlebotomy, and it isn’t authorized for blood donation. The device guides the patient to position their arm, the patient or supervisor presses a button to start, and Aletta then locates a vein, distinguishes it from arteries, applies a tourniquet, prepares the skin, inserts and disposes of the needle, changes collection tubes, and places a bandage. The phlebotomist initiates each session, stays available to respond to issues, and verifies that the tubes are properly filled. One phlebotomist can oversee up to three devices simultaneously.

Safety is layered. If the patient moves too much, the needle automatically detaches and the draw stops, and onboard sensors can pause the procedure and alert the supervisor when they detect other unsafe conditions. Aletta was already CE-marked in Europe, where hospitals have used it since late 2024.

Read the Denominator: What the Clinical Evidence Shows

FDA based its decision on clinical data showing that Aletta’s successful blood draw rates were comparable to or better than those of trained phlebotomists when it proceeded with a needle stick, and that device-related adverse events were uncommon and mild. The published evidence comes from the ADOPT trial, reported in Clinical Chemistry in April 2026, which enrolled 1,633 patients across three outpatient phlebotomy departments in the Netherlands.

When Aletta identified a suitable vein, it succeeded on the first stick 94.5% of the time, including 97.4% for patients with a body mass index above 30, 92.7% for patients who reported difficult venous access, and 93.4% for patients over 65. Hemolysis, the red blood cell damage that can invalidate a sample, occurred in 0.3% of samples. Afterward, 82% of patients said they’d prefer the robot next time or had no preference, and in a separate simulated-use study at Mayo Clinic, where the device scanned for veins but didn’t insert a needle, 86% of patients said they’d be willing to use it.

The phrase “when Aletta identified a suitable vein” carries a lot of weight. According to an Epocrates summary of the study, the device found no suitable vein in 110 of 1,743 screened patients, about 6%, and sent them to a phlebotomist. Counting those patients, overall collection success was 88.5%. The trial was single-arm and industry-funded, it compared Aletta with published success rates for trained U.S. phlebotomists (93% to 97%) rather than with phlebotomists working alongside it, and Vitestro employees or equity holders were among its authors. The clinical data FDA reviewed hasn’t been published yet.

That pattern is instructive. The device declines when conditions fall outside what it can handle and hands the patient to a person, which is what responsible autonomy looks like. For software teams, it means reporting coverage alongside accuracy and treating the handoff path as a core feature.

How Autonomous Blood Collection Software Works

Vitestro describes Aletta as combining multimodal imaging with advanced control, and it hasn’t published its internals. Any system like it, though, depends on layers that work together.

Perception turns sensor data into a target. Near-infrared light shows veins near the skin’s surface, and Doppler ultrasound measures blood flow beneath it, which helps tell a vein from an artery. The software has to find a vein that’s large enough, deep enough, and stable enough to use, across patients who differ in skin tone, body mass, age, hydration, and vein history.

Control turns the target into motion: positioning, tourniquet pressure, needle trajectory and depth, tube changes, and withdrawal. Every step needs closed-loop feedback, because the target moves when the patient does.

Safety monitoring runs alongside both, independent of the logic it watches. It checks sensor inputs against defined limits for patient movement, needle position, and blood flow, and it owns the safe states: detaching the needle, pausing the procedure, and alerting the supervisor. A safety layer that keeps working when the others fail is what makes autonomy acceptable to a regulator at all.

Researchers describe robot autonomy on a six-level scale, from no autonomy to full autonomy, proposed in Science Robotics in 2017 and modeled on the levels used for self-driving cars. Most cleared surgical robots work at the low end, extending a surgeon’s own movements in real time. Aletta performs an entire routine procedure while a person supervises. The research frontier is moving further: in 2025, a Johns Hopkins robot autonomously performed one phase of a gallbladder removal on eight specimens in the lab. Supervised autonomy on bounded, repeatable procedures is likely to reach the market well before anything more open-ended.

The Regulatory Path for Clinical Robotics Software

Robotic medical devices reach the U.S. market through the same pathways as other devices. A 510(k) shows substantial equivalence to a legally marketed predicate, De Novo classifies a novel low- to moderate-risk device, and premarket approval covers high-risk devices. FDA’s fiscal 2027 user fee for a De Novo request is $191,020, or $47,755 for a qualifying small business, and a Pre-Submission meeting to get FDA feedback before filing carries no fee.

The software documentation follows FDA’s 2023 guidance on premarket submissions for device software functions. Its Enhanced documentation level applies when a software failure could present a probable risk of death or serious injury before risk controls are counted, which is likely for software that guides a needle into a patient. Expect to provide a software description, a risk management file built on ISO 14971, a requirements specification with traceability, an architecture diagram, a design specification, unit, integration, and system test documentation, and a list of unresolved anomalies.

Robotics also raises the stakes on human factors and cybersecurity.

• Human factors. Usability engineering has to show that intended users can operate the device safely. For supervised autonomy, that means testing how a phlebotomist monitors three robots, reads alerts, and intervenes under realistic workloads.
• Cybersecurity. A robot that connects to a hospital network or the internet can meet the cyber device definition in section 524B of the FD&C Act, which requires a vulnerability management plan, security processes, and a software bill of materials, as detailed in FDA’s cybersecurity guidance reissued in February 2026.

If perception relies on machine learning, FDA’s software guidance already asks how the model was built, what data trained it, and how bias was addressed. Since February 2, 2026, the Quality Management System Regulation has incorporated ISO 13485 by reference, and IEC 62304 remains the recognized standard for software life cycle processes.

Changes after authorization need planning too. A software change that could significantly affect safety or effectiveness generally needs a new 510(k), and a predetermined change control plan, authorized with the original submission, lets a manufacturer make specified future changes without one.

Where App Developers Fit: Device or Not

Most app developers won’t build the robot. They’ll build the software around it, and the regulatory status of that software depends on what it does.

Software function	Likely status	Why
Vein detection, motion control, safety monitoring	Part of the device	It drives the procedure, so it sits inside the manufacturer’s authorization
A supervisor app that starts or stops robots	Device software	It controls a medical device
A supervisor app that raises or prioritizes alerts across several robots	Device software	FDA treats alarms and multi-patient prioritization as analysis of device data
A dashboard that only displays device status and results	Possibly not a device	Software that solely transfers, stores, converts, or displays device data is excluded
Scheduling, queueing, check-in, and staffing tools	Generally not a device	Administrative functions are excluded
EHR and lab system integration that moves orders and results	Generally not a device	Data transfer, as long as it doesn’t modify or interpret the data

The display exclusion is narrower than it looks. Under section 520(o)(1)(D), FDA excludes software that solely transfers, stores, converts formats, or displays device data, but only if it doesn’t modify the data or control the device. Software that generates alarms or alerts, or prioritizes information on multi-patient displays, counts as a device function. A supervisor app for one phlebotomist watching three robots can cross that line quickly, so decide early whether each feature belongs in the manufacturer’s regulated system or in a non-device companion app.

Intended use and marketing claims decide the answer. When the line is unclear, a 513(g) request gets FDA’s classification view for a fiscal 2027 fee of $8,596, or $4,298 for a small business. Dogtown’s guide to software as a medical device covers the classification questions in more depth.

What One Supervised Draw Looks Like in Software

Here’s how the pieces might interact during a single hypothetical draw, and where the device boundary falls.

Step	Robot (regulated device)	Software around it	Likely status of that software
Check-in	Idle	A kiosk or front desk app confirms the appointment and queues the patient	Not a device
Identification	Waits for a verified patient	The supervisor scans the wristband, and the app pulls the open lab order from the LIS	Not a device
Start	Guides arm positioning and starts on the button press	Shows the session as in progress on the supervisor’s screen	Display only, likely not a device
Draw	Locates the vein, inserts the needle, fills tubes, monitors safety	Shows status and any alert the robot raises	Relaying and prioritizing alerts across robots is device software
Exception	Pauses or detaches the needle and alerts	Escalates to the supervisor, who decides whether to resume or hand off	Escalation logic is device software
Labeling	Completes the draw and places a bandage	Prints and verifies tube labels against the order	Likely not a device, but safety-critical
Results	Logs the procedure	Sends collection details to the LIS, which results the specimen	Not a device

The table shows why architecture decisions come first. Put alert prioritization in a companion app and that app becomes regulated. Keep it inside the manufacturer’s system, and the companion app can stay a non-device tool that handles identity, labels, and logistics.

Technical Integration Points for Robotics-Enabled Apps

A robot that draws blood has to fit the systems that order, label, track, and result the specimen, and hospitals will ask about each connection.

Orders and results. Lab orders and results still flow mostly through HL7 version 2 messages between the EHR and the laboratory information system, with FHIR resources such as ServiceRequest, Specimen, and Observation increasingly available. A robotics workflow has to pull the right order for the right patient, record collection details such as time and tubes drawn, and hand results back through the lab’s normal path. Where a hospital’s systems don’t support FHIR, an interface engine or FHIR facade can translate.

Patient identification and labeling. The Joint Commission’s patient safety goals call for at least two patient identifiers when collecting blood samples and for labeling specimen containers in the patient’s presence, the main defenses against wrong-blood-in-tube errors. Automating the draw doesn’t remove those steps. The workflow has to confirm identity, typically by scanning a wristband, and tie each labeled tube to the right order, with the supervising phlebotomist verifying the tubes as FDA’s authorization describes.

Device data. Real-time device interoperability has a new standards effort behind it. HL7 launched the Caliper FHIR Accelerator on March 5, 2026, an implementation community focused on exchanging data from medical and personal health devices. It builds on the joint HL7 and IHE Gemini Device Interoperability Program and aligns with IEEE, ISO, and IEC device standards.

Imaging data. The ultrasound and near-infrared images a robot uses for guidance may not belong in the medical record at all. Decide deliberately whether to retain them for quality review or troubleshooting. If you do, store them with consistent metadata, link them to the encounter, set a retention period, and use DICOM if they’ll live alongside other clinical images.

Network. Hospitals commonly isolate medical devices on segmented networks and restrict which systems they can reach. Document every connection the robot and its companion apps need, including any remote service access, and expect the hospital’s security team to review them. Dogtown’s guide to EHR integration covers the integration patterns in more depth.

HIPAA: Who Owns Which Obligations

HIPAA applies to covered entities, such as hospitals and labs, and to business associates that handle protected health information on their behalf. A robot manufacturer isn’t automatically either. It becomes a business associate when it creates, receives, maintains, or transmits PHI for the hospital, for example through a cloud dashboard, stored procedure records, or remote service that can see patient data. HHS’s cloud guidance treats a cloud provider holding ePHI as a business associate even when the data is encrypted and the provider has no key, so cloud-connected robotics platforms should expect to sign BAAs.

Lists of HIPAA “requirements” in vendor marketing often blur law and good practice. The Security Rule requires a risk analysis but sets no annual schedule for it. It requires a contingency plan with a data backup plan, a disaster recovery plan, and an emergency mode operation plan, but no specific failover architecture. Workforce clearance procedures, which might include background checks, are addressable. Separating database servers from web servers and running monthly security reviews can be sound practice, but HIPAA doesn’t mandate them.

On the technical side, the Security Rule requires unique user identification, audit controls that record activity in systems containing ePHI, access controls, integrity protections, and transmission security. Encryption is an addressable specification today. HHS proposed making it mandatory in January 2025, along with annual risk analyses and network segmentation, but as of mid-2026 the rule remained a proposal. Encrypt anyway, since PHI encrypted to HHS’s standards isn’t “unsecured,” so a lost device or stolen dataset doesn’t trigger breach notification.

For a robotics platform, the practical work is minimizing PHI. Keep patient identifiers off the robot where you can, decide how long procedure images and logs live, control who can access the device remotely and log every session, and give the hospital what it needs for its own risk analysis. Dogtown’s HIPAA-compliant app development work builds these controls into the architecture.

Workflow, Human Factors, and Adoption

One phlebotomist supervising three robots is the operational core of Aletta’s value, and it puts the supervision interface on the critical path. That person needs to see every device’s status at a glance, know which alert matters most, intervene quickly, and confirm that every tube is correctly filled and labeled. Design that experience with phlebotomists, test it under realistic workloads and interruptions, and treat it as safety-critical.

Alarm design deserves its own attention. The Joint Commission made clinical alarm safety a national patient safety goal after years of reports on alarm fatigue, and IEC 60601-1-8 sets requirements for alarm systems in medical electrical equipment. A supervision app for three robots should rank alerts by urgency, make the most urgent one impossible to miss, require acknowledgement, escalate when an alert goes unanswered, and show what each robot is doing at a glance. It also has to handle the ordinary disruptions of a phlebotomy room: a supervisor stepping away, a shift change, a patient who needs help mid-draw. Test those scenarios with real phlebotomists, and keep the results as human factors evidence.

Clinicians are receptive, with conditions. In a qualitative JMIR study of 15 ICU clinicians at five Southeastern U.S. hospitals, participants largely viewed robots as supportive tools, not substitutes for human expertise, while raising concerns about privacy, patient safety, and the loss of human touch. Patients in Aletta’s trial were largely comfortable with it, as the 82% and 86% acceptance figures show, though phlebotomy educators have questioned whether comparing a 2026 robot with success rates from older literature is a fair contest.

Adoption also depends on the work around the draw: scheduling, check-in, queue management, staffing across sites, and quality reporting. A robot that sits idle because patients can’t reach it, or because staff have to switch between three systems to use it, won’t deliver its labor savings. That operational layer is where most app developers will build, and Dogtown’s health system and hospital app development team works on exactly that kind of workflow software.

Testing Autonomy Before and After Launch

Autonomous systems need testing that goes well past unit tests.

Before launch, exercise perception and control on anatomical phantoms with veins of different sizes and depths, then with people under an investigational protocol. Inject faults deliberately, such as a dropped sensor feed, sudden patient movement, or a lost network connection mid-draw, and confirm the safety layer reaches a safe state every time. Test across the patient population the indications cover, including the skin tones, body sizes, and ages where imaging performance can vary, and report results by subgroup, as the ADOPT trial did for high body mass index, difficult venous access, and older patients.

After launch, track the same measures in the field, starting with the abstention rate, first-stick success, hemolysis, and adverse events, broken down by site and patient group. A rising abstention rate at one site can signal a training gap or a patient population the device handles less well. Under FDA’s medical device reporting rules, manufacturers must report deaths, serious injuries, and certain malfunctions, and user facilities such as hospitals and outpatient diagnostic facilities must report device-related deaths to FDA and the manufacturer, so build incident capture into the software from the start.

Field data also feeds the next version. Under a predetermined change control plan, it can support planned improvements, such as better vein detection, without a new submission for each one.

What It Costs, and Where the Money Goes

Device development cost figures often get quoted without their context. A widely cited HHS analysis in JAMA Network Open estimated a mean of $54 million to develop a novel therapeutic complex medical device, rising to $522 million once failed projects and the cost of capital are counted, with only 46.9% of devices advancing from nonclinical work to a feasibility study. Those figures describe high-risk Class III devices that need premarket approval. Low- to moderate-risk devices like Aletta, and the software around them, sit in a different cost range.

The costs that matter for a robotics software team are more specific: the quality management system, verification and validation, human factors studies, cybersecurity testing, the De Novo or 510(k) fee, and any clinical study. Aletta’s evidence base alone took a 1,633-patient multicenter trial. The biggest controllable cost is rework. FDA’s software guidance warns that design documentation created retrospectively can raise concerns about whether a developer had its design process under control, so build traceability, risk management, and test evidence as you write the code.

A Readiness Checklist for Clinical Robotics Software

• Intended use defined. The indications, setting, users, and supervision model are written down, along with every claim marketing will make.
• Regulatory status mapped. Each software function is classified as part of the device or non-device, with a 513(g) request or Pre-Submission planned where the line is unclear.
• Documentation level set. Enhanced documentation is assumed for any function that could cause serious injury before mitigations, and traceability starts with the first requirement.
• Safety layer independent. Safety monitoring can halt the procedure and reach a safe state even if perception or control fails.
• Abstention measured. Evaluation reports how often the system declines and what happens next, alongside success rates.
• Supervision tested. The supervisor experience has been validated with real users under realistic workloads.
• Identification preserved. Patient identity checks and specimen labeling are built into the workflow.
• Integrations documented. Orders, results, device data, and network connections are specified for the hospital’s review.
• PHI minimized. The design limits what the device stores, logs, and exposes remotely, with BAAs in place wherever PHI leaves the hospital.
• Change plan ready. Planned software updates are covered by a predetermined change control plan or budgeted as new submissions.

Why Partner With Dogtown Media

Dogtown Media builds medical device apps and clinical workflow software that connect to the EHR and laboratory systems hospitals already run. Our AI compliance and risk mitigation practice plans the regulatory path alongside the architecture, from classifying each software function to building the documentation FDA expects, and our AI-powered healthcare app development team builds the AI features, dashboards, and supervision apps that clinical devices depend on.

If you’re building software for clinical robotics or the workflows around it, request a free consultation to map your product to the right regulatory and technical path.

Frequently Asked Questions

Does a blood draw robot app need separate FDA clearance from the robot itself?

It depends on what the app does. Software submitted as part of the device system is covered by that authorization. A separately developed app that controls the robot, generates alarms, or prioritizes alerts across devices is device software, so it either belongs inside the manufacturer’s regulated system or needs its own authorization. An app that only transfers, stores, or displays device data without modifying it generally isn’t a device under section 520(o)(1)(D). Intended use and marketing claims decide, and a 513(g) request or Pre-Submission can confirm FDA’s view.

Can healthcare robotics software use cloud infrastructure while maintaining HIPAA compliance?

Yes. Major cloud providers offer infrastructure under business associate agreements, with encryption, access controls, and audit logging. A cloud provider that stores or processes ePHI is a business associate even if the data is encrypted and it holds no key, so the BAA isn’t optional. The hospital and its business associates each remain responsible for their own HIPAA obligations, including a risk analysis that covers the cloud components and a contingency plan for outages.

What happens if the robot encounters a situation it wasn’t validated for?

It should stop safely. Device software has to define the conditions it was validated for, and Aletta shows the pattern: it declines when it can’t find a suitable vein, detaches the needle if the patient moves too much, and pauses and alerts the supervisor when sensors detect other unsafe conditions. The software can’t expand its own operating envelope in the field. Changing that envelope generally requires a new submission unless the change falls within a predetermined change control plan FDA has already authorized.

How do you integrate robotics software with legacy hospital EHR systems?

Most lab orders and results still move through HL7 version 2 messages between the EHR and the laboratory information system, so plan to support them alongside FHIR. Interface engines and FHIR facades translate between formats, and direct APIs work where the EHR vendor offers them. Whatever the method, the integration has to preserve patient identification, data integrity, and audit trails, and it has to work within the hospital’s network rules, which often restrict device traffic to specific network segments or require VPN connections for remote access.

Will other companies be able to bring similar robots to market faster now?

Likely, yes. Because FDA classified Aletta through De Novo and established special controls for labeling, performance testing, and clinical testing, a comparable device can now pursue a 510(k) using Aletta as its predicate, which is typically a faster and less expensive path than De Novo. The special controls also show competitors what evidence FDA will expect.