Re: SV: More generic reference model

http://hl7.org/fhir/2016Sep/valueset-operations.html#expand, see params offset and count Grahame On Tue, Sep 13, 2016 at 3:27 PM, Thomas Beale wrote: > Grahame, > > can you post a URL to that functionality / spec? > > thanks > > - thomas > > > On 12/09/2016 16:36, Grahame Grieve wrote: > >> ye

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 who

Re: SV: More generic reference model

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 do not often see such a good work. I will check it out today again, thanks for post

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 is?

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 openEHR-technical@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 use

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 a pre-release version of o

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

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 are just selectors; what I m

Re: SV: More generic reference model

> 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 > > we also still need a standard appr

Re: SV: More generic reference model

-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>; Subject: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?- thoma

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 usin

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 the > screen? Has that been

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 termin

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 wrote: > Bert,

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 goog

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: More generic reference model

Thomar, I know of the SOLOR project where SNOMED is harmonised with LOINC and RxNorm http://wiki.hl7.org/index.php?title=CIMI_Quality_Modeling_Collaboration http://www.healthcare-informatics.com/blogs/david-raths/interoperability/can-solor-snomed-loinc-rxnorm-project-create-terminology http://www

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 https://www.nlm.nih.g

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 lu

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 GM

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 understand your point. But w

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

Re: SV: More generic reference model

__ From: openEHR-technical on behalf of Diego Boscá 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 terminology services, I'm not against that. In pra

Re: SV: More generic reference model

sure thing, that's why we need standard expressions 2016-09-12 8:27 GMT+02:00 Bert Verhees : > 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 onc

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 >> that the code you are

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 run

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

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

Re: SV: More generic reference model

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 subset won't be as clear. El 11/9/2

Re: SV: More generic reference model

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 terminology services, I'm not against that. In practical terms however, you can't always expect to have all the a

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 go

Re: SV: More generic reference model

ct:*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 to integrate the potential of SCT largely. Even you can keep on using the semantic rich entry types like Observation, etc

Re: SV: More generic reference model

Date: Sun, Sep 11, 2016 15:33 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 terminologyservices, I'm not against that. In practical terms however, you can'talways expect to have all the acces

Re: SV: More generic reference model

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

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 ter

Re: SV: More generic reference model

omeone 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 (spec

Re: SV: More generic reference model

essage-- *From: *Diego Boscá *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 t

Re: SV: More generic reference model

gt;> >>> >>> What I'm saying is that I prefer to delegate the complexity of SCT to >>> the TS and create simpler queries in AQL or path-based queries, but your >>> idea is interesting. One problem though is that query creators need to be >>> experts in SC

Re: SV: More generic reference model

te: 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 represent

Re: SV: More generic reference model

gt;> >> 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; >> >> *

Re: SV: More generic reference model

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: More generic reference mod

Re: SV: More generic reference model

LG Mobile -- 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 referenc

Re: SV: More generic reference model

??rrez > http://cabolabs.com <http://cabolabs.com/es/home> > <http://twitter.com/ppazos> > -- > *From:* openEHR-technical > on behalf of Mikael Nyström > *Sent:* Friday, September 9, 2016 4:15:53 AM > *To:* For openEHR technical d

Re: SV: More generic reference model

http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos> From: openEHR-technical on behalf of Mikael Nyström Sent: Friday, September 9, 2016 4:15:53 AM To: For openEHR technical discussions Subject: SV: SV: More generic reference mode

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

SV: More generic reference model

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På vegne av Thomas Beale Sendt: tirsdag 6. september 2016 23.04 Til: openehr-technical@lists.openehr.org Emne: Re: More generic reference model I will actually have some time to start to look at this in the next few

Re: More generic reference model

Very good, Thomas, I appreciate your help. I have some good starting thoughts and will write them tomorrow in the wiki. Bert Op 6 sep. 2016 23:04 schreef "Thomas Beale" : I will actually have some time to start to look at this in the next few weeks - i.e. to facilitate / coordinate some work, a

Re: More generic reference model

I will actually have some time to start to look at this in the next few weeks - i.e. to facilitate / coordinate some work, and possibly do some. I would propose to proceed as follows: * gather current unmet requirements * examine current state of AQL spec to clarify what it alredy says,

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 thinking

Re: More generic reference model

Op 6-9-2016 om 21:05 schreef Bert Verhees: we should sit down and wait until something will happen. we should *NOT* sit down and wait until something will happen. (sorry) ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http:/

Re: More generic reference model

Op 6-9-2016 om 19:01 schreef Erik Sundvall: Many of us think that a better integration of the openEHR and the Snomed CT modelling efforts would be great. But there are not enough resources (e.g. dedicated time of people with the right knowledge) being put into doing this, since this is hard (bu

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 po

Re: More generic reference model

this is an eminently sensible suggestion for how to implement certain aspects of terminology processing in an openEHR system. - thomas On 02/09/2016 06:28, Daniel Karlsson wrote: Bert, if I understand your issue correctly, I believe that some sort of "code index" is needed in openEHR persist

Re: More generic reference model

On 03/09/2016 10:34, Bert Verhees wrote: On 03-09-16 18:17, Thomas Beale wrote: WHERE c/name/value='Current Problems' AND diagnosis/data/items[at0002.1]/value/defining_code *matches* { http://snomed.info/id/4257030190487|cancer Dx refset|} That is a very OpenEHRish way to do it,

Re: More generic reference model

Bert, doing most of what you want should come in AQL, e.g. the following in a WHERE clause is already possible. SELECT e/ehr_status/subject/external_ref/id/value, diagnosis/data/items[at0002.1]/value FROM EHR e CONTAINS Composition c[openEHR-EHR-COMPOSITION.problem_list.v1]

Re: More generic reference model

Thomas, I agree. In the Semantic Stack various layers are orthogonal and intersect. The intersection between SNOMED Reference Terminologies and structures (archetypes) is exactly at the righthand side of the ‘is’ relation. Codes from SNOMED are ‘universals’, meaning definitions, like entries in

Re: More generic reference model

On 02/09/2016 04:04, Bert Verhees wrote: On 02-09-16 11:18, Daniel Karlsson wrote: Terminologies typically do not specify which pieces of information are needed in a given situation. Hi Daniel, I don't have at the moment opportunity to reply to all you write, so excuse me for cherrypicking

Re: More generic reference model

I would be interested to see a) developer code for a 100 event time series of BP with no dedicated structures, just hierarchy + SNOMED and b) a query to find systolic BPs over 165 that persist for more than 10 mins in that same series. They're both doable, but they will be harder. - thomas

Re: More generic reference model

rt Verhees wrote: Hi, I am just wondering if there are some opinions about this. Do we still need the not so generic reference model which OpenEhr has, with archetypes denoting Observation, Evaluation etc? Wouldn't a more generic reference model, like ISO13606 be sufficient, when

Re: More generic reference model

On 02-09-16 14:28, Daniel Karlsson wrote: Bert, if I understand your issue correctly, I believe that some sort of "code index" is needed in openEHR persistence implementations. This "code index" would link all codes used with the (full) path to the node where the code is used. There are sever

Re: More generic reference model

Bert, if I understand your issue correctly, I believe that some sort of "code index" is needed in openEHR persistence implementations. This "code index" would link all codes used with the (full) path to the node where the code is used. There are several considerations to be made when implemen