Glossary | Medtech Curriculum

How participants should use this page

This glossary is for participants who bring strong domain expertise but are still building technical fluency. You are not expected to become a specialist in every area. The goal is to understand enough language to lead decisions, challenge assumptions, and communicate clearly with software, hardware, quality, and operations teams.

When you read a term, connect it to a practical decision: what changes if this goes wrong, who owns the decision, and what evidence proves it is working. That mindset helps turn terminology into execution strength.

What this page helps you decide

This page helps learners keep vocabulary from becoming a barrier. The glossary is written for quick orientation, so a participant can look up a term and return to the workbook without losing the thread.

Use it while reading any page, especially when a technical, regulatory, security, or business term changes the decision being discussed.

Filter glossary terms

Search by term, alias, acronym, or practical phrase

Building Blocks

Frontend: The user-facing part of software: screens, forms, buttons, charts, alerts, navigation, and interactions. In medtech, frontend design must support workflow, accessibility, and safe interpretation.
Founder check: Ask whether the screen reduces cognitive load in the real workflow, not only whether it looks polished.
Backend: The server-side logic and services users do not directly see. It handles workflows, permissions, data processing, integrations, notifications, and other product behavior behind the interface.
Founder check: Ask who can explain the backend behavior when data is missing, late, duplicated, or unauthorized.
API: Application programming interface: a defined way for software systems to exchange information or trigger actions. In medtech, APIs need clear permissions, data formats, error behavior, auditability, and version control.
Founder check: Ask what happens when the API receives bad data, duplicate data, old app versions, or an unauthorized request.
API contract: A shared agreement for how systems exchange data, including formats, version behavior, and error handling. It reduces confusion between teams and lowers integration risk.
API endpoint: A specific address or operation where software sends or receives data, such as submitting a reading or requesting a patient summary. Endpoints should define inputs, outputs, permissions, errors, and version behavior.
Founder check: Ask what the endpoint does when permissions fail, data is invalid, or the client uses an older version.
Server: A computer or cloud runtime that runs backend software and responds to requests from apps, devices, integrations, or administrators. Servers may be self-managed or provided as managed cloud services.
Founder check: Ask what happens if this server is slow, unavailable, or misconfigured during a clinical workflow.
Database: Organized storage for product data such as users, readings, events, notes, device status, audit trails, and configuration. Database design affects privacy, traceability, reporting, and long-term maintainability.
Founder check: Ask where sensitive records live, how long they are kept, and who can access or change them.
Deployment: The controlled process of moving software from development into a test, pilot, or production environment. Good deployment planning includes approvals, monitoring, rollback, and communication.
Founder check: Ask who approves release, who watches it, and how quickly it can be rolled back.
Release management: Coordinated planning and execution of software deployment, rollback, and communication. Good release management reduces avoidable production incidents.
SDLC: Software development life cycle: the staged process from discovery through maintenance, including requirements, implementation, testing, release, and support.
Latency: Time delay between a request and the corresponding response. High latency can degrade user trust even when accuracy is high.
Prototype: An early version built to answer a learning question, explore a workflow, or test feasibility. A prototype may be useful for discovery without being reliable, secure, validated, or ready for real clinical use.
Pilot: A limited real-world deployment used to test workflow fit, support assumptions, privacy/security controls, data quality, and operational readiness before broader rollout.
Founder check: Ask what must be true before the pilot can start safely and what evidence will decide whether it should scale.

Apps And Cloud

Native app: An application built for a specific platform such as iOS or Android. Native apps can provide deeper device capabilities but usually require app store release management and platform-specific maintenance.
PWA: Progressive web app: a web application that can behave more like an installable app, often with caching, offline behavior, and home-screen access. PWA fit depends on device capability needs, workflow risk, and support requirements.
Founder check: Ask whether the workflow needs device permissions, offline behavior, or app store distribution before choosing PWA or native.
No-code: Tools that let teams build simple workflows, forms, automations, or prototypes with little or no programming. They are useful for learning and internal experiments, but medtech teams must still review privacy, security, validation, and maintainability limits.
Cloud hosting: Rented infrastructure and managed services used to run software, store data, handle networking, keep backups, monitor behavior, and support recovery. Hosting choices affect reliability, security, cost, and operational workload.
Managed service: Cloud component operated by a provider, such as managed database or managed queue. It reduces operational burden but does not remove customer security responsibilities.
Shared responsibility model: A cloud security model where providers secure core infrastructure, while customers secure workloads, identities, and configuration choices. Misunderstanding this split causes common security gaps.
Offline-first: Design principle that assumes networks fail: core workflows remain safe and usable with local state, sync, and clear conflict handling when connectivity returns. Essential for many clinical and home-use device paths.

Hardware

Sensor: Hardware that captures a physical signal such as motion, voltage, temperature, light, pressure, sound, or image data. Sensor choice affects what the software can trust.
Firmware: Low-level software embedded in hardware devices. Firmware quality directly affects device behavior, update safety, and field reliability.
Edge computing: Running computation near the device or point of care rather than only in centralized cloud systems. This can improve responsiveness during poor connectivity.
Calibration: Adjustment process to keep sensor measurements aligned to known references. Strong calibration improves trust in downstream analytics and decisions.
Signal-to-noise ratio: Relative strength of useful signal compared with unwanted noise. It strongly affects model quality and alert usefulness.
OTA update: Over-the-air update delivered remotely to devices. OTA workflows should include staged rollout and rollback controls.
MTBF: Mean time between failures, a reliability metric for repairable systems. It helps estimate support and maintenance needs over time.
Bathtub curve: Common mental model for hardware failure rate over time: higher early, a longer middle period of useful life, and rising failures later. It helps plan burn-in, field service, and warranty policy; real data rarely matches a neat curve, so validate with your product and environment.
Derating: Using components below their maximum rated conditions on purpose, to leave margin for age, temperature, and manufacturing spread. In batteries and power systems, it keeps field behavior inside safe, predictable bounds.
Thermal throttling: Automatic performance reduction to control device heat. It can impact responsiveness under sustained workload.
Graceful degradation: Planned behavior when a device cannot run at full performance: reduced speed, quality, or non-essential features, while preserving safety-critical function and clear user messaging. Pairs with thermal, power, and network limits.

Data And AI

AI-assisted development: Using AI tools to help draft code, interfaces, tests, documentation, or prototypes. It can speed exploration, but generated work still needs engineering review, security review, testing, documentation, and maintenance ownership.
Founder check: Ask who owns, tests, secures, and maintains any AI-generated work before it touches real users or data.
Human in the loop: Workflow design where humans review or approve AI-supported outputs before final action. This is a key control in higher-risk use cases.
Performance drift: Reduction or shift in model behavior over time due to changing data or environment. Drift monitoring is essential for long-term safety and quality.
PCCP: Predetermined Change Control Plan: a structured plan for specific future AI or software changes, including how those changes will be implemented, verified, and kept within approved boundaries.
Founder check: Ask which changes are inside the plan, which are outside it, and what evidence triggers release or rollback.
GMLP: Good machine learning practice: lifecycle discipline for data, training, evaluation, validation, monitoring, transparency, and change control for ML-enabled medical products.
Provenance: Documented origin and transformation history of data or artifacts. Good provenance supports reproducibility and trust in outputs.
Audit trail: Chronological record of actions and changes for accountability and review. It supports incident investigation and helps teams explain what happened and when.
Founder check: Ask whether the audit trail can reconstruct who did what, when, and under which product version.
Data residency: Policy and contractual expectations around where data is stored and processed. Residency requirements can directly influence architecture and provider choice.
Data map: A practical inventory of data categories, sources, systems, owners, locations, subprocessors, access rules, retention, and allowed uses. It supports privacy, security, architecture, and AI planning.

Regulatory, Quality, And Risk

Design controls: A structured process linking user needs to requirements, implementation, testing, and evidence. It keeps product decisions traceable and reviewable.
Founder check: Ask the team to trace one important user need to requirement, implementation, test, and evidence.
QMS: Quality management system that governs how products are designed, changed, documented, and improved in a consistent, controlled way.
CAPA: Corrective and preventive action process used in quality systems. It addresses root causes and reduces repeat failures.
Document control: Versioning and approval mechanisms that ensure records are current and trusted. It reduces confusion caused by outdated procedures and specs.
IEC 62304: Software lifecycle standard for medical device software development and maintenance. It clarifies process and evidence expectations across release phases.
Software safety class: IEC 62304 classification indicating potential risk from software failure. Class assumptions affect effort, evidence, and timeline expectations.
Indications for use: Statement describing target patient population and intended clinical purpose. It sets boundaries for product claims and validation scope.
SaMD: Software as a medical device: software intended for one or more medical purposes without being part of a specific hardware medical device. SaMD planning depends on intended use, claims, risk, validation, cybersecurity, and change control.
Predicate device: Existing legally marketed device used as a comparison in 510(k) submissions. Predicate strategy influences evidence planning and claim framing.
Q-Sub: U.S. FDA Q-Submission or Pre-Submission program: a structured way to request feedback on plans, study designs, or regulatory questions before submitting a marketing application. Outcomes depend on what you ask and how complete your package is; not a binding promise of final review results.
Hazard: Potential source of harm. Hazard identification is a starting point for risk control planning.
Risk control: Measure used to reduce likelihood or severity of harm. Effective controls are specific, testable, and monitored.
Residual risk: Risk remaining after risk controls are implemented. Teams should document why that remaining risk is acceptable.
Risk register: A working record of hazards, hazardous situations, harms, risk estimates, controls, verification evidence, residual risk, and review status. It keeps safety decisions visible across product, engineering, clinical, and quality teams.
Change control: Formal process for evaluating, approving, and documenting product changes. It helps prevent risky untracked updates in production.
Verification: Confirmation that outputs meet specified requirements. Verification checks whether the system was built correctly.
Validation: Confirmation that the product meets intended use in real or representative settings. Validation focuses on practical usefulness in context.
Founder check: Ask whether the evidence proves the product works for the intended users in the intended environment, not just in a demo.
Privacy impact assessment: Structured review of how a system collects, uses, stores, and protects personal information. Completing this early reduces costly redesign later.
Postmarket surveillance: Ongoing monitoring of product safety and performance after release. It helps teams detect issues early and improve continuously.
Traceability: Ability to connect needs, requirements, implementation, tests, and evidence throughout the lifecycle. Strong traceability improves decision quality and audit readiness.

Security And Operations

Threat model: Structured analysis of potential attackers, attack paths, and mitigations. It helps prioritize security work where impact is highest.
SBOM: Software bill of materials listing software components and dependencies. SBOMs improve vulnerability response and lifecycle governance.
Founder check: Ask how the team knows whether a newly disclosed vulnerability affects your product.
Coordinated vulnerability disclosure: Managed process for receiving and responding to security issue reports. A clear process improves trust with partners and customers.
Incident response: Planned process for detecting, containing, communicating, and recovering from security, privacy, or operational incidents. Strong response planning reduces avoidable confusion under pressure.
Observability: The ability to understand system behavior through logs, metrics, traces, and alerts. It is essential for rapid diagnosis and safe operations.
SLO: Service level objective defining target reliability or performance thresholds. SLOs align operations priorities with real workflow needs.

Business And Funding

Reimbursement pathway: Payment route by which healthcare systems or payers cover product use. It affects adoption speed and commercial feasibility.
TCO: Total cost of ownership across implementation, operations, maintenance, and support. It includes people and process costs, not only cloud spend.
Founder check: Ask what the buyer must pay, learn, integrate, support, and maintain after the contract is signed.
Procurement: The buyer-side process for evaluating, approving, contracting, implementing, and renewing a product. Procurement often depends on evidence, privacy/security review, integration effort, support burden, and total cost of ownership.
SR&ED: Scientific Research and Experimental Development program offering Canadian R&D tax incentives. Strong documentation improves claim reliability and review outcomes.
Mitacs: Canadian organization supporting industry-academic research collaborations and internship programs. It can provide practical support for targeted technical milestones.
NSERC: Natural Sciences and Engineering Research Council of Canada, a major federal engineering and science funding body. NSERC pathways can support deeper technical R&D collaborations.
CIHR: Canadian Institutes of Health Research, a major federal health research funding body. It is often relevant when clinical evidence generation is central to the product plan.

Interoperability

Clinical workflow: The sequence of real-world clinical tasks, handoffs, and decisions in care delivery. Workflow fit is often more important than feature count for adoption.
Human factors: Design discipline focused on user behavior, usability, and error prevention. It helps teams reduce avoidable misuse in high-pressure workflows.
EHR integration: Connecting a product to an electronic health record or related clinical system so users can exchange information inside an existing workflow. Integration depth affects adoption, privacy review, security review, implementation effort, and support burden.
HL7: Healthcare messaging standards, commonly including legacy HL7 v2 formats. Real-world HL7 integrations often vary by institution.
FHIR: Fast Healthcare Interoperability Resources, a modern API-oriented healthcare data standard. It helps structure clinical data exchange but still requires implementation planning.
FHIR implementation guide: Published rules that constrain and extend FHIR for a use case, jurisdiction, or program. “On FHIR” is not a complete integration plan without naming the guide your partners test against.
Founder check: Ask which resources, profiles, operations, and test expectations the customer will require.
DICOM: Standard for medical imaging data formatting, storage, and transfer. It supports consistent imaging exchange across systems and sites.
IHE (Integrating the Healthcare Enterprise): Industry initiative that publishes integration profiles and connectathon-style testing for scenarios that combine standards such as HL7, FHIR, and DICOM. Useful for scoping what “interoperable” can mean in a given workflow.
Interface engine: Middleware that routes, translates, and manages messages between systems such as the EHR, LIS, RIS, and devices. Many HL7-based integrations are shaped more by the engine and site configuration than by the standard alone.

Practical next step

Look up three unfamiliar terms from the talk or workbook and write what decision each term changes.

Template or worksheet: templates catalog.
Glossary terms: API, QMS, TCO.
Pathway links: Talk companion, Pathways.

Previous: Capstone case studyNext: Templates and resources

Medtech glossary