Product discovery: what teaching digitization to medical practices has taught us

In 2024, through the EDIH-DIZ project, RomSoft took on a role in what’s called a “test before invest” stage: our job was to show medical clinics what digitization actually looks like in practice. Online appointments, virtual consultations, electronic patient records – every possible digital service would be demonstrated, so each clinic could decide for itself whether it needed these tools at all.

RomSoft medical app featured image

Where we were at

We came into this with experience from similar projects – like EMIM – which, on paper, had everything you’d expect from a complete medical platform: online scheduling with automated reminders, electronic patient records, integrated billing, and on top of that, smooth communication between everyone in the system, especially doctors and patients, plus a module for communicating with pharmacists and looking up medications.

What users actually wanted

What turned out to be different in real life wasn’t the technology – it was the expectations of the beneficiaries in the project. They weren’t interested in a generic platform. Their questions were specific: how do I help my patients with nutrition and diabetes issues stick to an extremely strict and complex protocol? How do I get a patient in a rural area, with no experience with technology, to actually use a mobile app to book appointments?

However well built, a generic application remained an abstract story – clinics couldn’t see themselves in an application that had, in fact, been built for someone else.

From presenting a demo to building one

We dropped the idea of “presenting a demo” and adopted a “build a demo” approach instead. For each clinic, we built an app tailored to it – its own services, its own mix of specialties and doctors, its own patient flow. We weren’t showing them an application anymore. We were showing them their own clinic, digitized.

RomSoft app medical digital clinic - doctor schedule

That obviously meant a lot more work each time – every demo was practically its own small project. But it surfaced things a generic demo never would have. The nutrition and diabetes care clinic mentioned above, for instance, asked us for something we hadn’t considered at all: not just scheduling appointments, but a medication plan with push notifications – because for them, treatment adherence mattered just as much as the consultation itself.

Other clinics took that customization even further. At a pediatric therapy center, for instance, the whole vocabulary changed – there was no “doctor,” only “therapist” – and so did the patient profile itself: children followed personalized intervention plans across several therapy types, each broken down into evaluation areas where staff could add and track objectives and activities on an ongoing basis, then generate a progress report for any given period.

At another beneficiary, working in the legal space, customization went in a different direction entirely. Appointments needed downloadable consent forms – for processing personal data, for biological sampling, for psychiatric evaluations on request – plus other customizations specific to legal cases, and confirmations issued as an official document rather than a simple notification.

Every conversation like that revealed a need that was different from what we’d assumed, and over time, a pattern: clinics’ needs weren’t small variations of the same product. They were fundamentally different configurations of the same underlying building blocks – specialties, scheduling, patient records, patient communication.

The next step

That’s what’s leading us into the stage we’re working on now: instead of building a custom demo every time, we’re rebuilding those blocks into a modular platform that a clinic administrator can configure themselves – how many specialties, how many doctors per specialty, what kind of appointments they accept, what documents get generated. We’re essentially taking what dozens of real conversations taught us and turning it into configurable options, instead of code written from scratch each time.

Medical app patient medical folder example

The same logic, applied to AI

The same logic applied when AI entered the picture. One recurring complaint from doctors was the time lost filling in standardized medical forms by hand – such as Annex 43, also known as “medical letter”, in any case, documents with a fixed format, that every clinic has to produce regardless of specialty.

That became a transcription module: a doctor dictates during the consultation, and the system transcribes the conversation, extracts exactly the information a given template needs, and fills it in automatically. Once we validated it, it stopped being a one-off customization and turned into a standalone feature – available across the entire platform, to any clinic, any beneficiary.

RomSoft medical app AI transcription module

An appointment-confirmation assistant, built on top of a calling service, went the opposite way. It calls patients to confirm upcoming appointments by voice, and hands the call to a human operator when it can’t close it out – solving a real bottleneck for one beneficiary who had to confirm hundreds of appointments a day by hand. But it was only developed as proof of concept. That’s arguably the clearest test-before-invest decision in the whole project: with each beneficiary, we could agree case by case how far an implementation should go – a fully built feature open to the whole platform, or a proof of concept meant to answer one question first: is it worth building further at all.

Learning that goes both ways

We went into this thinking our job was to teach: to walk clinics through what we’d already built and let them decide what they needed. What we hadn’t planned for was that the teaching would go both ways. Every question we couldn’t answer on the spot, every “but how would this work for us,” was a clinic teaching us something we needed to learn.

That’s the part we’re carrying into what we’re building now. Out of listening more than we expected to – at a point when we thought we were the ones there to explain – came the idea for a new product – a product that is still very much in progress, with real technical decisions being made along the way. So why are you reading this?

We’d like to talk

The learning process goes on. If you own a clinic, or a small medical practice, and you’d like to share your vision about what your digital clinic looks like, we’d love to hear from you.