MedTech Startup and Its First Clinic: What to Check Before a Patient Data Pilot

A medical startup founder approached us while preparing the company’s first pilot with a clinic. The service was designed to process patients’ medical data: store computed tomography (CT) and magnetic resonance imaging (MRI) results and other medical records so that patients could retrieve them and give a doctor access through a link.

The client already had a draft agreement with the clinic and wanted it reviewed before negotiations. During the review, it became clear that checking the agreement alone was not enough: the legal model depended on how the files actually moved through the service, where they were stored, who could access them, and what happened after the pilot ended.

This case is therefore relevant to other medtech startups preparing to work with a real clinic and real patient data for the first time. It shows which issues should be checked before agreements are signed and the service is launched using live data.

What Should a Medtech Startup Check in Its Agreement With a Clinic Before a Pilot?

Our client already had a draft medtech agreement with the clinic and its appendices. Our task was to review the legal package before negotiations. During the audit, we found that the documents described the same service workflow differently: in one document, revoking a link meant only terminating access; in another, it meant deleting the study. It was also unclear what would remain in backups and when those copies would be deleted.

For the founder, this created a practical risk: by signing the agreement, the startup could take on obligations that the product and infrastructure were not yet able to perform. We therefore compared the agreement with the actual file lifecycle: who uploads the file, where it is stored, who opens it, how access is revoked, and what happens after the pilot ends.

The storage volume also had to be defined. CT and MRI files can require significant storage capacity, while the draft did not set an agreed limit for the pilot. Without such a limit, both infrastructure costs and the volume of service promised to the clinic remained uncertain.

That uncertainty led directly to the next question: where the data would actually be stored and who would be responsible for the infrastructure.

You may also find this useful: Contract Management Setup: A System Instead of a Single Agreement Template

Can Patient Health Data Be Stored Outside Ukraine?

Initially, the client considered storing medical data in Germany while allowing patients and doctors in Ukraine to access it. We analyzed that data route and the related contractual requirements. The client later chose a different model for the pilot: engage a separate Ukrainian infrastructure contractor while keeping the software service and its administration within the startup.

The fact that a server is located abroad does not automatically make the arrangement prohibited. Article 29 of the Law of Ukraine “On Personal Data Protection” regulates transfers of personal data to foreign recipients, and the legal assessment depends on the parties involved and the full access route. At the same time, a provider’s Ukrainian address does not prove where primary data and backups are actually stored. This must be established for the specific service being purchased.

After the model changed, we had to compare the clinic documentation again with the terms of the new infrastructure provider. Choosing Ukrainian infrastructure simplified the intended data route, but questions remained about permitted data categories, staff access, backups, and termination of processing.

The next step was therefore to review not the clinic agreement, but the infrastructure provider’s own terms.

For medtech products planning to work with clinics or users in the EU, you may also find this useful: Ukrainian Company Without an EU Office: When GDPR Applies and What to Check Before Your First European Client

Do you need professional help with this matter?

Submit a request, and we will find the optimal solution for your situation.

Order a service

What Should Be Checked in a Cloud Provider Agreement for Patient Health Data?

When reviewing the selected provider’s terms for cloud storage of medical data, we found a prohibition on processing sensitive personal data. Health data falls within that category. The provider’s standard agreement therefore conflicted with the core purpose of the service: storing patients’ medical studies.

This conflict could not be solved solely by obtaining patient consent or changing the clinic agreement. Special terms had to be agreed with the infrastructure contractor to expressly permit the relevant processing and define its limits. If the contractor would not agree to those terms, the standard service agreement could not be used as the basis for the planned pilot; another service or another model would be required.

We prepared amendments covering data categories, the contractor’s role, staff access, backups, deletion, and incident notifications. In the cloud service order, we also proposed identifying the specific environment and service parameters so that both the clinic and the startup would clearly understand what the infrastructure provider was responsible for.

Important! A provider’s security documentation must also be assessed in relation to the specific service being purchased. For cloud processing of restricted-access information protected by law, Cabinet of Ministers Resolution No. 154 dated February 11, 2025 establishes special requirements, including requirements for a compliance document and the contract term. A provider certificate does not override a contractual prohibition and does not automatically prove that the startup’s application itself is secure.

Only after these issues were addressed could we return to the clinic agreement and properly define the parties’ roles and the rules for patient access.

You may also find this useful: What Does the Ombudsman Check When Reviewing a Business’s Personal Data Practices?

How Should Data Processing Between a Clinic and a Medtech Startup Be Structured?

In the model we reviewed, the clinic determines the purpose of processing the medical data, while the startup performs agreed operations on the clinic’s instructions. Ukrainian law refers to these roles as the personal data controller and processor. Parts 4 and 5 of Article 4 of the Law of Ukraine “On Personal Data Protection” require a written agreement and allow the processor to process data only for the purpose and within the scope specified in that agreement.

The documentation should therefore cover file upload, storage, access, return, and deletion, as well as the involvement of the infrastructure contractor. An instruction to store medical studies does not give the startup the right to use those studies independently to develop another product or train algorithms.

For this voluntary pilot, we proposed a model based on informed patient consent for the relevant processing. This does not mean that every medical action always requires a new separate consent: Article 7 of the Law provides other legal grounds for processing health data as well. The specific purpose of the pilot and the clinic’s existing documents must be assessed. If an existing consent validly covers the planned operations, there is no need to duplicate it mechanically.

For link-based access, we proposed agreeing the validity period, the scope of accessible materials, the revocation method, and protection against access by unauthorized third parties. A patient retrieving their own files and another doctor accessing those files are different scenarios and should be described separately. The technical ability to forward a link does not replace rules governing the recipient and any subsequent processing.

Once the access model was clear, the final stage of the data lifecycle still had to be addressed: what happens to the files after the pilot ends.

How Should Retention and Deletion Periods for Medical Data Be Defined After the Pilot?

One of the most significant inconsistencies concerned the data deletion timeline. A promise in the clinic agreement to delete all copies quickly had to match the provider’s actual backup cycle. Otherwise, the startup would be committing to something outside its control.

We separated three different events: revoking access through the link, deleting active files, and completing deletion from backups. For each operation, we proposed agreeing a deadline, the responsible party, and evidence of completion. Before deletion, the parties should also address return of the agreed data to the clinic: ending the service test should not deprive the clinic of medical records it still needs.

Before using real patient data, we recommended testing these mechanisms with synthetic data—specially created test files containing no information about real patients. The test should cover, among other things, sending a link to the wrong recipient, revoking a link, restoring a backup, and deleting data. If the test result differs from what the agreement promises, the service functionality or the contractual term should be changed before the pilot begins.

This allowed the project to move from isolated legal edits to an integrated decision on pilot readiness.

Result: a Clear Pilot Model and Ready-to-Negotiate Document Amendments

As a result of our legal support for the startup project, the client received more than a contract review. The work answered the key question: whether the pilot could be launched in the intended form and what had to change first. By the end of the engagement, the client had:

• an analysis of the legal relationships between the startup, the clinic, and the infrastructure contractor, together with the patient-data flow;
• draft amendments to the clinic and provider documents;
• a list of conditions that had to be agreed and implemented before real patient data could be uploaded;
• answers to the team’s additional questions.

For the founder, this meant entering negotiations with a clear position: knowing which clauses to change, what to require from the provider, and which functions to test with the developers. Most importantly, the founder could see whether the intended model would actually work on the selected infrastructure before the clinic and patients began using the service.

When Should a Medtech Startup Review Its Model Before Launching a Pilot?

A similar review is appropriate if your product works with medical information and you:

• are preparing an agreement with a clinic or another healthcare provider;
• store patient files in the cloud or with a third-party contractor;
• give patients or doctors access to materials through a link;
• plan to use the data for purposes beyond the service’s core function, such as product development.

Our legal team can assist at different stages. If the pilot is already prepared, we can conduct a focused audit: compare the agreements with how the product actually works and prepare amendments for negotiations with the clinic and providers. If the model is still being designed, it is better to involve us earlier so that data requirements can be taken into account when selecting the provider and developing product functionality rather than corrected immediately before launch.

To begin, it is enough to provide the draft agreement and appendices, the infrastructure contractor’s terms, and a description of how files move through the product. If the documents have not yet been prepared, the review can start with a description of the intended model.

Preparing a medtech pilot with a clinic? Submit an online request through our website or call our toll-free number.