At the HL7 meeting last week in San Diego, Grahame Grieve presented something called Resources for Healthcare (RFH), essentially a replacement model for much of HL7v3, for ‘practical use’. The driver was the well-known over-complexity of HL7v3. According to his report on the reception of RFH at the HL7 meeting, there appears to be a real appetite for change at HL7, which is good to see.
Within RFH, Grahame has proposed a new data types model. In practical terms this will presumably mean that implementations directly based on the RIM and 21090, and particularly the creation of RIM/21090 data instances will see much reduced use in the future. From the point of view of openEHR and 13606 this represents some positive possibilities for bridging implementations in the future, and maybe finally solving the ‘logjam’ in health informatics standards.
Things to note about the RFH data types:
They use orthodox object modelling rather than the subtractive modelling / profiling approach used to date HL7.
They define a very lean set of semantics (so far).
These two together mean that for the first time, HL7 data types (if that is what RFH data types become) can be extended in the normal OO sense, rather than having to be ‘profiled’ (creating N variants, all non-interoperable with each other). Interoperability can potentially now be found by connecting to the core definitions, even if it can’t directly be found with more complex extensions of the core types.
They incorporate a lot of features of the openEHR data types.
The current openEHR data types are currently more full-featured, and in some cases probably more complex than they need to be - adjustments may be possible here (one example: the normal / reference ranges in DvQuantified should be pulled out into a wrapper type or else added by inheritance to DvQuantity and possibly DvCount, DvProportion).
My conclusions at this point:
building a data conversion interface between openEHR and HL7 of the future now has a good chance of success, if the RFH data types develop in an appropriate way
CEN/ISO 13606 should move to the RFH data types, and not use 21090 - doing so is likely to set up a legacy in the future for 13606 users that HL7 community is about to leave behind. It will allow 13606 to become much closer to openEHR, and facilitate the merging of the models into one, which I think is a necessary future step for both openEHR and 13606.
If HL7 goes this way, some real convergence finally looks possible, and people working on openEHR and 13606 need to think about how to go about it.
This is wonderful news! Now there is a chance to use the word
harmonization in a more productive manner
Thank you to Grahame Grieve and others involved!
This is too important to leave only to time- and people-constrained
physical committee meetings, we probably all need to help out somehow
with good technical thinking and some kind of real prototype
implementation before any formal decisions are made.
- Where are the main online discussion/information hubs where key
people discuss this kind of redesign work in the different efforts
(HL7, CEN, ISO, openEHR etc)? For openEHR I'd guess this technical
mailing-list is the main hub for this (possibly complemented by a
"harmonization"-wiki page or two as condensed memory-notes with links
to some list messages etc).
- How do we best set up communication links between the communities?
Is it by joining each others mailing-lists/discussions? Other ways?
This is wonderful news! Now there is a chance to use the word
harmonization in a more productive manner
Thank you to Grahame Grieve and others involved!
This is too important to leave only to time- and people-constrained
physical committee meetings, we probably all need to help out somehow
with good technical thinking and some kind of real prototype
implementation before any formal decisions are made.
- Where are the main online discussion/information hubs where key
people discuss this kind of redesign work in the different efforts
(HL7, CEN, ISO, openEHR etc)? For openEHR I'd guess this technical
mailing-list is the main hub for this (possibly complemented by a
"harmonization"-wiki page or two as condensed memory-notes with links
to some list messages etc).
- How do we best set up communication links between the communities?
Is it by joining each others mailing-lists/discussions? Other ways?
As you say, profiling ISO 21090 data types leads to several problems of inconsistency and non-interoperability. And in terms of efficiency, our tests using the new data types in LinkEHR are not satisfactory at all.
But my main question is if this initiative has possibilities of achieving an official support from HL7. This is an important question to prepare the future of current norms. This is what the 13606 says about the data types:
“It is recognised that, at the time of producing this standard, a new set of health informatics data types is being developed by ISO TC/215. Once this is published, CEN may choose to deprecate TS 14796 in favour of this new standard. In doing so, it will need to provide a mapping correspondence to the new data type standard, and this mapping will also need to be used in order to adopt the new data types alongside EN13606-1.”
Thus, while no official ISO 21090 profile has been defined and mapped to existing TS 14796 (although there are some proposals), the last ones are still the valid ones for 13606. If there is any possibility for this new proposal of Grahame to succeed, it would be a waste of time to change current data types working with 21090.
@Erik: CEN/ISO 13606 discussions take place at the Association forums and wiki, to prepare inputs for the CEN/ISO committee. The data types topic is one of the most important to work on.
Web and forums: www.en13606.org
Wiki: wiki.en13606.org
Hi Tom,
Thanks for the update, really good news. Did you by any chance come
across any discussions regarding the formalism for specifications? Are
we still talking about XSD here?
Thanks for taking note of my work. There certainly was an appetite for
change amongst the HL7 meeting gathered in San Diego. However
there is a long way go yet; it's not clear that we can solve the problems
that must be solved in order to make RFH a serious proposal for change
to HL7; as yet some of these things are just a twinkle in someone's
eyes. I think they can be solved, but the cake hasn't been eaten yet.
And even if all these problems can be solved, we do not yet have a feel
for what kind of change would be required.
In the meantime, the RFH model has some features not to everybody's
liking - or perhaps I should say, everybody will find something in RFH
not to their liking. (http://www.healthintersections.com.au/?p=470)
RFH, for instance, has no concept of polymorphism, which will be
a struggle for some. (well, not none, but much reduced)
That is indeed a good venue to meet as HL7/openEHR implementers. As I
understand it there are no meetings for openEHR implementers, and as
such the HL7 RIM implementers are unable to join such meetings.
RIMBAA has an open invitation to all openEHR implementers to join its
meetings - to just listen, or to act as a speaker and inform your
colleagues about the best way to solve some of the common RIM/RM-based
challenges we're all facing.
On November 15th we'll have an in-depth look at RFH, presented by one of
its co-authors, Ewout Kramer. This meeting has no registration fee -
your cost will be limited to that of a one-day trip to Amsterdam. See
the URL above for details.
Hoi Roger, ik heb me geregistreerd, doe jij dat ook? Lijkt me wel zinvol.
Maar dan moet ik misschien de bedrijfsnaam veranderen, anders is de
vertegenwoordiging vanuit Zorggemak wel erg zwaar.
die datum valt waarschijnlijk in de vakantie van onze oppas, en ik
moet even afwachten hoe de agenda van mijn vrouw is gevuld.
Vanavond weet ik wat meer.
As you say, profiling ISO 21090 data types leads to several problems
of inconsistency and non-interoperability. And in terms of efficiency,
our tests using the new data types in LinkEHR are not satisfactory at all.
But my main question is if this initiative has possibilities of
achieving an official support from HL7. This is an important question
to prepare the future of current norms.
well it has become an official activity at least in HL7, and it seems
from the interest of people at the San Diego meeting, it is not going to
disappear. So I think it is a question of:
a) what is the official form / structure of RFH accepted in HL7 and
b) what is its status - e.g. DSTU, replacement, additional option, ....
This is what the 13606 says about the data types:
"It is recognised that, at the time of producing this standard, a new
set of health informatics data types is being developed by ISO TC/215.
Once this is published, CEN may choose to deprecate TS 14796 in favour
of this new standard. In doing so, it will need to provide a mapping
correspondence to the new data type standard, and this mapping will
also need to be used in order to adopt the new data types alongside
EN13606-1."
Thus, while no official ISO 21090 profile has been defined and mapped
to existing TS 14796 (although there are some proposals), the last
ones are still the valid ones for 13606. If there is any possibility
for this new proposal of Grahame to succeed, it would be a waste of
time to change current data types working with 21090.
