ISO 21090 data types too complex?
I second that!! Carol Dra Carola Hullin Lucay Cossio Presidente of IMIA-LAC PhD Health Informatics www.imia-lac.net +5628979701 Chile From: s...@vivici.nl Subject: Re: ISO 21090 data types too complex? Date: Sun, 7 Nov 2010 14:53:04 +0100 To: openehr-technical at openehr.org It looks like we're getting to the heart of the matter here. What I really would like to know from the others what their opinion's on these subjects are? If it indeed turns out to be true that Tom don't understand how datatypes, RIM or data types are working, we, as the openEHR community, should ask him to shut up. If not we should find better ways to get the message across... Cheers, Stef Op 7 nov 2010, om 12:12 heeft Grahame Grieve het volgende geschreven: hi Tom . The context specific stuff is specific to HL7 only. It just doesn't apply elsewhere. not at all. And I'm surprised you still think this. HXIT is to do with capturing and managing foreign data. As is some of the II stuff. It doesn't and won't arise in an EHR system for internal data, but it will for imported data. So where it does arise is not HL7 specific. Flavors are a ISO 21090 thing. And optional - they aren't in the schema, for instance. Update mode is transactional. Almost everybody will profile it out. .. There is not a close correspondence between the 21090 idea of ?ANY? and the typical Any/Object or other root class of most object-oriented type systems ? this name clash would have to be resolved in some way; It appears I will have to keep repeating this until I am blue in the face. It is not a name clash, nor does it (or should it) correspond to a root class in any other system - it is it's own class. The fact you think this indicates that you are totally confused as to what ISO 21090 is. (Hint: look at how you modeled your own data types...) ... The modelling style seems to follow the strange HL7 obsession with non-object orientation, popularised in the RIM. which indicates that you don't understand the RIM or the data types, and how they differ. Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/1f297d30/attachment.html
Why is OpenEHR adoption so slow?
Here is a wiki page for governance discussion - http://www.openehr.org/wiki/display/oecom/Community+Governance Bob Mayes is a great guy by the way, he worked for many years in Zimbabwe. - thomas On 05/11/2010 01:21, pablo pazos wrote: Hi Thomas, I see we agreed in much of the points, I hope to see other's visions. Governance is a good issue to discuss with the community, but I can't see any governance if the OpenEHR boards are distant from the community, and do not understand their real needs. What I was really talking from the begining of this discussion is that people, institutions, and goverments have needs that OpenEHR can satisfy, but at the same time, OpenEHR as a whole is not aware of their needs, or is not taking actions to do something. There are a lots of ways of funding, just yesterday, we had an event here in Uruguay of ICT developments in healthcare (we showed our Open EHR-Gen Framework and people was amazed about the concept), there was a man called Bob Mayes from AMIA, and their are launching a subarea called GHiP to build and support communities that solve problems in healthcare informatics (with funding from Rockefeller and Bill Gates foundations, tehy have a buck or two :D). GHiP may be a good place to find some cash to build a governance program to the regional OpenEHR communities, and to support development and objective acomplishment in those communities. The governance program must have an item on how to spend the funding, and this item must be agreed by the community. *It'd be a good idea if we create some section on the web or the wiki, where we can write some thoughs on the governance subject, also we can put some governance ideas from other communities, discuss them, and see if the community agree them. Again, without the involvement of the boards, this will be a dead-before-born subject.* Again, I think we can build some money to improve the tools, like making courses, events (like the IHE Connectathon), selling books, t-shirts, coffe cups, etc (donations are always welcome). I'm against a paid membership, it closes a community that claims to be open, this is not a gym :D well, its why we never did that. I think your ideas are good, the only concern I have is that I think there still has to be a sufficiently strong central part of the organisation to help organise materials, resources, and run the governance structure; at the moment there is not enough funding to do what would be needed to support local orgs. But I would very much like to see openehr.cl, .br, .uy, etc. Just an idea: I think the Service Model is very green yet, but when it go a little more mature, we can make automated tests to test the implementations, and they can have an OpenEHR certificate that the software meets the specification (a paid certificate). we can already test with XML schemas. You are right, the service models will be a key basis for conformance testing, but it will take some more time to get the required maturity. ** - thomas -- Atte. A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos ___ 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/20101108/8722e20e/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/20101108/8722e20e/attachment.jpg
ISO 21090 data types too complex? - (longish)
Stef et al,
In response to Stef's plea for others' opinions, I'd like to add my voice to
Tom's concerns.
I certainly believe that the whole ISO process with respect to health
informatics standards is deeply flawed. As Grahame implies with the datatypes
standard, the process is politically driven and compromises in modelling,
engineering, safety, implementability inevitably occur. The question is how
significant are these compromises and what effect will they have on the
evolution of e-health?
It is highly unlikely that we would have an ISO standard for Health
Informatics - Harmonized data types for information interchange without the
monumental effort of Grahame Grieve in producing and managing the draft.
However, it is, first and foremost, an HL7 flavoured standard. The most recent
draft I have seen is, according to its forward, a shared document between
Health Level Seven (HL7) and ISO. ISO 21090 is undoubtedly complex. One has to
question the value of an international standard, if it is so complex that it
has to be 'profiled' by different organisations before it can be used. By whom,
for what purposes, and by what processes, will such profiling be managed?
ISO 21090 suffers some of the significant flaws that permeate much of HL7
specifications. Tom has already cited the peculiar inheritance hierarchy
amongst others. Another engineering flaw is the pervasive use of cryptic, often
ad hoc enumerations. Even the names of the types wouldn't pass muster in most
quality engineering schools. Names like ENP, HXIT, CO, EN, EN.TN, CD.CV, URG
are simply inexcusable. Levels of indirection never aid readability, and lead
to difficulty in implementation and testing.
It is not necessarily sensible to compare openEHR datatypes with ISO 21090.
They are designed for different purposes. openEHR datatypes underpin openEHR's
reference implementation and archetype object models for building electronic
health record software and so can be augmented by these additional artefacts,
as described below. The ISO datatypes should be able to stand on their own in a
diverse range of implementation environments. This is a much harder task, and
bumps up against fundamental principles of information exchange, whereby the
assumptions of participating systems need to be carefully considered.
Contraints and constraint mechanisms are pivotal here.
A datatype embodies the agreed set of values and operations pertaining to
that type. If an item of received data 211414 has been denoted to be of type
integer, then the receiving system knows how to process it, and will process
it differently than if it had been denoted as a date ( AKA TS.DATE in
HL7/ISO/DIS 21090 HI-HDTII ). Healthcare includes a very rich vocabulary, and
text-based value sets are common in information exchange. A datatype for coded
text, say, needs to convey the agreed set of values of that type. Let's firstly
consider values for severity of adverse reaction to medication. Ideally, both
a sending and a receiving system needs to agree on the set of values - and may
behave sub-optimally if one system uses the set { undetectable, mild,
moderate } and the other uses the set { mild, moderate, severe,
extreme, almost inevitably fatal } , even if these values all came from the
same terminology. In other words, the sending and receiving system are not
actually using the same datatypes in this case.
How do we deal with this in real systems? The United Kingdom's Connecting for
Health program has addressed this in their HL7 V3 - based models by carrying
the constraint within the datatype - in the coding scheme's identifier. So
rather than say the values come from some specific version of SNOMED CT, they
constrain the values to a specific subset using a Refset Identifier. And this
can be carried in instance data.
Now whilst ISO 21090 is capable of constraining text-based value sets, such
constraints are often done by other means - particularly through conformance
statements in non-computable documents, most notably HL7 CDA Implementation
Guides. We are seeing plenty of this in the US, as a result of their Meaningful
Use provisions. In these cases, the datatype does not necessarily carry the
constraint. It almost invariably doesn't. This means that in such transactions,
the receiving system has no way of knowing the true datatype - i.e. the set of
values - for each such data item. The only way for such constraints to be known
to the receiving system is through access to HL7 templates - thus violating THE
principal tenet of HL7's RIM-based information exchange paradigm.
This leads on to one of William Goosen's favourite topics - that of Coded
Ordinals. These have been introduced in ISO 21090 to meet the needs, often
encountered in patient assessment forms, whereby weights are given to
descriptive phrases to indicate the scope of functionality a patient has to
perform, say, activities of daily living (e.g. Barthel Index).
ISO 21090 data types too complex?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/ee957113/attachment.html
ISO 21090 data types too complex? - (longish / CO challenge only)
,
in datatyping, etc. However, this is the level we talk about and it is indeed
beyond the datatype.
The only hope I have is in cooperation and sharing and not blocking such
work with copyright matters.
And, the hope that from this fine grained level of dcm creation we can move
up into the larger modeling efforts e.g. in OpenEHR to represent an entry,
in HL7 to represent a clinical statement and in UML to represent a small
logical model in a larger architectural picture.
William
In a message dated 8-11-2010 4:05:33 W. Europe Standard Time,
eric.browne at montagesystems.com.au writes:
This leads on to one of William Goosen's favourite topics - that of Coded
Ordinals. These have been introduced in ISO 21090 to meet the needs, often
encountered in patient assessment forms, whereby weights are given to
descriptive phrases to indicate the scope of functionality a patient has to
perform, say, activities of daily living (e.g. Barthel Index). The weights
can be used to derive an accumulated score for a collection of individual
activities. Unfortunately, ISO 21090 can't actually provide for this use
case via the CO ( that's code for Coded Ordinal ) datatype, because it has no
way of denoting the set of allowed values. Such a set might look like
[ { 0 , unable}, { 5, needs help (verbal, physical, carrying aid },
{10, independent}]
i.e. a set of pairs of weights and phrases. A coded ordinal only describes
one value, not the set of permissable values! Now, of course it would be
possible to specify these sorts of sets, and to publish them for use in
clinical systems and information exchange. My point is that ISO 21090 doesn't
support such a type and there currently is not a mechanism for this within
HL7 - the primary standard for communicating clinical information. Even
after all these years! I'd like to know how William, for one, hopes to solve
this problem? Perhaps Ed Hammond has a solution in mind?
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/3d0f3f12/attachment.html
ISO 21090 data types too complex? - (longish / CO challenge only)
William,
I follow most of your posting, and I agree that much of the modelling of the
concepts you describe can be done independently of an implementation context.
[There is, of course, the question of tools that best help with this.] I
think, in many instances, you are seeking agreement on your
mini-vocabularies, and help in defining them, in the first place? I've seen a
number of variants of just Barthel index from country to country. Variations
include the number of values for each component data element; the weighting
that should be applied to those values; the phrases that describe each value of
each activity of daily functions. And you would like some efficient way for
these to be edited, shared, stored and ultimately processable into systems. You
would also, I assume want an efficient way for these to be translatable from
language to language and become truly international standards?
Without going into a broader discussion on Detailed Clinical Models, I'd like
to just tease out the specific ISO21090 issue around CO (Coded Ordinal).
You imply that the enumerations can be associated with an OID, and therefore
made available to receiving systems for processing. I don't see how this is
possible, given the inheritance model for CO, which from my understanding goes
something like this:-
ANY
+ nullFlavor
+ flavorId
+ updateMode
QTY
+ expression
+ originalText
+ uncertainty
+ uncertaintyType
CO
+ code : CD [ 0..1]
+ value: Real [ 0..1]
Now are you actually implying that an OID associated with the code in the CO
not only constrains the vocabulary in the code:CD, but also constrains the
numerical value? In other words, we could have two vocabularies
[ {0, unable},
{5, needs help (verbal, physical, carrying aid },
{10, independent} ]
and
[ {1, unable},
{3, needs help (verbal, physical, carrying aid },
{7, independent} ]
and that these could be differentiated by different OIDs ?? How would that
work in practice? How would systems know that little trick? What terminology
servers know that under some circumstances they may not only have to return a
set of term descriptions, in response to an OID query, but some other
associated (numeric) data as well? Have the CTS/CTS 2 projects considered this
requirement?
Beyond this specific issue, there's a broader catch 22 here. Without doing more
clinical modelling, it is difficult to determine the implementation
requirements of datatypes and more complex data structures. Yet without
implementable datatypes and data structures and tools, it is hard to do, and
engender clinician's enthusiasm to do a great deal of clinical modelling.
That's why I think it so important to get behind and support the good work
already done with the openEHR Clinical Knowledge Manager. It seems such an
excellent vehicle for collaborative clinical modelling - irrespective of the
deployment environment. And certainly a tremendous step up from spreadsheets,
Word documents or pieces of paper! I and my colleagues wasted years in NEHTA
and in a clinical information project prior to that, trying with those archaic
tools to undertake a modest amount of modelling and share it with state
government health departments, clinical colleges etc. Not something I would
wish on anyone.
- eric
On 2010-11-08, at 5:36 PM, Williamtfgoossen at cs.com wrote:
I see a kind of cooperation emerging here, which is fine and what I like
most.
Eric points at one are that has my particular interest since I started to
represent such assessment scales in HL7 v3 space in 2002. We where using the
existing HL7 R1 datatypes then and found that for the calculation of the
sumscore the INT could do all counting, but, the specification of each single
score needed to be done with a CO that at that time did not allow for the
calculation. It dit allow Eric's example for Barthel to be expressed.
[ { 0 , unable},
{ 5, needs help (verbal, physical, carrying aid },
{10, independent}]
However, the CO in science is a number and in statistics it is used
differently, namely it has an order, a code and can be calculated upon.
(Although of course there is discussion again on the yes and no's of
calculating averages, there is no science without debate, but that is for me
out of scope for what I am asked to discuss).
Eric is very right that we do need more than just data types. We need
vocabulary, we need units, we need relationships and we need the clinical
knowledge around it, and proof that the persons doing the work can be trusted.
How I see it from a clinical point of view with in mind the many reuses of
clinical data is the following:
bottom line are the atoms of data elements.
This is the minimum level of information that can bring semantics.
the number 38 does not say anything. However, if we define the data type as
being a PQ, more or less equivalent with interval / ratio in statistics), it
becomes
ISO 21090 data types too complex?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/ea79d47f/attachment.html
ISO 21090 data types too complex?
Andrew, I agree that there can be value in producing lower common denominator artefacts for short term implementation gains. I don't, however, see why we can't aim to gain agreement on more specifically defined artefacts as the basis for clinical models, and then, as you suggest, provide adapters for actual implementations, particularly if the cost in doing so is minimal - it is simply a matter of automatically processing from the richer openEHR specification to the simpler ISO 13606. The difference essentially boils down to collapsing archetypes defined according to openEHR's richer ENTRY subclasses of OBSERVATION, EVALUATION, INSTRUCTION and ACTION into archetypes based on the simpler 13606 ENTRY class. As for HL7 V2, I cannot understand why the manifestation of ENTRY types is a relevant issue here. Are you suggesting that if ISO 13606 were balloted today, based on today's openEHR richer ENTRY subclasses that it would substantially change the way archetyped data could be carried in V2, to the point where you could not entertain supporting it? Or conversely that you would be happy to adopt it because it were a standard. Or are you merely suggesting that if Australia, for example, were to develop/adopt/compromise on a set of archetypes based on the openEHR model rather than ISO13606 that one company - Medical Objects - might have to undertake modifications to their product suite? I have to confess that neither my technical skills, nor my clinical knowledge may be sufficient to allow me to form a strong view on the detailed merits of the attributes of openEHR's ENTRY subclasses, other than it seems patently obvious that one needs (somehow) to distinguish between INSTRUCTIONS, ACTIONS and OBSERVATIONS/EVALUATIONS in the openEHR sense of their meanings. To dismiss these differences in favour of some ISO standard, and walk away from the whole process, at least for clinical modelling purposes, seems akin to throwing the baby out with the bath water. And wouldn't that run counter to the Hippocratic oath? - eric On 2010-11-08, at 9:35 PM, Andrew McIntyre wrote: Hello Hugh, As someone who believes in a level playing field I think an international standard, even if a little flawed is better than waiting forever for perfection which will never come. I would extend this ISO 13606-2 to enable sharable archetypes as well. At least then we have a situation where everyone has a common point of reference. I guess everyone is also a little unhappy, but that is better than the current situation. I think the standards are virtual in any system, with adapters to the actual implementations, and to expect anything else is dreaming of a mono culture, usually your own variety of mono culture of course. There are great ideas to be reused from all players, but to expect the world to accept openEHR as the only standard is unreasonable. We have actually done a lot of work to enable the use of archetypes in HL7 V2, not because we thing V2 is the best and most efficient mechanism, but because its a standard and it has widespread usage and we gain a backward compatible encoding, which means we can actually use it. (And the data model is actually transformable into another encoding if desired) Similarly we adapt HL7V2 data for use in the Virtual Medical Record (VMR) and use ISO data types there, not because they are a seamless match for HL7V2, but because the ISO data types are a standard and we would otherwise have to ballot a whole new standard. Its planned to constrain out many, or most of the esoteric base class methods in the ISO data types for the VMR, but they are still a compliant subset. If the openEHR CKM produced ISO archetypes then it would be a lot more acceptable to many people, as it is standards based. Currently you have to buy into the whole game of openEHR, which is I think a problem for many. Its not a criticism of openEHR, but a desire for a neutral agnostic model. You may defend the Evaluation class to the hilt, but there is no reason that every other model has to and this is the problem. We need to accept some level of imperfect abstraction to enable inter-operability, where everyone has to provide glue to make it concrete. Its then less than optimal for everyone, which is I guess what compromise and consensus is all about. I still think it provides several orders of magnitude of functionality, over the current reality. Otherwise we are doomed to the My Model is better than yours war until the last man is standing. I also lament the lack of real technical input into the standards, but that's the reality, I am sure in retrospect many standards eg http, smtp, html could have been designed much better, but inter-operability and pragmatism has trumped perfection and we all live with an imperfect world. That's why I think we should give the ISO Data types a go. Andrew McIntyre Medical-Objects
ISO 21090 data types too complex?
I appreciate all of the remarks that have been make thus far. I am responding because I think we might have some shot at being better. I think many of you tak pot-shots at HL7, and that's OK. An elephant is easier to hit than an ant. In the early years, HL7 had only a few members who were very focused on what we wanted to do. Most were vendors and providers. We create standards that were simple and did precisely what we wanted. As HL7 grew, so did the complexity. David makes the comment about defence of one's lifes work. That is multiplied in spades in HL7. Not only from companies but now increasingly from countries. Hoe can a standard be global unless it addresses global issues. As a result complexity and compromise. The world is political; life is political. We exist in a competitive environmment. We just finished a frustrating political election in the U.S., Most the the political adds told be how basd the oposition was, rather than telling me what they can do for me. Governmnets make decision. Governments fund efforts. To ignore governments would be foolish. Every country has an official government body that is responsible for standards - ANSI, BSI, DEN, AFNOR, others. Complexity causes collapse. Organizations and societies grow in complexity until they finally collapse. IN my opinion, many of the criticisms of HL7 are simple disagreements, not right or wrongs. What group doesn't have acronyms - it's part of today's society - military, government, healthcare - you name it. I would like to see a process in which we fully and completely define the requirements for the standards we need. We debate, discuss and compromise. A small group of technical expeerts create the standard and then everyone evaluates if the requirements are met. HL7 has established a huge presence in the world. It would seem to me to be foolish to ignore HL7 when creating a datatype standard. As long as you have your standard and I have my standard, we have no standard. I think it is important to examine our motivations - what drives us in our work with standards. Is it a life-time work, or is it simple a detail that must be accomplished before we can do what we really want to do. Is our work with standards our claim to fame. There are times when I think HL7 has so many groups because we want a tribe of chiefs. Even that is driven by real requirements - my boss won't pay for my participation unless I have a titled job. You claim that ISO is flawed. Ballot is by standard, a only a few countries dominate. That obviously is not restricted to standards. Again, that's life.But what is a better solution? Shall we live with a decision making prosess in which a relative few people decide what is correct? While I like that approach, if I am a decsion making, I don't like that approach if I'm not. How to we change? What is the solution? HL has honestly tried to find solutions. We recognize flaws and problems and try to solve them. I have issues with archetypes as storage components, I have issues with content and structure. I have the same issues with DCM. I don't like components and folders. Wjy? Debates seem not to solve the problem for many reasons. Can we create an open society that leaves some of the history and biases behind and find the best possible solution? Can we bring together the SDO organizations. I also have a problem that openEHR refuses to be an SDO. Perhaps because they have no rules to follow - while HL7 is bound by ANSI and ISO rules. By the way CEN also votes on the data types. I would like to see some real proposals to try to provide simpler, workable global solutions. It's like World Peace - a great idea but probably not achievable. W. Ed Hammond, Ph.D. Director, Duke Center for Health Informatics David dneilsen at bigpond .net.au To Sent by: For openEHR technical discussions openehr-technical openehr-technical at openehr.org -bounces at openehr. cc org Subject Re: ISO 21090 data types too 11/07/2010 10:48 complex? PM Please respond to For openEHR
ISO 21090 data types too complex?
On Mon, 2010-11-08 at 08:45 -0500, William E Hammond wrote: I would like to see some real proposals to try to provide simpler, workable global solutions. It's like World Peace - a great idea but probably not achievable. I think that pretty much sums up the situation. :-) Cheers, Tim -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/fe96cebf/attachment.asc
ISO 21090 data types too complex?
of representing health information. People in love with CDA presumably defend those classes to the hilt and hope one day that the whole world will use them. But the evidence from trying to model typical clinical information structures as archetypes clearly shows that the openEHR OBSERVATION class (to stick with this example) is better adapted to observational data than its RIM equivalents. This is for one reason only: /we adapted them directly to the challenge of real clinical data/. Are there even better adaptions possible? Undoubtedly, I can even see a few improvements myself. I think any models of structured clinical statements need to address the challenge of real clinical data in a direct and formal way. Until then, most of their claims are unverifiable. We need to accept some level of imperfect abstraction to enable inter-operability, where everyone has to provide glue to make it concrete. Its then less than optimal for everyone, which is I guess what compromise and consensus is all about. I still think it provides several orders of magnitude of functionality, over the current reality. Otherwise we are doomed to the My Model is better than yours war until the last man is standing. well I cling to the hope that we are emotionally mature enough to be uninterested in mine/yours comparisons, and instead be interested in solving the problem in an evidence-based way. This means accepting that models be compared by verifiable, formalisable challenges. If it can be shown that the openEHR OBSERVATION class makes it objectively easier (e.g. in a 'blind tool test' by 50 clinicians) to model BP time series, Apgar, GTT, etc etc, than to do it with a neutral ENTRY type like in 13606, then this should count for something. If it showed it was in fact harder, it would be just as valid - we would really learn something then. But at least we would be doing science and progressing. Currently in the standards arena, there is very little science going on, just hand-waving. I also lament the lack of real technical input into the standards, but that's the reality, I am sure in retrospect many standards eg http, smtp, html could have been designed much better, but inter-operability and pragmatism has trumped perfection and we all live with an imperfect world. That's why I think we should give the ISO Data types a go. well we are forced to anyway, since they are now apparently the one true standard for clinical data types. Oops until profiled according to your own needs into your own version of the standard - thomas Andrew McIntyre Medical-Objects * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/614370e8/attachment.html
ISO 21090 data types too complex?
On 08/11/2010 13:45, William E Hammond wrote: I appreciate all of the remarks that have been make thus far. I am responding because I think we might have some shot at being better. I think many of you tak pot-shots at HL7, and that's OK. I want to clarify one thing: HL7v2 is an excellent standard in the overall judgement of perfection versus pragmatism. It was developed with large amounts of empirical evidence, and has slowly grown over the years. I heard talk of 2.9 recently. It is relatively compact, solves problems it addresses with a reasonable hit rate, and has a pretty good cost/benefit ratio. Yes, it drives developers up the wall, and has all kinds of warts. But the penetration and utility shows the real value. It is no accident that the US and Australia and others make such heavy use of it. The problems we have today with HL7 I think are to do with having entered into massive complexity while losing touch with evidence. Governmnets make decision. Governments fund efforts. To ignore governments would be foolish. Every country has an official government body that is responsible for standards - ANSI, BSI, DEN, AFNOR, others. Complexity causes collapse. One of the main points I made on my blog about this was that in every other industry I know of, the standards are created from fully engineered products, usually created by companies, the military or academia. In the case of toughened glass or mobile phone signalling, the standards orgs are doing the right (more or less) job. In health informatics, other than IHTSDO, they are on some other planet. You claim that ISO is flawed. Ballot is by standard, a only a few countries dominate. That obviously is not restricted to standards. Again, that's life.But what is a better solution? Shall we live with a decision making prosess in which a relative few people decide what is correct? I think that today's world has shown us better solutions. Here are 2: * IETF - largely built by dedicated academic, military and industry people, produced an engineering framework on which most of our modern communications work. The design work did not occur in committees. * the large open source projects, e.g. Linux and Apache to mention a couple, and let's add Python, Plone etc, as Tim would no doubt do. In both examples, a relatively small number of people do decide (in a technical development environment) what is a correct solution to the problem at hand. In the case of Linux, Linus Torvalds is famous for being autocratic - but it works. This is life, not everyone is an architect. The number of designers at BMW is but a tiny fraction of the overall payroll. If it were any other way, we would have chaos. These efforts then offer their output to the world at large, and the world at large decides. Both IETF and the LAMP platform are massive successes. That is because they did not decide on what was /correct for us/ - we did that - we decided what /worked for us/. The success and quality of the above efforts shows us just how flawed building technical artefacts by the paper-based committee approach is. We really need to have total reform, and as soon as possible, because the wastage of having the best and brightest of the medical and IT fields working in such a hopeless structure surely cannot be borne for much longer. Can we create an open society that leaves some of the history and biases behind and find the best possible solution? Can we bring together the SDO organizations. I also have a problem that openEHR refuses to be an SDO. I didn't know that openEHR had refused... I didn't even know that it had been asked. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/633c93cd/attachment.html
ISO 21090 data types too complex?
Well said Ed! Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/bc55f1f9/attachment.html
ISO 21090 data types too complex?
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale at oceaninformatics.com writes: I have been asking HL7 since 2003 or so to show a clean model of any of the following in RIM or CDA structures: 2 or 3 sample Apgar standard 3 sample GTT (glucose tolerance test) with patient state ICU vital sign time series Tom, these are available since about that time in HL7 space. However, they where not balloted yet. William Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/9da9514f/attachment.html
ISO 21090 data types too complex?
Great, do you have a link where they can be found/seen. Cheers, Stef Op 8 nov 2010, om 21:02 heeft Williamtfgoossen at cs.com het volgende geschreven: In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale at oceaninformatics.com writes: I have been asking HL7 since 2003 or so to show a clean model of any of the following in RIM or CDA structures: 2 or 3 sample Apgar standard 3 sample GTT (glucose tolerance test) with patient state ICU vital sign time series Tom, these are available since about that time in HL7 space. However, they where not balloted yet. William Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/1f167442/attachment.html
ISO 21090 data types too complex?
Thanks. W. Ed Hammond, Ph.D. Director, Duke Center for Health Informatics Williamtfgoossen@ cs.com Sent by: To openehr-technical openehr-technical at openehr.org -bounces at openehr. cc org CTeam at lists.hl7.org Subject Re: ISO 21090 data types too 11/08/2010 03:03 complex? PM Please respond to For openEHR technical discussions openehr-technica l at openehr.org Well said Ed! Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
ISO 21090 data types too complex?
On 08/11/2010 20:02, Williamtfgoossen at cs.com wrote: In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale at oceaninformatics.com writes: I have been asking HL7 since 2003 or so to show a clean model of any of the following in RIM or CDA structures: 2 or 3 sample Apgar standard 3 sample GTT (glucose tolerance test) with patient state ICU vital sign time series Tom, these are available since about that time in HL7 space. However, they where not balloted yet. * * yes I have seen the HL7 models for these things. They are really poor (nothing to do with the people doing them; the formalism just doesn't support modelling them easily). - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/1a65de94/attachment.html
ISO 21090 data types too complex?
On 08/11/2010 18:51, Grahame Grieve wrote: hi All A roll up of comments: 1. ISO 21090 is often (always?) profiled It seems remarkable to me that people think it's a problem that ISO 21090 needs to be profiled. Who would've guessed that a full standard that meets many requirements is simpler to implement if you profile out the features that reflect requirements you don't have? I'm pretty sure that this is true of every other standard as well. It's certainly true of all my implementations of W3C, IETF, and OMG standards. I know that in HL7 this profiling is normal. The only kind of 'profile' I know of elsewhere in other standards is of the kind 'we only implement x, y but not z'. In other words, choosing a subset of classes or features to implement. As soon as one has to actually chop up the classes in a model however, we are on different ground. The answers Grahame gave me last time I discussed how to profile 21090 for 13606 use are here http://www.openehr.org/wiki/display/stds/openEHR+to+ISO+13606-1%2C+ISO+21090+mapping, about half-way down. As you can see, it was not 100% clear on a cursory inspection what exactly the profile version would look like. As Grahame has said, this is still to be done properly with Dipak. This means that official users of 13606, e.g. Sweden, can't actually use the standard out of the box, and do not have any official version to use until that work is done. I happen to know that Sweden, Singapore and the UK have created at least 3 different 'profiles' of 21090 over time, all to suit their own needs. There is no guarantee that data or software built on these home-grown profiles will talk to each other, nor that any of them would talk with software or data built on the pure 21090 specification. So in fact, we have N pseudo-standards, and no real standard. This can't be anybody's idea of an easy way to get started with a data types standard. 2. Some people have responded vehemently to Tom's initial comments I suppose I'm a little guilty. I don't mind people criticising ISO 21090. Other's people's list of criticisms will never be as a long as mine. But it's frustrating to respond to the same wrong comments repeatedly, especially when the come from people who are widely and rightfully regarded as genuine experts Note that I am not particularly making criticisms as if it were me personally trying to address the problems; I am mainly reflecting common responses from others, e.g. in government departments, universities and so on. There is no escaping from the fact that having a type called 'Any' representing a concept that should be called something like 'AnyDataValue' (in openEHR it is DV_ANY) is annoying and has to be dealt with in some way. 3. In health informatics, standards are done differently. We had this discussion last week. I made the point that this is true of IT vertical industry integration standards. I don't believe Tom offered a counter example to this. I have not been tracking other vertical industry ICT standards. But I did offer a examples of 'stacks' of standards which do not follow the strange world of HL7 modelling. Everyone else uses normal OO modelling, or else something accepted like XML schema (admittedly terrible for object models, but that's another story); but HL7 can't (it instead tries to get OMG to change UML). I fail to see why standards in e-health have to be done in such a bizarre way. There is nothing special about e-health requiring that. 4. The ISO process is flawed Yes. As is every other process, each in it's own way. well yes and no... there are different categories of flawedness in e-health, the paper standards bodies a) 'design' technical artefacts by (randomly self-selected) committees, b) take many years to ratify them, c) don't validate them properly and d) don't maintain them in any meaningful time period. Engineering processes (i.e. requirements capture, analysis, design, implement, test, deploy, maintain - all with feedback loops - by technically competent people) are also flawed, but usually only in minor ways. We still feel safe getting into an aircraft designed by an engineering process. Hardly any modern aircraft fall out of the sky due to engineering faults (the current problem with the Rolls Royce Trent 900 engines shows just how far you have to push the boundaries before any kind of serious problem occurs).* I still contend that we can do much, much better. * - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/600e36af/attachment.html
Why is OpenEHR adoption so slow?
/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thomas Beale Chief Technology Officer, Ocean Informatics Chair Architectural Review Board, openEHR Foundation Honorary Research Fellow, University College London Chartered IT Professional Fellow, BCS, British Computer Society Health IT blog ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/d81e60d6/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/20101108/d81e60d6/attachment.jpg
Why is OpenEHR adoption so slow?
are horrible, or not open source, or not updated recently). I think regional communities can create courses, resources, materials, etc... and share them with other communities, throught OpenEHR foundation. Guidelines to do this must be set from the OpenEHR Foundation Boards (I think they are there to lead the community, to encourage the spread and adoption of the standard, I can't remember the last time I saw an email of the OpenEHR Boards in the mailling lists). Within those guidelines, we can be coordinated, and maybe set year-based goals. And once a year or two we can make some event to share our experiences and progress from our local communities (can be local or regional events, since for most of ours it's hard to travel so far). These ideas are not new, just look at the HL7 coutry based structure. I know this words may sound hard to someone, I just want to support the success of the standard, but I think if we keep doing things the same way, we'll end with a high quality standard with no one to implement it. Cymraeg:- Mae'r neges hon yn gyfrinachol nad chi yw'r derbynnydd y bwriedid y neges ar ei gyfer, byddwch mor garedig ? rhoi gwybod i'r anfonydd yn ddi-oed. Dylid ystyried un rhywd datganiadau neu sylwadau a wneir uchod yn rhai personol,ac nid o angen rhaid yn rhai o eiddo Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg, nac unrhyw ran gyfansoddol ohoni na chorff cysylltiedig. Cofiwch fod yn ymwybodol ei bod yn bosibl y bydd disgwyl i Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg roi cyhoeddusrwydd i gynnwys unrhyw ebost neu ohebiaeth a dderbynnir, yn unol ag amodau'r Ddeddf Rhyddid Gwybodaeth 2000. I gael mwy o wybodaeth am Ryddid Gwybodaeth, cofiwch gyfeirio at wefan Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg ar www.abm.wales.nhs.uk English:- This message is confidential. If you are not the intended recipient of the message then please notify the sender immediately. Any of the statements or comments made above should be regarded as personal and not necessarily those of Abertawe Bro Morgannwg University Health Board any constituent part or connected body. Please be aware that, under the terms of the Freedom of Information Act 2000, Abertawe Bro Morgannwg University Health Board may be required to make public the content of any emails or correspondence received. For further information on Freedom of Information, please refer to the Abertawe Bro Morgannwg University Health Board website at www.abm.university-trust.wales.nhs.uk. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/d0589ce0/attachment.html
ISO 21090 data types too complex?
process, each in it's own way. well yes and no... there are different categories of flawedness in e-health, the paper standards bodies a) 'design' technical artefacts by (randomly self-selected) committees, b) take many years to ratify them, c) don't validate them properly and d) don't maintain them in any meaningful time period. Engineering processes (i.e. requirements capture, analysis, design, implement, test, deploy, maintain - all with feedback loops - by technically competent people) are also flawed, but usually only in minor ways. We still feel safe getting into an aircraft designed by an engineering process. Hardly any modern aircraft fall out of the sky due to engineering faults (the current problem with the Rolls Royce Trent 900 engines shows just how far you have to push the boundaries before any kind of serious problem occurs). I still contend that we can do much, much better. - thomas Cymraeg:- Mae'r neges hon yn gyfrinachol nad chi yw'r derbynnydd y bwriedid y neges ar ei gyfer, byddwch mor garedig ? rhoi gwybod i'r anfonydd yn ddi-oed. Dylid ystyried un rhywd datganiadau neu sylwadau a wneir uchod yn rhai personol,ac nid o angen rhaid yn rhai o eiddo Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg, nac unrhyw ran gyfansoddol ohoni na chorff cysylltiedig. Cofiwch fod yn ymwybodol ei bod yn bosibl y bydd disgwyl i Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg roi cyhoeddusrwydd i gynnwys unrhyw ebost neu ohebiaeth a dderbynnir, yn unol ag amodau'r Ddeddf Rhyddid Gwybodaeth 2000. I gael mwy o wybodaeth am Ryddid Gwybodaeth, cofiwch gyfeirio at wefan Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg ar www.abm.wales.nhs.uk English:- This message is confidential. If you are not the intended recipient of the message then please notify the sender immediately. Any of the statements or comments made above should be regarded as personal and not necessarily those of Abertawe Bro Morgannwg University Health Board any constituent part or connected body. Please be aware that, under the terms of the Freedom of Information Act 2000, Abertawe Bro Morgannwg University Health Board may be required to make public the content of any emails or correspondence received. For further information on Freedom of Information, please refer to the Abertawe Bro Morgannwg University Health Board website at www.abm.university-trust.wales.nhs.uk. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/b6c481e3/attachment.html
