Re: SV: More generic reference model

I rewrote the part, I think it is easier to understand now. When someone will improve it, I am available to explain when something appears to be unclear. https://openehr.atlassian.net/wiki/display/spec/Terminology+Querying+for+AQL Op 13-9-2016 om 7:21 schreef Thomas Beale: Can everyone

Re: SV: More generic reference model

hr.org> on behalf of Bert Verhees <bert.verh...@rosa.nl> Sent: Tuesday, 13 September 2016 2:49 PM To: For openEHR technical discussions Subject: Re: SV: More generic reference model Hi Michael, I have seen it before a few months ago, a great tool. Very innovative. And easy to work with. I d

Re: SV: More generic reference model

I will give it a new try, I have explained it so much, I know where people stop to follow the explanation. Op 13-9-2016 om 7:21 schreef Thomas Beale: Can everyone who has concrete ideas on ways forward make an effort to update the wiki page

Re: SV: More generic reference model

Michael, Very nice tool, thanks for the link. One small comment - in a few places like where the SCT edition is chosen, something more human-readable than a concept code would be nice. Other than that, it's a very nice tool. Can you give a quick idea on what the main intended eventual use

Re: SV: More generic reference model

Grahame, can you post a URL to that functionality / spec? thanks - thomas On 12/09/2016 16:36, Grahame Grieve wrote: yes. In our terminology, this is paging through an expansion Grahame ___ openEHR-technical mailing list

Re: SV: More generic reference model

Can everyone who has concrete ideas on ways forward make an effort to update the wiki page we created for this, and/or add to the Questions facility for some of the

Re: SV: More generic reference model

Hi Michael, I have seen it before a few months ago, a great tool. Very innovative. And easy to work with. I do not often see such a good work. I will check it out today again, thanks for posting Bert Op 13 sep. 2016 01:00 schreef : > It is definitely possible - here's

Re: SV: More generic reference model

Dear Grahame, I modeled ICF to an archetype for my ice bucket challenge, but forgot to publish on CKM. Do you need this? Shinji Kobayashi 2016-09-12 23:37 GMT+09:00 Grahame Grieve < grah...@healthintersections.com.au>: > FHIR terminology servers can (and mostly do) handle all of those >

Re: SV: More generic reference model

It is definitely possible - here's a pre-release version of our Shrimp browser using only FHIR APIs http://ontoserver.csiro.au/shrimp/ (Hope that Unicode works :-) Michae Sent from my iPhone > On 13 Sep 2016, at 1:23 AM, Thomas Beale wrote: > > Bert, > > these

Re: SV: More generic reference model

impler internal structure). > > > Sent from my LG Mobile > > -- Original message-- > > *From: *Thomas Beale > > *Date: *Mon, Sep 12, 2016 05:33 > > *To: *openehr-technical@lists.openehr.org; > > *Subject:*Re: SV: More generic reference model > >

Re: SV: More generic reference model

Thomas, from my phone, short. The Sct integration as I propose is optional. No changes in openehr specs is needed. No software change is needed. It are only additions except for two minor issues. So if organization's do not want to use Sct, or are not allowed to use it, they still can keep on

Re: SV: More generic reference model

yes. In our terminology, this is paging through an expansion Grahame On Tue, Sep 13, 2016 at 1:34 AM, Thomas Beale wrote: > > In other words something like a DB cursor to traverse large value sets > that reside on the server, in response to client (user) actions on

Re: SV: More generic reference model

In other words something like a DB cursor to traverse large value sets that reside on the server, in response to client (user) actions on the screen? Has that been implemented in FHIR-land? - thomas On 12/09/2016 16:26, Grahame Grieve wrote: The best way to resolve this is to make the

Re: SV: More generic reference model

On 12/09/2016 07:25, Bert Verhees wrote: Op 11-9-2016 om 20:21 schreef Thomas Beale: Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services.

Re: SV: More generic reference model

The best way to resolve this is to make the terminology server part of the local system, and have the resolution a dynamic one between the systems. That allows you to optimise the performance implications of large value sets. Grahame On Tue, Sep 13, 2016 at 1:21 AM, Thomas Beale

Re: SV: More generic reference model

On 12/09/2016 10:27, Bert Verhees wrote: Op 12-9-2016 om 10:32 schreef Thomas Beale: we also still need a standard approach for non-SNOMED CT terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of progress on this issue? There is a detailed answer, I

Re: SV: More generic reference model

Bert, these are just selectors; what I mean is that in the generated result - the actual value set - that IS-A relationships are returned as well as concept codes. Without IS-A relationships a user can't navigate a value set larger than a few terms in a useful way in a real system. - thomas

Re: SV: More generic reference model

FHIR terminology servers can (and mostly do) handle all of those terminologies, though I don't know if anyone has handled ICF in practice. And expansions can preserve is-a relationships if you want, though... life is complicated and the answer is not automatically 'yes' Grahame On Mon, Sep 12,

Re: SV: More generic reference model

Op 12-9-2016 om 10:32 schreef Thomas Beale: we also still need a standard approach for non-SNOMED CT terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of progress on this issue? There is a detailed answer, I googled on SNOMED to ICD10

Re: SV: More generic reference model

Op 12-9-2016 om 10:30 schreef Thomas Beale: does the expansion preserve IS-A relationships (at least optionally)? That's crucial for making any value set of more than about 20 terms usable in a real system. I think you need to do that by additional refinements, f.e. < 19829001 |disorder of

Re: SV: More generic reference model

we also still need a standard approach for non-SNOMED CT terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of progress on this issue? - thomas On 12/09/2016 07:32, Diego Boscá wrote: sure thing, that's why we need standard expressions 2016-09-12 8:27

Re: SV: More generic reference model

On 12/09/2016 07:01, michael.law...@csiro.au wrote: I strongly recommend looking at the way terminology services are handled in FHIR. A ValueSet Resource (ie the subsets you're talking about) has a URI, so that it can be replicated in a local TS and referenced by it's well-known identifier

Re: SV: More generic reference model

My comments were on the discussion 'expressions vs queries to external terminology services in archetypes' 2016-09-12 8:40 GMT+02:00 Bert Verhees : > Op 12-9-2016 om 8:32 schreef Diego Boscá: >> >> sure thing, that's why we need standard expressions > > > Maybe I don't

Re: SV: More generic reference model

Op 12-9-2016 om 8:32 schreef Diego Boscá: sure thing, that's why we need standard expressions Maybe I don't understand your point. But what I make of it, is that you are referring to the ever lasting discussion about a standardset of archetypes, or every medical institution making its own.

Re: SV: More generic reference model

-technical <openehr-technical-boun...@lists.openehr.org> on behalf of Diego Boscá <yamp...@gmail.com> Sent: Monday, 12 September 2016 4:32 AM To: For openEHR technical discussions Subject: Re: SV: More generic reference model I mean, I can see that there can be valid queries to known

Re: SV: More generic reference model

code subsets are important in data validation or query part, I would say not so much in semantic label definition 2016-09-12 8:23 GMT+02:00 Bert Verhees : > Op 11-9-2016 om 20:10 schreef Diego Boscá: >> >> The problem I see with depending on a given terminology service is >>

Re: SV: More generic reference model

Op 11-9-2016 om 20:32 schreef Diego Boscá: In practical terms however, you can't always expect to have all the access that you want to a given external service. e.g. I was banned from W3C once for launching a transformation (more like 10k...) that depended on a online schema. A hospital can

Re: SV: More generic reference model

Op 11-9-2016 om 20:21 schreef Thomas Beale: Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services. This problem hads been tackled by IHTSDO.

Re: SV: More generic reference model

Op 11-9-2016 om 20:10 schreef Diego Boscá: The problem I see with depending on a given terminology service is that the code you are defining may or may not be known by the terminology service. I don't see that happen easily. Validate your archetypes on content also before using them.

Re: SV: More generic reference model

Op 11-9-2016 om 20:01 schreef Thomas Beale: On 11/09/2016 15:48, pablo pazos wrote: Hi Bert, I was thinking about integrating SCT with path-based queries (I'm not in AQL yet), but maintaining the complexity of the SCT relationships and expressions on the terminology service (TS) side,

Re: SV: More generic reference model

Op 11-9-2016 om 16:56 schreef Diego Boscá: I'm not a real fan of having just codes instead of expressions. Expressions are far more readable and may help in the understanding of the archetype. Just a single code representing the subset won't be as clear. Diego, I think you are right, a

Re: SV: More generic reference model

in a general way, but with each conversation we get closer to a solution, this is a great exercise. Sent from my LG Mobile -- Original message-- From: Diego Boscá Date: Sun, Sep 11, 2016 15:33 To: For openEHR technical discussions; Subject:Re: SV: More generic reference model I mean, I can

Re: SV: More generic reference model

I mean, I can see that there can be valid queries to known terminology services, I'm not against that. In practical terms however, you can't always expect to have all the access that you want to a given external service. e.g. I was banned from W3C once for launching a transformation (more like

Re: SV: More generic reference model

Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services. On 11/09/2016 19:10, Diego Boscá wrote: The problem I see with depending on a given

Re: SV: More generic reference model

in SCT, I prefer someone else that knows SCT defines > the expressions and relationships in the terminology server so I can create > queries just using codes. > > > Sent from my LG Mobile > > -- Original message-- > > From: Diego Boscá > > Date: Sun, Sep 11, 2016 11:57 >

Re: SV: More generic reference model

On 11/09/2016 15:48, pablo pazos wrote: Hi Bert, I was thinking about integrating SCT with path-based queries (I'm not in AQL yet), but maintaining the complexity of the SCT relationships and expressions on the terminology service (TS) side, so on queries there are just simple codes

Re: SV: More generic reference model

scá *Date: *Sun, Sep 11, 2016 11:57 *To: *For openEHR technical discussions; *Subject:*Re: SV: More generic reference model I'm not a real fan of having just codes instead of expressions.. Expressions are far more readable and may help in the understanding of the archetype. Just a single code re

Re: SV: More generic reference model

is that query creators need to be >>> experts in SCT. >>> >>> >>> What do you think? >>> >>> >>> Sent from my LG Mobile >>> >>> -- Original message-- >>> >>> *From: *Bert Verhees >>> >>

Re: SV: More generic reference model

un, Sep 11, 2016 11:57 To: For openEHR technical discussions; Subject:Re: SV: More generic reference model I'm not a real fan of having just codes instead of expressions.. Expressions are far more readable and may help in the understanding of the archetype. Just a single code representing the su

Re: SV: More generic reference model

be >> experts in SCT. >> >> >> What do you think? >> >> >> Sent from my LG Mobile >> >> -- Original message-- >> >> *From: *Bert Verhees >> >> *Date: *Sat, Sep 10, 2016 13:14 >> >> *To: *For ope

Re: SV: More generic reference model

> experts in SCT. > > > What do you think? > > > Sent from my LG Mobile > > -- Original message-- > > *From: *Bert Verhees > > *Date: *Sat, Sep 10, 2016 13:14 > > *To: *For openEHR technical discussions; > > *Subject:*Re: SV: Mor

Re: SV: More generic reference model

-- Original message-- From: Bert Verhees Date: Sat, Sep 10, 2016 13:14 To: For openEHR technical discussions; Subject:Re: SV: More generic reference model Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it now, there is no change necessary in the reference model

Re: SV: More generic reference model

t; Kind regards, > Eng. Pablo Pazos Guti??rrez > http://cabolabs.com <http://cabolabs.com/es/home> > <http://twitter.com/ppazos> > -- > *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org> > on behalf of Mikael Nyström <mika

SV: SV: More generic reference model

-technical [mailto:openehr-technical-boun...@lists.openehr.org] För Bert Verhees Skickat: den 9 september 2016 08:42 Till: openehr-technical@lists.openehr.org Ämne: Re: SV: More generic reference model Op 9-9-2016 om 8:37 schreef Bjørn Næss: But in addition to that we need to map terms from diffe

Re: SV: More generic reference model

Op 9-9-2016 om 8:37 schreef Bjørn Næss: But in addition to that we need to map terms from different other terminologies like SNOMED-CT, LOINC and also Disease Ontologies. There is a mapping effort by IHTSDO en Regenstrief, they started that a few years ago, and it will be finished, next

SV: More generic reference model

This is perfect timing with ongoing activities in Norway. There is a government lead activity to explore how to use SNOMED-CT and openEHR archetypes together. The first domain is to use SNOMED-CT to define anatomical location and structures. The most important outcome for this is to be able to

Re: SV: More generic reference model

I realise that what I said made it sound like IHTSDO experts still think that terminology solves everything, but I didn't mean to do that, I actually meant to imply that there are people in user orgs who still think like this (I often run into them). Mikael's characterisation of IHTSDO

SV: More generic reference model

Hi, My more recent impressions from inside the SNOMED CT community are not entirely in line with Tom's impression below. The people that believe that SNOMED CT is on its own are nowadays quite few. My impression is that most people understand that SNOMED CT needs to be implemented using