I’d be interested to see that although, on the surface, it looks similar to what HL7 International attempted to achieve with the RIM. It would also need to be accompanied by a new, or existing (SQL?) query language. Furthermore, unless specifically targeted at ‘green field’ solutions, any new model has to be capable of integrating with legacy data and systems. OpenEHR might have been far more successful if it hadn’t tried to ‘own’ the complete stack.
I love International Standards… there are so many of them to choose from. (Oscar Wilde?, or someone witty anyway.)
But seriously - OpenEHR, FHIR & HL7 v3/RIM (and other things), are bound to continue to co-exist, and the best thing we can do is to take the best from what’s already looking closest to what we need and emulate it, and then fill in the gaps with things that are as easy as possible to convert back and forth.
I think this article is a little credulous about the OpenEHR claims of consensus standards that can be “re-used in the real world”, despite being around a lot longer. The practice of using Archetypes and Templates from OpenEHR is in fact a lot like the use of FHIR - people in national or regional contexts still take existing Archetypes and add locally required specialisations, and zero-out the cardinalities of things that aren’t suitable in their context. I have seen this in practice in NEHTA in myHealthRecord in Australia - which even though I wouldn’t call their use of OpenEHR Archetypes, Templates and mappings from them to HL7 v3 “best practice”, I know why they did that. Apart from no tech stack for OpenEHR messaging in the EMRs and EHRs already deployed, and RIM-constraint-based specs being essentially not human-readable (and not machine readable either!): the Archetypes didn’t have elements that were needed in the Australian context, and NEHTA needed to add them, and the RIM was so general purpose that you can specify anything in it once you’ve selected the right top-level category.
DrJo - I’d suggest you learn the FHIR Structure Definition and its specialisation mechanisms, and put your efforts into making the emerging standards that are being specified into the best that they can be in the framework in which they will be eventually published. Doing your own thing can keep your models pure and beautiful, but if they are not merged into the group effort, then they are ultimately futile. There’s plenty of time, as you can see, as the spec is still gathering requirements independent of what’s in the FHIR base already.
Thanks for your considered responses. I think I’ve now said my bit—that I can see tactics but no strategy. The ‘clinical model’ that’s being imputed from what are effectively messaging constructs* is to my mind putting the cart before the horse. Unfortunately I can’t see how tinkering with resource profiles is going to fix this.
I agree that in many ways, OpenEHR and FHIR are very similar ( something like the homoousians and the homoiousians : ) I’m sure you’re right that constructs like the RIM, FHIR and OpenEHR will persist, and I’m equally certain that we will continue to disagree about their functionality. As a clinician, it’s my perception that the resulting ‘standards’ are already poorly supportive of good clinical medicine; you equally clearly see huge promise.
I agree with Keith that there is no point in models that lie unused (however good they are) and that everything ultimately depends on the group pulling together. However, it seems to me that we have a pretty fundamental disagreement about not just what should be pulled, but the direction it’s to be pulled in!
I feel fairly confident in predicting that in about 20 years’ time, some unfortunates will simply have to unpick all of the unnecessary complexity that has accreted, and concentrate on getting the strategy right—this time built around a solid model of clinical medicine.† I’ve already emphasised some of the components I think are important. I had prepared quite a detailed response to Peter’s most recent post, outlining a simple working model that mirrors good clinical medicine as I see it. On consideration, I think this would simply waste bandwidth, for the reasons already explored.
It’s very possible that the three analogies at the start of my last post are way off beam. I sincerely hope I’m wrong, and if there is a simple but robust overarching strategy to all of this, then I’d still love to have it pointed out.
I can’t see it.
Cheers, Dr Jo.
* In the article Peter referenced, Vivek Krishnan talks about ‘freeing the data’. Data are not captured orcas that need ‘freedom’—they need to be interpreted in context and turned into useful, shared information. I’ve already explained at length why complex ontological constructs are a poor fit here, whether they are in the EHR, or part of the process of message construction. † Or 50 years’ time. Or a hundred.
Hi @DrJo
It’s been interesting to read the full conversation about the IPS and I’m keen to touch base. We can discuss our clinical perspectives and hopefully summarise it here for others to digest.
I’ll be back in NZ at the end of June.
Becky
Always happy to discuss this topic and offer any insights I might have. I also have a GPL-based working demonstration of several of the principles I’ve espoused, on about 360,000 surgical patients, FWIW.
Tone of voice is hard to get right in short text interchanges – it is not my intent was not to reject the contribution of clinical experience unless it’s expressed in “the right” way. I reverted to the DrJo throw-the-gauntlet style to encourage @DrJo to continue to engage (in future - I will admit to throwing too many words out there in this thread).
I look forward to your inputs, in whatever form, and will see if my skill set and experience with many different, necessarily imperfect, formalisms, and the translations between them can assist in getting the clinical semantics (in context!) represented (and messaged and stored and retrieved as a by-product) as close to the way clinicians wish them represented as possible.
@DrJo HL7 International’s Chief Standards Development Officer has just confirmed that the current policy is to make no further changes to the HL7 v3 RIM & Data Types and that the section of the FHIR R4 specification that you cited is “vestigial”. Peter J
The expectation is that these changes will be supported in the next version of the v3 data types model.
Presumably before they finalise this release, they will alter this comment to reflect the policy change, that is, that HL7 v3 RIM & Data Types are now frozen and will no longer keep in synch with FHIR.
Otherwise this looks to me more like misinformation than a mere vestige. What does this imply for those who have invested in all of the complexities of the RIM? Will the gap between it and FHIR widen progressively over time?
@DrJo , I’m sure that there will be some communications from HL7 International when the current ‘Re-Envisioning HL7’ strategy is completed and signed-off. Fortunately, TTBOMK, there has been very little investment in the RIM in New Zealand, other than the constrained version that underpins CDA and that standard has been declared to be ‘in containment’ by HISO. When one healthcare information standard is being actively maintained and another is not, it’s highly likely that the ‘gap’ between them will widen over time.
It is more interested in diagnoses (Problems) than symptoms (problem manifestations). The concern I have is that making symptoms a second tier citizen, clinicians are likely to over diagnose which will increase investigations or proliferate conflicting diagnoses.
SNOMED CT Severities (qualifier value) – eg, mild, moderate, severe
Onset date
Approximate or exact onset date of the problem
Date
Resolution date
Approximate or exact onset date of the problem
Date
Further, I think metadata relating to this would be helpful and should include - “confirmed by” and “date”. Should be provided by the documenting clinician. Should also have a metadata category for the person themselves to endorse with a date (or not) and have a description which supports patient described symptoms and diagnoses.
Could of other thoughts on this one are whether things like implants are captured in this (ICD both kinds, THJR etc).
Will read some more. Have read some more:
Medications - page 21/22
Cessation needs a date (stopping today means much more than stopping 5 years ago). Which suggests we may need a cut off (but knowing a medicine has previously been tried is useful - even if it was a while ago).
Allergies and Adverse Reactions
I think the concept of who has added/endorsed/confirmed is important in here.
Thanks for the feedback on these sections, Jon
There has been quite an amount on problems/conditions that we’ll need to reconcile, but the suggestions for a flatter structure have a good feel
The measurements and vital signs needs to account for streaming data - given it is a summary you might get lots more than you bargain for in this as it currently is described.
I think the careplan thing is well under cooked. Is missing goals, outcome measures, activities that contribute to careplan activity completion or reptitive actions eg. doesn’t consider needing to tick off “take your medicines every day” every day.
I think it needs to be linked to the diagnosis/symptom info above, there are some interesting questions about whether it is a “standard care plan”(we don’t really have these) and then whether extra tasks have been added.
Also recent encounter doesnt say who it was with (has the location but not the person). Maybe that should be a blanket comment that “who generated the content should be included for all of this given in theory this comes together from lots of sources.
In the NZePS Data Model, ‘stopped’ in one of a small, enumerated set of medication actions (the others being new, changed, continued or none). We are about to add a (free text) reason element to that model and introduce a new message type for ‘stopped’ scenarios. These elements are rendered the NZePSCDA documents and, as such, contain the critical metadata that @jon_herries mentions. However, there is time for us to consider using a coded data type for (cessation) reason, although I’m not aware of any endpoint system that codes this data at the moment - so we will just get ‘original text’, if anything.
One perspective that I would like to advance in support of FHIR is the tremendous gaps we currently have between our aspiration and needs for better access to medical information and the current state. And it’s fairly well accepted that you can’t go from basic to advanced in a step: you have to iterate your way up the capability maturity model .
I’ve seen some recent feedback from PHO’s around their ability to support an analytics-orientated subset of the IPS, and we’ve got a long way to go.
I see a key benefit of FHIR as being the definition of standard resources that can be reused across specific implementations. So resources from a specific problem use-case (as defined in an IG) can be accessed and reused in different contexts.
I believe (as are pushing) a key architectural goal in the next 5 years is the creation and population of Sources of Truth, containing FHIR resources with defined profiles, and exposed to Hira for indexing and subscription. Most new national capabilities from the (ex) MoH have been following this model.
This does not resolve the problems at the IG layer, where we define how complex real-world stuff into mapped into these resources (ERD, constraints, extensions etc), but it’ a good start.
to encourage