When support for electronic medical records or other systems is ending: securing the conditions for continued use and data migration

1 Distinguishing what will end and when

When an end-of-support notice arrives, first distinguish what is ending. Is it maintenance and updates, the software license as well, or services such as authentication or servers? Different elements may end on different dates. Identify the scope and dates stated in the notice and compare them with the contract's service scope and termination conditions.

Then investigate what will actually be lost, since this affects clinical care and access to records. Even if the software is installed at the institution and the license continues, reliance on the vendor for reauthentication when a terminal is replaced means that current operation alone does not establish continuity. Even where only updates end and authentication and integrations continue, separately check whether fixes or alternative measures can be secured to address newly discovered vulnerabilities.

Identifying what will be lost when support or services end

Function or support ending	Mechanism to check	Situations in which to assess the impact
Updates and incident support	Scope of patches and recovery support	Discovery of a vulnerability; system failure.
Authentication for use	Periodic authentication and reauthentication after equipment replacement	Authentication expiry; equipment replacement or recovery.
Integration with other systems	Routes for importing test results and other data	New imports; changes to connected systems.
Viewing and exporting records	Dependence on viewing software and available export formats	Access to historical records; migration work.

2 Setting a deadline for interim use and conditions for reassessment

The old system may need to be used temporarily until migration and cutover verification are complete. If the license also ends and there is no other basis for continued use, an agreement permitting interim use or another valid basis must be secured. If this cannot be secured, consider methods of providing care and carrying out migration that do not depend on continued use of that software.

Plan this interim period separately from simply continuing to use the system as before. Specify the operations and functions covered, the deadline for use, and the conditions for maintaining authentication, integrations, and data export. Decide which measures will be implemented, who will verify them, and who will decide whether to continue, reduce, or stop use.

Reassess the scope of use and alternatives even before the deadline if a new vulnerability is discovered, a planned measure proves unworkable, or migration is delayed. Do not make a migration delay automatically extend the period of use.

Assess the components that will no longer receive updates, external connections, the effectiveness of alternatives, and clinical functions lost as a result of mitigation. Disconnecting the system from the network may not be sufficient on its own and may prevent the import of test results or remote access. Recording the risk assessment and approval by the responsible person does not make up for a failure to implement necessary measures.

In discussions with the vendor, distinguish what can be required under the existing contract from what requires an additional agreement.

3 Whether maintenance and modifications can be transferred to another provider

Identify the planned work before deciding whether another provider can take over maintenance or modifications. Does the work involve only incident response, compatibility with operating system updates, additional functions, or changes needed to extract data? The authority and materials required vary with the work.

Next, identify who will reproduce or modify which programs and what will be handed to the replacement provider. The owner of a copy of a program may, in certain circumstances, reproduce or adapt it to the extent considered necessary to run it themselves. First establish whether the medical institution owns the relevant copy. Having a service agreement for an electronic medical records service does not, by itself, mean that the institution owns a copy of the program. Then assess the institution's own use separately from reproduction or modification by the replacement provider. The institution's satisfaction of the applicable conditions does not automatically permit supplying the program to another provider or that provider's work.

Also apply the license scope and any clauses prohibiting modifications or requiring confidentiality, and determine the conditions under which the work may be performed.

Establish whether the source code, design documents, and environment needed to test operation can be obtained. Even where the law permits modification, that alone does not oblige the original vendor to hand over materials. Check whether delivery can be required under the existing contract and seek an additional agreement for anything missing. If the necessary materials or testing environment cannot be secured, revise any plan for continued use that depends on those modifications.

Modifications to software classified as a medical device cannot be assessed solely on the basis of the framework described here.

If the authority to use software acquired through an acquisition or business succession is itself in doubt, see When software use rights are called into question after an acquisition.

4 Separating data for the new system from data retained as historical records

Distinguish data to be used in day-to-day clinical care in the new system from data to be preserved and accessed as historical records. The same migration method may not be necessary for both.

First, specify what will be migrated. In addition to the scope and format of exports, check whether patient associations, units for test values, and links to images and histories will be preserved. Information about who created a record, when it was created, and how it was amended is also needed to verify its content later. Decide how records added or amended after the initial migration export will be incorporated into the final data.

Next, decide how successful migration will be verified. Matching record counts and being able to read the content correctly are different matters. Define the scope of verification and check that the data selected for migration has been transferred without omissions and can be accessed when needed.

The obligation to preserve records rests with the medical institution. It does not disappear when the vendor contract ends. Equally, that obligation does not itself require the original vendor to continue maintenance. Check the applicable rules and the starting point for each retention period, and establish which records must remain readable and for how many more years.

Check whether the provision of data to a provider in Japan accompanies the outsourcing of its handling within the scope necessary to achieve the purpose of use. If so, individual patient consent is not required for that provision. Define the outsourced work and how the provider will be supervised. If any handling falls outside the outsourcing arrangement, separately check its legal basis.

5 Setting the conditions for retiring the old environment

The new system's becoming operational does not necessarily mean that the old environment can be retired. Decide separately when to stop entering and updating data in the old environment, when to end access to historical records there, and when to erase data held by the original vendor.

End access through the old environment once the necessary records have been transferred without omissions, their content and creation and amendment information can be verified, and a means of access for the required period has been secured. Those conditions are not met if historical images or records of changes remain accessible only in the old environment.

Before migration, agree on the data to be erased, the method, the conditions for erasure, and how completion will be verified. Avoid arrangements under which data is erased on a scheduled date before verification is complete. Also provide for delayed verification by setting the conditions for extending viewing access or authentication, or for securing an alternative means of access.

Check whether the current contract covers these matters and seek an additional agreement where it does not. Avoid planning the migration on the assumption that the vendor will agree to an extension.

Use pending migration, transfer of maintenance and modification work, data migration, and retirement of the old environment each require confirmation of their contractual basis and conditions, followed by agreement with the vendor. We advise on reviewing license and maintenance agreements, negotiating interim use and migration and erasure terms with vendors, and contracting with replacement providers.

Our guides for hospitals and clinics are collected in Legal matters for hospitals and clinics: incidents, reimbursement claims, advertising, and succession.

Contact

Making an inquiry

Please tell us the outline of the situation, any notice you have received and its date, and any deadline you are working to.

Contact Form

Related information

Related explainers and practice areas

Intellectual property, IT and data: overview

Individual guides, according to the situation, on disputes over rights, the removal of trade secrets, and system development and the management of data.

Intellectual property, IT and data (practice areas)

Our practice areas covering the acquisition and use of intellectual property rights and responding to infringement, contracts relating to IT and systems, and the handling of data.

This article is provided for general informational purposes only and does not constitute legal advice on any specific matter. Please consult us regarding your specific situation. The content is based on the laws and regulations in effect as of the date of the last update.