Robotics forclinical and biomedical research
A Robotics Partner Built for Research, Not Bedside Care
Petronella Technology Group works with healthcare research teams that need robotics prototypes, on-premises AI, and HIPAA-aware data handling under one roof. We are explicit about where our scope ends so principal investigators, research-IT directors, and innovation leads know exactly what they are buying.
This page is the buyer view. It explains what we mean by healthcare research robotics, who tends to call us first, what we will build for you, and where our boundaries are. The technical stack we deploy lives on the sister robotics prototyping page. The wider cybersecurity practice that protects every research engagement is on cyber security and CMMC compliance. Together, the three pages describe the whole engagement model.
Petronella is based at 5540 Centerview Dr., Suite 200, Raleigh, NC 27606. Our team is local to the North Carolina Research Triangle, which is where most of our healthcare research work originates. We come on-site. We sign business associate agreements. We talk to your IRB. We are reachable at (919) 348-4912 from the first conversation through the final handoff.
Triangle Health Systems, Biomedical Labs, and Research Innovation Arms
Healthcare research robotics buyers do not look like clinical operations buyers. The titles, budgets, oversight bodies, and risk tolerance are different. Here is the environment we have learned to work inside.
The first call usually comes from a director of research operations at a Triangle health system, a principal investigator running a National Institutes of Health funded study, an innovation lead at a hospital innovation arm, or a research-IT director at a university medical center. These are not bedside roles. They sit between the basic-science labs that publish papers and the clinical operations side that delivers patient care, and their job is to move research ideas through prototyping, pilot studies, and dissemination without entangling the clinical environment or breaking compliance posture.
The Research Triangle is unusually dense for this kind of work. Duke Health, the University of North Carolina health system, WakeMed, and the North Carolina State College of Veterinary Medicine all run active research programs. Around them, RTP houses one of the largest concentrations of contract research organizations and biotechnology companies in the country. The Research Triangle Foundation lists hundreds of life-science tenants in the park, and the regional concentration means a single research robotics project frequently touches multiple institutions through subawards, data-use agreements, and shared cores. We are local to that web. We can drive to your lab.
The funding fingerprint is also distinctive. Most healthcare research robotics work we see runs on competitive grant dollars. Federal sources include the NIH (multiple institutes, particularly the NIH BRAIN Initiative for neuroscience-adjacent platforms), the National Science Foundation Foundational Research in Robotics program, and the Defense Health Agency for biomedical research with dual-use components. State and foundation sources include the North Carolina Biotechnology Center, the Burroughs Wellcome Fund, and various health-system internal innovation funds. Each funder has its own data-management plan, intellectual-property requirements, and reporting cadence. A robotics partner that does not understand grant compliance creates problems on month nine of a three-year award.
Hospital innovation pilots add another layer. Innovation arms at large health systems frequently underwrite pre-clinical robotics work that is not yet IRB-approved for human subjects but is intended to mature toward an IRB submission. The internal sponsor is the innovation office. The technical owner is often a research-IT or biomedical engineering director. The clinical sponsor is a physician-investigator who shapes the use case but does not run the build. We have learned to map all three voices into a single statement of work so the project does not stall when one of them pivots.
Regulated-device startups in the Research Triangle round out the picture. These are the firms whose ultimate path is regulatory: 510(k), De Novo, premarket approval. Petronella is not the regulatory consultant for that path, and we say so up front. We are useful to these startups during the pre-clinical research phase only, when the team is building research prototypes, generating bench data, and refining their concept before regulatory engagement is locked in. Once a project crosses the regulatory line, we hand the build to a partner who specializes in design-controls and quality management systems for FDA-cleared devices. We stay available for cybersecurity and IT services around that path, which is a different scope of work than research robotics.
One pattern we see often enough to call out: a lab principal investigator decides to "spin out" a research finding into a startup, and the team imagines the same robotics partner can carry the work from grant phase through clinical phase. That handoff almost always benefits from two partners, not one. The research-phase build needs grant-compliance fluency, IRB documentation, HIPAA discipline, and the ability to iterate fast inside a small team. The regulatory-phase build needs design-controls process discipline, quality-system rigor, and the ability to slow down when the rules say slow down. We are good at the first; we are explicit that we are not the second. Knowing where to draw the line up front saves the team from a difficult re-architecture conversation eighteen months in.
Biomedical research labs, finally, are an underserved population. Many lab principal investigators have grant funding for a robotics component but no robotics engineer on staff and no time to learn one. They are most often interested in patient-companion robots for behavioral studies, low-cost teleoperation rigs for telerehabilitation research, perception platforms for clinical-workflow observational studies, or simulation-rich training environments for staff research. The common thread is that the robot is an experimental instrument, not a clinical device. The data flows back to the principal investigator, not to the patient chart. That distinction is everything.
Robotics in Healthcare Research, Bounded to Pre-Clinical Scope
These are categories of project we will take on. Each is grounded in published academic and federally-funded research traditions, and each stays inside the research and prototyping line.
Patient companion robots, research-only
Expressive desktop humanoids used in observational studies of social interaction, cognitive engagement, or behavioral health pilots. Intended for IRB-approved research recruitment, not clinical deployment. The robot is the instrument; the principal investigator owns the protocol.
Clinical-workflow assist prototypes
Pre-clinical prototypes that study how a robotic assistant could change a workflow without being deployed into the workflow. Examples include observational rigs that watch a simulated procedure room, or teleoperated arms used as a research probe in a non-care setting.
Teleop research for biomedical labs
Bilateral and unilateral teleoperation rigs used in academic biomedical research. Examples include force-reflection studies, low-bandwidth haptic experiments, or perception-and-control studies feeding into rehabilitation engineering papers. The data plane is research, not patient care.
Sim-to-real research environments
MuJoCo and Gazebo simulation pipelines plumbed into a real desktop platform such as the Reachy Mini. Used to develop behaviors safely before any in-lab session, and to publish reproducible benchmark code under the LeRobot ecosystem.
Multimodal perception platforms
Camera, microphone, and inertial-measurement experiments wired into Hugging Face foundation models on a private graphics-processing-unit fleet. Useful for human-subjects research where the model must never touch a public cloud and the data must never leave the principal investigator's environment.
Research dataset capture rigs
Custom rigs that capture LeRobot-format datasets for downstream policy learning research. Built to publish openly under appropriate licenses, or to retain privately under a research-data agreement when the underlying material includes protected health information.
The traditions we draw on are well-documented. The NIH BRAIN Initiative has funded a generation of neuroscience and rehabilitation engineering work that uses robotics as research instrumentation. The NSF Foundational Research in Robotics program funds biomedical and assistive robotics research at universities across the country, including in the Triangle. Carnegie Mellon Robotics Institute publications, particularly from the Quality of Life Technology Center, have set the academic baseline for socially-assistive robotics in research settings. We treat that body of literature as our methodological reference frame, and we cite it in proposals and statements of work.
The platforms themselves are accessible in a way they were not five years ago. The Reachy Mini we operate in our Raleigh lab is a $299 to $449 desktop humanoid with 6 degrees of freedom in the head, body rotation, animated antennas, four microphones, a wide-angle camera, and a fully open-source Python software development kit. It runs on the open-source Hugging Face LeRobot stack, which supports more than a dozen real-world hardware platforms and ships with a MuJoCo-based simulator. Spec data sourced from the Hugging Face Reachy Mini launch announcement. The point is that healthcare research robotics no longer requires a six-figure capital outlay before the first behavioral study runs. The cost barrier has moved from hardware to integration, and integration is where we work.
HIPAA, Common Rule, and the Regulatory Boundary
Healthcare research robotics sits at the intersection of three regulatory frames. None of them assume robotics, all of them apply when the project involves human subjects or protected health information.
HIPAA Security Rule
The HIPAA Security Rule applies to protected health information held or transmitted electronically by covered entities and their business associates. When a research project pulls electronic protected health information into a robotics workflow, even briefly, the rule attaches. We design data flows to minimize that exposure and to satisfy the administrative, physical, and technical safeguards the rule requires.
Common research robotics scenarios that trigger HIPAA: pulling research-subject identifiers from an electronic health record into a study database, recording video or audio in a research session that captures identifiable information, training a foundation model on session recordings before they have been fully de-identified, or storing session telemetry on a third-party cloud service that does not have a business associate agreement in place.
IRB and the Common Rule
The Federal Policy for the Protection of Human Subjects (Common Rule, 45 CFR 46) governs human-subjects research at any institution receiving federal funding. The institutional review board owns the local enforcement of the rule. Every research robotics project that involves human subjects, recordings of human subjects, or identifiable data about human subjects passes through the IRB. The IRB cares about consent language, data-handling, risk minimization, and withdrawal rights. We build documentation that fits the IRB's review template, not a generic technology change-control template.
When a study has multiple IRBs (single IRB review, reliance agreements, or commercial IRBs for industry-funded work), we adapt. The compliance evidence package we build is designed to survive review by any IRB, not optimized for one institution.
FDA SaMD context (cite-only, not our scope)
The FDA Software as a Medical Device (SaMD) framework defines when software qualifies as a regulated medical device. We cite it here for context, because research-phase work sometimes informs a downstream regulatory submission. Petronella does not currently submit 510(k), De Novo, or premarket approval applications, does not author quality management system documentation under 21 CFR Part 820, and does not run human-factors validation testing under IEC 62366. If your project is on the SaMD path, the work you need is from a regulatory consultancy, not from us. We coordinate with regulatory partners when a research engagement is meant to feed a downstream submission.
Human Research Protection Program
Beyond the Common Rule and HIPAA, most research institutions operate a Human Research Protection Program (HRPP) that handles consent monitoring, conflict-of-interest declarations, vulnerable-populations review, and data and safety monitoring. The HRPP is the operational layer the IRB sits on top of. Robotics projects in this domain interact with the HRPP at several points: equipment risk review, audio-visual consent supplements, and data-management plan attestations. We provide HRPP-friendly documentation as part of every healthcare research engagement.
One more piece of regulatory context that healthcare research clients ask about. Federally-funded research with controlled unclassified information also triggers the same Department of Defense compliance frameworks that drive our defense practice: NIST SP 800-171 and the Cybersecurity Maturity Model Certification program. Most healthcare research does not carry CUI. When it does, particularly in dual-use military-medical research, the same Petronella team that delivers robotics is also the team that runs CMMC engagements. We do not bolt on a separate compliance vendor.
Cyber Foundation, Private AI Fleet, and an Open-Source Humanoid in Raleigh
The differentiator for healthcare research robotics is not a robotics specialty alone. There are several capable pure-robotics shops in the country. The differentiator is the combination of cybersecurity depth, on-premises artificial intelligence infrastructure, and an emerging robotics practice operating under one engagement. For a research team that already has to satisfy HIPAA, IRB, and grant-compliance regimes, that combination removes vendor count and reduces the seams where data leaks happen.
Cybersecurity foundation. Petronella has served North Carolina healthcare organizations since 2002. We hold CMMC-AB Registered Provider Organization #1449, verified at cyberab.org/Member/RPO-1449. Our entire team is CMMC Registered Practitioner certified. Founder Craig Petronella is a North Carolina Licensed Digital Forensics Examiner #604180 (verified at forensicresources.org) who has testified as a digital forensics expert witness in cybercrime cases. That depth matters when an IRB asks who handles incident response on the research-robotics platform, when a subaward audit asks for the security plan, or when a sponsor due-diligence questionnaire asks about supply-chain integrity. We answer those questions with documentation, not promises.
Private artificial intelligence fleet. Petronella operates a graphics-processing-unit fleet that runs production research-grade AI workloads on premises. Hardware sourced through the NVIDIA Elite Partner Channel includes systems suitable for training and inference of Hugging Face SmolVLA-class vision-language-action models, large language models for research transcription pipelines, and computer-vision models for perception experiments. The salient point for healthcare research is that nothing has to leave the data plane. Protected health information from a research session does not need to make a round trip to a public LLM provider for a model to train or infer. Foundation-model training, fine-tuning, and inference can all happen inside a controlled boundary with auditable logs. Read more on the private AI solutions page.
Reachy Mini in our Raleigh lab. We acquired our first humanoid platform, the Reachy Mini, in 2026. The Reachy Mini is a desktop expressive humanoid designed by Pollen Robotics and acquired by Hugging Face in April 2025, priced at $299 to $449. The platform is open-source on the software side and integrated with the LeRobot ecosystem at launch. We run it in our Raleigh lab as the proving ground for healthcare research engagements. More on the Reachy Mini hardware page.
RPO #1449 cybersecurity foundation as the data-handling spine. Every healthcare research engagement we deliver inherits the same data-handling discipline as our defense and CMMC engagements: minimum-necessary access, audit logging at the data-plane and at the model-inference layer, encryption at rest and in transit, segmented research environments separated from clinical operations, and incident response playbooks aligned to the NIST Secure Software Development Framework (SP 800-218). Healthcare research clients do not get a watered-down version because the data is research and not clinical. They get the same spine.
Open-source ecosystem participation. Healthcare research robotics moves faster when the underlying tools are open. Petronella participates in the open-source Hugging Face LeRobot ecosystem, which counted more than twelve thousand GitHub stars at the April 2025 Hugging Face acquisition of Pollen Robotics and continues to grow. The LeRobot stack supports more than a dozen real-world hardware platforms (SO-101, SO-100, Koch v1.1, LeKiwi, Hope Jr, Reachy 2, Unitree G1, OpenArm, ViperX, and others, per the official LeRobot documentation). We can use a different platform when the protocol requires it, and the openness of the stack means a research lab can replicate, extend, or fork our work without paying for a proprietary license. This matters at grant-renewal time, when reproducibility is a funder requirement.
Local team, on-site engagement, no offshore handoff. Healthcare research robotics is hands-on work. Petronella's engineering and security team is local to North Carolina. We come to your lab. We do not subcontract the build to an offshore team and pretend a Slack channel is the same as engineering on the bench. For a Triangle research client, we are typically thirty minutes from your lab. For an out-of-state client, we travel. The team that builds the robot is the team that signs the BAA and the team that holds the credential stack. We have no team-laundering layer between the principal investigator and the people writing the code.
Three Shapes the Work Tends to Take
Most healthcare research robotics engagements fit one of three patterns. Each is bounded, scoped, and explicitly in the research lane.
Research-pilot scoped study
A single principal investigator, a single IRB, a defined recruitment goal, and a fixed-duration build. Typical scope is six to twelve weeks, ending with a runnable Reachy Mini or comparable platform configured to the study protocol, plus the data-management plan, business associate agreement, and IRB-friendly evidence package. Useful for departmental innovation funds and small foundation grants.
Multi-IRB program support
A research program spanning multiple institutions, multiple IRBs (single-IRB review or reliance), and shared datasets. The deliverable is a reproducible reference architecture documented well enough that subaward sites can replicate it without bringing in our team for each replication. Typical scope is three to six months, with handoff to the program coordinating center.
Biomedical research data infrastructure
A research lab needs an on-premises data plane, AI inference cluster, and robotics integration that can be reused across multiple grants and multiple students. Typical scope is a one-time build plus an annual review-and-refresh engagement. The lab principal investigator owns the data; we own the platform.
What none of these archetypes contain: clinical deployment, patient-care robotics, or any work that would be regulated as a medical device under FDA Software as a Medical Device guidance. We will say no to the work and refer you to a partner that does it well. That trade-off is intentional. Saying yes to clinical-deployment work without the regulatory and quality-management infrastructure to support it would put your study and patients at risk. A focused research practice serves you better.
PHI Segregation, Encryption, Audit Logs, and Data Residency
The data side of healthcare research robotics is where most of the risk lives. Here is how we handle it.
Protected health information segregation
Research robotics sessions that touch protected health information are run inside a segregated environment with no shared identity plane and no shared storage with any clinical system. Recording artifacts (video, audio, telemetry) are written to a controlled research-data store, not a general-purpose lab share. De-identification routines run on capture or on first ingestion. The principal investigator approves the de-identification rule before recording starts.
Encryption at rest and in transit
Every storage tier in a healthcare research robotics engagement carries encryption at rest. Every network path between the robot, the inference cluster, and the data store uses transport encryption with mutual authentication where the protocol supports it. Encryption keys are managed in a hardware security module or equivalent. Key rotation is documented in the security plan that ships with the project.
Audit logs sized for IRB review
Audit logs cover identity events, data access, model inference invocations, and configuration changes. Retention is sized to outlive the IRB review cycle, typically three years from the last data access by default and longer when a sponsor agreement requires it. The log structure is designed so an auditor or IRB monitor can answer the question "what happened to record X" without us writing custom queries on demand.
Data residency for federally-funded work
Federally-funded research, particularly NIH-funded work touching the BRAIN Initiative or NIH common funds, increasingly imposes data-residency expectations through Data Management and Sharing policies. We default to United States data residency for healthcare research engagements, with explicit attestations in the data-management plan. Workloads run in our Raleigh facility or in a client-owned facility we operate; we do not rehost healthcare research data to international cloud regions absent explicit principal-investigator consent and matching IRB approval.
Model inference and training boundary
The single biggest data-handling risk in modern research robotics is the temptation to send a video clip or a transcript to a public foundation model for a quick analysis. Doing so moves protected health information across the data-plane boundary and almost always triggers HIPAA, IRB, and grant-compliance issues simultaneously. Our default is on-premises inference for any workload that has touched, or could touch, identifiable research data. Hugging Face SmolVLA-class models, large language models for transcription, and computer-vision models for perception experiments all run inside the controlled boundary. When a project genuinely needs a hosted model, we use it only on data that has been de-identified to the principal investigator's and IRB's satisfaction, with the inference call logged.
Incident response and breach notification posture
Every healthcare research robotics engagement ships with a written incident response plan that names roles, timelines, and notification thresholds. The plan distinguishes between operational incidents (a robot crash, a service-degradation event) and regulated incidents (a possible PHI exposure, an IRB-reportable event, a grant-compliance trigger). Regulated incidents trigger immediate notification to the principal investigator, the institution's privacy or security officer, and Petronella's incident commander. The plan integrates with HIPAA breach notification rules, applicable state breach notification statutes, and any sponsor-specific reporting obligations. Forensic evidence is preserved in line with our digital forensics practice; founder Craig Petronella is a North Carolina Licensed Digital Forensics Examiner #604180.
Vendor and supply-chain hygiene
Healthcare research robotics projects pull from open-source software supply chains (LeRobot, ROS, MuJoCo, PyTorch, Hugging Face), open-source hardware supply chains (Reachy Mini, SO-101, community-built rigs), and commercial vendors (NVIDIA Elite Partner Channel for GPU hardware, microphone and camera vendors for sensors). We apply the discipline of a software bill of materials (CISA SBOM guidance) to every engagement: dependencies are tracked, vulnerability signals from upstream are monitored, and the SBOM is delivered as part of the audit-evidence package at handoff. Hardware sourcing follows the same logic; we record provenance for the components in the data plane.
IRB Collaboration, Innovation-Fund Cycles, and BAA Structure
IRB collaboration. Every healthcare research robotics engagement starts with an IRB conversation. We meet with the principal investigator's IRB liaison or the IRB coordinator before the build kicks off. We bring drafts of the data-management plan, the data-flow diagram, the recording-and-retention plan, the consent-language addendum, the security plan, and the incident response plan. The IRB does not have to invent the documentation. We provide it; the IRB edits and approves it. That changes the rhythm of the project from "wait three months for IRB" to "iterate with IRB during the build" and is the single biggest accelerator we have found in this space.
Innovation-fund cycle alignment. Hospital innovation arms run on an annual or semi-annual award cycle. Most pilots have to demonstrate progress at the next quarterly innovation-committee meeting. We design healthcare research robotics engagements to fit those cycles: a six-week prototype that lands in time for a steering-committee demo, a twelve-week pilot that produces a poster-ready dataset for the next academic conference deadline, a year-long program that aligns with the next NIH renewal application. The cycle drives the scope, not the other way around.
Business associate agreement structure. Petronella signs a HIPAA business associate agreement on every healthcare research engagement that involves protected health information, even when the data has been de-identified, because the de-identification process itself is a covered activity. Our standard BAA is reviewable in advance, references the full HIPAA Privacy and Security Rule obligations, and has been signed by health systems, contract research organizations, and academic medical centers across multiple grant cycles. We will sign your institution's BAA template when one is available. If not, ours is on the table.
Data-use agreement and intellectual-property clarity. We do not retain rights in research data. Data ownership stays with the institution and the principal investigator. Reusable code we build during an engagement is delivered under a license you and we agree on at the start of the project, typically a permissive open-source license unless the funder requires otherwise. Reusable Petronella infrastructure (security playbooks, deployment templates, audit-evidence formats) remains ours. The boundary is documented in writing before kickoff.
Reporting cadence. Standard reporting is a weekly written status note plus a biweekly working session with the principal investigator and the research-IT director. We add an incident-only reporting line for IRB and HIPAA matters: any event that touches the regulated boundary triggers a written notification within the timeframe the IRB and the security plan require. We have not had to use that escalation path, and the discipline of having it documented is part of why.
Need the buyer-identity sister page on healthcare cybersecurity?
This page covers healthcare research robotics. The sister page covers healthcare cybersecurity for hospitals, clinics, and medical practices: who you are, what threatens you, and how the HIPAA program runs. Different intent, different deliverable.
See healthcare cybersecurity for clinical operations →Healthcare Research Robotics, Common Questions
Do you support FDA SaMD or 510(k) submissions?
Will you sign a HIPAA business associate agreement?
Can you work with multiple IRBs on a multi-site research program?
Do you keep healthcare research data on premises?
What happens if our research robotics work later moves toward an FDA submission?
Do you do surgical robotics, robotic-assisted procedures, or in-clinic patient-care robotics?
What hardware platforms do you support?
How do you handle research data that contains identifiable information about minors or other vulnerable populations?
Can you align a healthcare research robotics build with our NIH Data Management and Sharing Plan?
How fast can a research-pilot scoped study start?
Bring the Study. We Bring the Robotics, the Compliance Spine, and the Private AI Fleet.
Petronella Technology Group has served North Carolina healthcare and research organizations since 2002. Free initial conversation. IRB-aware engineers. Pre-clinical scope only. No hard sell.
For an overview of how we approach robotics across healthcare research, defense research, and university programs, see our custom robotics development pillar.
For technical specifications of the desktop humanoid we operate in our Raleigh lab, see the Reachy Mini hardware page.
For the deliverable side of a research robotics engagement, see robotics prototyping services.
Get the Secure Robotics Development Brief
Tell Petronella Technology Group about your robotics project. We will reply within 4 business hours with a CMMC-RP led scoping conversation and the early-access edition of our Secure Robotics Development Brief covering CUI handling, on-prem AI inference for robotics, and CMMC-aligned development practices. No obligation. No sales pressure.