RAYPCB · ENGINEERING GUIDE
Medical Electronics Architecture: Connect Intended Use, Interfaces and Manufacturing Evidence
Medical electronics architecture allocates a device's intended functions across hardware, software, sensors, power and external interfaces. The useful starting point is the intended use and the controlled product requirements, not a universal PCB construction or a list of medical component labels. Different devices and installation contexts create different evidence needs.
This page supports the engineering handoff between product development and manufacturing. It does not offer clinical advice, determine regulatory classification or certify a device. The evidence worksheet records requirements and references without receiving patient information or deciding whether a risk is acceptable.
Establish the intended-use and product boundary
Identify the device function, user, operating environment and interfaces through the responsible product-development process. State what the electronics are assigned to measure, communicate or control, and what remains outside their scope. A component application diagram cannot define the intended use of the finished device.
Keep accessory, host and power-source relationships explicit. A standalone board, a replaceable module and a complete instrument can have different acceptance boundaries. Identify which organization owns the complete product and which work is requested from the PCB or assembly supplier.
For manufacturing-service scope, use the medical PCB assembly guide. This architecture page addresses requirement allocation and evidence transfer. The distinction prevents an assembly quotation from being interpreted as validation of clinical performance or approval of the finished device.
Separate medical-device evidence responsibilities
| Evidence object | Possible supplier scope | Product-team responsibility |
|---|---|---|
| Component | Exact fitted item and agreed sourcing record | Application suitability and allocated function |
| PCB/assembly | Controlled construction and acceptance observations | Relationship to complete device requirements |
| Programmed module | Agreed image, identity and interface checks | Intended-use and integration verification |
| Finished device | Only the explicitly contracted observations | Applicable validation, risk and regulatory process |
Allocate interfaces with observable requirements
Create a record for sensing, processing, communication, user interaction and power. For each interface, state the information or electrical behavior exchanged, relevant operating states and the responsible design element. Define how the requirement will be observed without assuming that a passing system demonstration proves every internal boundary.
Sensor requirements should identify the physical quantity, range, response and relevant uncertainty. The IoT sensor-selection guide provides general measurement-chain concepts, but medical-device requirements must come from the actual controlled product process. Do not transfer a generic sensor example into a clinical performance claim.
Keep normal operation, invalid information and unavailable interfaces distinct. A plausible numeric output is not automatically a valid measurement. Define how the product represents and handles those conditions according to its intended function and responsible risk-management process.
| Review item | What to establish |
|---|---|
| Intended use | Controlled device function, user, environment and product owner. |
| Allocation | Hardware/software/interface requirements and observable verification. |
| Risk process | Assigned controls, evidence and authorized disposition of open decisions. |
| Manufacturing transfer | Critical characteristics, controlled files, fixtures and acceptance scope. |
| Records and changes | Traceability, configuration impact and confidential-data boundaries. |
Medical architecture evidence mapping
Medical architecture evidence mapping
Use the current inputs and keep the assumptions
Load the example to see the units and record format, then clear it before entering your own revision. Example values are illustrative and do not select components or establish acceptance limits. Every field needs an intentional value; a blank number is not treated as zero. For CSV input, retain the header and put one item on each row. Quoted cells can contain commas, but duplicate headers and malformed rows are rejected.
Generate a result only after checking the measurement boundary, operating condition and units. Editing an input invalidates the old result and disables its download until you calculate again. An edited example stays labeled as an example. The report is created locally; it does not upload a design, send an enquiry or populate the Contact form. Attach it manually if it helps explain a requirement. You can contact RAYPCB without completing the tool.
| Input | What to establish before using it |
|---|---|
| Review reference | Use a nonconfidential revision label. |
| Review record · CSV | Statuses: Open, Recorded, Not applicable. Recorded needs an evidence reference; Not applicable needs a reason. Entries are self-reported, not compliance approval. |
Keep risk-control decisions tied to their implementation and verification
ISO 14971:2019 describes a medical-device risk-management process. The public standard information establishes scope; it does not provide all licensed requirements or a ready-made acceptance decision for a particular device. The responsible team must apply the appropriate controlled process to the actual product.
When a risk control is allocated to electronics, identify the requirement, implementation and evidence needed to verify it. Avoid treating a component's presence as proof that the intended control is effective. Hardware, software, user interaction and manufacturing can all influence the outcome.
Keep unresolved decisions visible and assigned. The worksheet deliberately avoids an overall safety or compliance score. A single unresolved critical interface cannot be made acceptable by checking many unrelated administrative items. The authorized product team determines the significance and disposition of each gap.
Distinguish component, assembly and product evidence
Component documentation supports claims within its exact scope and conditions. Fabrication records, assembly workmanship observations and functional tests support different aspects of the manufactured object. Product validation and any required regulatory evidence add responsibilities beyond those records.
For U.S. device manufacturers within the applicable scope, FDA's Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. This is regulatory context, not a statement that RAYPCB or a particular customer device holds a certification or satisfies every applicable requirement.
Specify the standards, revisions and acceptance criteria relevant to the actual agreement. Do not combine medical, automotive or general workmanship labels into a universal quality claim. The automotive design evidence guide is a cross-industry example of separating evidence ownership, not a substitute for medical-device requirements.
Design the manufacturing handoff around critical characteristics
Identify the released board files, BOM, assembly instructions, firmware and configuration references. Mark critical characteristics and the agreed observations required to accept them. Keep the relationship between product requirements and manufacturing instructions clear enough that a supplier does not have to infer intent from a schematic alone.
Plan access for programming, calibration and functional tests where they are part of the scope. State which fixtures or reference equipment are supplied, developed or maintained by each party. A test that requires an integrated enclosure or external accessory should be assigned to the correct stage rather than credited to a bare-board observation.
The electronic module assembly guide defines physical and functional delivery boundaries. If a module is replaced or reworked, preserve the configuration and identity relationships required by the product process. Do not silently transfer a passing record from one physical configuration to another.
Preserve changes, records and confidential boundaries
Evaluate the effect of changes to parts, materials, firmware, fixtures and instructions through the controlled process. A footprint-compatible substitution can change electrical behavior, calibration or verification requirements. Keep approvals tied to the affected configuration and any permitted use of existing stock.
Define traceability and retention according to the project requirements. Useful records identify the relevant unit or lot, revision, process or test evidence and approved deviations. Collecting more data is not automatically better if the record lacks meaning or introduces unnecessary confidential information.
Use nonconfidential references in the public worksheet. Do not enter patient data, credentials or restricted project details. The tool operates locally, but its purpose is to organize an engineering discussion, not to become the controlled medical-device record system or an approval workflow.
Prepare an enquiry with the remaining decisions visible
The worksheet distinguishes open items, supplied references and reasoned not-applicable entries. Recorded means the user entered a reference; the tool does not inspect the underlying report or determine its adequacy. Review the actual evidence with the responsible team before treating the requirement as closed.
Send RAYPCB the controlled manufacturing files, quantity, requested delivery object and agreed acceptance scope. Identify the specific manufacturing or test-access question and any requirements that constrain alternatives. Keep product validation and regulatory responsibilities assigned explicitly.
A professional handoff lets the customer understand what will be built, what will be observed and which evidence remains elsewhere in the product process. That clarity supports trust more effectively than an unsupported promise that a generic medical PCB automatically makes the finished device reliable or compliant.
Maintain the design-to-manufacturing evidence chain
Document the intended-use boundary and the functions that the electronics must support before discussing a board construction. Allocate requirements to hardware, software, interfaces and manufacturing processes, and identify how the responsible team will verify each one. Do not use a generic checklist score as a risk-acceptance decision.
Keep device-level risk management and regulatory responsibilities with the appropriate controlled product process. Manufacturing information should identify the released revision, critical characteristics, traceability expectations and agreed acceptance evidence. An assembler's workmanship check does not validate clinical performance or approve the device. Public tools should use nonconfidential references and expose missing evidence without receiving patient information or secret project data. The outcome is a clearer engineering handoff, with open decisions visible and assigned.
Standards, source context and limits
Use the exact device, system and material documents relevant to the released design. A public reference design demonstrates a particular implementation under its stated conditions; changing its parts, layout, enclosure or firmware creates a different verification task. Standards summaries here identify the type of evidence to request, not every clause of a licensed standard. Component qualification, board workmanship, product validation and regulatory acceptance are separate decisions.
For fabrication scope and the agreed construction requirements, see PCB manufacturing.