Good thoughts Charlie... just a final thought from me (not really
needing any reply):
* I still want to know if the inheritance of the HL7v3 HXIT
messaging control class into every data type in 21090 is really
what everyone needs/wants, in order to maximise interoperability
and implementability...
- thomas
On 26/11/2010 12:25, Charles McCay wrote:
> Thomas / Ed and all
>
> I have been lurking on this thread - and am not sure that it is really
> constructive to contribute, but I will try.
>
> Changing the world in this space is difficult - indeed any wide-scale
> change to complex systems is hard to achieve, especially if you have a
> very clear view as to what the "right" future state is.
>
> Sharing and manipulating healthcare information happens in many
> evolving ways in different places and contexts - there is not going to
> be a single well engineered framework for this, any more than there is
> a single language uniformly engineered and tested for written and oral
> communication.
> As for written communication there will be some widely supported
> "lingua franca" for some purposes. What makes a good spoken language
> is use and usefulness, not necessarily tight semantics or
> clean grammar. What makes good HIT data exchange languages and
> syntaxes is something that we are all learning about - as we are about
> the best economic and social way to develop, test, improve and promote
> the use of such languages.
>
> I have always been somewhat surprised by the degree of similarity
> between openEHR and HL7v3, with their reference models, datatypes, and
> constrained, reusable models. Also with the fact that some people who
> try implementing them find them complex and brittle, and others find
> them useful. Also the fact that they seem to some to be controlled by
> a small cohort who do not seem to listen. I know that there is work
> going on on both organisations to understand and address these
> perceptions.
> My personal focus in HL7 for the last four years has been on improving
> the visibility of the work being done and the processes being
> followed, to make it easier to engage in a cost effective way, and to
> reduce duplication of effort.
> There is much more to be done in that regard, but I was still
> approached at the last HL7 WGM by a number of new and old attendees to
> be told that it was a remarkably good place to get work done. I know
> that this is a matter of perspective, and that there are folk who have
> found it frustrating and unproductive. I am sure that the HL7 TSC
> will continue to work on improving that.
>
> I personally find HL7 a pragmatic place where skilled engineers and
> subject matter experts address the problems that they care about and
> develop the specifications that they need and I see similar
> behaviours on this openEHR list.
>
> As for changing the world to make sharing healthcare information more
> effective, getting a good specification is important, but there are
> other factors. The supply chains and sets of collaborations that gets
> the right information to the patient and carer/clinician at the right
> time for effective management of health are very rich and varied -
> those of us that do think there is a valuable place for international
> consensus standards need to continue to work on identifying,
> measuring, improving and promoting that value. I am sure that the
> openEHR community will continue to do the same with the value of their
> work..
>
> I look forwards to continuing to learn from both traditions as well as
> others, and do have a great deal of respect for the energy and insight
> that exists in the openEHR community, and am hopeful that constructive
> collaborations and cross-fertilisations will continue
>
> all the best
> Charlie
>
>
>
>
>
>
> On 25 November 2010 16:59, Thomas Beale
> <thomas.beale at oceaninformatics.com
> <mailto:thomas.beale at oceaninformatics.com>> wrote:
>
>
> I have not seen much evidence of widespread uptake of HL7v3,
> indeed Stan and others have said in various places that it has
> been significantly lower than expected. CDA is the one thing that
> is getting use. The few large implementations have spent a
> MOUNTAIN of money to do what they did, and I know for a fact that
> the outcomes are not seen as good value.
>
> See here for what appears to be a reasonable outline of the status
> quo -
> http://www.hl7standards.com/blog/2007/10/10/preparing-for-hl7-v3/
>
> I don't believe changing the RIM, 21090 and other models (apart
> from CDA) would have that much negative impact on the industry as
> a whole, but if the changes were radical enough, they could help a
> lot.
>
> I currently don't have time to submit endless feedback to HL7
> processes, especially when I know they will not be listened to. I
> can't imagine that HL7 is going fix its basic modelling
> methodology, which is what it needs to do. I have actually
> provided very detailed critiques in the past, and nothing has
> happened (other than blocking). Today I just have to be concerned
> with things that are going to be economically implementable by
> normal programmers, correct and safe. I realise that openEHR still
> has to solve some things to make that true (mainly to do with
> better and more openly available Operational Template downstream
> generators), but at least we don't (for the most part) have models
> that just cannot achieve interoperability. In openEHR, every
> single installation of any major version of openEHR, anywhere in
> the world, is 100% safe for data creation, readability, and
> interoperability. It is the same schema forever, for all clinical
> and demographic data, within any given major release.
>
> I believe that the openEHR methodology provides a pretty good
> framework for a) safe data, b) interoperable data, c) data reuse,
> d) implementable software, and e) being domain driven (via
> archetypes). I just can't use any HL7 models to do anything useful
> in the EHR space.
>
> - thomas
>
> p.s. if v3 was so good and easy, I am pretty sure Stan would have
> introduced it at IHC.
>
>
>
> On 25/11/2010 17:31, William E Hammond wrote:
>> HL7 is following basic modeling procedures in the minds of a lot of
>> people.
>> HL7 and CDISC, for example, have worked together to produce BRIDG. A
>> large
>> number of international technologists have and are contributing to HL7.
>> I
>> agree that RIM has problems. RIM evolved early on from data models.
>> Decisions were made by a number of people who at that time believed that
>> was the approach. Stan Huff is leading a TF to look at some of these
>> issues (Graham is part of that TF). WHat changes will be made? I don't
>> know. The problem is further complicated in that the current model has
>> been used in a lot of applications. Thise applications work, even though
>> many of us believe there is a better way. Those changes have to be made
>> against an implemented set. I do urge you to submit your criticisms to
>> the
>> HL7 Technical Steering Committee and to John Quinn, the HL7 CTO. Or to
>> Stan HUff.
> *
> *
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org>
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
>
> --
> Charlie McCay, charlie at RamseySystems.co.uk
> <mailto:charlie at RamseySystems.co.uk>
> Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
> tel +44 1743 232278 / +44 7808 570172 skype: charliemccay
> linkedin:charliemccay
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101126/aa37e216/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101126/aa37e216/attachment.jpg>
