It could be interesting to openly discuss possible licensing/payment options of openEHR platforms, tools and services. We’ve heard it can be a bit tricky to find business models for some things.
The openEHR specifications and models (archetypes etc) are free to use, and are funded/fueled by voluntary donations of time and also by money via membership/sponsorship. This works pretty well now (but was a bit tricky in the beginning) and removes entry barriers to openEHR as such.
But tools, platforms etc based on the specs of course need time and/or funding to stay updated and supported. Let’s list some current and future possible models in this thread and discuss what fits what.
A. Free product (often Open Source) with paid consultancy and support services
B. Licence/support fee per user
B1. Per identified individual user (username etc)
B2. Per concurrent user (“seat”) - licenses shared in a pool for co-workers, e.g. maximum 5 logged in to the tool at once.
C. Licence/support fee per patient/EHR-record in a EHR/CDR-system
D. Licence/support fee per inhabitant in a region/territory (that a healthcare organisation serves)
E. Licence fee based on purchasing organisations size
F. …territory/country World Bank Gross National Income (GNI) based model where a territory license allows any person or organisation/company to use it within the territory.
G. Per hospital/ institution/ practice (practices cheaper than hospitals)
So what fits what from seller and buyer perspectives?
For CDRs (Clinical Data Repositories) A, C and D seem to be common.
What works for tools, like form-builders, form renderers, AQL querying/reporting tools if they are not bundled with a CDR offering? Have Low-code platforms and No-Code platforms found any good business models that would work?
(This post is a wiki-post and can be updated by others than the original author. Changelog: March12 Added B1 & B2)
I have been involved in IHTSDO/SNOMED International and the community for long time and I like both the community and the licensing models, which are alternatives F, G and H above. However, I am skeptical that these business models would work for openEHR platforms, tools and services.
I believe one reason that SNOMED International’s licensing model works is that there are no real competitors to SNOMED CT and therefore you need to accept the licensing model or not use any ontology in your EHR. This imply that even those that relatively pay more than what they get (so others can pay less than what they get) stays with SNOMED CT instead of moving to a competitor’s product that let you only pay for what you get.
Another reason the licensing model works is probably that SNOMED CT can be seen as basic infrastructure and this probably makes states interested to pay for a country license. I believe that openEHR platforms, tools and services can be seen as more applied infrastructure and products, which states usually are lesser interested in paying for.
A third reason the licensing model works is that those countries that pays for a country license also become members of SNOMED International and are able to have a seat in SNOMED International’s general assembly and influence what the organization do. For a commercial tooling company that provide openEHR platforms, tools and services this would correspond to that the organization that licenses a tool not only had the opportunity to use the tool during the license period, but also leased some of the tooling company’s shares during the license period. Although this would be an interesting business model, I have never heard about it in reality.
(BTW; All SNOMED CT platforms, tools and services I know of are provided using “normal” business models, like models A-E above. It is basically only SNOMED CT itself and the supporting documentation that is provided using the business models F, G and H.)
A common mantra is that ‘tools don’t sell, if they are not free, people won’t buy them’. This is partly a legacy of Eclipse originally being dumped on the market by IBM all those years ago.
This mantra is not quite true. Developers do pay for development tools, but for a pay-for tool to succeed, it has to be really good and really well-maintained. Tools fitting this description that people pay for:
IntelliJ - pretty much unbeatable in its class
Camtasia - a reasonably decent non-professional AV editing tool
Oxygen - an excellent XML / Xpath / Xquery / other things tool
the good UML tools like MagicDraw and RSA
MS Office - they’re better these days, and OpenOffice etc are reliably bad
MS Visual Studio - the MS IntelliJ competitor.
Now these are all fairly general purpose tools in their category, and generally cost around USD $75 - $150 p.a. per user.
In our area, low-code tools are one branch of the future for sure. Some of the openEHR vendors have them - internally or for sale. They’re probably all a bit buggy, but the ones I have seen are getting better, and do offer value. I think we are close to a point in time where the quality will be good enough that it will feel like paying for a tool like one of the above, in its earlier days.
Analytics and reporting tools are different I think - they are more used by business and process people, who expect to pay for everything. Almost all tools in this area are pay-for. But again, a pay-for tool has to be really good, and really well-maintained.
I think for both kinds of tools, a procuring org should expect to pay similar to what it pays for its enterprise / bulk licence for tools like VS, IntelliJ, etc.
I have been working on a medblocks-ui for generating forms and option A sounds like a possibility. Because most people don’t really care about the tool and they just want a working usable interface.
However, the competing commercial solutions are all part of CDR offerings - Their products are much more mature since a lot more time and money went into it. This is especially true for no-code environments since a solution for each and every situation must be provided by the team.
The only advantage of offering an open source solution is that many people have the same problem and we’re basically just working on the solution together. When more eyes are on it, it is likely that more bugs will be detected and common needs be meet by pull requests from the community.
I would like to agree with @thomas.beale that organizations will pay for good tooling. If I (once again) compare with the similar SNOMED CT community, there are several companies that sell tools. The companies range from small companies which have built their business around SNOMED CT and are deeply involved in the community, like B2i Healthcare (http://b2i.sg/) and termMed (http://www.termmed.com/), to large companies where SNOMED CT tooling are a minor product area, like 3M and Philips. I don’t see why this wouldn’t work also for openEHR.
Another reason the licensing model works is probably that SNOMED CT can be seen as basic infrastructure and this probably makes states interested to pay for a country license. I believe that openEHR platforms, tools and services can be seen as more applied infrastructure and products, which states usually are lesser interested in paying for.
I think there would be an argument that the clinical models provided as archetypes could be licensed in a similar way. This can also be compared with some clinical scales and scores that require users to pay license fees. As openEHR has “open” in its name and DNA, this is not suitable or desirable In the case of openEHR, industry members and healthcare providers provide the resources by membership fees or contribution of tools (Archie, Archetype Designer…) and archetypes.
Yes, I agree. The openEHR specifications, International CKM and archetypes probably quite well correspond to what SNOMED International provide using their license models. (The main difference is maybe that SNOMED International also provides subsidized courses and conferences.)
Yes I think organisations are willing to pay for openEHR tools (e.g. good Low-Code openEHR app builders, AQL tools etc) if they can be bought easily via normal already known licence/reseller-channels quickly when they first need them, without having to go through a procurement process. I believe many would start by buying single licences and scale up to enterprise license bundles when you get more users.
Many general (non-openEHR) developer tools/platforms/solutions offer a cloud based starter alternative and then organisations need to pay more to get enterprise versions that you can run “on prem” (on your own servers in your own network with your own login/IDP and integrations).
I guess the question is how tool/component providers can get enough revenue to improve and maintain good tools. If a national healthcare organisation for example would buy tools for three of their developers and then use the resulting application for the entire population of a country - then the cost/value is great for the healthcare organisation but the tool provider may have wanted a bit bigger share of that generated value (or saved cost)? On the other hand, the same could be said about “normal” non-openEHR developer tools.
Wonderful to see Medblocks (https://medblocks.org/) also offering a public understandable price table for an openEHR system, right now looking like this:
That’s a web app that collects many tools I’ve been building over the years to work, test, integrate, validate, etc. openEHR implementations. Actually used for testing EHRServer and EHRBASE (for HiGHmed). I would say the main tools people use is the canonical JSON instance generator from an OPT (we have around 230 users, I think we will double that amount this year), which is helpful to quickly test committing data to openEHR CDRs.
Then the openEHR Toolkit allows to manage OPTs while developing there (maintains semver internal versions), displays navigatable OPT mindmap, OPT archetype dependencies, shows archetype dependencies (slots), transforms archetypes to CSVs (useful for mapping/integration), displays all paths and types of archetypes and templates. It also has a basic API that can be tested via OpenAPI GUI.
We are preparing an OPT comparison tool, more API services, and integration with EHRServer/Atomik for Q2 this year.
That tool has an individual free tier and other team tiers for collaborative work.
In the case of openEHR, industry members and healthcare providers provide the resources by membership fees or contribution of tools (Archie, Archetype Designer…) and archetypes.
