The Truth About XML was: openEHR Subversion => Github move progress

Implementers (archive)
21

Sorry, Bert, IT guys want freedom to model and to code, not us. Clinical practice can be different but shared clinical knowledge is pursued by us since medicine exists, / always trying to be taken as a whole scientific subject. Mapping never, in my experience, which is precisely record linkage,can translate exactly the original statements , and it's expensive and time consuming. Erik has pointed that out brilliantly in his doctor thesis.
We just don't know anything on how IT people translate our requirements into bits and bytes. OpenEHR and the controled clinical knowledge management,based on collaboration and consensus driven for us clinicians iseems to br the right way to proceed, it's clinicians on the wheel. But i think it's a pain to IT developers. No matter they use adl, xml, ocl, whatever, we do need a maximal data set and reuse the models with some specializations. That's all we do in our daily work. We adapt the common knowledge to our practice, using for that our personal knowledge and professional experience. We do not create our personal view of medicine.

S

22

Of course, I talk a lot with medical professionals, it is part of my profession, I am even married to one. They need of course a good messageformat and a good use of that format. Their main goal is to exchange information. Precisely record linkage, as you express it is nice, but also will remain nice to have.

There will never be one system controlling the world, datamapping will always be needed.

Please translate the word "always" as " in my time", which will be more then ten years, insha'allah .

And you are right that physicians want a professional view on their profession which they don't want to invent themselve.

But still, inside that professional point of view, they have need to connect to systems that are different designed as their own, and thus mapping will be needed.
This mapping, however, is not done by technicians, but by medical informaticians. The technicians follow the orders.

It is not ideal, but it is reality.

Bert

23

Oh, we very MUCH do so. We can't help it. But we try to base
it on evidence (hopefully):

  http://www.youtube.com/watch?v=Ij8bPX8IINg

Unless you meant something very specific with "personal view
of medicine".

Karsten

24

Hi Bert, that’s obviously one thing customers want - data interoperability. But - what do they want to do with the data? Let’s say that want to have a managed medication list, or run a query that identifies patients at risk of hypertension, or the nursing software wants to graph the heart rate. Then they need more - just being able to get the data isn’t enough. You have to be able to compute with it. That means standardising the meaning somehow. Now, each healthcare provider / vendor / solution producer could just define their own ‘content models’. Like they do today. Or we could try and standardise on some of them. The openEHR way seems to me the one that can work: because it standardises on the archetypes, which are a library of data points and data groups, it means that anyone can write their own data set specification (template) based on that. So you define what blood pressure looks like once (in the archetype) and it gets used in 1000 places, in different ways. But - it’s guaranteed to be queryable by queries based on the archetype. That’s the essence of the system - 3 modelling layers:

25

Hi Tom

You ask:

Is there a better meta-architecture available?

When actually the question at hand appears to be: is it even worth having one?

I don’t think that this is a question with a technical answer. It’s a question of what you are trying to achieve. I’ve written about this here: http://www.healthintersections.com.au/?p=820

Grahame

26

There is always a meta-architecture. It’s just a question of whether system builders are conscious of it. If they aren’t, then by definition they are just doing development, with no comprehension of the semantics of what they build. I prefer to have conscious design going on, and make some attempts at defining rules for system semantics. Then you know what you can expect the system to do or not. To go back to the question of meta-architecture, let me ask the following questions… 1. is it worth trying to have a publicly agreed (by some community at least) information model? I.e. to at least be able to share a ‘Quantity’, a data tree of some kind, a ‘clinical statement’ and so on? => in my view yes. Therefore, define and publish some information model. Aka ‘reference model’ in openEHR. 2. do we really want to redefine the ‘serum sodium’, ‘heartrate’ and ‘primary diagnosis’ data points every time we define some clinical data set? => in my view no. Therefore, provide a way to define a library of re-usable domain data points and data groups (openEHR version of this: archetypes) 3. do we need a way to define data sets specific to use cases, e.g., the contents of messages, documents etc etc? => in my view, yes, it seems obvious. Therefore, provide a way to define such data sets, using the library of ‘standard data points/groups’, and also the reference model. and 4. would we like a way of querying the data based on the library of re-usable data items? E.g. is it reasonable to expect to query for ‘blood sugar’ across data-sets created by different applications & sources? => in my view yes. To fail on this is not to be able to use the data except in some brute force sense. You (I don’t mean Grahame, I mean anyone :wink: may answer differently, but if you don’t care about these questions, it means you have a fundamentally different view about how to deal with information in complex domains requiring information sharing, computation, and ultimately intelligent analysis (health is just one such domain). Either you think that the above is a ‘nice idea’ but unachievable, or else that it’s irrelevant to real needs, or.. something else. If you think the questions are relevant but have different answers to them, it means you believe in a different meta-architecture. Note that these considerations are actually orthogonal to whether standards should be built by agreeing only on messages between systems, or how systems are built (the topic of Grahame’s blog post). - thomas

27

Very funny

Bert

28

I think is a very good architecture, that is why I am using it, but I(we) keep having to deal with people who think otherwise.
I am not smart enough to point out why HL7v3 messaging is good or bad, or what William Goossen does now, DCM, is good or bad.
As long as a system can hold all required information, I think it is good enough.
But good enough does not mean that it cannot be improved.
I have some thoughts, but that concerns the way they define the messages, and I think, it is a shortcoming of the system, that it only can be done that way.
I think the messages themselves, as designed by NIctiz, for example, are very complete, and can hold all required information.

But, there is some doubt in evidence based practice, so freedom is very important. And in that part, HL7v3 and DCM do not satisfy on this.
They don't offer freedom, they impose elsewhere and predefined ways of thinking and methods of treatment.

Did you see the link Karsten Hilbert published?
http://www.youtube.com/watch?v=Ij8bPX8IINg
Don't eat like a pig and get some exercise is often a good medicine for many diseases, but that does not make money.
But not only, sometimes it is even better not to treat people at all.

There is quite some discussion between physicians on what is a good way to treat people.
And we also have alternative medicine, such as herbal medicine, acupuncture.
This should, all fit in information systems.

I am happy to be a technician and like to offer freedom to the users of my software.

The advantages come, as I already explained, from my point of view with the flexibility, and the completeness of the eco-system, and the easiness with which, even non-technicians can get involved in system-modeling.

I once explained it on Wikipedia with two drawings.

http://commons.wikimedia.org/wiki/File:SingleLevelModelling.png
http://commons.wikimedia.org/wiki/File:TwoLevelModelling.png

In the first, the technicians have to talk with domain-experts, and with the users. Technicians talking about evidence based practice? That does not make sense.
In the second, the technicians are standing beside, and create a base platform on which users and domain-experts can design their system.

More or less this is OpenEHR.
But there is still work to do, for example a good GUI-creator, like Visual Studio (does that still exist?), and generate archetypes from a designed GUI, helping them to incorporate terminology etc.
And of course, good non-GUI-building archetype-editors which are still not there, the complains I had about the both mainstream archetype-editors were admitted, but the improvement did not yet come.

A really good user friendly development environment, which is absolute necessary to make the idea of multi-level modeling to work, has not yet arrived.
Ten years we are working on that, and still we do not comfort the users, who we value very much as main system-modelers, with easy ways to do, what they are expected to do in our philosophy.

Bert

29

Hi Thomas,

I’m surprised that at this advanced stage of openEHR’s maturity you’d still have to defend concepts like these, which are self-evident. Your architecture, or something closely resembling it, is actually the only path to (1) computability, (2) shareability, and (3) coherent and maintainable program code. Ultimately the real enemy is chaos, and that’s precisely what you get unless someone detects and names the universal patterns amidst the diversity, and structures program code to conform to such patterns. I’m not clear why this should be controversial.

This discussion is now dividing into two unrelated branches: (1) the desirability of consensus around the content of data model, and (2) whether the model itself, whether widely agreed to or not, should embody a multi-level abstraction hierarchy permitting code and logic reuse at its more abstract levels. Both branches, wrongly argued, are a direct invitation to chaos. From what I understand of it, openEHR is an attempt, in both regards, to avoid chaos. I can only wish you success against the two challenges.

Randy

30

Hi Randy,

I take your point about there being two threads in this discussion but
I think they *are* closely related.

The nub of Tim's argument, if I understand it correctly, is that a
two-level model is appropriate but that a three-level model (i.e
openEHR specialisations and templates) , allowing for extensions and
further local constraint is unnecessary. He argues that the attempt to
create single, global 'maximal dataset' archetypes is doomed to
failure and that people will simply resort to creating their own
models, but I think that is to misunderstand the value of the 'maximal
dataset approach' and local templating.

This can happen at any level, even within a single hospital system
where a locally developed archetype is maximally developed to meet the
needs of the local clinical stakeholders, so that it can promote
interoperability between these stakeholders. I have been working with
medication and allergy archetypes specific to the UK but need exactly
the same specialisation and templating principles to satisfy the
varying requirements of a very wide group of developers and use cases.
It would have been preferable to use the international equivalents but
sometimes legacy gets in the way. OTOH I am using these same UK
medication archetypes alongside international archetypes as part of a
different UK CDR project. For the forseeable future we will be working
with this sort of mix and match of local. regional, national and
international models. Over time, people will use more of the latter
and less of the former as the need to interoperate grows.

The maximal dataset approach is really all about being inclusive of
the requirements of a groiup of stakeholders who want to maximise
interoperability, but recognise that each has legitimate variations or
legacy process to support. In this circumstance the archetype is as
much about creating a forum where the barriers to interoperability can
be discussed and gradually resolved. We need the specialisation and
templating layer to smooth this emergent activity, and this is what is
difficult to achieve, as I understand it, with UML and XML, at least
for now.

Ian

31

I am always somewhat surprised as well. Thanks by the way for your clarifying notes, that is exactly how I would summarise the discussions.

- thomas

32

There is always a meta-architecture. It’s just a question of whether system builders are conscious of it.

Thomas, perhaps you don’t intend humor, but gems like this are what make reading your posts both enlightening and entertaining, even for someone at my distance.

33

To put some numbers on things… in a 2012 snapshot of the openEHR.org CKM archetypes there are:

  • 267 compiling (i.e. technically valid archetypes)

  • including 94 specialised ones- In these archetypes there are:

  • 3208 ‘archetypable’ nodes (i.e. LOCATABLE nodes)

  • of which 2163 level level nodes with DATA_VALUE objects.

If we concentrate on the leaf level nodes, we can think of 2163 re-usable data points / groups for general medicine. That’s not nothing.

The downside:

  • the quality is variable (due to insufficient modelling work)
  • the coverage of medicine is patchy. Some areas are heavily covered, others with almost nothing.

Nevertheless… these archetypes are commonly re-used in local deployment situations, including some of the ones mentioned here. Re-used usually means that:

  • they were either used as is, or further specialised in order to add or modify some data points / groups
  • used by locally built templates, to create data set definitions that are actually used in systems.
  • they were also used by at least one major national programme (Australia) as a basis for production health information definitions for national use. Some of these archetypes will be re-incorporated into openEHR.org.
  • 30 demographic archetypes were provided by a Brazilian research group
  • numerous archetypes have had translations added by various health professionals and research groups.

With all the limitations implied in the above (and given the relative lack of endorsement by official bodies, who prefer largely hard-to-implement ‘official’ standards), I don’t think this can be claimed to be a failure.

As I said before, although there are a lot of things that can be improved (e.g. reference model simplifications, ADL/AOM 1.5 etc), there has been no thought of getting rid of or substantially changing:

  • the basic 3 levels of reference model, archetypes (the re-usable library of domain definitions) and templates (the usually locally produced data set definitions)
  • the ability to specialise within these levels, i.e. use an inheritance relationship
  • the ability to connect by association one model with other(s)

Indeed, the direction of development is to strengthen all of these. If you consider each level of inheritance (ignore the RM) as a ‘level’, this is what I would call ‘multi-level’ modelling. From the discussions to far, I think the MLHIM aproach, is essentially a method of defining XSD document definitions as constrained versions of an XSD-expressed base information model. As Tim explained, there is no specialisation, nor any distinction between the library (archetypes) and data-set (template) levels. MLHIM may be easier to implement in the short term. However, I think the capability for scaling (implementing numerous new data-sets but with diminishing effort due to a greater library level) and re-use will be relatively limited in the medium to long term. I also think the ability to generate different kinds of artefacts from the underlying definitions - e.g. UI data capture screen definitions, UI display definitions, PDF definitions, WSDL and so on, will be relatively limited.

It may be that the task we set in openEHR is too ambitious! Anyway, this is the world as I see it…

  • thomas
34

I followed the MLHIM for a few months, but I lost interest. I want to explain why.

The main reason for losing interest is for what Tim calls its power feature.
It is sometimes in life that the greatest strength of something is also the greatest weakness.

Every CCD is unique, even every element in a CCD is globally unique.
So an average CCD contains maybe 10 or 20 or more GUIDs inside. They are the structure.
This has technical advantages. Because of this, paths in a XML-database are short and unique, and queries will run quickly.

35

I had the same impression, Bert.

Randy

36

There are a large number of misconceptions and incorrect assumptions
in this thread. I don't have time right now to address all of them
but I will later this week.

Quickly though, there are no "tricks" to what we do in MLHIM.
Everything is 100% W3C standards compliant.

Exploiting a bug in a tool (like Bert is doing in Xerces) so you can
get what you want, is a "trick". A very poor practice trick at that.
One that is certain to come back to bite you and your customers.

Tom's definition of Multi-Level Modelling is not different than what
has been on the main page of the MLHIM website ( www.mlhim.org ) for a
long time. I am not sure how anyone can think that I do not
understand the layers and reusability issues at stake.

You will notice that we encourage artifact re-use in MLHIM as well.
CCDs, PCTs, XForms and XQueries are all reusable. We just do not
expect that there will ever be global consensus on any one artifact.

As far as reading the files. The meta data is standards compliant RDF
in standards compliant Dublin Core, in a standards compliant XML
Schema. What is tricky or difficult about that?

Yes Bert, most people use tools besides a text editor to do real
development. Maybe only yourself and Richard Stallman use Emacs for
everything?

Regards,
Tim

37

I forgot this link: https://github.com/mlhim/tech-docs
The walk through in the README is still incomplete. However, if you
clone this repository and browse the very well laid out documentation
I am sure that the way MLHIM operates will be clearer. The
BMP_CCD.html has the RM included in it so that you can go from the CCD
complexTypes directly to the RM types. If this isn't clear enough
documentation then I suggest http://www.w3.org/XML/Schema or several
of the plethora of excellent text books on the subject.

http://goo.gl/L1jML

Regards,
Tim

38

I thought too it was a bug, I wrote at Oxygen about it, and I became wiser.

It is exploiting not a bug, it is a feature, a switch you can put on and put off.
It is put there deliberately by Xerces.
It is documented in the paragraph about switches on their website.

I was pointed there by an engineer of Oxygen.

I would never exploit a bug, because you cannot be sure that it will remain to exist.
Thanks for giving the opportunity to explain this.

Bert

39

I was not talking about myself.
It is a serious handicap in recognizing element-structures in an XML when their names consist of non-readable GUIDs.
So it is difficult to judge the value of a specific CCD in a glance.

You have the freedom to deny this is so, or ignore it, or take it for granted.
It is just my opinion, and we discussed this before.

Best regards
Bert

40

There are a large number of misconceptions and incorrect assumptions
in this thread. I don't have time right now to address all of them
but I will later this week.

Quickly though, there are no "tricks" to what we do in MLHIM.
Everything is 100% W3C standards compliant.

Exploiting a bug in a tool (like Bert is doing in Xerces) so you can
get what you want, is a "trick". A very poor practice trick at that.
One that is certain to come back to bite you and your customers.

Tom's definition of Multi-Level Modelling is not different than what
has been on the main page of the MLHIM website ( www.mlhim.org ) for a
long time. I am not sure how anyone can think that I do not
understand the layers and reusability issues at stake.

it's similar, but misses the crucial distinction between archetypes and templates. Without that there is no library of re-usable concepts to use in your data-set definitions. As far as I can tell, this distinction just doesn't exist in MLHIM. So it means that every 'model' has to make up its own definition of standard items like vital signs, lab analytes and so on.

You will notice that we encourage artifact re-use in MLHIM as well.
CCDs, PCTs, XForms and XQueries are all reusable. We just do not
expect that there will ever be global consensus on any one artifact.

But you did say that there is no specialisation of models possible. That removes a major mode of re-use. With archetypes, a development project can take 10 archetypes from a national CKM, or openEHR's, and formally specialise them, by adding further restrictions and/or extra data points, as well as translating them, if that's needed. Those specialised archetypes then go into templates they build locally. This system gives fine-grained re-use and re-definition, while guaranteeing that a query for any archetype-defined systolic BP based on a shared archetype, will work, anywhere in the world, regardless of data set, application, clinical context or language.

As far as reading the files. The meta data is standards compliant RDF
in standards compliant Dublin Core, in a standards compliant XML
Schema. What is tricky or difficult about that?

Yes Bert, most people use tools besides a text editor to do real
development. Maybe only yourself and Richard Stallman use Emacs for
everything?

I have sympathies both ways. Example: trying to read RDF in raw form is useless. You can use a tool, but I'd rather have OWL abstract to look at, and that's just text.

- thomas