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 application
generator.
Op 12-9-2016 om 8:01 schreef michael.law...@csiro.au:
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
rather than just a URL. It has a definition (which may be an explicit list of
codes, or based on filters (ie rules) - for SNOMED CT you can use the
Expression Constraint Language), and it also has an expansion - the enumeration
of the codes that satisfy the definition with respect to a particular version
of the underlying code system.
There are operations like $subsumes to test the relationship between two codes,
and $closure to incrementally build up a subsumption graph in the client for
subsets of codes (those actually in the patient records) to support efficient
query. For SNOMED CT, a 'code' may be a single SCTID or a post coordinated
expression.
michael
--
Dr Michael Lawley
Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260
________________________________________
From: openEHR-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 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...) that depended on a online schema. I
can imagine that could even be worse for terminology services
(downtimes and maintenance aside).
That's why I said standard (explicit?) expression definitions should
be preferred when available
2016-09-11 20:21 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:
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 terminology service is
that the code you are defining may or may not be known by the
terminology service. This could be ok for templates, but not for
archetypes. In my opinion generic archetypes should be based on known
syntaxes rather than in specific queries to terminology services
whenever is possible
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
