mlhim-owners team mailing list archive

[Timothy Cook <timothywayne.cook@xxxxxxxxx>]

As usual, a biggie was left out.  :-(

10.  Remove DataStructure and its subclasses.  The conventional wisdom
is that any "shape" data structure can be built using Clusters,
Elements and Slots.

Thanks,
Tim



On Sun, Sep 18, 2011 at 08:21, Timothy Cook <timothywayne.cook@xxxxxxxxx> wrote:
> 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
>



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