Re: SV: More generic reference model

2016-09-12 Thread Michael.Lawley
Thanks Bert, The difference between this one and the old one is that the old one was using our old terminology server through its proprietary APIs. This new one is using generic FHIR APIs and can be pointed at an arbitrary FHIR Server that (correctly) implements the terminology services part

Re: SV: More generic reference model

2016-09-12 Thread Bert Verhees
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Bert Verhees
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

2016-09-12 Thread Shinji KOBAYASHI
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

2016-09-12 Thread Michael.Lawley
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

2016-09-12 Thread Bert Verhees
Even better, Pablo, it uses SCT, and does not stand in the way of other terminologies, it is a parallel process which fits inside the OpenEhr specs. I tried to explain it before, maybe I did not well explain it. Tell me if so. So, you can keep on proceeding as you were already doing, but you can

Re: SV: More generic reference model

2016-09-12 Thread Bert Verhees
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

2016-09-12 Thread Grahame Grieve
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Grahame Grieve
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Grahame Grieve
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

2016-09-12 Thread GF
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

Re: SV: More generic reference model

2016-09-12 Thread Bert Verhees
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

2016-09-12 Thread Bert Verhees
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

2016-09-12 Thread 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? - 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

2016-09-12 Thread Thomas Beale
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

2016-09-12 Thread Diego Boscá
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

2016-09-12 Thread 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 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

2016-09-12 Thread Bert Verhees
Exactly Michael, that is what I was pointing at in my blogs a few days ago, making a golden pair of SCT and OpenEHR by combining the full potential of both. Even go further then FHIR, because FHIR is a message system, while OpenEHR is so much more then that. OpenEHR is the base of an

Re: SV: More generic reference model

2016-09-12 Thread Diego Boscá
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: How can I model multiple checkboxs options with terminology?

2016-09-12 Thread Bert Verhees
Op 12-9-2016 om 8:27 schreef David Moner: Bert, what you propose is probably mixing things from the data structure definition and from the UI, which is not a good idea for future maintenance. If we want to render the different options as checkboxes, as a selection list or whatever other

Re: SV: More generic reference model

2016-09-12 Thread 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 once for launching a transformation (more like 10k...) that depended on a online schema. A hospital can

Re: How can I model multiple checkboxs options with terminology?

2016-09-12 Thread David Moner
I'm with Ian, a coded_text with multiple occurrences. Probably the existing "unique" option in the "items" attribute of the container CLUSTER already solves the problem of repetitions of the same ELEMENT. It will mean that you are defining a logical set of ELEMENTs. What I have never had clear

Re: SV: More generic reference model

2016-09-12 Thread Bert Verhees
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

2016-09-12 Thread 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 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

2016-09-12 Thread Bert Verhees
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,