mlhim-owners team mailing list archive

[Timothy Cook <timothywayne.cook@xxxxxxxxx>]

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.  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.

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.

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.
2.  Remove the Section class.
3.  Remove the Composition class.
4.  Remove or modify EventContext
5.  Remove or modify Activity.
6.  Remove Folder.
7.  Remove the Link class as it is superceded by Relationship.
8.  Examine further the PartyProxy class and subclasses.  These are
very important but are they the best implementation?
9.  Remove the word Feeder from FeederAudit and FeederAuditDetails.
Again, very important but need cleaning up and clarifying.

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.  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.

Kind Regards,
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.






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