What you will learn
By the end of this topic, you should be able to explain the application software engineer’s medical-device responsibilities; distinguish application concerns from embedded control; define workflows, data and interfaces; implement safety, usability, privacy and cybersecurity controls; produce proportionate verification evidence; and release software that can be deployed, supported and changed under control.
The application software engineer’s role
Application software turns clinical, operational and user needs into visible workflows and information. It may acquire or present results, guide a procedure, configure a device, calculate a value, exchange health information or support service. Its apparent distance from the physical device does not reduce its potential contribution to harm.
Workflow integrity
Ensure the right user can perform the right action, in the right sequence and context.
Data integrity
Preserve meaning, identity, units, provenance, completeness and association with the correct patient or device.
Safe interaction
Make status, limitations, alarms, confirmation, errors and recovery understandable.
Controlled evidence
Connect requirements, architecture, code, tests, dependencies, releases and field behaviour.
Separate application and embedded responsibilities explicitly
The boundary should follow responsibility, not programming language or processor. Embedded software usually owns hardware-near control, timing and diagnostics. Application software usually owns workflows, presentation, business rules, persistence, reporting and external-system integration. Shared concerns include system states, interface meaning, logging, cybersecurity, updates and end-to-end risk controls.
Agree the contract with MTL-207 — Embedded Software Engineers in Medical-device Development and define the complete system through MTL-105 — Systems Engineering, Architecture and Interfaces.
Contribute across the complete lifecycle
Define the application context
Users, workflows, claims, environments, system boundary and regulatory status.
Specify observable behaviour
Application requirements, business rules, data definitions, interfaces and acceptance criteria.
Design for safe workflows
Architecture, states, permissions, data integrity, error handling and risk-control allocation.
Implement under control
Source, configuration, dependencies, reviews, automated checks and reproducible builds.
Verify progressively
Unit, integration, workflow, interface, platform, security and regression evidence.
Release and maintain
Identifiable releases, deployment instructions, monitoring, problem resolution and controlled updates.
Use MTL-108 — Software Lifecycle and MTL-312 — IEC 62304 Software Lifecycle as the connected process foundations.
Specify behaviour that users and systems can observe
- Define users, roles, permissions, prerequisites and operating context.
- Describe normal, alternative, interrupted, invalid and recovery workflows.
- Specify calculations, rounding, units, limits and handling of missing or inconsistent data.
- Define interface messages, semantics, timing, acknowledgement, duplication and failure behaviour.
- State performance, capacity, availability, compatibility and accessibility needs.
- Make logging, audit, retention, export and deletion behaviour testable.
Requirements should trace to user needs, risk controls and acceptance evidence through MTL-103 — User Needs and Design Inputs.
Design workflows and state—not isolated screens
Model the user’s complete task, including entry conditions, transitions, concurrent events, interruptions, timeouts, confirmation, cancellation and recovery. Show device state, patient context, data validity and connectivity accurately. Prevent stale screens or delayed messages from presenting an unsafe picture of the system.
Work with usability specialists using MTL-110 — Usability and Human Factors; do not treat a polished interface as evidence of safe use.
Protect data meaning and association
Connect the design to MTL-111 — Data, Connectivity and Interoperability and MTL-112 — Privacy and Data Protection by Design.
Control platforms, services and third-party software
Operating systems, frameworks, databases, libraries, browsers, mobile platforms, cloud services and external APIs are part of the product dependency model. Record exact versions and configurations, intended use, known anomalies, vulnerabilities, support periods and update constraints. Verify the actual supported combinations and define what happens when a platform changes outside the manufacturer’s control.
Engineer safety, security and privacy together
- Translate hazardous sequences into application-level risk-control requirements.
- Control authentication, authorisation, session state and privileged actions.
- Validate data at trust boundaries and fail safely when dependencies are unavailable.
- Protect secrets, health information and security-relevant logs.
- Define update authenticity, rollback, compatibility and interrupted-update behaviour.
- Assess whether a cybersecurity failure could create a safety impact.
Use MTL-114 — Medical-device Risk Management and MTL-109 — Medical-device Cybersecurity.
Verify from rules to real workflows
Combine unit and component tests with database, API, interface, workflow, platform, installation, upgrade, usability, security and end-to-end system tests. Exercise invalid data, interrupted operations, timing, concurrency, permissions, loss of connectivity, recovery and supported platform combinations. Maintain traceability and explain unresolved anomalies.
Release a deployable and supportable product
A release should identify source and dependency baselines, build configuration, executable artefacts, database migrations, deployment settings, supported platforms, cybersecurity information, known anomalies and rollback arrangements. Monitoring and support should distinguish product defects, platform changes, data problems, misuse and external-service failures.
Control lifecycle changes with MTL-129 — Configuration and Change Management.
Work across the complete product
Application engineers should participate in user research, system architecture, risk analysis, privacy assessment, cybersecurity threat modelling, interface definition, verification planning, release review and post-market investigation. Escalate assumptions and unresolved interface ownership early; hidden gaps between teams are a common source of unsafe behaviour.
Common misconceptions
“The application cannot harm anyone because it does not control hardware.”
Incorrect information, delayed action, wrong-patient association or unsafe workflow can contribute directly to harm.
“The framework handles security.”
Libraries provide mechanisms; the product still needs a threat-informed architecture, secure configuration and lifecycle control.
“Automated tests prove the user workflow.”
Automation is valuable, but representative end-to-end, usability and abnormal-condition evidence remain necessary.
Authoritative starting points
Application software is a clinical and operational behaviour system—not a collection of screens
Control workflows, data, interfaces, dependencies and releases as one traceable part of the medical device.