Start here: Describe the project in one line

• In one sentence, describe the device concept and the primary clinical claim you intend to support
• Which stage best describes your immediate goal for this engagement Options: Early feasibility prototype, Pilot for clinical validation, Regulatory submission package, Transfer to manufacturing, Other
• How soon do you need a development partner to be fully engaged Options: Immediately (within 2 weeks), Within 1 month, 1–3 months, 3–6 months, Later than 6 months
• Tell me the single most important commercial outcome for this project, for example faster market entry, lower COGS, or easier reimbursement

Where the device actually has to work, and why that matters

• If wireless performance failed to meet your clinical threshold, what would it cost you in trial delays, repeat enrollments, or lost reimbursement pathways
• Estimate the operating environments where the device must reliably connect, including facility types and typical RF conditions Options: Inpatient hospital wards, ICU or procedural areas, Outpatient clinics, Home settings with consumer WiFi, Ambulatory settings, Mixed environments
• List the specific data elements the device must collect and transmit to support the clinical claim, including sampling rates and timestamp requirements
• Who owns the clinical protocol and who will sign off on data validity during verification and validation Options: Clinical lead (internal), External investigator or site, Shared responsibility, Not yet assigned
• Which single technical failure or missing capability in connectivity, sensors, or data integrity would make you pause moving forward with a partner

Who must be in the room when decisions are made

• Name the internal decision makers who will approve requirements, regulatory submissions, and budget
• Walk me through the chain of approvals from engineering through quality and regulatory to the C-suite for a design change
• Identify the team members allocated to support the engagement and the percent of their time they can commit Options: Full time (50%+), Part time (20–49%), Ad hoc (under 20%), Not yet assigned
• Could any external clinical sites, manufacturing partners, or customers veto technical decisions or block data access Options: Yes, clinical sites, Yes, manufacturing partner, Yes, customer/health system, No single veto
• If key stakeholders cannot be available during verification testing windows, would that stop the project immediately Options: Yes, testing cannot proceed, No, we can delegate sign-off, Depends on the stakeholder

Where the prototype hides risk and costs

• Where in your current prototype, firmware, or backend do you most often find defects that threaten timelines Options: Firmware stability, Wireless connectivity, Sensor calibration, Cloud ingestion and mapping, User interface/companion app
• Describe any previous attempts to productize this concept and the main causes of delay or rework
• How many third-party libraries, wireless stacks, or SDKs are embedded in the current firmware build Options: None or custom stack, 1–3, 4–7, More than 7, Unknown
• List the cybersecurity controls already documented and the ones still missing, for example threat model, SBOM, or pen test evidence
• What single unresolved technical or compliance risk would force you to halt development or refuse to sign off on a submission

The other paths you are weighing

• Name the vendors, consultancies, or internal teams you are actively considering as alternatives to outsourcing this development
• Describe the performance evidence, regulatory history, or manufacturing readiness your current approach would need to demonstrate for you to stay with it
• Who inside your organization has proposed solving this without an outside partner and what resources have they put on the table Options: Internal engineering team available, Cross-functional task force, No internal proposal, Undecided
• What outcome or proof point from a pilot would make you cancel other options and sign a contract that week

Readiness: the gates and dependencies we cannot ignore

• Identify the integration endpoints, lab or clinical systems, and vendor interfaces that must be available on day one, and name the owners for each
• On a scale from 1 to 5, how mature are the APIs and documentation for those systems Options: 1 - Little to no API, 2 - Early beta APIs, 3 - Usable with gaps, 4 - Well documented, 5 - Production grade
• Assess the cleanliness and accessibility of the clinical or device data the engagement depends on, and name who can grant access
• Could regulatory approvals, data use agreements, or site contracts create gating milestones that will delay a pilot beyond your target timeline Options: Yes, regulatory approvals, Yes, data use agreements, Yes, site contracts, No major gating items identified
• Answer yes or no, would failure to meet a single prerequisite within your target window force you to postpone the project Options: Yes, No, Depends on which prerequisite

How you will judge success and satisfy regulators

• Define the minimum clinical performance or data quality targets you require for submission, including sensitivity, specificity, or error rates where applicable
• Estimate the total time and budget you have allocated for verification, validation, and regulatory submission preparation Options: Under 3 months / low budget, 3–6 months / moderate budget, 6–12 months / standard budget, 12+ months / high budget
• Provide the regulatory artifacts you expect the partner to deliver and the ones you will retain control of, for example design history file, risk management file, and submission-ready docs
• Rate the acceptable residual cybersecurity risk after deployment and the evidence you will require, for example pen test report, SBOM, or mitigation plan Options: Low - full pen test and SBOM required, Medium - threat model and mitigation plan, High - basic controls only
• Yes or no, would an unexpected regulator request for additional clinical data cause you to pause the planned release Options: Yes, No, Only if the request is significant

Decision drivers and practical next steps

• Provide the name and role of the person who can sign a statement of work and the typical approval lead time
• Share the internal fiscal, procurement, or board milestones that must align before a contract can be executed
• Specify the target timeline, if met by a partner, that would make you ready to start integration work Options: Immediate start, Within 2 weeks, Within 1 month, 1–3 months, 3+ months
• Enumerate the non-negotiable commercial or legal terms you require in a statement of work, for example IP ownership, indemnity, or data rights
• Assuming a pilot meets your acceptance criteria, what is the shortest realistic lead time for procurement and legal to sign off Options: 1–2 weeks, 2–4 weeks, 1–2 months, Longer than 2 months
• Select the materials or evidence you would like to see as the next step, to help you decide whether to proceed Options: Pilot plan and acceptance criteria, Detailed schedule and milestones, Preliminary BOM and manufacturing plan, Draft regulatory strategy, Security assessment summary

• Solution Walkthrough, Connectivity and Compliance

• Confirm the current state and its cost
• You confirm the presented manufacturable architecture and BOM constraints address the manufacturability concerns from Discovery.
• Provide a draft manufacturable reference architecture and BOM constraints document for review.
• You confirm the connectivity, app, and cloud integration approach satisfies the clinical environment reliability and data flow requirements.
• Walk through the clinical use case and critical constraints
• Deliver a connectivity test matrix and recommended clinical-environment test plan.
• You agree the regulatory pathway and the list of artifacts and verification steps needed to reach submission readiness.
• Share clinical use-case documentation, target sites, representative connectivity environments, and existing validation data.
• Present manufacturable reference architecture and BOM constraints
• You agree on the next deliverables, who will produce them, and a target timeline toward design transfer.
• Demonstrate connectivity and clinical-environment test scenarios
• Share any prior risk assessments and your preferred regulatory pathway assumptions for alignment.
• Confirm acceptance criteria and decision points that will determine readiness to enter design transfer.
• Map regulatory and cybersecurity artifacts to verification needs
• Validation checkpoint — confirm this matches your priorities
• Agree next steps and decision criteria

• Solution Walkthrough — Manufacturable Connected Device
• Solution Walkthrough Deck
• Solution Brief — Solution Walkthrough

• meeting
• slides
• document

• Functional Prototype Build
• Industrial and Enclosure CAD Design
• Mechanical Design for Manufacturability
• PCB Schematic, Layout, and Bill of Materials
• Embedded Firmware Development and Debug
• Wireless Connectivity Integration (BLE/Wi‑Fi/Cellular)
• Over‑the‑Air Update Implementation
• Companion Mobile App Development (iOS and Android)
• Cloud Platform Integration and API Development
• Device Cybersecurity Controls and Technical Documentation
• Risk Management File and Hazard Analysis
• Design Verification Testing and Test Reports
• Usability/Human Factors Validation and Report
• Design Transfer Package and Production Test Fixtures
• Regulatory Submission Package (510(k)/De Novo‑Ready)

Functional Prototype Build

• Do you need a single proof-of-concept board or multiple hardware variants for the prototype build? Options: Single variant, Multiple variants, Undecided
• What clinical use case will the prototype must demonstrate (for example continuous glucose sampling, ambulatory ECG, or pulse oximetry logging)?
• Which prototype deliverables do you require: assembled prototypes, prototype firmware image, and a prototype bill of materials (BOM)? Options: Assembled prototypes, Prototype firmware image, Prototype BOM, All three, Other
• When should the first functional prototype be available for bench testing (specify target week or month)? Options: Within 4 weeks, 4-8 weeks, 8-12 weeks, Custom timeline
• Provide the target performance metrics the prototype must meet during bench validation (for example sensor accuracy, sample rate, battery run-time in hours).

Industrial and Enclosure CAD Design

• Which ergonomic constraints must the enclosure satisfy (for example IP rating, cleanability, ingress protection level, single-handed use)? Options: IP rating required, Cleanability requirement, Single-handed operation, Weight/size limit, Other
• Specify the regulatory material constraints for the enclosure such as biocompatibility grade, flammability rating, or latex-free requirements.
• Identify the production intent for enclosure tooling: rapid 3D prints, low-volume soft tooling, or production injection molding. Options: 3D printing, Soft tooling, Injection molding, Undecided
• Describe any clinical workflow mounting or sterilization interfaces the enclosure must include (for example tray mount, surgical drape compatibility, or hospital wall mount).
• Indicate whether you require generation of CAD exports for manufacturing including STEP files, 2D drawings, and a material spec sheet. Options: STEP + 2D drawings + material spec, Only STEP, Only 2D drawings, Other

Mechanical Design for Manufacturability

• Which manufacturing scale are you targeting for DFM: prototype short-run, pilot production (hundreds), or mass production (thousands+)? Options: Short-run prototypes, Pilot production (100s), Mass production (1000s+)
• List any supplier constraints that affect DFM such as preferred contract manufacturers, material sourcing restrictions, or domestic-only manufacturing.
• Estimate allowable per-unit cost targets for the assembled device including enclosure and PCB, excluding regulatory and tooling amortization. Options: Under $25, $25-$100, $100-$500, Above $500
• Detail required manufacturing acceptance criteria for mechanical fit and finish, for example torque values, snap-fit engagement depth, or paint/coat adhesion tests.
• Specify whether you require first-article inspection (FAI) documentation and the level of Cpk/quality metrics to be recorded. Options: FAI required with Cpk metrics, FAI required without Cpk, No FAI required

PCB Schematic, Layout, and Bill of Materials

• Which electronic subsystems must the PCB include: analog sensor front end, power management, cellular modem, Bluetooth Low Energy module, or others? Options: Analog sensor front end, Power management, Cellular modem, BLE module, Other
• Specify the preferred component lifecycle requirements for the BOM such as long-life parts, AEC-Q qualified components, or COTS only. Options: Long-life / lifecycle-managed, AEC-Q qualified, COTS acceptable, Undecided
• Identify the PCB assembly level required: prototype hand-assembled, SMT low-volume, or fully automated high-volume SMT. Options: Hand-assembled prototypes, Low-volume SMT, High-volume SMT
• Provide the target regulatory testing constraints for the PCB such as EMC margins, isolation distances, or creepage/clearance per IEC 60601-1.
• Indicate whether you require delivery of Gerber and ODB++ files, X-ray/layer stackup documentation, and a validated parts placement (pick-and-place) file. Options: Gerber + ODB++ + pick-and-place, Gerber + pick-and-place only, Gerber only, Other

Embedded Firmware Development and Debug

• Which software safety class will the embedded firmware be designed to under IEC 62304 (for example class A, B, or C)? Options: Class A (no injury hazard), Class B (possible injury), Class C (serious injury/death), Undetermined
• Describe required firmware features such as data sampling rates, local buffering, time sync, and power management policies.
• Identify your preferred bootloader and secure boot strategy including encryption or code signing requirements for firmware images. Options: Signed firmware images required, Unsigned allowed for prototype, Undecided
• Estimate the target overrun tolerance for interrupt latency and jitter for real-time sensor tasks in milliseconds. Options: Under 1 ms, 1-10 ms, 10-50 ms, Above 50 ms
• Which debugging artifacts do you require on delivery: source code repository, build pipeline, hardware-in-the-loop test scripts, or live debug session logs? Options: Source repo, Build pipeline, HIL test scripts, Debug logs, All of the above

Wireless Connectivity Integration (BLE/Wi‑Fi/Cellular)

• Which wireless radios must be integrated and tested: Bluetooth Low Energy with GATT profile, Wi‑Fi with enterprise auth, and/or cellular LTE with carrier certification? Options: BLE (GATT), Wi‑Fi, Cellular LTE, Multiple
• Specify required wireless performance thresholds such as minimum RSSI, first-packet latency on a hospital Wi‑Fi, or throughput for streaming telemetry.
• Identify the target BLE GATT services and characteristics you expect the device to expose for the companion app to consume.
• Detail any carrier or regulatory constraints for cellular modules such as specific carrier certification, eSIM support, or regional radio approvals.
• Indicate whether you require coexistence testing and EMC margin analysis between wireless subsystems and analog sensor chains. Options: Yes, required, Not required, Undecided

Over‑the‑Air Update Implementation

• Which update scope do you require OTA to cover: full firmware image, delta patches, bootloader updates, or application-layer only? Options: Full image, Delta patches, Bootloader updates, Application only, Other
• Specify the cryptographic requirements for OTA such as code signing algorithm, certificate rotation policy, and key escrow needs.
• Identify whether the OTA channel must support resumable downloads and integrity checks for low-bandwidth clinical environments. Options: Resumable + integrity checks, Integrity checks only, No special requirements
• State the maximum acceptable update window during clinical use (for example background update only or requires patient/device idle state). Options: Background only, Requires idle state, Requires clinical staff consent, Other
• Do you require an OTA rollback plan and verification evidence that rollback correctly restores the previous DHF-traced firmware? Options: Yes, No

Companion Mobile App Development (iOS and Android)

• Which app features are required at launch: device pairing, live telemetry display, local data caching, remote configuration, or clinician dashboard? Options: Device pairing, Live telemetry, Local caching, Remote configuration, Clinician dashboard, Other
• Specify required app security controls such as biometric login, encrypted local storage, and remote wipe capability for lost devices.
• Identify whether the app must meet platform store requirements including Apple App Store and Google Play health app policies. Options: Both stores, One store only, Undecided
• Describe the expected integration points between the app and device such as BLE characteristic UUIDs, pairing flow, and DFU initiation.
• Indicate required app deliverables on handoff: signed APK/IPA for testing, source code repository, and an SDK or API reference. Options: Signed APK/IPA + source repo + SDK, Signed binaries only, Source repo only, Other

Cloud Platform Integration and API Development

• Which cloud integration artifacts do you require: OpenAPI specification, event schema, data retention policy, and data export endpoints? Options: OpenAPI spec, Event schema, Data retention policy, Data export endpoints, All of the above
• Specify required data latency and throughput SLAs between device ingestion and analytics pipeline in seconds or messages per minute.
• Identify authentication method for device-cloud communication such as mutual TLS, JWT with rotating keys, or token-based API keys. Options: Mutual TLS, JWT rotating keys, API keys, Other
• Describe the data retention and de-identification requirements that must be enforced in the cloud to meet HIPAA or other privacy regimes.
• Indicate if you require integration with an electronic health record (EHR) or health information exchange and which interfaces are needed. Options: EHR integration required, No EHR integration, Undecided

Device Cybersecurity Controls and Technical Documentation

• Which artifact set do you expect for cybersecurity deliverables: SBOM (software bill of materials), threat model, penetration test report, and security requirements traceability? Options: SBOM, Threat model, Pen test report, Security traceability, All of the above
• Specify which standards or guidance should anchor cybersecurity work such as FDA premarket cybersecurity guidance, NIST Cybersecurity Framework, or IEC 62443. Options: FDA guidance, NIST CSF, IEC 62443, Other
• Identify expected hardening measures for the device such as secure boot, encrypted storage, minimum necessary network ports, and runtime integrity checks.
• Indicate whether you require third-party penetration testing and if so the scope: firmware, BLE channel, cloud APIs, or mobile app. Options: Firmware, BLE channel, Cloud APIs, Mobile app, All of the above, No pen test required
• Provide the required evidence package for cybersecurity acceptance such as SBOM, signed threat model, and a remediation plan for critical findings.

Risk Management File and Hazard Analysis

• Which risk standard should the risk management file follow: ISO 14971 identified processes and formats or an alternate format you provide? Options: ISO 14971, Alternate provided template, Undecided
• List the primary hazards you expect to analyze such as sensor failure modes, wireless disconnection during therapy, and false alarm rates.
• Specify required risk acceptance criteria including acceptable residual risk thresholds and severity/probability matrices.
• Indicate whether you require traceability between risks, design controls in the DHF, and verification test cases. Options: Full traceability required, Partial traceability, No traceability required
• Identify if a post-market risk management plan is required describing surveillance signals, vulnerability monitoring, and CAPA triggers. Options: Post-market plan required, Not required, Undecided

Design Verification Testing and Test Reports

• Which verification domains must be included in test reports: electrical safety, EMC, environmental (temperature/humidity), and firmware functional tests? Options: Electrical safety, EMC, Environmental, Firmware functional, All of the above
• Specify pass criteria for critical tests such as signal-to-noise ratio, ADC linearity, and wireless packet error rate.
• Indicate the level of traceability required from test cases back to design inputs and risk controls in the DHF. Options: Full traceability required, Test-to-requirement mapping only, No mapping required
• Provide the preferred test environments for verification: lab bench, clinical simulated environment, or accredited test lab. Options: Lab bench, Simulated clinical environment, Accredited test lab, Multiple
• What acceptance criteria will confirm verification is complete for transfer to manufacturing and regulatory submission (for example test coverage percentage and zero critical failures)?

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Pricing & Payment Schedule
• Acceptance Criteria & Verification Protocol
• Data Processing Agreement (DPA) / HIPAA Business Associate Addendum (BAA) [conditional]
• Data Sharing Authorization
• Project Governance & Timeline Agreement
• Change Order Agreement
• Intellectual Property & Licensing Exhibit
• Termination & Transition Plan

• Go-live Health Check (Week 1-4)
• First Outcomes Measurement (Weeks 4-10)
• Acceptance Gate: Post-Market Outcome Review (Day ~90)
• Vulnerability and Field Issue Triage (Monthly, then as needed)
• Quarterly Post-Market Review

• Assign owners and due dates for top-priority field issue tickets and update the ticketing system.
• Produce a documented pass/fail decision for each numeric acceptance criterion recorded in Solution Scope with a named buying signatory.
• For any failed criteria, agree remediation deliverables, owners, and re-test timelines sufficient to close the acceptance loop.
• Confirm which outcome artifacts will be stored in the DHF and post-market surveillance records.
• Publish the Acceptance Gate decision record with per-criterion outcomes and named signatory.
• Create remediation plans for failed criteria with owners, acceptance re-test metrics, and due dates.
• Deliver the finalized evidence package for archiving into the design history file and post-market files.
• Review open cybersecurity vulnerabilities
• Ensure high-severity vulnerabilities have assigned mitigations and scheduled patch deployments.
• Reduce the mean time to resolve field issues through assigned owners and committed resolution dates.
• Confirm any required regulatory or safety reporting actions are initiated with owners and dates.
• Publish the vulnerability remediation plan with severity, mitigation steps, and deployment windows.
• Reconfirm deployment checklist and owners
• Prepare any required safety or regulatory notification drafts for legal/QA review.
• Quarterly performance dashboard
• Confirm whether weekly active devices reporting and adverse event rates meet the Solution Scope targets.
• Ensure the top operational and regulatory risks have owners and quarter-specific mitigation plans.
• Clear or re-prioritize the enhancement backlog items that affect safety, connectivity, or data integrity.
• Deliver the quarterly performance report with metric trends and site-level breakdowns for archive.
• Assign remediation or process-change owners for the top three recurring failure modes with target completion dates.
• Update post-market surveillance and cybersecurity evidence packages with any new artifacts from the quarter.
• Confirm deployment checklist items recorded in Solution Scope are complete or have named owners and dates.
• Validate that device provisioning and initial data flow are functioning, or document remediations with owners and due dates.
• Agree the date and required data extracts for the First Outcomes Measurement meeting.
• Publish a deployment status summary showing completed checklist items and outstanding tasks with owners and dates.
• Owner to deliver device activation and enrollment export for the First Outcomes Measurement meeting.
• Create ticket(s) for any critical data-flow defects and assign remediation owners with target resolution dates.
• Present metric data vs targets
• Determine whether connectivity uptime and data transmission rate are on-track or require remediation.
• Agree a prioritized remediation plan with owners and dates to achieve targets by the Acceptance Gate.
• Confirm the data extracts and evidence each party will present at the Acceptance Gate meeting.
• Provide sliced metric exports (by site, firmware, and network) and the raw ingestion logs for diagnostic review.
• Create remediation tickets with owners and target dates for the top three root causes identified.
• Schedule a technical detailed review with engineering owners for any unresolved connectivity clusters.
• Restate acceptance criteria and numeric targets
• Field issue ticket burn-down
• Present outcome data against each criterion
• Diagnose gaps and root causes
• Deployment and provisioning validation
• Open issues and enhancement backlog status
• Coordinate patching and deployment windows
• Early adoption and usage signals
• Document pass/fail per criterion and decision
• Agree corrective actions and owners
• Support and operational metrics
• Escalations and regulatory safety notifications
• Regulatory and compliance posture
• Confirm readiness timeline to Acceptance Gate
• Agree remediation plan for any failed criteria
• Open issues and immediate remediation
• Record evidence for quality and regulatory traceability
• Document minor findings for operational follow-up
• Confirm next steps and owners
• Agree quarter actions and owners
• Confirm next steps and measurement timeline