Your Marketing Copy Decides Whether Your Software Is a Medical Device

Picture two apps. Both take symptoms the user enters, run an algorithm, and return a list. The code is nearly identical. One falls under medical-device regulation. The other doesn't.

What makes the difference is the description in the app store listing. The first says: "provides information about possible conditions based on your symptoms." The second says: "assesses your symptoms and shows a likely diagnosis." That second sentence puts the product forward for a diagnostic purpose, and with it come risk classification, conformity assessment, a technical file, clinical evaluation and post-market surveillance obligations.

This is the most expensive, and most easily avoidable, mistake I see on health-technology projects. Marketing writes the product description, nobody thinks through its legal consequence, and the product ends up inside a compliance regime it never intended to take on.

The intended-purpose statement is a legal document

The practical rule that follows is this: a product description should be written with the same care as a privacy policy, and reviewed legally before it's published.

The review can't stop at the app-store listing. A headline on the website, a line in a promotional video, a claim in a sales deck, a statement in a support document can all produce the same effect. Saying "provides a diagnosis" in one place doesn't get withdrawn by saying "for informational purposes only" somewhere else.

The decision has to be made upfront. If the product is going to be a medical device, the process that regime requires is built in from the start and priced into the plan as a cost line. If it isn't, keeping every piece of copy within that line becomes a product-development rule.

Access architecture for health data

Article 6 of Law No. 6698 classifies health data as a special category of personal data and subjects it to narrower conditions. The technical counterpart of that classification is missing in most projects.

The pattern I see most often: the application runs, data is stored, but everyone inside the organisation can see everything. Developers can query the production database. Support staff can open a patient record. A manager can see raw data in a report. That means access hasn't actually been restricted, and it's hard to defend at audit.

The right setup starts with role-based access, but doesn't stop there. Every access needs to be logged, the log needs to show who accessed it and for what purpose, and unusual access needs to be detectable. If someone opens a patient record at two in the morning, that has to be visible in the system.

The test environment is a separate issue. Testing with real patient data is the most common, and most dangerous, habit in health technology. Working with masked or synthetic data removes most of that risk and isn't technically difficult to set up.

Clinical decision support and responsibility

AI-assisted decision-support systems raise the question of where responsibility sits. In practice, the safe design is for the system to produce a recommendation and leave the final decision to the qualified health professional.

For that design not to stay theoretical, three things need to be kept together: the recommendation the system produced, the inputs it relied on, and the final decision the health professional made. Kept separately, they can't be matched up later; not kept at all, responsibility can't be shown at all.

One more metric is worth adding: track how often the health professional overrides the system's recommendation. If that rate approaches zero, human oversight has become nominal, and the system is effectively making the decision. That finding can matter a great deal in a later dispute about responsibility.

Remote healthcare

Remote health services in Türkiye operate within Ministry of Health regulations. Which services can be delivered remotely, record-keeping duties and the limits of the service are set out in secondary legislation, and because those rules can change, a product needs to be checked against the current text at design time.

The principle that doesn't change is this: situations that require an in-person examination cannot be handled remotely. A remote-health product needs to be able to recognise a request that crosses that line and redirect it. A system able to say "please see a doctor in person for this" isn't a usability nicety — it's a legal requirement.

Starting a project

In the first meeting on a health-technology project, the question that needs answering isn't what the product will do — it's what it will declare itself to be. Every line of code written before that answer is settled may end up written for the wrong regime.

The second question concerns the data model: what data is genuinely necessary, who can see it, where is access logged, and what happens once the purpose has ended. The answers to those four questions directly shape how the tables are designed, and changing that design later — because it means migrating existing patient data — creates both a technical and a legal problem.