Why Platform-Specific SKU Logic Matters
“Robotic single-port access” can sound like one product category. In practice, the patient-side interface depends on how the robotic system physically reaches the incision.
Some architectures use several independent robotic arms entering through separate sleeves. Others bring a main robotic instrument assembly through one primary sleeve and use a separate visualization pathway.
Those differences change channel geometry, sleeve arrangement, docking clearance, and the access-platform design.
The correct product question is not “Which robotic port do you have?” It is “Which patient-side architecture does this exact robot require?”
HK-FDDC-5DF: Development Around the SHURUI Workflow
AeroMed / HTKD developed and manufactures the HK-FDDC-5DF for the SHURUI single-port workflow.
In the workflow relevant to this platform, the main robotic instrument assembly enters through the white primary sleeve, while the black sleeve provides the separate endoscope / camera pathway.
This is not the same architecture as a multi-arm robot using several independent sleeves.
The development history is useful because it shows how the robot’s entry pathway directly shapes the access-device architecture.
HK-TS-120.C: A Separate Multi-Channel Configuration
HK-TS-120.C belongs to the same broader robotic access portfolio, but it uses a different multi-channel patient-side architecture.
It should therefore be treated as a separate configuration rather than as an interchangeable version of HK-FDDC-5DF.
Public mapping of HK-TS-120.C to any named robotic system should be based on the exact current controlled product records, verification evidence, IFU / labeling, and target-market regulatory scope.
What a Distributor Should Confirm Before Quotation
- Exact robot manufacturer and model.
- Instrument pathway: independent robotic arms or one integrated primary assembly.
- Visualization pathway: integrated or separate endoscope / camera sleeve.
- Patient-side geometry: channel spacing, docking clearance, sleeve dimensions, and interface arrangement.
- Exact AeroMed model: do not substitute one robotic access SKU for another without documented review.
- Controlled documentation: current IFU, labeling, regulatory scope, evaluation requirements, and hospital policy.
One Family Does Not Mean Universal Compatibility
Grouping products under one “robotic single-port” family is useful for navigation and portfolio organization. It does not mean every product in the family fits every robotic system.
This distinction matters commercially. A broad compatibility statement may hide the engineering question that matters most: whether the patient-side geometry and instrument pathway are documented for the intended system.
Portfolio family = related product category.
SKU = specific access configuration.
Robot mapping = system-specific evidence.
For the Full Architecture Explanation
Our newer architecture guide explains the patient-side difference in more detail, including distributed multi-sleeve access, integrated single-port entry, the SHURUI main-sleeve / endoscope-sleeve logic, and a practical six-step selection workflow.
Frequently Asked Questions
Why are robotic single-port access SKUs platform-specific?
Because different robotic systems can use different patient-side instrument pathways, sleeve arrangements, camera pathways, and docking geometries.
What is HK-FDDC-5DF?
HK-FDDC-5DF is an AeroMed robotic single-port access platform developed for the SHURUI single-port workflow.
Is HK-TS-120.C interchangeable with HK-FDDC-5DF?
No. HK-TS-120.C is a separate multi-channel robotic access configuration.
Does one robotic access SKU fit every robot?
No. Named robot-system mapping should follow current controlled product records, verification evidence, IFU / labeling, and target-market regulatory scope.
Related Products
Contact
For robotic-access development, distributor evaluation, OEM cooperation, or model-specific documentation:
AeroMed Surgical
winnie@aeromedsurgical.com
Third-party company and product names, when used, identify the relevant development or architecture context only. They do not imply endorsement, affiliation, or universal compatibility. Product selection should follow current controlled documentation and target-market requirements.