Building a connected health device with a companion app but unsure whether your software meets FDA SaMD classification requirements and what documentation you need before you can market it?
Device telemetry generating patient data that lives in a proprietary cloud with no integration to the EHR, forcing clinical staff to check a separate portal for device readings?
Medical Device Software Development
Medical device software is not a standard app with a compliance layer added at the end. The software classification, the design controls, the risk management documentation, and the cybersecurity requirements are engineering decisions made at the start -- not retrofitted before submission.
We build software for medical devices and connected health hardware: companion apps for patient-facing devices, cloud platforms for device telemetry, clinical decision support layers, and the documentation framework that FDA and notified bodies ask for during review.
SaMD classification assessment and design control documentation framework (FDA 21 CFR Part 11, IEC 62304)
Companion mobile apps for iOS and Android with BLE/Wi-Fi device communication
Cloud telemetry platforms for device data ingestion, aggregation, and clinical alerting
FHIR R4 integration to push device data into Epic, Cerner, and other EMR systems
RaftLabs builds software for medical devices and connected health hardware -- embedded device firmware interfaces, companion mobile apps for patient-facing devices, cloud data platforms for device telemetry, FDA Software as a Medical Device (SaMD) classification considerations, IEC 62304 software lifecycle documentation, and integration with EHR systems via FHIR. We build for medical device manufacturers, digital health companies, and hospital operators deploying connected devices. Most medical device software projects deliver in 14-20 weeks at a fixed cost.
FDASaMD aware
·IEC 62304Lifecycle docs
·FixedCost delivery
·14-20Week delivery
Medical device software is a different engineering problem
The FDA classifies software that meets the definition of a medical device -- Software as a Medical Device (SaMD) -- under a risk-based framework. Class I, II, and III SaMD face different pre-market requirements, from 510(k) substantial equivalence submissions to De Novo requests and PMAs. Software that is NOT a medical device (Software in a Medical Device, SiMD) has different requirements entirely. Getting this classification wrong creates either unnecessary regulatory burden or a compliance gap that surfaces at the worst moment -- during a customer audit, an FDA inspection, or a clinical partnership review.
What engineering teams need beyond the regulatory framework: a device companion app that communicates reliably with hardware over BLE and Wi-Fi, handles reconnection gracefully, stores data locally when connectivity drops, and syncs cleanly to the cloud. A telemetry platform that ingests high-frequency device readings at scale, runs alerting logic in real time, and surfaces clinically relevant events to the right person on the care team. FHIR integration that puts device observations into the EHR without a manual data entry step. We build all of these alongside the design control documentation the regulatory process requires. We build for medical device manufacturers adding software to existing hardware, digital health companies launching connected device products, and hospital operators deploying connected devices who need a software platform alongside the hardware.
What we build
SaMD classification and design control framework
Assessment of whether your software meets the FDA's SaMD definition and which risk category applies based on the intended use and the significance of the information provided to clinical decision-making. Design control documentation covering software requirements specification, architecture design, risk management file (ISO 14971), hazard analysis, and traceability matrix linking requirements through to test evidence. IEC 62304 software lifecycle documentation for the development process. Cybersecurity documentation covering SBOM (Software Bill of Materials), threat modelling, and vulnerability management procedures per FDA's 2023 cybersecurity guidance for medical devices. We build the documentation alongside the software -- not as a post-development exercise.
Companion mobile applications
iOS and Android apps that communicate with medical devices over Bluetooth Low Energy (BLE) or Wi-Fi Direct. Connection management covering device pairing, reconnection on disconnection, background BLE scanning, and graceful handling of out-of-range events. Data display for device readings with appropriate precision and units. Local data storage when the device is offline with sync queue management when connectivity is restored. User authentication and device pairing linked to a clinical account. Accessibility requirements for medical app UIs -- font scaling, screen reader compatibility, and colour contrast ratios appropriate for patients with impairment. App Store and Play Store submission support including health app privacy documentation required by both platforms.
Device telemetry and data platform
Cloud ingestion layer for device telemetry streams -- high-frequency vital signs, continuous glucose readings, ECG waveforms, or intermittent measurement events depending on the device type. Time-series data storage with efficient querying for both real-time alerting and historical analysis. Real-time alerting engine that applies clinical threshold rules to incoming readings and routes alerts to the appropriate care team member via the clinical portal, mobile push, or EHR inbox message. Data aggregation for trend views and population health analytics across a patient cohort on the same device type. HIPAA-compliant data architecture with encryption at rest, in transit, and at the API layer, with PHI handling documented for your BAA and compliance review.
Clinical dashboard and alerting
Clinician-facing dashboard showing device readings per patient with trend graphs, alert history, and reading-to-clinical-note association. Alert queue showing unacknowledged alerts sorted by severity and time since trigger, with the ability to escalate, acknowledge, or dismiss with documentation. Patient cohort view for remote monitoring programmes showing aggregate compliance rates and alert frequency across all enrolled patients. Alert configuration UI so the clinical team can adjust threshold values and alert routing without a code change. Report generation for reimbursable remote patient monitoring CPT codes (99453, 99454, 99457, 99458) with time-in-monitoring tracking and data transmission counts per billing period.
EHR integration and FHIR
Device observation data pushed to Epic (FHIR R4), Cerner (FHIR R4), or other EHR systems using standard FHIR Observation and DiagnosticReport resources, so device readings appear in the clinical record alongside manually entered vitals. Patient demographic synchronisation from the EHR patient record to the device platform to keep identifiers aligned. Clinical order integration where the EHR order for remote monitoring triggers device enrolment in the platform. Result acknowledgement written back to the EHR so the clinician's review of device alerts is recorded in the clinical record. HL7 v2 interface as an alternative for EHR systems that do not yet support FHIR R4 APIs.
Cybersecurity and post-market surveillance
Cybersecurity architecture covering secure boot, firmware update authentication, encrypted BLE communication, certificate pinning for API calls from the companion app, and network segmentation for the cloud platform. Software Bill of Materials (SBOM) generation and vulnerability scanning integrated into the CI/CD pipeline so known vulnerabilities are identified before release. Post-market cybersecurity monitoring covering CVE tracking for third-party components in the SBOM and a vulnerability disclosure programme. Incident response procedure documentation per FDA post-market cybersecurity guidance. Audit logging of all user actions and system events for post-market surveillance and adverse event investigation.
Frequently asked questions
SaMD -- Software as a Medical Device -- is software that is intended to be used for a medical purpose without being part of a hardware medical device. If your software diagnoses, treats, monitors, or predicts a clinical condition, the FDA may classify it as SaMD. Software that runs on or controls hardware (SiMD) has different requirements under FDA Quality System Regulations. SaMD classification is risk-tiered: non-serious, serious non-critical, and critical -- based on the significance of the information provided to the clinical decision and the healthcare situation. We assess which category applies to your software based on the intended use statement. Regulatory counsel confirms the classification and submission strategy; we give you the technical picture so that conversation is grounded.
IEC 62304 defines the software lifecycle process for medical device software. The core documentation set includes: software development plan, software requirements specification, software architecture design, unit and integration test records, system test evidence, software risk management file (tied to ISO 14971 for the device-level hazard analysis), anomaly resolution records, and a traceability matrix linking each requirement to a design decision and a test result. The level of documentation required scales with the software safety class (A, B, or C) based on the severity of potential harm if the software fails. We build this documentation alongside the software during each development sprint -- not as a separate documentation project after the code is written.
Yes. Both Epic and Cerner expose FHIR R4 APIs that allow device data to be written as Observation and DiagnosticReport resources into the patient's clinical record. For Epic, integration goes through Epic App Orchard or directly via Epic's FHIR R4 APIs for organisations with existing Epic agreements. For Cerner, integration uses Cerner's open FHIR platform. Device observations, vital sign readings, and alert responses can all be written back to the patient record so the clinical team sees device data in the same place as manually entered vitals. For EHR systems that do not yet support FHIR R4, we implement HL7 v2 feeds as an alternative path.
The Consolidated Appropriations Act of 2023, Section 3305, created new pre-market cybersecurity requirements for medical devices submitted to FDA after October 2023. Device manufacturers must submit: a Software Bill of Materials (SBOM) listing all commercial and open-source components, a plan for monitoring and addressing post-market cybersecurity vulnerabilities, a coordinated vulnerability disclosure policy, and evidence that the device and its software were designed securely. Technically, this means SBOM generation at build time, a CVE monitoring process for components listed in the SBOM, a vulnerability disclosure intake mechanism, and documentation of the secure development lifecycle. We implement all of these in the development and CI/CD pipeline and deliver the documentation artefacts required for your submission.
