Re: Templates for application form development

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

Re: Templates for application form development

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

Re: Templates for application form development

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

Re: Templates for application form development

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

Re: Templates for application form development

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

Re: Archetype pattern

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),

Re: Archetype pattern

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. > > > >

Templates for application form development

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

Re: Optmizing AQL

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,

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: Optmizing AQL

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: Optmizing AQL

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: Optmizing AQL

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 ___

Re: Optmizing AQL

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 >

Re: Optmizing AQL

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

Re: Optmizing AQL

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

Re: Optmizing AQL

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: Archetype pattern

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

Optmizing AQL

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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