Sorry for moving away from the original subject. It was old annoyance
coming up when thinking about some RM issues.
Maybe when having a strict separation between the common and some other
parts the problems I mentioned partly disappear.
Anyway, it is not yet the moment to discuss such details in
I think SET has a lot of applications, including result sets. Of
course that should interior from LOCATABLE to be archetypable.
I'm not sure on the types associated with the UI. I have a specification
for UITenplates that includes some of that, I can share it :)
I'm interested in moving this idea
I know Thomas, but they have dependencies to other classes in the RM. To
data types, to support. By the way, I have never seen use for translation
details except for the archetype metadata. But maybe i missed it. That is
possible, if so, excuse me for this example.
The terminology service also has
On 17/02/2018 18:06, A Verhees wrote:
If it was to me to design, I would not change the RM. In fact, I think
the RM has already classes which do not belong there in my opinion.
I think of AuthoredResources, TranslationDetails, they belong in the AOM.
these things are generic and are in the
If it was to me to design, I would not change the RM. In fact, I think the
RM has already classes which do not belong there in my opinion.
I think of AuthoredResources, TranslationDetails, they belong in the AOM.
The RM should not be a myriad of classes used left/right in the OpenEhr
system.
We
Thomas, that joke, let me elaborate on that. Sorry for the the lot of
context
I know most EHR systems for GP's in the Netherlands. Lately I checked the
most used EHR system, the latest version. It is designed by GP's
They register according SOEP: Subjective (complaint), Objective
(observations),
It was my own idea, I wrote they will not say that out loud.
(It was a joke)
Bert
Op za 17 feb. 2018 20:18 schreef Thomas Beale :
>
>
> On 16/02/2018 18:30, A Verhees wrote:
> >
> > But I have one remark about your point 4, about SNOMED. Just some
> > thinking.
> >
> > I think I understand the o
On 16/02/2018 18:30, A Verhees wrote:
But I have one remark about your point 4, about SNOMED. Just some
thinking.
I think I understand the original purpose why it is designed. Encoding
every clinical term and arranging them in graphs, and also offer
translations.
But they did not stop t
I've been recently messing around with ADL-designer, and thinking more
about how to do application building with templates. A few things are
becoming clearer to me. Firstly, templates based on COMPOSITION (or
PARTY, PERSON etc, for demographics) are potentially good for data
capture, but don't
Here you can find info about the firs proof of concept of openEHR+SNOMED
for querying, it worked better than expected and the integration was easier
than expected :)
https://cabolabs.com/blog/article/openehr__snomed_ct_a_perfect_combination_for_data_querying-5a440acd0f763.html
On Sat, Feb 17, 201
On 17-02-18 16:33, Pablo Pazos wrote:
I think that is the expected behavior, also what is returned depends
on the operators in the SNOMED expression, like << will return all
descendants. The expression can be tuned to return just what you want,
and the process of the result should work consider
On 17-02-18 16:22, Pablo Pazos wrote:
Just thinking out loud! But I'm working towards this with Diego :)
Ah, I didn't know that. I must read the mailing-lists more often.
Good luck with that. I am very interested to hear about proceedings and
plans
Bert
___
On 17-02-18 16:39, Pablo Pazos wrote:
That is why SNOMED alone can't be used for querying.
I agree with that, else, you would not need OpenEhr at all ;-)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org
IMO what gives context is the OPT that constrains the underlying reference
model, queries are based on archetypes and paths defined in OPTs and SNOMED
expressions are just a way of creating semantically complex criteria for
querying, nothing more.
That is why SNOMED alone can't be used for queryin
Hi Bert,
On Sat, Feb 17, 2018 at 4:57 AM, A Verhees wrote:
> Hi, sorry to interfere, if II understand well,
>
> I think a possible problem could be that respiratory infection caused by a
> virus can return some derived codes to be returned although in this case it
> are not so many.
I think th
That is exactly the idea of "features" that I mentioned on the other post.
But besides defining syntax (AQL and how to express features in AQL-like
form), I mean the declarative format, what is more valuable is to define
each feature functionality. So features can be implemented in AQL and
non-AQL
On 17-02-18 11:21, GF wrote:
That context/epistemology is defined by meta-data in COMPOSITION that
as committed to databases and documents.
That is why OpenEhr and SNOMED can be a strong combination.
___
openEHR-technical mailing list
openEHR-techni
On 17-02-18 15:47, Diego Boscá wrote:
https://bioportal.bioontology.org/
It has tons of knowledge exposed as queriable web services. All
services have an RDF output, so is perfect to demonstrate linked data
Thanks, very interesting
___
openEHR-tec
I agree with all your points BTW :)
2018-02-17 15:09 GMT+01:00 Bert Verhees :
> On 17-02-18 13:11, Diego Boscá wrote:
>
> Maybe it is possible to generalize it in a way that it could be external
> calls that return a value or list of values. Maybe this is enough for
> SNOMED, CDSS, but also for q
https://bioportal.bioontology.org/
It has tons of knowledge exposed as queriable web services. All services
have an RDF output, so is perfect to demonstrate linked data
2018-02-17 15:09 GMT+01:00 Bert Verhees :
> On 17-02-18 13:11, Diego Boscá wrote:
>
> Maybe it is possible to generalize it in
On 17-02-18 13:11, Diego Boscá wrote:
Maybe it is possible to generalize it in a way that it could be
external calls that return a value or list of values. Maybe this is
enough for SNOMED, CDSS, but also for queries to linked data such as
drug-drug interaction and other services availabe in bio
Maybe it is possible to generalize it in a way that it could be external
calls that return a value or list of values. Maybe this is enough for
SNOMED, CDSS, but also for queries to linked data such as drug-drug
interaction and other services availabe in bioportal, etc.
2018-02-17 9:23 GMT+01:00 A
In an ideal world you probably would just ask if the code is in the subset
(both as parameters). From the snomed evaluation cost of both operations
(give me all the codes and is this code in the subset) cost virtually the
same (or less). Also several caching techniques could be used in both
scenari
Hi,
In order to reach full interoperability and interpretability we need a clearcut
separation between constituting models that are part of the Interoperability
standards stack.
It is the function of a Terminology to create a system of concepts that
coherently defines concepts in a domain.
And
I agree that the different kinds of ‘templates’ show up in different parts of
the RM.
But we need to think more.
All are ‘patterns’ of different kinds.
Gerard Freriks
+31 620347088
gf...@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
> On 16 Feb 2018, at 12:41, Thomas Beale wrote
The discussion Pablo has makes me think it could be good to have in an
AQL-engine an entry to have external query languages executed like SNOMED
expressions which can treat result data as hierarchies of data and so add
an extra functionality layer
Bert
_
Hi, sorry to interfere, if II understand well,
I think a possible problem could be that respiratory infection caused by a
virus can return some derived codes to be returned although in this case it
are not so many.
However to use this mechanism generally, it can happen that really many
derived co
27 matches
Mail list logo