Custom software for medical device startups, SaMD companies, health monitoring hardware makers, and digital health vendors whose clinical software requirements, regulatory obligations, or device data architecture have outgrown generic platforms and off-the-shelf solutions.
SaMD platforms and companion apps built to FDA premarket submission requirements and IEC 62304 software lifecycle standards
Device data collection pipelines using AWS IoT, Azure IoT Hub, and Bluetooth Low Energy for continuous and periodic telemetry
Remote patient monitoring interfaces with real-time alert workflows, clinician dashboards, and FHIR R4 data models
Clinical data management systems with audit trails, role-based access, and HL7 integration to existing EHR platforms
The problem
Sitting on a working hardware prototype but no compliant software layer to collect, store, or display the device data it generates?
Your development team can build features fast but keeps hitting walls around FDA documentation, IEC 62304 traceability, and HIPAA data handling requirements?
Remote patient monitoring data flowing into spreadsheets and manual review queues because no purpose-built clinical interface exists?
Short answer
RaftLabs builds custom medical device software for SaMD companies, health monitoring device makers, and digital health startups: SaMD platforms, remote patient monitoring interfaces, and clinical data pipelines built to IEC 62304, ISO 13485, HIPAA, and EU MDR standards. A focused v1, such as a companion app or RPM dashboard, launches in 12 to 16 weeks at a fixed, agreed cost, then grows into a full platform.
Medical device software is purpose-built software that either functions as a medical device itself (Software as a Medical Device, or SaMD) or is embedded in a hardware medical device to drive its operation. It covers everything from companion mobile apps that pair with wearable health monitors, to clinical data management platforms that collect, process, and display patient data for clinical decision-making. Medical device software development follows regulated lifecycle standards, primarily IEC 62304 for the software lifecycle and ISO 14971 for risk management, and requires compliance with FDA premarket submission requirements, HIPAA data protection rules, and, for devices sold in the EU or UK, the Medical Device Regulation (MDR).
01 Diagnosis
Hardware is ready but software compliance is blocking your regulatory submission
You have a working device prototype. The clinical validation is in progress. But the software layer that drives the device, collects its data, or displays readings to clinicians was built without a documented software development lifecycle, and the FDA's premarket submission requirements demand one.Assembling IEC 62304-compliant documentation after the fact is expensive and slow. Traceability between requirements, design decisions, and test results has to be reconstructed from memory and commit logs. Each revision cycle to close documentation gaps delays your submission by weeks.We scope the regulatory documentation artefacts alongside the product build so the Software Requirements Specification, risk analysis, and verification records are produced as code is written, not pieced together under submission pressure. IEC 62304 applied from the first sprint keeps traceability intact, which is what turns a pre-submission documentation scramble into a routine export.
Device data ends up in spreadsheets because no compliant collection platform exists
Your device generates continuous telemetry: vitals, sensor readings, usage events. Today that data lands in CSV exports or manual review queues because the software infrastructure to receive, store, and surface it at clinical scale was never built.The cost is two-fold. First, clinical staff spend hours per week manually reviewing raw data exports, catching alerts late and missing patterns that a structured dashboard would surface immediately. Second, data held outside a HIPAA-compliant environment creates regulatory exposure that grows with every patient added.A purpose-built device data collection platform built on AWS IoT or Azure IoT Hub receives telemetry in real time, stores it in a HIPAA-compliant data environment with full audit logging, and surfaces it to clinicians through a structured dashboard with configurable alert thresholds. Manual review queues disappear.
Remote patient monitoring runs on disconnected tools with no clinical workflow
Patients are using the device at home. Data is coming in from Bluetooth-connected wearables or cellular-connected monitors. But the clinical team reviews it through a patchwork of vendor portals, phone calls, and email threads because no integrated remote patient monitoring interface exists.Late alert responses, missed readings, and clinician time spent on coordination rather than care are the operational symptoms. As patient volume grows, the patchwork breaks down completely and the program cannot scale without hiring more coordinators.A remote patient monitoring interface built for your clinical workflow puts all active patient data in one screen, routes alerts to the right clinician automatically, and documents every clinical decision in the patient record. Medicare reimburses remote patient monitoring care-management time through established CPT codes, so a structured RPM workflow that captures the required device readings and clinician minutes is a billing prerequisite, not just an operational preference.
EHR integration is stalled because the device data format does not match what the hospital IT team accepts
The hospital system your device is deployed in runs Epic or Cerner. Their IT team will accept FHIR R4 resources or HL7 v2 messages. Your device outputs proprietary binary or CSV data. The translation layer between them does not exist, so device data sits siloed in a vendor portal that clinicians do not check.Integration stalls turn into sales blockers. Procurement decisions at hospital systems increasingly require demonstrated EHR integration before a device enters the approved vendor list. Without it, your commercial pipeline slows and each deployment requires a manual configuration engagement.We build device data middleware that transforms raw telemetry into HL7 v2 ORU messages or FHIR R4 Observation resources and delivers them to the target EHR. SMART on FHIR for app launch within Epic, DICOM for imaging data, and bi-directional HL7 interfaces for result acknowledgment are all patterns we implement.
02 What we ship
We build Software as a Medical Device for iOS, Android, and web, covering the full software lifecycle required by IEC 62304. That means a documented Software Requirements Specification, a risk analysis aligned to ISO 14971, a Software Design Specification, and a full set of verification and validation test records that form part of your FDA premarket submission package.
Bluetooth Low Energy pairing with wearable and portable medical devices, cloud data transmission over Wi-Fi and LTE, and over-the-air firmware update management are all standard connectivity patterns we implement. UI design follows FDA human factors guidance so the interface does not introduce use errors that become adverse event reports.
Built for SaMD startups preparing for FDA 510(k) or De Novo submission, medical device makers adding a regulated software companion to an existing hardware product, and digital therapeutics companies building prescription software.
We build the backend infrastructure that receives telemetry from medical devices at scale: AWS IoT Core, Azure IoT Hub, or Google Cloud IoT for device connectivity; HIPAA-compliant data storage with encryption at rest; role-based access controls; and a complete audit log of every data access and modification that satisfies HIPAA technical safeguard requirements.
Data ingestion handles continuous streams from wearable sensors and periodic batch uploads from portable devices. Configurable alert rules fire when readings cross clinical thresholds, routing notifications to the appropriate clinical user. Time-series data is stored in a format that supports both real-time dashboards and retrospective clinical reporting.
Built for health monitoring device makers without an existing data backend, RPM program operators replacing manual data review processes, and digital health companies connecting multiple device types to a single data platform.
We build clinician-facing RPM dashboards that aggregate patient data from connected devices, display readings against configurable clinical thresholds, and route alerts to the responsible care team member without a manual triage step. Patient list views, individual patient timelines, reading trend charts, and alert acknowledgment workflows are all part of the standard interface pattern.
Patient-facing companion apps display readings back to the patient with education content, medication reminders, and symptom logging. Secure messaging between patient and care team reduces phone call volume. Medicare's RPM CPT codes reimburse care-management time, so the workflow also captures the device readings and clinician minutes a reimbursement claim has to document.
Built for RPM program operators scaling past what spreadsheet-based review can handle, health systems building an in-house RPM capability, and device companies that need a clinical interface to accompany their device in hospital procurement conversations.
We build clinical data management platforms that collect structured data from medical devices, clinical staff, and patient-reported outcomes; store it in a HIPAA-compliant environment with full audit logging; and make it available to the right user through role-based access controls. Every data field is timestamped and attributed to its source. Every access event is logged. Every modification is versioned.
Configurable data collection forms handle device onboarding, clinical assessments, and adverse event reporting. Reporting tools export data in formats compatible with FDA postmarket surveillance requirements and IRB-defined clinical study protocols. Integration with existing EHR platforms via FHIR R4 or HL7 v2 keeps the clinical record current without duplicate data entry.
Built for clinical research organizations managing device study data, health systems running postmarket surveillance programs, and medical device companies building the data infrastructure needed for FDA 522 postmarket study obligations.
We build the integration layer between medical device data and the EHR systems hospital IT teams will accept. Device telemetry is transformed into FHIR R4 Observation, DiagnosticReport, or DeviceMetric resources for systems running Epic's FHIR API or Cerner Millennium. HL7 v2 ORU interfaces handle legacy integration requirements at health systems that have not yet migrated to FHIR. DICOM integration handles imaging-adjacent device data.
SMART on FHIR enables your application to launch in-context within the Epic or Cerner clinical workflow, so clinicians access device data without switching systems. Bi-directional interfaces support result acknowledgment and order-driven device activation workflows. Every integration is scoped against the specific EHR version and site configuration rather than a generic specification.
Built for medical device companies whose hospital sales are blocked by missing EHR integration, digital health startups building SMART on FHIR applications for Epic App Orchard, and RPM operators whose device data needs to land in the patient record automatically.
We produce the software documentation package that FDA premarket submissions require: a Software Requirements Specification that maps to the IEC 62304 software safety class, a risk analysis in ISO 14971 format, a Software Design Specification with architecture diagrams, and a verification and validation test report covering unit, integration, and system testing. A Software Bill of Materials satisfies the FDA's cybersecurity documentation requirement for connected devices.
Change control documentation covers every post-release modification with an assessment of safety impact, updated risk analysis, and regression test evidence. Postmarket cybersecurity monitoring includes a vulnerability management plan and a defined process for issuing patches within the FDA's expected response timeframes for the device's risk class.
Built for medical device startups preparing their first 510(k) or De Novo submission, established device companies adding SaMD to an existing hardware submission, and quality teams that need a development partner who produces compliant documentation as a standard output, not an afterthought.
03 How we work
Four stages that produce submission-ready documentation as a by-product of the build, not a scramble after it.
We map the device, the clinical workflow it serves, and the regulatory pathway that applies to the software. FDA 21 CFR Part 820 quality system requirements, IEC 62304 safety class, ISO 13485 quality obligations, HIPAA technical safeguards, and, where the device is bound for the EU or UK, MDR and UKCA documentation needs are all fixed before development begins. Integration touchpoints, device connectivity protocols, and clinical user roles are scoped in detail. A fixed-price specification covering product scope, documentation artefacts, and milestones is agreed before any code is written.
We design the system architecture around the safety class and clinical use case. The data model, access control structure, device connectivity layer, and EHR integration approach are defined before implementation begins. FDA human factors guidance shapes the interface so it reduces rather than introduces use errors. Risk analysis in ISO 14971 format starts here, so identified hazards drive design decisions instead of being documented after them.
Development follows the IEC 62304 software lifecycle with a maintained matrix linking every requirement to its design decision, its implementation, and its test result. Working software ships at each two-week checkpoint so clinical stakeholders validate behavior against real device data rather than static specifications. Core data collection and display ships first; alert workflows, EHR integration, and reporting follow in subsequent builds.
Formal software validation covers unit testing, integration testing against the device and any EHR systems in scope, and system-level testing against the Software Requirements Specification. Penetration testing against OWASP and FDA cybersecurity guidance is completed before go-live. Post-launch support covers change management, postmarket surveillance data requirements, and product iterations as clinical use generates new requirements.
04 Safety classes
The standard sorts medical device software into three classes by the harm a software failure could cause. The class sets how much verification and documentation the build needs, and we confirm yours in the Classify stage.
Class A
No injury possible
A software failure cannot lead to injury or damage to health.
Class B
Non-serious injury possible
A failure could contribute to a non-serious injury.
Class C
Death or serious injury possible
A failure could contribute to death or serious injury.
Trusted by
05 Track record
We are straight about where our proof sits. We have not yet shipped a Class C implantable. Our closest work is in adjacent healthcare, where the data handling, HIPAA controls, and clinical workflows are the same problems medical device software has to solve. On a remote patient monitoring platform for PDC, a US healthcare company, and a telehealth platform for a US health system, we shipped the clinical interfaces, device data pipelines, and compliance controls that a device program needs.
06 Proof
07 Why us
08 Questions
Yes. We build SaMD with the documentation artefacts FDA requires for 510(k) and De Novo submissions: Software Requirements Specification, Software Design Specification, risk analysis aligned to ISO 14971, verification and validation test records, and a Software Bill of Materials for cybersecurity review. We scope the regulatory documentation package during discovery alongside the product build, so the submission artefacts are produced as the software is written, not assembled after the fact.
Yes. Our development process maps to IEC 62304 software safety classes A, B, and C. That means defined software development planning, requirements analysis, architectural design, detailed design, unit and integration testing, and a maintained problem resolution process. We document the lifecycle as we go, so every change is traceable from requirement to test result. Where your quality system runs to ISO 13485, or the device is bound for the EU under MDR or the UK under UKCA, the lifecycle records we produce feed the technical documentation those routes require. If your product sits in Class B or C, we build the traceability matrix into the workflow from day one.
HIPAA technical safeguards are designed into the architecture during discovery, not bolted on at the end. That means encryption of protected health information at rest and in transit, role-based access controls, session management and automatic logoff, a complete audit log of every access and modification to patient data, and a Business Associate Agreement covering our engagement. We do not provide legal compliance advice, but we build the technical controls your compliance team needs.
A focused first build, such as a companion mobile app for a wearable device or a remote patient monitoring dashboard, launches as a validated v1 in 12 to 16 weeks and starts in the $40,000 to $80,000 range. A full SaMD platform covering device data ingestion, clinical data management, clinician dashboards, and FHIR-based EHR integration is a larger, regulated build that grows into the $80,000 to $200,000 range as device complexity, safety class, and integration count increase. Fixed cost is agreed before development starts.
Yes. We build device data pipelines that transform raw telemetry into HL7 v2 or FHIR R4 Observation resources and deliver them to the target EHR or downstream analytics platform. SMART on FHIR for app launch within Epic, bi-directional HL7 interfaces, and DICOM for imaging-adjacent data are all integration patterns we implement. The integration complexity is scoped during discovery and factored into the fixed price.
Both. Early-stage startups often come with a hardware prototype and need the software and regulatory documentation built from scratch. Established device companies typically need a new SaMD companion, a data platform for a new device line, or an EHR integration to unblock hospital sales. The engagement structure is the same: fixed scope, fixed cost, IEC 62304-compliant process from day one.
Tell us what you are building, where you are in the regulatory process, and what your device data needs to do. We will scope it out together.
Stay on topic
Service
Healthcare SaaS Development
See the service
Service
Regulatory Document Management Software for Pharma
See the service
Service
Remote Patient Monitoring Development
See the service
Service
Dental Patient Communication Software Development
See the serviceProof
Brux ships a dental marketing SaaS: AI smile previews, GoHighLevel sync, and self-serve onboarding built for 1,000-office scale
Read the case studyTry it yourself
HIPAA Compliance Checklist
30+ requirements, plain-English, filtered to what you're building.
Open the free tool