mlhim-owners team mailing list archive

[Timothy Cook <timothywayne.cook@xxxxxxxxx>]

Good points.  I'll ponder this while I am outside over the next hour.  :-)

On Thu, Sep 22, 2011 at 09:45, Luciana Tricai Cavalini
<lutricav@xxxxxxxxx> wrote:
> Hi Tim,
>
> I am dealing with different types of knowledge modelling using the
> openEHR approach and I want to state that everything you are suggesting
> to delete from the clinical part of the MLHIM 2.x Reference Model is
> unnecessary indeed. Not sure about the demographic model tough. I am not
> an expert.
>
> We need more critical mass in this area of demographic models but that's
> difficult since demograhic models are more consolidated in the expert
> literature. According to Kuhn's approach, that makes new ideas more
> difficult to be accepted.
>
> Since our community is basicly composed by expectators, I want to tell
> you that I support the majority of the changes that you are making; on
> the other hand, we need to figure out a way to develop a least two tiny
> had-coded demos and send data extracts from one to another and publish
> it quickly on an Open Acess journal. Without that, everything we are
> discussing here is a conjecture, and MLHIM deserves to be much more than
> a conjecture.
>
> Sincerely,
>
> Luciana.
>
>
> Em 22/09/2011 11:20, Timothy Cook escreveu:
>> Hi All,
>>
>> I have now created a blueprint at:
>> https://blueprints.launchpad.net/mlhim-specs/+spec/rm-simplify-2011
>>
>> as well as creating bug reports:
>> https://bugs.launchpad.net/mlhim-specs
>>
>> for the items discussed so far in this email.   BUT!!! this doesn't
>> mean the discussion part is over.  I am just hoping that it will make
>> it easier for everyone to make comments directly on the bug reports
>> themselves instead of replying to this huge email.  The Blueprint
>> references this thread in the archives.
>>
>> Cheers,
>> Tim
>>
>>
>>
>> On Mon, Sep 19, 2011 at 15:04, Luciana Tricai Cavalini
>> <lutricav@xxxxxxxxx> wrote:
>>> Hi Tim and mlhim-owners,
>>>
>>> I decided to rebuild the entire thread from the beginning for us not to
>>> loose important part of the discussion that is still pending, but I
>>> don't have anything else to add or suggest. Thank you Tim for your
>>> dedication to this project and you kind attention to our questions.
>>>
>>> ======================================================================
>>>
>>> Em 18/09/2011 21:21, Luciana Tricai Cavalini escreveu:
>>>> Hello Tim and mlhim-owners,
>>>>
>>>> Thank you Tim for sharing your considerations about the MLHIM 2 model.
>>>>
>>>> After working a little bit with real examples of knowledge modeling,
>>>> it was clear to me that some classes bring confusion among knowledge
>>>> modelers. The most prevalent confusion, amazingly IMO, was the fact
>>>> that apparently there is too much semantics into the RM classes, what
>>>> might not be a good idea.
>>>>
>>>> I'll make more comments and ask some questions along Tim's original
>>>> text:
>>>> Em 18/09/2011 10:21, Timothy Cook escreveu:
>>>>> Hi All,
>>>>>
>>>>> >From the beginning MLHIM design has been focused on the good things
>>>>> about the more popular models as well as the Albert Einstein quote;
>>>>> "Make everything as simple as possible; but no simpler."
>>>>>
>>>>> It has certainly been my experience based on talking to many people
>>>>> and reading many blog posts.  That the reason for lack of wide spread
>>>>> implementations of any of these models has been complexity that did
>>>>> not readily show a reason for being so complex.
>>>>>
>>>>> MLHIM shows a marked reduction in complexity as well as use of main
>>>>> stream technologies.
>>>>>
>>>>> The original MLHIM 1.x model, as a proof of concept, is largely
>>>>> openEHR converted to using XML as the constraint and implementation
>>>>> technology.
>>>>>
>>>>> MLHIM 2.x already has a number of changes in order to reduce
>>>>> complexity and to bring it further in alignment with XML.  I think
>>>>> the benefits of using XML is obviously and need to be discussed here.
>>>>>
>>>>> But in consultation with Luciana and her experiences with teaching
>>>>> modelling and analyzing the model.  Especially the quantitative
>>>>> datatypes section.
>>>> I would suggest that we discuss the quantitative datatypes here in
>>>> this thread as well. IMO, at this point in MLHIM 2, there are overlaps
>>>> between the Data Types inherited from openEHR and the XML datatypes.
>>>> The main example is DvCount and DvInteger. The only difference
>>>> between them is that DvInteger doesn't have an element to constraint
>>>> the unit(s) of measurement of what's being counted. Still IMO, this
>>>> is not enough to keep both classes; maybe we should consider
>>>> including an element "units" in DvInteger. Same thing for DvQuantity
>>>> and DvDecimal.
>>>
>>>>   We have come up with a few more points to remove
>>>>> some classes that carry semantics and do not necessarily benefit the
>>>>> art of modelling.  In fact in many cases students find them
>>>>>  confusing. In addition to classes like Observation and Instruction
>>>>> carrying semantics.  There are also a number of classes that carry
>>>>> the semantics of an EMR/EHR.
>>>> The CareEntry child classes are the most classical cases of "excessive
>>>> semantics" inside RM classes that only bring confusion to knowledge
>>>> modellers. Twice this year I gave KM courses and there were many
>>>> moments in which the students wouldn't agree about which class to
>>>> choose and the ambivalence of the classes was genuine. The main
>>>> example is modeling psychometric diagnostic instruments. There is
>>>> ambivalence between Observation and Evaluation classes in many
>>>> Elements of this kind of concept.
>>>> Furthermore, some students have trouble understanding why do we need
>>>> an Instruction class archetype and an Action class archetype in order
>>>> to model something that has the same structure (e.g., medication). My
>>>> orthodox answer: "oh, because one is for drug prescription and the
>>>> other is for drug administration" didn't convince even myself. IMO,
>>>> we are leaving semantics inside the RM that is perfectly solved at
>>>> the CCD or implementation level.
>>>>
>>>>> It is my opinion that these do not benefit the idea of creating
>>>>> Concept Constraint Definitions (CCDs).  Specifically classes like
>>>>> Composition do not make sense in making a CCD (and possible sub-CCDs
>>>>> in Slots) as a unit of committal and transfer.
>>>> Here I would like to hear you more. Why do you think that the
>>>> Composition class carries semantics into it?
>>>>
>>>>> All of these ideas below will need to be put into blueprints and bug
>>>>> reports to make them formal to the project.  However, I wanted to
>>>>> pass these along as a simple email first to get general feedback.
>>>>> At this point some of these are just ideas and do not contain all of
>>>>> the detail required for actual model implementation.  Sometimes
>>>>> things like additional attributes, removing or renaming attributes
>>>>> may also be needed.
>>>>>
>>>>> 1.  Make CareEntry a concrete classes and remove its subclasses.
>>>> Agree (see above)
>>>>
>>>>> 2.  Remove the Section class.
>>>> Definitively Section and Folder are confusing. But could you please
>>>> explain to us what you have in mind if those classes are removed from
>>>> the MLHIM 2 RM?
>>>>
>>>>> 3.  Remove the Composition class.
>>>> Please ellaborate (see above).
>>>>
>>>>> 4.  Remove or modify EventContext
>>>
>>> This is a typical class completely full of context and EHR-oriented (EHR
>>> somewhere, what's more problematic). You can probably model all that
>>> knowledge on an AdminEntry class CCD and/or as any Entity class CCD.
>>>
>>> Exactly.
>>>
>>>>> 5.  Remove or modify Activity.
>>>
>>> I knew I remembered that; I just wasn't sure. This is the class you use
>>> under the CareEntry child class Action. It is like History under
>>> Observation, sort of. Agree to eliminate if Action is being eliminated.
>>>
>>> Similar to.  But it was put into openEHR for the ability to model a
>>> State Machine.  Since that functionality is actually part of an
>>> implementation it doesn't need to be here.
>>>
>>>>> 6.  Remove Folder.
>>>> Same as Section (see above).
>>>>
>>>>> 7.  Remove the Link class as it is superceded by Relationship.
>>>
>>> OK, Relationship replaces Link and it keeps the same attributes? Is it
>>> just a renaming decision? But we already renamed so many classes, why
>>> not this one?
>>>
>>> I don't have the original openEHR definition at hand and Link has
>>> already been changed in MLHIM.  However, Relationship was designed to
>>> allow for the semantics of the relationship to be entered from a
>>> standard ontology.  <red_faced>I see now that the relationship_type
>>> attribute is missing.  </red faced> In this way you could use 'is-a',
>>> 'contains', 'part-of', etc.  Link did not have that ability and I
>>> personally think Relationship is a better word for the function.
>>>
>>>>> 8.  Examine further the PartyProxy class and subclasses.  These are
>>>>> very important but are they the best implementation?
>>>
>>> I can't see any problems with the way they are implemented now.
>>>
>>> The remaining message is similar to the last one, OK?
>>>
>>>>> 9.  Remove the word Feeder from FeederAudit and FeederAuditDetails.
>>>>> Again, very important but need cleaning up and clarifying.
>>>> Why do you think it is important to remove "Feeder" from those
>>>> classes?
>>>
>>> I just think they are unneeded and can be confusing to developers.
>>>
>>>> 10.  Remove DataStructure and its subclasses.  The conventional wisdom
>>>> is that any "shape" data structure can be built using Clusters,
>>>> Elements and Slots.
>>>>
>>>> Agree. When you start teaching people and giving them "hints" such as
>>>> "if you are confused, choose ItemTree" or axioms such as "everything
>>>> might be ItemTree except ItemTable", it is because something is not
>>>> working well.
>>>>
>>>>> AFAIK there is no implementation work going on with MLHIM2.  It is
>>>>> all still MLHIM 1.x  So the impact is minimal if at all.
>>>> Yes. We need to do something. There is a reason why such a good idea
>>>> is not widely implemented and everything that comes to my head is: (1)
>>>> opposite academic and economic interests, (2) excessive complexity
>>>> that makes people give up and go do something else and (3) sustained
>>>> adoption of old-fashioned technologies for knowledge modeling when
>>>> there are updated industry standards for that (e.g. XSDs).
>>>>
>>>>
>>>>   I would really
>>>>> appreciate your replies with questions, comments or criticisms.  One
>>>>> thing that may need to be explained further is how CCD Slots work and
>>>>> what the instance data looks like.  I know that this was a concern
>>>>> Luciana had concerning interoperability.   If anyone needs a more
>>>>> formal explaination please let me know.
>>>> I do! Slot as a class is still an enigma to me.
>>>>
>>>>> Kind Regards,
>>>> Likewise and thank you Tim!
>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>> PS.  Just as an FYI for those that may not be following the other
>>>>> mailing lists.  HL7v3, openEHR and 13606 are all currently pursuing
>>>>> various types of simplifications.  Many of which we have already done
>>>>> in MLHIM.
>>>> I wonder if at least a tiny proportion of that is not due to the
>>>> existence of MLHIM itself. Well, about the discrete release of the
>>>> Template Designer as a freeware software I am almost convinced it was.
>>>
>>> Well, even in my most arrogant hour (and they can be big and often)  I
>>> wouldn't suggest that to be the case.  I doubt they even know we are
>>> here.
>>>
>>> If we were that significant in their eyes then there would be people
>>> from those groups on the mailing lists.
>>>
>>> Cheers,
>>> Tim
>>>
>>>>
>>>> Sincerely,
>>>>
>>>> Luciana.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Esta mensagem foi verificada pelo sistema de antivírus e
>>>  acredita-se estar livre de perigo.
>>>
>>>
>>
>>
>>
>
> --
> Esta mensagem foi verificada pelo sistema de antivírus e
>  acredita-se estar livre de perigo.
>
>



-- 
================
Timothy Cook, MSc
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook