Because archetypes and templates allow to use one or more instantiations
depending on constraints, querying needs to be done on instantiations informed
by the Template.
Gerard Freriks
+31 620347088
gf...@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
> On 19 Sep 2018, at 03:13,
Solution is easy, just created specific structures for the results of some
test that I needed to store and query so I have different node ids on each
analyte. That will allow me to query, create some CDS rules and some fancy
indicators for reports :)
On Sun, Sep 16, 2018 at 7:36 AM Karsten
> openEHR data representation and querying are founded upon this
> fundamental principle - store how you like, query how you like.
OK, as long as "store how you like" does not impede
"query how you like", the principle seems reasonable.
Karsten
___
On 16/09/2018 10:15, Karsten Hilbert wrote:
Panels are like folders. Whether to define inhabitants
thereof by LOINC, by arbitrary instance links, or by other
means, is an implementation detail.
that is more or less the design concept of the current lab archetypes; I
would just say that
On 15/09/2018 22:45, Pablo Pazos wrote:
Thanks Thomas, that in fact seems to generate different nodeIDs for
each analyte, thus avoids the querying issue.
right. The key is that it is done in specialisations - so the querying
in the generic form based on the generic archetypes will still
Thanks Thomas, that in fact seems to generate different nodeIDs for each
analyte, thus avoids the querying issue.
BTW, to be generic is not a requirement on my side, just wanted to reuse
what is published on the CKM, I can create specific archetypes per panel or
analyte, but that approach seems
Pablo,
I have also seen a need for queries that distinguish analyte level
objects, within the new lab archetypes. The original reason was to be
able to distribute pre-built panel templates (or even archetypes) to EMR
(=PEP) locations in Brasil, but your need is generic.
This wiki page
7 matches
Mail list logo
