The use of CKM
bert.verhees at rosa.nl
Sat Jan 28 05:48:35 EST 2017
It is true, while I am thinking about this myself, I was indeed looking
for a Gang of Four like pattern rules which makes the archetype
development predictable, and also advises for efficiency and
consistency, and indeed, also machine processable.
This is important, tell people to use a cluster-slot for a dataset,
always do. If it does not exist, write it. And never use wild/wild (very
wild) cards in those slots. Wild/wildcards should only be permitted in
root container entry-archetypes, not in pointers to specific datasets.
There is a risk of rewriting archetypes, while there are similar
archetypes, because they cannot find for what archetypes are already
used for, or risk for including structures in a new archetype
But when you demand this kind of things, you also have the obligation to
offer help, and that is possible. Because it is not anymore allowed to
use wild/wild cards, you can machine generate a mindmap of all the
existing archetypes. Not the overview mindmap which is already on CKM,
that is just a translation of the tree on the left, but a dependency
So for example (having the risk that it is a wrong example)
Medication-action can be replaced with:
*> Cluster Medication Action
->> Medication course, etc.
*> is a wild/wild card
-> is a more specific wild card
->> leaf node archetypes, only containing lists of leaf nodes, maybe
only one level of structure
So, concluding, we need rules (pattern) and (machine generated)
guidance, and a redesign of the existing archetypes following the rules
These are my two cents
Op 28-1-2017 om 9:47 schreef Thomas Beale:
> there is no text book for that yet, although programming principles
> are generally applied these days. But just as in programming, one can
> build a class that doesn't use a separate class for its inner
> structure, if that structure is not re-usable. There is undoubtedly
> some sub-optimal modelling in the CKM archetypes, but I suspect what
> you are looking for is some machine-processable general rule that you
> can use in software to e.g. always know that when you hit a CLUSTER,
> it will be a new archetype? I don't think this kind of thing can ever
> be guaranteed.
> What I foresee creating is a handbook of 'patterns' in the same sense
> as the Gang-of-for software patterns. It might be possible one day to
> machine discover which pattern a given archetype conforms to and to do
> something with that knowledge at runtime, but we are not there yet.
> - thomas
> On 27/01/2017 23:51, Bert Verhees wrote:
>> Hi Thomas, Now I read it back I see that my previous reply was not
>> my.most understandable English.
>> I try again. Is there somewhere described that archetypes should be
>> structured in cluster archetypes which fill slots in container entry
>> I see that it is done a lot in CKM, but I also see (must be)
>> leftovers in which the entry - archetypes contain the structures
>> itself, and in this way disturb the building block idea.
>> Like in programming languages are described paradigms, it would be
>> good to have that for archetypes. An advantage of formal structure
>> descriptions would be that discussion would become possible. Another
>> advantage would be that newcomers would have some directions.
>> So, that is why i hsve this question: are there some paradigms
>> described which shape new archetypes for CKM?
>> Op vr 27 jan. 2017 17:03 schreef Bert Verhees <bert.verhees at rosa.nl
>> <mailto:bert.verhees at rosa.nl>>:
>> Op 27-1-2017 om 16:26 schreef Thomas Beale:
>> > Hi Bert,
>> > I think your statements describe things as they are today - or
>> > you meant something different?
>> Thanks for replying
>> That is nice, I must have found a leftover from the past and I
>> did not
>> find this strategy somewhere formalized.
>> Is there description a formal strategy of desirable structures?
>> Best regards,
>> > - thomas
>> > On 24/01/2017 11:33, Bert Verhees wrote:
>> >> Hi
>> >> I have a remark about the use of some archetypes in CKM.
>> >> I think that it would be nice to have archetypes of some specific
>> >> content, for example, medication, always of type cluster, and have
>> >> container archetypes, for example in this case, of type action to
>> >> hang them in a composition.
>> >> If this was a policy, then the idea of building blocks would
>> be much
>> >> more usable.
>> > _______________________________________________
>> > openEHR-clinical mailing list
>> > openEHR-clinical at lists.openehr.org
>> <mailto:openEHR-clinical at lists.openehr.org>
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
> *Thomas Beale*
> Management Board, Specifications Program Lead, openEHR Foundation
> Chartered IT Professional Fellow, BCS, British Computer Society
> Health IT blog <http://wolandscat.net/> | Culture blog
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical