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
Sound familiar?
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 designed around IEC 62304, ISO 13485, HIPAA technical safeguards, and EU MDR documentation requirements. 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.
01 Diagnosis
Problems we solve in medical device software
01
Problem
Hardware is ready but software compliance is blocking your regulatory submission
Solution
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.
02
Problem
Device data ends up in spreadsheets because no compliant collection platform exists
Solution
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 and stores it in a data environment configured for HIPAA-grade access controls with full audit logging. Clinicians see it through a structured dashboard with configurable alert thresholds. Manual review queues disappear.
03
Problem
Remote patient monitoring runs on disconnected tools with no clinical workflow
Solution
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.
04
Problem
EHR integration is stalled because the device data format does not match what the hospital IT team accepts
Solution
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
Medical device software we build
01
SaMD platforms and companion apps
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.
02
Device data collection and IoT platforms
We build the backend infrastructure that receives telemetry from medical devices at scale. That means AWS IoT Core, Azure IoT Hub, or Google Cloud IoT for device connectivity, plus data storage configured for HIPAA-grade access controls with encryption at rest. Role-based access controls and a complete audit log cover every data access and modification.
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.
03
Remote patient monitoring interfaces
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.
04
Clinical data management systems
We build clinical data management platforms that collect structured data from medical devices, clinical staff, and patient-reported outcomes. The data sits in an environment configured for HIPAA-grade access controls with full audit logging, and is made available to the right user through role-based access controls. Each data field is timestamped and attributed to its source, and every access event is logged. Modifications are versioned, so the history is always recoverable.
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.
05
EHR integration and interoperability
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.
06
Regulatory documentation and software validation
We produce the software documentation package that FDA premarket submissions require. That includes 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, and for established device companies adding SaMD to an existing hardware submission. Quality teams get compliant documentation produced as a standard output, not an afterthought.
Safety classes
How IEC 62304 safety class shapes the build
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.
Software development plan
Requirements and architecture
System-level verification
Class B
Non-serious injury possible
A failure could contribute to a non-serious injury.
Everything in Class A
Detailed design documented
Integration testing and traceability
Class C
Death or serious injury possible
A failure could contribute to death or serious injury.
Everything in Class B
Unit-level verification
Rigorous risk controls end to end
Most SaMD and connected-device software we build sits in Class B or C, where the traceability matrix is built into the workflow from day one rather than reconstructed for submission.
03 Buy, build, or wait
The medtech software question is really about when regulatory obligation makes generic platforms a dead end.
Buy or rent
Vendor portals and manual review, for the earliest prototype
Fine while device data volume is small and the submission is far off.
Wait, while no regulated claim is in the product
Stay manual until you need documented lifecycle, risk, and validation artefacts.
Build custom
When FDA submission needs IEC 62304 traceability
Requirements, design, and test evidence must link up; reconstructed documentation delays submission.
When device data outgrows spreadsheets and vendor portals
Clinicians need one compliant interface with alerts and audit trails, not patchwork tools.
When hospital sales need EHR integration
Procurement increasingly requires demonstrated Epic or Cerner integration before a device is approved.
Bottom line
Stay on vendor portals and manual review while data volume is small and no submission is pending. Build when regulatory traceability, clinical scale, or hospital procurement blocks you.
Four stages that produce submission-ready documentation as a by-product of the build, not a scramble after it.
01
Classify
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.
02
Architect for risk
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.
03
Build on a live traceability matrix
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 your clinicians 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.
04
Verify and validate
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.
Trusted by
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.
05 Track record
What medtech teams get when they work with us
01
Weeks to a validated v1, such as a companion app or RPM dashboard, then iterate into a full platform
12-16
02
Cost agreed before development starts, no change orders for scope defined at discovery
Fixed
03
Software lifecycle documentation produced as a standard output on every regulated build
IEC 62304
04
Risk analysis maintained from design decisions through validation, not written up after the fact
ISO 14971
08 Why us
Why choose us?
01
We've seen your problem before
Across dozens of industries, we recognise your situation fast, then frame the fix around your margin and your operations, not a generic template.
02
We own the number, not the ticket
We measure success the way you do: hours saved, revenue earned, margin recovered. We stay through launch and growth, so the result is ours to own.
03
Serious businesses trust us
Vodafone, T-Mobile, Cisco, Energia, Aldi, Nike. Building since 2015. Serious businesses keep coming back because we stay accountable long after launch.
09 Questions
Common 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 each requirement links to its design decision, its implementation, and its 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. A full SaMD platform covering device data ingestion, clinical data management, clinician dashboards, and FHIR-based EHR integration is a larger, regulated build scoped separately by device complexity, safety class, and integration count. We scope every project before pricing. Fixed cost, agreed before work 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.