GuidelinesGMP2026.10.27
Medical Device Software Updates: Connecting Versions to Deployment Records
Recording that an update was sent does not complete change control. Link the reason, risk assessment, verification, regulatory decision and actual installation status for each affected device.
Key point — A change record should run from the request to verified installation. Sending a file is different from confirming the correct version on every intended device.
Assess the actual change before its version label
A small fix or security patch can affect measurement results, alarms, data storage or connections. Conversely, a simple text change does not necessarily require a new authorization. Explain the changed behavior and compare it with the Korean license, certification or notification.
Quality-system approval and regulatory change procedures require separate assessments. Consider Articles 12 and 15 of the Medical Devices Act and the other provisions applicable to the product. Products governed by the digital medical product framework require that assessment as well. This record example is not a universal regulatory classification table. See the change approval guide for the basic distinction.
Connect four decisions to one change
KGMP Annex 2 section 7.3.9 requires assessment of the significance of design changes, followed by review, verification, validation where applicable, and approval before implementation. Assess effects on products in production or already delivered, risk management and product realization. A deployment work order alone is insufficient.
| Decision | Record | Connected outcome |
|---|---|---|
| Reason | Defect, improvement request or vulnerability evidence | Scope and affected functions |
| Risk | New hazards and effects on existing controls | Testing and mitigation |
| Regulatory impact | Registered information and applicable procedure | Required preceding action or reason none is needed |
| Deployment readiness | Supported environment, installation and recovery conditions | Approved version and target devices |
Where a support complaint initiated the change, retain its identifier. Without that connection, it is difficult to judge whether the change resolved the original event when the symptom recurs.
Test both the changed function and its dependencies
Request affected configurations, test scope and results, unresolved issues and applicable environments, as well as release notes. For a communications-library change, a successful connection test may be insufficient: assess data preservation, alarms and reconnection after interruption. Repeating an identical test pack for every release can miss the actual risk.
Define justified regression testing and validation where needed. Assess compatibility with operating systems, servers, connected devices and data formats. Evaluate outstanding issues against release criteria. Link security changes to the cybersecurity review guide while checking that the mitigation does not impair medical functionality.
Identify deployment targets beyond customer names
One customer may operate multiple models and versions. Use the model and serial number or deployed instance, current version, target version and environment. Identify who will complete backups or arrange any service interruption before installation.
Useful statuses include selected, scheduled, attempted, verified successful, failed or held, and restored. File transfer or a successful remote command may not prove successful application. Retain version confirmation and required post-installation checks. Instructions and training should match the version actually deployed.
Prepare failure and emergency routes
Decide how to respond to lost power or connectivity: retry, restore the previous version, or stop use and contact support, as appropriate. Confirm restoration versions, data compatibility and log collection in advance. Avoid leaving a field engineer to choose an arbitrary file after a failure.
Urgent security or safety corrections may warrant prioritized action. They do not create a general exemption from risk assessment, applicable regulatory procedures, reporting or customer communication. Assess links to adverse-event and advisory notice reporting and record the basis and approver for rapid decisions.
Close after installation and effectiveness checks
Use one change identifier to connect the approved file identity, release documentation, testing, regulatory decision, target list and success or failure records. Offline devices or customer deferrals remain open targets; they should not be counted as completed. Retain interim measures and the next follow-up date.
Monitor recurrence of the original issue and new complaints after release. Clare Partners can review the evidence and deployment records against your Korean registration scope through a free preliminary review.
Official sources checked on 2026-09-28: KGMP Notice 2026-46, Annex 2 sections 7.3.9, 7.3.10 and 8.2.2; Medical Devices Act, Articles 12 and 15. The table and deployment statuses are practical examples, not a determination of a particular software product's statutory change route.
Frequently asked questions
- Q. Can a bug fix skip regulatory change assessment?
- The label is insufficient. Assess actual changes to function, performance, safety, intended use and registered information, including the medical device or digital medical product framework applicable to the product.
- Q. Does manufacturer verification replace Korean deployment records?
- No. Verification evidence and the local installed population answer different questions. Identify which version reached which device or customer and whether installation succeeded, failed or was reversed.
- Q. Can an urgent security patch be deployed everywhere immediately?
- Urgent mitigation may be needed, but priority does not eliminate assessment and records. Promptly evaluate impact, applicable procedures, deployment conditions and failure responses, and document the decision.