Cross-Platform Medical Simulation Application — Android and iOS
Budget / Salary$1,500–3,000
TypeFreelance project
LocationRemote
Posted1 hour ago
I am looking for a developer to create a cross-platform medical simulation and training application for Android and iOS using a shared codebase.
This application is intended for medical education and simulation. It will simulate the operation of a patient monitor, AED and defibrillator. It is not intended to control a real medical device unless physical-device integration is separately agreed in writing.
I have an existing detailed project specification and additional requirements. The final scope consists of the attached specification together with the requirements described below.
MOST IMPORTANT REQUIREMENTS
1. SMOOTH ECG AND PATIENT-MONITOR WAVEFORMS
The most important part of this project is the smooth and realistic display of ECG and other patient-monitor waveforms.
The application should support:
- ECG waveforms.
- 12-lead ECG.
- SpO2 waveform.
- EtCO2 waveform.
- Respiratory-rate waveform where applicable.
- Heart rate, QTc, blood pressure/MAP, pulse and temperature values.
- Real-time changes to patient parameters.
- Alarm events and emergency-procedure actions.
The waveforms must not freeze, visibly stutter, restart or jump whenever the user changes a parameter or when data is received from another device.
The communication layer must not block the user interface or interrupt waveform rendering. The developer must explain how the simulation engine, communication layer and rendering layer will be separated. Please also document the update rate, buffering and interpolation strategy.
The developer must demonstrate waveform smoothness on real Android and iOS devices, not only in an emulator.
2. COMMUNICATION THROUGH BOTH WI-FI AND BLUETOOTH
The application must support communication between devices through both:
- Wi-Fi.
- Bluetooth.
Bluetooth is a required communication method. It must not be omitted and must not be used only for device discovery.
The application should support:
- Nearby-device discovery.
- Device selection.
- Connection status.
- Connection errors.
- Temporary connection interruption.
- Reconnection where technically possible.
- Safe disconnection.
The developer must test both Wi-Fi and Bluetooth on real devices. During communication, the ECG and other waveforms must continue to work smoothly.
APPLICATION MODES
The application must include three operating modes:
1. INSTRUCTOR MODE
The instructor uses one phone or tablet to connect to a patient monitor, select or create a scenario, configure the patient and control the simulation in real time.
Instructor Mode must include:
- Connecting to a Patient Monitor.
- Selecting or creating a scenario.
- Selecting the monitor layout.
- Configuring the initial patient condition.
- Changing HR, QTc, ECG rhythm, BP/MAP, SpO2, EtCO2, RR, pulse and temperature.
- Triggering and configuring alarms.
- Starting, pausing/stopping and ending the simulation.
- Displaying a 12-lead ECG on the monitor.
- Uploading an image or animation to the monitor.
- Enabling ECG artifacts.
- Configuring after how many defibrillator shocks the rhythm changes.
- Selecting which rhythm is displayed after the specified number of shocks.
- Synchronizing relevant changes with the connected monitor in real time.
2. MONITOR MODE
The device operates as a realistic Patient Monitor and receives the instructor’s changes.
It should display, where applicable:
- ECG waveforms.
- 12-lead ECG.
- HR and QTc.
- SpO2 and waveform.
- EtCO2 and waveform.
- BP/MAP and recent measurement history.
- RR.
- Pulse.
- Temperature.
- Alarm indicators and audible alarms.
- Simulation status.
- Connection status.
When the instructor starts the simulation, the monitor should automatically open the live-monitor screen.
3. STANDALONE MONITOR MODE
The user can operate the simulation completely on one device without connecting to a remote controller.
The user must be able to:
- Select or create a scenario.
- Configure the patient.
- Start and stop the simulation.
- Change patient parameters directly.
- Change the ECG rhythm directly.
- Configure alarms.
- Use AED functions.
- Use Defibrillator functions.
- Use Cardioversion functions.
- Use Pacing functions.
- Use the CPR Metronome.
AED AND DEFIBRILLATOR REQUIREMENTS
AED Mode and Defibrillator Mode must work in both:
- Monitor Mode.
- Standalone Monitor Mode.
Defibrillator Mode must include:
- Switching the defibrillator on.
- Selecting the energy level.
- Pressing the Charge button.
- Displaying the charging state.
- Delivering a simulated shock.
- Updating the simulation state after the shock.
- Synchronizing the event with the monitor during a remote session.
- Cardioversion as a function within Defibrillator Mode.
- Pacing as a function within Defibrillator Mode.
The CPR Metronome must be available as a function within both AED Mode and Defibrillator Mode.
The user must be able to complete the following simulated sequence:
1. Activate the defibrillator.
2. Set the energy level.
3. Press Charge.
4. Press Discharge
4. Deliver a simulated shock.
5. Display the result of the shock in the simulation.
6. Set Cardioversion function
7. Set- Pacing function
In Instructor Mode, the instructor must be able to define after how many shocks the rhythm changes and which rhythm is selected afterwards.
These are simulation functions. Physical AED or defibrillator hardware integration is excluded unless separately agreed in writing.
REFERENCE APPLICATIONS
The developer should review the SIM-MON and free Simple Monitor applications to understand the expected interaction and behavior of monitor, AED and defibrillator functions.
The final interface may have a different visual design or layout. It does not need to copy the reference applications graphically. However, the relevant functions and logical behavior should be comparable. No protected code or graphic assets may be copied.
ADDITIONAL FEATURES
The application should also include:
- Three monitor layouts: Basic, Extended and Vital Signs.
- Scenario creation, editing, deletion, saving and loading.
- Local storage of settings and scenarios.
- Alarm thresholds for HR, BP, SpO2, RR and EtCO2.
- Oxygen/air selection.
- Consciousness states and NEWS score as specified in the attached documentation.
- Seven languages: English, Polish, Spanish, German, French, Portuguese and Italian.
- Free Demo Version with full simulation functionality during an active 15-minute session.
- Paywall after Demo expiration.
- One-time in-app purchase to unlock the Full Version.
- No subscription is required under the current scope.
- Settings for communication preferences, EtCO2 unit, device name, session duration and BP display behavior.
- User-friendly error and recovery messages.
DEVELOPMENT AND PAYMENT METHOD
The project must be completed through fixed-price milestones on Freelancer.
The project must not be treated as one single payment for the entire application.
Each milestone must include:
- A working test build.
- A list of completed functions.
- A list of known issues.
- Updated source code in the project repository.
- A short description of how the result was tested.
A milestone will be released only after the client has tested and accepted the result against the agreed acceptance criteria.
PROPOSED MILESTONES
1. Technical analysis, architecture and waveform prototype.
2. Wi-Fi and Bluetooth communication.
3. Smooth ECG and vital-sign waveform engine.
4. Live Patient Monitor and monitor layouts.
5. Instructor Mode and real-time control.
6. AED, Defibrillator, Cardioversion, Pacing and CPR Metronome.
7. Scenario Management, local storage and Standalone Monitor Mode.
8. Demo Mode, Paywall and one-time purchase.
9. Seven-language localization and Settings.
10. Final testing, bug fixing, documentation and handover.
ACCEPTANCE PRIORITIES
The first acceptance priorities are:
- Smooth and realistic waveforms.
- Reliable Wi-Fi communication.
- Reliable Bluetooth communication.
- No freezing or stuttering during communication or parameter changes.
- Correct behavior on real devices.
- Correct synchronization between the Instructor device and the Monitor device.
SOURCE CODE AND FINAL HANDOVER
The final delivery must include:
- Complete source code.
- Git repository or complete repository export.
- Project and configuration files.
- Build and installation instructions.
- Localization files.
- Scenario and test data.
- List of external libraries and licenses.
- Android and iOS build instructions.
- App Store and Google Play preparation materials.
- All project-specific graphics and audio files created for this project.
The client must own or control the Apple Developer and Google Play accounts used for publication. The developer must not retain exclusive control over the source code, repository or publishing accounts after completion.
The developer must also help prepare and publish the application on both the Apple App Store and Google Play. This includes preparing the Android and iOS release builds, configuring the required signing and store settings, uploading the builds, assisting with the submission process, and responding to technical rejection messages from Apple or Google.
The client will own and administer the Apple Developer and Google Play accounts. App Store, Google Play and third-party account fees are paid directly by the client. Technical publication support is included in the agreed project scope and is not an optional extra.
WEEKLY COMMUNICATION
The developer must provide a weekly update containing:
- Completed work.
- Work currently in progress.
- Planned work for the next week.
- Problems and risks.
- Link to the current test build.
- List of known bugs.
- Confirmation whether the schedule and budget remain vali
This application is intended for medical education and simulation. It will simulate the operation of a patient monitor, AED and defibrillator. It is not intended to control a real medical device unless physical-device integration is separately agreed in writing.
I have an existing detailed project specification and additional requirements. The final scope consists of the attached specification together with the requirements described below.
MOST IMPORTANT REQUIREMENTS
1. SMOOTH ECG AND PATIENT-MONITOR WAVEFORMS
The most important part of this project is the smooth and realistic display of ECG and other patient-monitor waveforms.
The application should support:
- ECG waveforms.
- 12-lead ECG.
- SpO2 waveform.
- EtCO2 waveform.
- Respiratory-rate waveform where applicable.
- Heart rate, QTc, blood pressure/MAP, pulse and temperature values.
- Real-time changes to patient parameters.
- Alarm events and emergency-procedure actions.
The waveforms must not freeze, visibly stutter, restart or jump whenever the user changes a parameter or when data is received from another device.
The communication layer must not block the user interface or interrupt waveform rendering. The developer must explain how the simulation engine, communication layer and rendering layer will be separated. Please also document the update rate, buffering and interpolation strategy.
The developer must demonstrate waveform smoothness on real Android and iOS devices, not only in an emulator.
2. COMMUNICATION THROUGH BOTH WI-FI AND BLUETOOTH
The application must support communication between devices through both:
- Wi-Fi.
- Bluetooth.
Bluetooth is a required communication method. It must not be omitted and must not be used only for device discovery.
The application should support:
- Nearby-device discovery.
- Device selection.
- Connection status.
- Connection errors.
- Temporary connection interruption.
- Reconnection where technically possible.
- Safe disconnection.
The developer must test both Wi-Fi and Bluetooth on real devices. During communication, the ECG and other waveforms must continue to work smoothly.
APPLICATION MODES
The application must include three operating modes:
1. INSTRUCTOR MODE
The instructor uses one phone or tablet to connect to a patient monitor, select or create a scenario, configure the patient and control the simulation in real time.
Instructor Mode must include:
- Connecting to a Patient Monitor.
- Selecting or creating a scenario.
- Selecting the monitor layout.
- Configuring the initial patient condition.
- Changing HR, QTc, ECG rhythm, BP/MAP, SpO2, EtCO2, RR, pulse and temperature.
- Triggering and configuring alarms.
- Starting, pausing/stopping and ending the simulation.
- Displaying a 12-lead ECG on the monitor.
- Uploading an image or animation to the monitor.
- Enabling ECG artifacts.
- Configuring after how many defibrillator shocks the rhythm changes.
- Selecting which rhythm is displayed after the specified number of shocks.
- Synchronizing relevant changes with the connected monitor in real time.
2. MONITOR MODE
The device operates as a realistic Patient Monitor and receives the instructor’s changes.
It should display, where applicable:
- ECG waveforms.
- 12-lead ECG.
- HR and QTc.
- SpO2 and waveform.
- EtCO2 and waveform.
- BP/MAP and recent measurement history.
- RR.
- Pulse.
- Temperature.
- Alarm indicators and audible alarms.
- Simulation status.
- Connection status.
When the instructor starts the simulation, the monitor should automatically open the live-monitor screen.
3. STANDALONE MONITOR MODE
The user can operate the simulation completely on one device without connecting to a remote controller.
The user must be able to:
- Select or create a scenario.
- Configure the patient.
- Start and stop the simulation.
- Change patient parameters directly.
- Change the ECG rhythm directly.
- Configure alarms.
- Use AED functions.
- Use Defibrillator functions.
- Use Cardioversion functions.
- Use Pacing functions.
- Use the CPR Metronome.
AED AND DEFIBRILLATOR REQUIREMENTS
AED Mode and Defibrillator Mode must work in both:
- Monitor Mode.
- Standalone Monitor Mode.
Defibrillator Mode must include:
- Switching the defibrillator on.
- Selecting the energy level.
- Pressing the Charge button.
- Displaying the charging state.
- Delivering a simulated shock.
- Updating the simulation state after the shock.
- Synchronizing the event with the monitor during a remote session.
- Cardioversion as a function within Defibrillator Mode.
- Pacing as a function within Defibrillator Mode.
The CPR Metronome must be available as a function within both AED Mode and Defibrillator Mode.
The user must be able to complete the following simulated sequence:
1. Activate the defibrillator.
2. Set the energy level.
3. Press Charge.
4. Press Discharge
4. Deliver a simulated shock.
5. Display the result of the shock in the simulation.
6. Set Cardioversion function
7. Set- Pacing function
In Instructor Mode, the instructor must be able to define after how many shocks the rhythm changes and which rhythm is selected afterwards.
These are simulation functions. Physical AED or defibrillator hardware integration is excluded unless separately agreed in writing.
REFERENCE APPLICATIONS
The developer should review the SIM-MON and free Simple Monitor applications to understand the expected interaction and behavior of monitor, AED and defibrillator functions.
The final interface may have a different visual design or layout. It does not need to copy the reference applications graphically. However, the relevant functions and logical behavior should be comparable. No protected code or graphic assets may be copied.
ADDITIONAL FEATURES
The application should also include:
- Three monitor layouts: Basic, Extended and Vital Signs.
- Scenario creation, editing, deletion, saving and loading.
- Local storage of settings and scenarios.
- Alarm thresholds for HR, BP, SpO2, RR and EtCO2.
- Oxygen/air selection.
- Consciousness states and NEWS score as specified in the attached documentation.
- Seven languages: English, Polish, Spanish, German, French, Portuguese and Italian.
- Free Demo Version with full simulation functionality during an active 15-minute session.
- Paywall after Demo expiration.
- One-time in-app purchase to unlock the Full Version.
- No subscription is required under the current scope.
- Settings for communication preferences, EtCO2 unit, device name, session duration and BP display behavior.
- User-friendly error and recovery messages.
DEVELOPMENT AND PAYMENT METHOD
The project must be completed through fixed-price milestones on Freelancer.
The project must not be treated as one single payment for the entire application.
Each milestone must include:
- A working test build.
- A list of completed functions.
- A list of known issues.
- Updated source code in the project repository.
- A short description of how the result was tested.
A milestone will be released only after the client has tested and accepted the result against the agreed acceptance criteria.
PROPOSED MILESTONES
1. Technical analysis, architecture and waveform prototype.
2. Wi-Fi and Bluetooth communication.
3. Smooth ECG and vital-sign waveform engine.
4. Live Patient Monitor and monitor layouts.
5. Instructor Mode and real-time control.
6. AED, Defibrillator, Cardioversion, Pacing and CPR Metronome.
7. Scenario Management, local storage and Standalone Monitor Mode.
8. Demo Mode, Paywall and one-time purchase.
9. Seven-language localization and Settings.
10. Final testing, bug fixing, documentation and handover.
ACCEPTANCE PRIORITIES
The first acceptance priorities are:
- Smooth and realistic waveforms.
- Reliable Wi-Fi communication.
- Reliable Bluetooth communication.
- No freezing or stuttering during communication or parameter changes.
- Correct behavior on real devices.
- Correct synchronization between the Instructor device and the Monitor device.
SOURCE CODE AND FINAL HANDOVER
The final delivery must include:
- Complete source code.
- Git repository or complete repository export.
- Project and configuration files.
- Build and installation instructions.
- Localization files.
- Scenario and test data.
- List of external libraries and licenses.
- Android and iOS build instructions.
- App Store and Google Play preparation materials.
- All project-specific graphics and audio files created for this project.
The client must own or control the Apple Developer and Google Play accounts used for publication. The developer must not retain exclusive control over the source code, repository or publishing accounts after completion.
The developer must also help prepare and publish the application on both the Apple App Store and Google Play. This includes preparing the Android and iOS release builds, configuring the required signing and store settings, uploading the builds, assisting with the submission process, and responding to technical rejection messages from Apple or Google.
The client will own and administer the Apple Developer and Google Play accounts. App Store, Google Play and third-party account fees are paid directly by the client. Technical publication support is included in the agreed project scope and is not an optional extra.
WEEKLY COMMUNICATION
The developer must provide a weekly update containing:
- Completed work.
- Work currently in progress.
- Planned work for the next week.
- Problems and risks.
- Link to the current test build.
- List of known bugs.
- Confirmation whether the schedule and budget remain vali
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.