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

Implementers (archive)
41

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

By the way, the problem you solve by use of GUIDs can also be solved by use of another validation-language: RelaxNG.
It is from Oasis (so also prestigious, even Microsoft is member https://www.oasis-open.org/member-roster ),
and the OpenOffice-documents are validated this way.

RelaxNG allows complex elements with different types in the same group with the same name and checks at run/validation time how to validate an element.

Suppose you want this:

<addressBook>
   <card>
     <givenName>John</givenName>
     <familyName>Smith</familyName>
     <email>js@example.com</email>
   </card>
   <card>
     <name>Fred Bloggs</name>
     <email>fb@example.net</email>
     <note>bla bla bla</note>
   </card>
</addressBook>

Two kind of complextype of "card", one containing name, email and the other containing firstName, familyName, email.
In XML-schema this is not possible.

In RelaxNG the schema looks like this:

element addressBook {
   element card {
     (element name { text }
      > (element givenName { text },
         element familyName { text })),
     element email { text },
     element note { text }?
   }*
}

It has a card-definition with two elements for both: email and note, the element note is optional.
And it validates the first group as: it must be a name OR it must be firstName and lastName.

I think Tim, you can leave your GUIDs out of your element-names in your schema's and validate against relaxNG
What do you think?

Bert

42

The book on RelaxNG is free available on the Internet

http://books.xmlschemata.org/relaxng/page2.html

It is released under the/Free Software Foundation GFDL <http://books.xmlschemata.org/relaxng/relax-APP-B.html&gt;\./

Bert

43

RelaxNG and Schematron are well known solutions to XML Schema 1.0
deficiencies. However, they add another level of semantics into
modelling as well as additional concepts and tools. I am not certain
that you can maintain precise CONSTRAINT BASED multi-level modelling
in this case. Even if you can it is going to be more complicated.

Your insistence in adding meaningful names to elements in constraint
definitions, I think, is problematic. There is nothing in MLHIM to
keep you from using a generated element id of any kind. If you want
to use sequential ids in your elements that is fine. However, it will
mean that you can't reuse those complexType definitions effectively.

Validating a CCD and reading the metadata should be enough for anyone
to determine if a CCD is useful for them or if they need to create
one. Modellers should add the semantics in computable form to the
metadata section for every complexType. For example, from the BMP
CCD:
              <!-- Semantic links for complexTypes -->
              <rdf:Description
rdf:about="mlhim2:ct-f6c5ea6e-6458-4799-874d-7f3d365d260d"> <!--
Sodium (Na) -->
                <rdfs:isDefinedBy
rdf:resource="http://purl.bioontology.org/ontology/SNOMEDCT/365761000&quot;/&gt;
              </rdf:Description>
              <rdf:Description
rdf:about="mlhim2:ct-28f7ec54-254b-4b66-9c42-3b275fc1df38"> <!--
Glucose -->
                <rdfs:isDefinedBy
rdf:resource="http://purl.bioontology.org/ontology/SNOMEDCT/365812005&quot;/&gt;
              </rdf:Description>
              <rdf:Description
rdf:about="mlhim2:ct-781e9dda-055a-4a95-bee3-d482c44d1186"> <!--
Potassium (K) -->
                <rdfs:isDefinedBy
rdf:resource="http://purl.bioontology.org/ontology/SNOMEDCT/312468003&quot;/&gt;
              </rdf:Description>
              <rdf:Description
rdf:about="mlhim2:ct-866aa21b-9cd2-48cc-9c18-8e799086d222"> <!-- Urea
(BUN) -->
                <rdfs:isDefinedBy
rdf:resource="http://purl.bioontology.org/ontology/SNOMEDCT/144004004&quot;/&gt;
              </rdf:Description>
              <rdf:Description
rdf:about="mlhim2:ct-51b66f95-13b5-4e25-9c08-5e6d43aeba79"> <!--
Creatinine -->
                <rdfs:isDefinedBy
rdf:resource="http://purl.bioontology.org/ontology/SNOMEDCT/365756002&quot;/&gt;
              </rdf:Description>

--Tim

44

I am not certain
that you can maintain precise CONSTRAINT BASED multi-level modelling
in this case.

It would be interesting if you can pinpoint a problem-situation.

If you want
to use sequential ids in your elements that is fine.

I would like to have the element-names referring to the information-model. I want to call an ITEM_LIST-attribute "items" just "items", not "items_12".
If the validation-schema does not allow that (XML-Schema has this problem), and there can't be worked around, than the schema is not good enough for me.

What you do else, is defining a standard around a problem of XML-schema, so you can still keep on using XML-Schema, that is bad, in my opinion.

Bert

45 
[reposted for Tim; hist original bounced]

On Wed, Apr 10, 2013 at 5:14 AM, Thomas Beale [<thomas.beale@oceaninformatics.com>](mailto:thomas.beale@oceaninformatics.com) wrote:


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.


MLHIM allows reuse but does not allow redefinition.  Redefinition of a
component after it has been used to generate instance data is a BAD
THING.  You are simply looking for trouble when models can morph into
something they were previously not.  Then we can discuss the
complexity managing that process.  It just isn't necessary in MLHIM.


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

_______________________________________________
openEHR-technical mailing list
[openEHR-technical@lists.openehr.org](mailto:openEHR-technical@lists.openehr.org)
[http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org](http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org)



-- 
============================================
Timothy Cook, MSc           +55 21 94711995
MLHIM [http://www.mlhim.org](http://www.mlhim.org)
Like Us on FB: [https://www.facebook.com/mlhim2](https://www.facebook.com/mlhim2)
Circle us on G+: [http://goo.gl/44EV5](http://goo.gl/44EV5)
Google Scholar: [http://goo.gl/MMZ1o](http://goo.gl/MMZ1o)
LinkedIn Profile:[http://www.linkedin.com/in/timothywaynecook](http://www.linkedin.com/in/timothywaynecook)
46

This is an open door, a definition can never be changed again and having the same name.

Bert

47

I am not certain
that you can maintain precise CONSTRAINT BASED multi-level modelling
in this case.

It would be interesting if you can pinpoint a problem-situation.

Sure, if you are willing to fund that research.

If you want
to use sequential ids in your elements that is fine.

I would like to have the element-names referring to the information-model. I
want to call an ITEM_LIST-attribute "items" just "items", not "items_12".
If the validation-schema does not allow that (XML-Schema has this problem),
and there can't be worked around, than the schema is not good enough for me.

Did you actually LOOK at MLHIM CCDs? For example:

    <xs:complexType name="ct-ef7dc8ee-5cf5-47cc-92a5-7143094b88c8">
        <xs:complexContent>
            <xs:restriction base="mlhim2:CareEntryType">
                <xs:sequence>
                    <xs:element maxOccurs="unbounded" minOccurs="0"
ref="mlhim2:links"/>
                    <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:feeder-audit"/>
                    <xs:element maxOccurs="1" minOccurs="1"
name="language" type="xs:language" default="en-US"/>
                    <xs:element maxOccurs="1" minOccurs="1"
name="encoding" type="xs:string" default="utf-8"/>
                    <xs:element maxOccurs="1" minOccurs="1"
ref="mlhim2:el-c2c7e652-46f8-498a-99d0-c85005d98f6f"/>
                    <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:entry-provider"/>
                    <xs:element maxOccurs="unbounded" minOccurs="0"
ref="mlhim2:other-participations"/>
                    <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:protocol-id"/>
                    <xs:element maxOccurs="1" minOccurs="0"
name="current-state" type="xs:string"/>
                    <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:workflow-id"/>
                    <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:attestation"/>
                    <xs:element maxOccurs="1" minOccurs="1"
ref="mlhim2:el-a69717be-7b3f-4be7-9fec-80f8ec1891e8"/>
                </xs:sequence>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    <xs:element name="el-a69717be-7b3f-4be7-9fec-80f8ec1891e8"
substitutionGroup="mlhim2:entry-data"
type="mlhim2:ct-a69717be-7b3f-4be7-9fec-80f8ec1891e8"/>
    <xs:element name="el-c2c7e652-46f8-498a-99d0-c85005d98f6f"
substitutionGroup="mlhim2:entry-subject"
type="mlhim2:ct-c2c7e652-46f8-498a-99d0-c85005d98f6f"/>

This CareEntry contains the same element names from the reference
model for all simple types. Where there are complexTypes required the
reference model element name is the substitution group for the
constraining element/complextype pair. The use of xs:sequence means
that it is easy to determine the correct order of the elements so they
are sequentially related to the reference model and they are named in
the substitution group.

Thanks for allowing this MLHIM tutorial on the openEHR mailing list.
I did request earlier that questions be addressed in the MLHIM areas.
But everyone wanted to post questions here instead.

What you do else, is defining a standard around a problem of XML-schema, so
you can still keep on using XML-Schema, that is bad, in my opinion.

That is your opinion. Frankly I do not see it as a problem. It
certainly is not a technical problem. In fact because you can't have
global elements with the same name is not different than in object
oriented programming. There is a way to get around the use of unique
identifiers in MLHIM CCDs and that is to use different namespaces. So
if you want to start injecting semantics into CCDs you can namespace
each one. But then you start to run up against the same problem that
openEHR has with naming archetypes. There will be clashes. The
overall management using one namespace and unique IDs is MUCH simpler
and doesn't require any central control. The MLHIM approach allows
complete autonomy of development and still provides for semantic
interoperability. This approach also makes improvements in the
reference model easier to manage and never invalidates any previously
developed CCDs.

--Tim

48

I am not certain
that you can maintain precise CONSTRAINT BASED multi-level modelling
in this case.

It would be interesting if you can pinpoint a problem-situation.

Sure, if you are willing to fund that research.

Sorry Tim, I was thinking you had reasons to question the ability of Relax NG to define the needed constraints.
I just asked to pinpoint just one problem in this context.

But now it is clear that you cannot pinpoint not one problem without any research.

Thanks, for illustrating this. We can as well close this discussion subject, because I will not pay you for your arguments.

If you want
to use sequential ids in your elements that is fine.

I would like to have the element-names referring to the information-model. I
want to call an ITEM_LIST-attribute "items" just "items", not "items_12".
If the validation-schema does not allow that (XML-Schema has this problem),
and there can't be worked around, than the schema is not good enough for me.

Did you actually LOOK at MLHIM CCDs? For example:

Yes I did.

And your example below illustrates my arguments.
The problem of GUIDs appearing in the complextypes, because, that is exactly where the referred XML-Schema rule is applicable.

     <xs:complexType name="ct-ef7dc8ee-5cf5-47cc-92a5-7143094b88c8">
         <xs:complexContent>
             <xs:restriction base="mlhim2:CareEntryType">
                 <xs:sequence>
                     <xs:element maxOccurs="unbounded" minOccurs="0"
ref="mlhim2:links"/>
                     <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:feeder-audit"/>
                     <xs:element maxOccurs="1" minOccurs="1"
name="language" type="xs:language" default="en-US"/>
                     <xs:element maxOccurs="1" minOccurs="1"
name="encoding" type="xs:string" default="utf-8"/>
                     <xs:element maxOccurs="1" minOccurs="1"
ref="mlhim2:el-c2c7e652-46f8-498a-99d0-c85005d98f6f"/>
                     <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:entry-provider"/>
                     <xs:element maxOccurs="unbounded" minOccurs="0"
ref="mlhim2:other-participations"/>
                     <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:protocol-id"/>
                     <xs:element maxOccurs="1" minOccurs="0"
name="current-state" type="xs:string"/>
                     <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:workflow-id"/>
                     <xs:element maxOccurs="1" minOccurs="0"
ref="mlhim2:attestation"/>
                     <xs:element maxOccurs="1" minOccurs="1"
ref="mlhim2:el-a69717be-7b3f-4be7-9fec-80f8ec1891e8"/>
                 </xs:sequence>
             </xs:restriction>
         </xs:complexContent>
     </xs:complexType>
     <xs:element name="el-a69717be-7b3f-4be7-9fec-80f8ec1891e8"
substitutionGroup="mlhim2:entry-data"
type="mlhim2:ct-a69717be-7b3f-4be7-9fec-80f8ec1891e8"/>
     <xs:element name="el-c2c7e652-46f8-498a-99d0-c85005d98f6f"
substitutionGroup="mlhim2:entry-subject"
type="mlhim2:ct-c2c7e652-46f8-498a-99d0-c85005d98f6f"/>

This CareEntry contains the same element names from the reference
model for all simple types. Where there are complexTypes required the
reference model element name is the substitution group for the
constraining element/complextype pair. The use of xs:sequence means
that it is easy to determine the correct order of the elements so they
are sequentially related to the reference model and they are named in
the substitution group.

Thanks for allowing this MLHIM tutorial on the openEHR mailing list.
I did request earlier that questions be addressed in the MLHIM areas.
But everyone wanted to post questions here instead.

What you do else, is defining a standard around a problem of XML-schema, so
you can still keep on using XML-Schema, that is bad, in my opinion.

That is your opinion. Frankly I do not see it as a problem. It

Of course, we are exchanging opinions. Of course there are technical solutions, more then one. You found one.
I don't like it. It is my opinion.

Your solution has advantages, I already agreed on that, two days ago.
But I have problem with the disadvantages, which I described in the same contribution to this subject.

I do not want to repeat the arguments.

Bert

49

A couple of things to say here. ‘Redefinition’ as in openEHR and most model-based systems I know of doesn’t mean you change something that has been deployed. It means being able to specialise an existing model in the design environment, in a similar way as in object-oriented programming. So the point is to be able to re-use and adapt existing definitions, not just ‘use’ things. Not being able to do this means either: There is actually no such thing as ‘redefining a deployed model’. Models can be evolved over time, and they get new version numbers. Breaking changes get new major versions, which are treated as distinct models in archetype land. But new versions with non-breaking changes can be treated by querying, modelling tools, reporting etc as being compatible with earlier versions. Being able to query safely over longitudinal data whose models change over time is essential in health. It’s clear that these needs (specialisation of models, longitudinal querying over data) are seen as essential by large orgs, e.g. the CIMI members Mayo clinic, InterMountain Health, Veterans Health, Nehta and so on. The OHT Model-driven Health Tools (MDHT) project is founded upon concepts like model specialisation and re-use. I don’t think there is any way these needs can be ignored in a scalable, adaptable health information modelling ecosystem. - thomas

50

The scientists under Ptolemy's conceptual umbrella didn't think there
was any way that "the fact" that the earth stood still could be
ignored until Copernicus had doubts about their approach and proved
them wrong and Kepler refined the model either.

So goes innovation.
Dare to think different.

"Insanity: doing the same thing over and over again and expecting
different results." - Albert Einstein

--Tim

51

The scientists under Ptolemy's conceptual umbrella didn't think there
was any way that "the fact" that the earth stood still could be
ignored until Copernicus had doubts about their approach and proved
them wrong and Kepler refined the model either.

So goes innovation.
Dare to think different.

"Insanity: doing the same thing over and over again and expecting
different results." - Albert Einstein

--Tim

52

The scientists under Ptolemy's conceptual umbrella didn't think there
was any way that "the fact" that the earth stood still could be
ignored until Copernicus had doubts about their approach and proved
them wrong and Kepler refined the model either.

So goes innovation.
Dare to think different.

"Insanity: doing the same thing over and over again and expecting
different results." - Albert Einstein

--Tim

53

Tim,

Looking at the extract below, this MLHIM model would be hard to use as a basis for generating source code facades, WSDL, JSON UI form specifications, and other things we regularly generate downstream from templates.

- thomas

54

Tim,

Looking at the extract below, this MLHIM model would be hard to use as a
basis for generating source code facades, WSDL, JSON UI form specifications,
and other things we regularly generate downstream from templates.

I have no clue why you would say that when there are TONS of tools and
libraries, built and tested, for working with XML Schemas and XML data
in building WSDL, XForms, XQueries and other XML family artifacts, as
well as JSON.

Your earlier statement on this subject was just so bizarre to me that
I didn't reply to it. A simple survey of what is available as well as
common sense dictate that these things all work together. The only
thing I can think of is your "I must build it myself" approach. Which
in that case, it might be difficult for you to build them. But why?

I don't understand your concern. This is XML, you don't have to build
or adapt it.

--Tim

55

Tim,

A couple of things to say here. ‘Redefinition’ as in openEHR and most model-based systems I know of doesn’t mean you change something that has been deployed. It means being able to specialise an existing model in the design environment, in a similar way as in object-oriented programming. So the point is to be able to re-use and adapt existing definitions, not just ‘use’ things.

Not being able to do this means either:

  • you are stuck using someone else’s definition, and you just live with not having the bits you wanted

  • you have to make a copy, and rewrite to suit yourself. Now you have a different model, technically unrelated to the original, and tools have no idea that they might be able to query for some of the same data points.
    If you look at the sort of thing Tim models in his CCDs, the concepts tend to be very granular and low-level and tend to embody pre-existing classification systems, such as ICD10. As long as he keeps to that sort of thing, these individual tiny units of thought, in and of themselves, would probably not need to be specialized or extended. That’s why he can argue that specialization and extension are bad. The need to specialize would seem to increase when the archetype or concept embodies a higher level of thought, involving more interrelated and moving parts. For example, concept A will probably not change or be extended, nor will concept B. But when your concept includes some combination of A and B, combined with C, then someone will probably need to extend or specialize it.

As I understand it, Tim’s system could model A, B and C into some CCD known as E. But not the slightest thing about E could be extended or added to without calling A something else, B something else, C something else and the whole thing (E) something else. Then, as you say, the power to query across the change is lost despite continuity of most of the content.

The real question thus comes down to what level of thought the nameable components of a model should express. If the entire model could be understood as a tree, how complex should the named branches of that model be, and how enduring should the names of those branches be and what sort of change triggers a change of name? Should named branches be allowed at all? Or should the model consist only of re-usable leaves on unnamed branches? Branches, even very complex branches, would certainly exist in the models based on his CCDs, yes, but they would probably not be given names, and if they are, those names would not endure across even tiny changes or extensions.

I wonder whether at even the most granular level, immutability is realistic. There is a fair bit of content that Tim models for just one ICD10 code component. Each ICD10-based CCD is itself a little tree, with one branch with some leaves on it. What if the WHO “extends” the low-level content in some small way, adding a leaf, without changing the code? That would push Tim into a new CCD (named with a new GUID) for the very same code with a completely different set of GUIDs for ALL the leaves. Models using the old CCD would need to adopt the new one, and querying across the transition would be aborted. And that would be consequential for something as basic as an ICD10 code. This concern probably reflects some ignorance on my part over what sort of change the WHO permits to the content of a given ICD10 code, and how Tim would adapt to that.

Randy

56

The reality is that an entire ecosystem will have to be built to prove
its usefulness. I did this over a three year period with XML Schema
1.1.
If you have a desire to use RelaxNG to build a multi-level modelling
ecosystem. Then you either need to go to work doing it or provide
funding for others to do it.

My intuition tells me that there will be problems. Maybe not
intractable problems. I do not know. But I personally have no reason
to spend my time and energy exploring that possibility. If you are
passionate about it, then go for it. I look forward to your results.

Cheers,
Tim

57

Sorry Tim, I was thinking you had reasons to question the ability of Relax
NG to define the needed constraints.
I just asked to pinpoint just one problem in this context.

But now it is clear that you cannot pinpoint not one problem without any
research.

Thanks, for illustrating this. We can as well close this discussion subject,
because I will not pay you for your arguments.

The reality is that an entire ecosystem will have to be built to prove
its usefulness. I did this over a three year period with XML Schema
1.1.
If you have a desire to use RelaxNG to build a multi-level modelling
ecosystem.

I use OpenEHR as multi-level modeling model.
But I want to translate the datasets to XML, and I am looking for validation.
XML-schema works but it has problems. Especially that complextype rule which brings you to the GUID-thing is difficult.
But I have a workaround for it. Works good and fast.

My situation is different then yours. XML-Schema does not define my eco-system. XML is only a way to use proven technology on a new eco-system.
My eco-system is ADL, AQL and so on. I am perfectly happy with that. I only need to transform from ADL to XSD and from AQL to XQuery.
And back, of course.

Maybe RelaxNG is better. It looks better. I need to study that. I checked the simple data-type constraints, very complete.
Let's say, I bought a book. I am not in a hurry. My solution works, I am looking for improvement.
But right now, there are other things to do.

To translate archetypes to XML-Schema was hard, but is finished. It can be used.
Using the code and experience, I think translating archetypes to RelaxNG is not that hard.

When RelaxNG serves all the ADL constructs, I might change the validation part from XMLSchema to RelaxNG.

Then you either need to go to work doing it or provide
funding for others to do it.

Don't worry, I don't need you to help me.
I was in discussion, and interested in your arguments.

My intuition tells me that there will be problems. Maybe not
intractable problems. I do not know.

You were questioning the ability of RelaxNG to the specific point of constraints.
I wondered were that questioning was based on. You made clear that it was based on nothing then intuition.

But I personally have no reason
to spend my time and energy exploring that possibility. If you are
passionate about it, then go for it. I look forward to your results.

I wonder why that is.

Because, when I look at MLHIM. You don't want to improve it by looking at other schema's.
I would understand if it were dozens.
But it are only three. XML-schema, RelaxNG and Schematron?

Why not do research for you choose one?
In fact you implicitly say that your choice is made on base of intuition. That is a small base.

XML-Schema forces you to the GUID-thing.
For RelaxNG you have a bad intuition about.
And Schematron?

Suppose XML-Schema drops in its version 1.2 the rule which forces you to use GUID's. Do you drop the GUID constructs for complextypes then?
It would be foolish to remain them, in that case, wouldn't it?

And if you drop the GUID-thing for complextypes in case of this supposed XML-schema 1.2, why not looking already at schema's which don't have this dumb XML-schema rule?
I think that the solution for RelaxNG is very elegant.

You know Tim, I am thinking this quite some time.
When you drop the GUID for complextypes thing, all that remains from MLHIM is a Reference Model.
And that Reference Model, it looks very much like the OpenEHR Reference Model, but it is very much simplified. And you added all the HL7 Exception-types.

Maybe your Reference Model is better, maybe it is worst, I cannot judge that. I am not that clever on Reference Models.
But the fact remains that when all the XML-Schema workarounds are dropped, that an OpenEHR-like Reference Model remains.

And of course, not to forget, your archetype-id (CCD-id) is globally unique without any governance. However, I would not favor your solution.

I think that is the reason why you don't want to look at other schemas is that you need the XML-Schema problems to distinguish MLHIM from OpenEHR.
"Excusez le mot", I suspect to see some revanchism.

I think that is a small base for another multi-level eco-system.

Anyway, I wish you good luck and wisdom
Bert

58

actually, that’s true, but I was thinking more about the semantic content of the model rather than what tools can do the transformation work. And I just realised now I am looking at a RM-only definition, not a clinical model definition, so ignore what I said for now. I need to look more closely at the clinical MLHIMs. It depends on what you are trying to build. We have already described our aims:

59

I adapt with codeine. Due to the pain of thinking about it :wink: - thomas

60

Hi Tim,

Because of your wide exposure to numerous systems and experts, I have two questions for you, both of which you can answer as briefly as you choose:

  1. Did I capture an underlying difference between experts in this discussion we’ve had about Tim’s system? Specifically, does one camp prefer high-level reusable units of meaning with enduring names (with some resilience to changes without changing the name), while others prefer to restrict re-usability to lower-level, more primitive (atomic) units of meaning, units consisting of fewer subparts and which allow for no changes without a name change? Are there basic variances of opinion around this axis and would Tim’s MLHIM be a case in point? I can see how the question could be argued both ways, but maybe I’m assuming a lack of consensus where there actually might be little dispute. And I could be mischaracterizing MLHIM’s position along this axis. I should have taken more time with it.

  2. A second question concerns InterMountain Health and the VA’s MDHT and other systems with which you are familiar. How do these systems persist their data? Do they put everything in standard RDBMS tables or do they put their records in some other container, such as XML or binary blobs, as do some openEHR implementations? A system based on MLHIM, for its part, would use XML (I’m assuming) to store all instance data. Is that practice quite common? Is it the norm? We’ve been arguing about whether XML is a good modelling tool. But how widely is it used for actual instance-level storage?

Thanks,

Randy