eQMS Data Models: Hard-Coded Entities vs. Flexible Entities

Dr. Oliver Eidel • QMS Software • Updated June 26, 2025

Besides all the ranting I usually do in this website, today I (surprisingly) had a constructive idea for an article. This is one of those "I wish someone had written this 8 years ago, when I got into medical devices" kind of things - at the time, there was exactly zero content about on this internet, and given the glacial pace at which medical device compliance "innovation" happens, fast-forward to today, and there's still zero content. So this is my try to solve this, 8 years later, chuckle..

Okay okay, this is getting boring. So let's move on, here's a rough sketch of the problem: You're a medical device manufacturer, and you're looking for a magical compliance software to help you document your medical device in a structured way. That sort of software is typically called an eQMS software with requirements management features.

Here's what it does. For example, the IEC 62304 requires you do document something called "software requirements". The standard is kinda vague about which "fields" a software requirements should exactly have, but let's just assume a software requirement looks like this:

Title: User can log in
Description: The user can enter their email and password to log in.
Software Tests: Covered by Test-1, Test-2 and Test-3.

Okay, as you can see above, the idea is that a software requirement describes a feature of your software (a bit like a user story, but calling it that way would confront regulators with the fast pace of modern software development, danger!). And a software requirement has a title a description and is linked to many software tests.

If you're a technical person, you're likely already thinking how to handle this in a database: The title and description fields would be strings (or text), and the software tests would be a many-to-many relation.

Cool.

So hold on, what's the question?

The question is this: Should a user be able to customize this data model?

Enter: The Over-Engineering Company With Fancy Tests

Let's say a manufacturer goes and says something like "oh no, that data model wouldn't work for us, because we do fancy testing at [insert over-engineering company name]. we need an additional fields named Fancy Tests". Okay. So, for the fancy company, the software requirement data model would look like this:

Title: User can log in
Description: The user can enter their email and password to log in.
Software Tests: Covered by Test-1, Test-2 and Test-3.
Fancy Tests: Covered by Fancy Test-1 and Fancy Test-2.

Besides the obvious question whether this is a good idea (it's not), there's a much more pressing question we have to answer first: We're now referring to Fancy Tests from software requirements, yet, so far, our other data models didn't contain any Fancy Tests, only Software Tests. So, besides the Software Tests data model (which we had already, let's assume), we also have to go ahead and create Fancy Tests now, too!

But it doesn't stop there. While it's clear for Software Tests what they should be linked to (= Software Requirements), it's entirely not clear what Fancy Tests should be linked to, because they're something we came up with ourselves, and the standard is not helpful here at all (it's mostly not helpful in general, too). So the fancy company will be losing lots of time while their over-engineering employees sit down for lengthy discussions on which sort of relations a Fancy Test should actually have.

Okay, let's summarize here. We started with a simple data model (Title, Description, Software Tests) which fulfills the requirements of the IEC 62304. But then a fancy company came along and said "this doesn't work for our internal processes because we're fancy", and added a "Fancy Tests" field to the model.

Why is this relevant?

Because some eQMS and requirements management softwares allow you to create these "custom entities", as I'll call them, while others do not.

Which one should you choose? That's the big question.

Let's start with the simple "hard-coded" entities first, before we move on to the custom entities.

eQMS Software With Hard-Coded Entities

The benefits of the hard-coded entities are obvious: The eQMS manufacturer can simply read through the standards, create all relevant entities with great care, and package this sort of "data model collection" into their eQMS software.

There are some pretty crazy benefits here:

Once customers start passing audits with this data model, it can generally be assumed that all future customers will have similar success in their audits, too.
It removes a gigantic amount of mental overhead for customers, because they no longer have to conduct these useless discussions of "let's re-invent our eQMS data model".
It gives customers a better indication on when they're "done" with their documentation, because the amount of fields they have to fill out is fixed - it's not like someone in the company can come up and say "hey cool, I added another field to the software requirements model, now you guys have to re-document everything again". Nope.

Additionally, there are many hidden benefits:

Versioning and backups are typically easier, because the data model doesn't change between versions. Like, you can export all your software requirements for version 1 of your device, and once you export them for version 2, the content might be different, but the fields won't be.
In contrast, if the fields would change between versions, that would lead to huge chaos.
Once you give customers the feature of creating custom entities, many of them tend to go crazy, and not in a good way. Where's the limit? You could create a custom entities for Customers, Customer Support Requests, CAPAs, Audits, Audit Findings, Audit Reports, etc., etc.. All of those are reasonable, but didn't you want to document your software requirements and get those done first?

There are, however, some drawbacks, too. The biggest one is that when a company already has created some sort of medical device documentation and passed their audits, then they usually have already created some sort of custom entities with fancy tests (or similar), unknowingly, because everyone interprets the standard in a different way (ugh). So those companies are faced with a huge problem when trying to migrate to an eQMS software with hard-coded entities. So far, I haven't seen a company pull this off successfully.

Still, in my personal opinion, the approach with hard-coded entities is the superior one. I guess it boils down to what your priorities are: Do you want to get your documentation done in an efficient way and pass your audit? Choose hard-coded entities. Do you want to create the most fancy quality management system on the planet and spends the rest of your life doing so? Choose custom entities.

So let's talk about custom entities next.

Ah hold on, by the way, here's some eQMS software which, to the best of my knowledge, uses hard-coded entities: The first obvious mention is our own eQMS software, Formwork (chuckle). But also others use them, notably Greenlight Guru and Qualio. From what I've heard, they sometimes somewhat pretend to offer more customization, but, on a technical level, their entities are hard-coded.

eQMS Software With Custom Entities

Alright. Next up are custom entities. As hinted above, those enable you to do crazy things by creating your own entities and linking them with each other - you want Fancy Tests? Sure, create some, but now the people in your company will be scrambling to find out how the Fancy Tests map to the IEC 62304, when to document them, how to update your SOPs, blabla, it's an epic mess. But you have Fancy Tests, maybe that was worth it.

Still, here are some benefits:

If you've already got a product on the market (audits passed etc.), and you're migrating your documentation from a crappy directory structure (e.g. Jira, Google Drive, etc.) to an eQMS software, choosing an eQMS software with custom entities is, in many cases, your only option. That's because your own "entities" likely just don't map to the entities of eQMS software providers, and no one in your company is probably willing to take the risk of radically simplifying your already-audited documentation so that it would fit into a new data model. Sad dog face.
If you think your company is a special snowflake and really needs custom entities because Fancy Tests are a core aspect of your business, then an eQMS software with custom entities might be for you.
In my experience, I haven't come across even one case where such a decision was reasonable. Roughly speaking, they either fall into the bucket of 1) founders having a huge ego and thinking their startup is special (it's not) and does things differently (it doesn't) or 2) huge enterprises which have accumulated so much complexity in their documentation that any sort of simplification is impossible and hopeless.
In those cases.. yeah, custom entities might be for you, but you'll be in a world of pain, as mentioned above. Good luck forming the "committees" on figuring out which entities you'd like to add and how to link them.

Yup, and besides the already-mentioned drawbacks, there's also the technical drawback that versioning, backups and linking are much, much harder. Sure, some eQMS providers have figured this out, and on a technical level, I'm impressed that they got this done because this essentially means building some sort of SQL (relations) on git (versioning). But, for me, the big question here is "was this a problem worth solving, and doesn't the solution just introduce even more problems?".

The software "out in the wild" which I've seen doing this is usually some home-cooked Jira approach, which nearly always ends up becoming a huge mess. Also, the data exports (usually crappy Word files) are super terrible, good luck backing those up.

A notable mention here is Matrix Requirements which has solved the custom entity problem on a technical level, at the cost of presenting it to the user in an interface which resembles Windows 95. Still, as a software engineer, I am impressed. That being said, I've ranted about them on this website a bit already after the founders unfortunately ended up selling their company to a private equity fund, and nearly doubling their prices for their customers (ugh).

What Should You Choose?

So what should you choose? Here's a quick guide, based on your company's stage:

Startup: Go for hard-coded entities. Choose Formwork.
Existing company, passed audits already: Either radically simplify your documentation and go for hard-coded entities (will save you lots of time and nerves in the long run), or accept that you're in a world of pain and go for an eQMS software with custom entities. Or just don't migrate.

That's it. I wish I could send this blog post to myself 8 years ago, chuckle.. what do you think?

On a different note: Do you need any help with your EU MDR efforts?

We've worked with 100+ companies and helped them certify their devices in weeks, not months. Talk to us now – first calls are free! Check out our services and prices here.

Or, if you don't like talking to humans, check out our Wizard. It's a foolproof, step-by-step video course for getting your compliance done yourself.

And if you're looking for the best QMS software for lean, founder-led companies, check out Formwork. It automates your compliance, and there's even a free version for you to try out!

No image yet.

Congratulations! You read this far.

Get notified when we post something new. Sign up for our free newsletter.

No spam, only regulatory rants. Unsubscribe anytime.

0 comments

No comments yet. Be the first one to share your thoughts!

Dr. Oliver Eidel

I’m a medical doctor, software engineer and regulatory dude. I’m also the founder of OpenRegulatory.

Through OpenRegulatory, I’ve helped 100+ companies with their medical device compliance. While it’s also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)

If you’re still lost and have further questions, reach out any time!

More about me