Software for devices worn on the body, and for the care teams who watch the data they produce.
These four systems were delivered by our founder through an earlier company, Hashtaag Technologies, which Biofourmis later acquired. They are not Innometrique client projects. Innometrique started in 2025. We list them because they are the experience this page is based on. The founder's track record page has the full detail.
A cardiac care platform for patients recovering at home. It took readings from wearables and a mobile app, processed them in real time, and fed a dashboard that a care team watched around the clock. The aim was to spot a patient getting worse before they needed to go back to hospital.
The analytics engine behind Biofourmis products. It worked with data from many different sensors, including FDA and CE approved ones, and learned each patient's own baseline so it could flag decline, recovery, or changes caused by medication.
A mobile app for people recovering from hip and thigh replacement surgery, built with Mundipharma. It tracked recovery and how well pain medication was working, using Bluetooth connected devices that fed the biovitals engine.
A full mobile app, from design to working code, for a wearable dialysis device. This included the protocol work between the app and the device: building data packets and handling the device's replies.
Most of these products follow the same path. Each step can fail in its own way, so we test them one at a time and then together.
A wearable or sensor on the patient reads vitals.
Pairs over Bluetooth and sends the readings on.
Cleans, stores and time-stamps every reading.
Learns what normal looks like for this patient.
A dashboard shows who needs attention first.
A fixed alert level treats every patient the same. Someone whose heart rate normally sits near 62 can get noticeably worse and still stay under a fixed line. Someone whose normal is high can trigger alerts every day for no reason.
A personal baseline learns each patient's usual range during the first days of data. It then flags changes against that range. The chart shows the idea.
Fewer false alerts also matters for the people reading them. A team that gets too many alerts starts to ignore them.
This is the part many app teams have not done before. A device is not an API. These are the things we plan for early:
In the United States, the FDA has a final guidance, issued in December 2024, on predetermined change control plans for AI-enabled device software. A plan like this says up front which changes to the model are allowed, how each change will be built and tested, and how its effect will be checked. That can let a model improve without a new submission every time.
Also, the FDA's Quality Management System Regulation took effect on 2 February 2026. It builds on ISO 13485. In practice your quality system sets the rules for how software is planned, tested and documented. We work inside it.
Sources: FDA predetermined change control plan guidance and FDA QMSR page. Rules change, so check with your regulatory advisor.
We want this clear from the first call. We are a software engineering partner, not a regulatory consultant.
We do not hold FDA or CE clearance, an ISO 13485 certificate or a HIPAA attestation as a company, and we do not claim to.
For a project of this kind we suggest a paid discovery sprint of two to four weeks. We test the riskiest part, usually the device connection or the data, and give you a fixed-scope plan. You can get a rough range first with the cost estimator.
No. We build the software and write documents for your team to review. Your regulatory team or advisor handles the submission.
Yes. Share your procedures early and we will plan, test and document to them.
Bluetooth connected devices, including ones with their own protocol. The first step is reading the device's interface notes and testing a real unit.
You do. You receive the source code and the documentation.
Tell us what the device does and where you are now. We will reply within one business day.
Tell us about your project →