The use of CKM

Bert Verhees 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 
mindmap.

So for example (having the risk that it is a wrong example)
Medication-action can be replaced with:

Action
     *> Cluster Medication Action
         -> Medication
             ->> Product
             ->> 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 
and guidance.

These are my two cents

Bert





Op 28-1-2017 om 9:47 schreef Thomas Beale:
>
> Bert,
>
> 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 
>> archetypes?
>>
>> 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?
>>
>> Thanks
>> Bert
>>
>>
>> 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
>>     maybe
>>     > 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,
>>     Bert
>>
>>     >
>>     > - 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>
>>     >
>>     http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>>     >
>>
>>
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
> -- 
>
> 	*Thomas Beale*
> Management Board, Specifications Program Lead, openEHR Foundation 
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society 
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog 
> <http://wolandsothercat.net/>
>
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170128/f63eb059/attachment-0002.html>


More information about the openEHR-clinical mailing list