Bert Verhees, a colleague from the openEHR community made this post recently to the openehr-technical mailing list:
OpenEHR is not a standard, it is a formal specification. http://www.iso.org/iso/home/standards.htm ISO, What is a standard: "A standard is a document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose."
I’ve grappled with this question many times over the last 20 years. My current thinking is as follows.
The ISO definition is a standards authority’s view on the concept of ‘standard’. The notion of standard meant here is de jure, i.e. ‘of the law’, or official. A de jure standard is something that some authority wants us to use. In some cases its use becomes unavoidable, due to:
- legislation – e.g. requirement for seat belts in cars;
- practicality – e.g. connecting to the power network at 220-240/110 VAC, 50/60 Hz;
- utility – it’s much easier for everyone to use ISO8601, the date/time string standard, than not to use it.
At the end of the day, a de jure standard expresses an aspiration by an authority that some population of potential users must or should use the published standard. But there’s no guarantee that it will be used. What standard actually is used, if any, is a de facto standard. TCP/IP is the prime modern example of a non-de jure standard in networking, even though the comprehensive ISO OSI standards were available. The de facto standard for the need in question may also be a de jure standard – the ISO 8601 example.
The other aspect of de jure standards, as they are in modern reality – documents published for sale, and revised only every 3 years or less frequently – speaks of their near irrelevance for IT and health IT. Much more on that in past posts. The summary of the problem: if doesn’t have a live maintenance crew, issue tracker, and responsive program of new releases and updates, it’s not going to work for IT (and that affects most industries today). One could probably argue similarly for standards in other domains, particularly modern medicine.
In e-health, openEHR is not a de jure standard but is arguably becoming a de facto standard. It’s gaining use on the ground, among vendors, national e-health programmes, academia and open source initiatives like HANDI in the UK. It is regularly compared to de jure standards in published standards reviews. Cherished colleagues won’t like me saying this, but the evidence is that the closest ISO standard – 13606 – isn’t. Related ISO standards like the HL7 RIM are also dead for practical purposes.
In the HL7 space, it is FHIR that is gaining ground, and I hear numerous times (example) that it will probably displace CDA (I think it will in places where unstructured clinical documents are unnatural things to generate, which is the majority of places outside the US hospital-like environments). FHIR will probably become a de facto standard well before it becomes a de jure standard, assuming it gets that far; at that point, its official de jure status will just be rubber stamping reality.
What matters practically is what is used. What’s used is what works. What works is what is worked on, and made to work by an active community (there are other requirements as well of course, relating to the specific nature of the standard).
In my view, top-down (de jure first) standardisation is only valid when public interest, safety and major economic costs are at stake. This is particularly true when determining the standard is an expensive and specialised activity, e.g. vehicle manufacture standards for limiting injury in traffic accidents. For most other situations, there are multiple technical solutions possible, and we should proceed with de facto standardisation, and treat de jure standardisation as a process that rubber stamps particular releases of a de facto standard.
Unfortunately official Standards Development Organisations (ISO, ICU, CCITT etc) appear to have no understanding of this. They still publish documents, not computable artefacts, standards have no maintenance team, no issue reporting capability and no update release strategy.
Even more unfortunately, many government bodies wanting to use standards don’t understand the above, and obsess that only ‘official standards’ can be candidates for use in e-health. This thinking is understandable – it just reflects how they think about standards for car safety or child carer certification. But for ICT and Health ICT standardisation, this attitude is about as close as they can get to signing the death warrant of their programme as they can get without actually cancelling it. In fact it’s probably worse: they’ll spend and lose huge amounts of money and time, and retard other more appropriate developments. Carola Hullin posted in the same thread that the Uruguay e-health programme won’t consider openEHR for this reason. But in Brazil, openEHR is the official choice for shared EHRs.
If government e-health programmes, MoHs, DoHs etc around the world want to make progress, they need to start studying what is used, what works and could be used, and nurture that. They need to facilitate, not legislate. Some of what is used will in fact be de jure standards (HL7v2 messages for example). Much of it won’t be. They need to think about issues like ‘platform’, ‘coherence’, and ‘ecosystem’, not legislating mindless obedience to out of date documents.
The health IT standards of tomorrow will be found in the grass roots, not the tree tops.
wolandscat
Woland's cat 
I agree Thomas, it is a fun topic, with billions of dollars involved, not quite so funny for who is paying them. You and me, the taxpayers.
In the reference you made to Brazil, the section is just a listing of what is available for use. openEHR isn’t mandated or even the only listing for interoperability solutions.
That’s right – it just says this: 4.1. Para a definição do Registro Eletrônico em Saúde (RES) será utilizado o modelo de referência OpenEHR, disponível em http:// www. openehr. org / home. html.
i.e. for defining the EHR, the openEHR reference model will be used.
What current legislators will do with this is another question. Maybe it’s time to get openEHR (in forthcoming releases) joined up with MLHIM, and make the result the only possible sensible choice for the Brazil EHR?
Thomas, you write: “They still publish documents, not computable artefacts, standards have no maintenance team, no issue reporting capability and no update release strategy.”
This not true, at least not at ECMA and ISO.
1) Example in the standard for Microsoft OOXML are XML Schema’s (XSD) included. So they deliver computable artefacts.
2) They do not only puvblish standards, but organize international teams of people which create/edit the standards. A standard in a specific version is stable, it cannot change, it would be unusable if it was not.
3) Maintenance, ISO standards can get updated, there are even fast trajects, so not the complete standard has to be talked through. An update, of course, gets a distinguible version/name/id.
What you write about OpenEHR doing much better as a de facto standard is not fully correct.
Example: I am missing some computable artefacts. For example, we have waited five years before the RM-XSD was published in a correct way, and still there are some inconveniences in it. There were errors in that XSD, I emailed about it years ago. Now it has been revised, but still it is not optimal.
For example by using xs:sequence instead of xs:choice, and so enforcing a useless sequence of properties. There are some more issues, I do not want to discuss them here.
Also, the XSD for OET is still not published, and it is used in software and by developers. How long are we using templates by now?
OpenEHR seems to be in some parts a moving target. A quality-institute as ISO would not allow this. There are some quality-requirements used by ISO. The standard is not only created by the designers (stakeholders), but by worldwide teams and it becomes accepted by vote of the voting members of ISO.
I would welcome if OpenEHR would become a standard, not only because many governments do not invest in non-standards, but also for the quality requirements standardization-bodies pose and for having worldwide non-stakeholding teams looking at it.
Well, ECMA is a special case – it was created as an independent standards organisation based on a membership model. And since it’s main output is programming language standards, it’s normal that it generates computable artefacts. But ECMA is a long way from the kind of body that generates most standards in e-health.
ISO’s business model could be further away from ECMA’s, and you only have to look at the year numbers of subsequent issues of the same ISO standard to see how slow it is. But much worse, It has no requirement for technical competence in the area of the standard being voted on. What gets made a standard in ISO is heavily based on lobbying of country votes in political blocs, political influence by other standards bodies and so on. TC 215 has produced good things, but junk as well.
openEHR can do better that’s for sure, and right now the community is working on that – see the report of the Oslo meeting (http://www.openehr.org/news_events/2014-09-16_openehr_meeting_report). If artefacts like XSDs can be improved, it needs those with expertise to get involved and make it happen. I think the appropriate model looks more like open source production, with competent people involved, and a controlled release programme. We should have it up and running properly by the end of this year, if people will put in the effort.
I completely agree, that is also my experience with ISO, especially this became clear in the OOXML-case.
I remember that Malta became a voting member for the occasion, 400.000 inhabitants, famous for their potatoes and beaches, came on equal voting as ANSI on a very complex subject.
ISO is very much depending on the good will of the proposers. There are also good standards at ISO. You mentioned yourself the date-time-notation, but that is a bit simple comparing to OpenEHR.
But still, even if ISO has many examples of bad history, I would welcome OpenEHR becoming a standard, not necessarily an ISO-standard.
I mentioned my reasons, governments who find this important, and non-stakeholders looking at the standard, and the third reason, the obligation to do it good.
There is pressure from outside needed. Stockholm will maybe improve something, I don’t follow the process, but it still is an incrowd. Standardization will push unconditional.
I have a feeling the combination of an open formal definition guarded by fans and a company having the lead, does not necessary lead to much self-criticism.
I don’t give names. But there are important people saying this. I think you know that too. It could well be that government officials also are influenced by rumours.
Standardization can kill all these rumours. Standardization is a transparent process. I don’t see any reason against it.
Bert,
it would be useful as you say if openEHR could be ‘standardised’. How could that be done? It would take a number of countries to go to ISO TC 215 and say that they want to create a new ISO standard ‘openEHR’, or whatever they want to call it, and then ISO would need to agree on the principle of taking a specific release of openEHR to be the standard NNN, and some basis for updating the ISO standard from new releases of the openEHR specifications. I think we would need advice on how to do this. It undoubtedly would help funding and uptake.
With respect to ‘company’, well, in the UK at least, a non-profit is always a ‘company’ – that’s just an unavoidable legality. Currently it’s ‘owner’ is UCL, one of the largest universities in the world. That should count for something.
I’m not aware of any obvious legal alternatives, other than ‘associations’, e.g. as used for sports clubs.
I surely think you need advice. And it does not necessary has to be ISO. It is a long way, you start with a standardization which has less status, but still has a reputation on quality of process. And it will surely take funding.
I cannot advice you on these details. Sorry for that. First of all, you need to have the ambition.
The process is even more important then the goal.
I tend to think there are aspects of openEHR worth ‘standardising’ for reasons Bert is rightfully pointing out – ADL for example. And AFAIK part of 13606 that describe Archetypes is ADL1.4 currently – right? So we already have a formal standard. We have divergence in RM but that’s fine ADL can work with multiple reference models – maybe in future certain snapshots of openEHR or CIMI RM can be made a formal standard for same reasons. But everything else is really leading edge and I think it should stay like that on openEHR front. What works will be picked up by vendors and clever governments not for sake of standards compliance but just so that it works! That’s pretty much how the innovative ICT industry works in elsewhere…I’ll be straight: openEHR is the way to implement a real working clinical system (with the possible exception of MLM which I don’t know much about other than that it is a fork of openEHR at a point in time). 13606 is designed for health information exchange – not for building fully fledged EHR systems in first place.
My 2 cents
I agree with you that Reference Models can get standardized for interoperability reasons.
When you exchange OpenEHR data, you exchange the Reference Model also. The Reference Model is an important part from interoperability point of view.
It is similar with HL7v3, it has the RIM which is standardized, it has exchange-formats which are standardized, but the way you implement an HL7v3 engine is not.
Templates should also be standardized. Templates should have an implementation independent way for data-representation.
That is why they will need an implementation-independent formal definition of computable artefacts.
We are not that far yet, and that is a pity.
Suppose you have all these things I mention standardized. Then there could arise a new industry, selling information-models consisting of archetypes and accompanying templates, vendor-independent, to implementers of the OpenEHR Reference Model.
That would be nice, wouldn’t it, complete separation of information (archetypes/templates) from technique (implementation of the RM).
I believe, this has always been the primary goal for two level modelling.
ADL 2 does standardise templates – a template is just a special kind of archetype. All the relationships and flattening algorithms are now implemented, and you can do a one-click create of a template in the ADL WB these days. Quite impressive when you do it with a CIMI panel archetype. Only one thing remaining to do – finalise the source file format. We think it will look like this: https://github.com/openEHR/adl-archetypes/blob/master/Example/openEHR/single_file_template/templates/openEHR-EHR-COMPOSITION.t_clinical_info_ds.v1.adls
The latest ADL / AOM specifictions will be online soon, and along with the ADL WB, define a 98% complete formalism for multi-level modelling. The 2% will be resolved based on IHTSDO input.
Interesting, cannot wait to see the explanation and specification.
Sorry for desagreeing with Tim, but openEHR won’t br, actually it is already the adopted reference model for the national EHR in Brazil. The first national template to be shared, the primar care health summary uses openEHR reference model, I presonally was involved with the modelling. We also used the openEHR terminology binding interface to make use of terminology and this is going to be used in the adoption of Snomed CT in the country. At Medinfo there will be a workshop to present this national approach. OpenEHR in Brazil is being adopted also by the private sector. The largest health insurance plan in Brazil is implementing a national EHR, where Marand plataform is the back end.