Re: Postcoordinated terminology expressions in openEHR

I'm with Ian on this. The only use of post coordination is hard and requires complex tooling support that is way beyond any value you get. I would say even laterality & other qualifiers should go in the information model and not in the terminology if you have the choice. If you are instead

Re: SMART on FHIR integration

Broadly, the context is the current patient being looked at in the EMR, or other platform being used to launch the SMART App. This allows the app to request authorisation for data specific to the 'current patient' and then launch directly into the task. Michael Sent from my iPhone On 24 Apr

Re: SMART on FHIR integration

The real value of SMART (whether its "on FHIR" or not) is that it sets a mechanism for EMRs to pass context to external apps. This means apps are re-usable across different back ends. Note that this is not really about authentication (SSO) but rather it is about authorisation. michael

Re: SV: [Troll] Terminology bindings ... again

Hi Heather, In general, anyone is welcome to participate in the work; you don't need to be one of the small number of Advisory Group members. That helps with travel costs, but most of the real work is done on teleconferences, not so much at the face to face meetings. I would be very

Re: Terminology bindings ... again

Yes, it wasn’t part of STU3 (aka 3.0.1) but is now in the R4 spec - see http://build.fhir.org/snomedct.html#implicit Michael Sent from my iPhone On 12 Mar 2018, at 8:39 pm, Diego Boscá > wrote:https://www.hl7.org/fhir/snomedct.html#implicit

Re: Terminology bindings ... again

FHIR also supports the expression language in the URL with, for example, http://snomed.info/sct?fhir_vs=ecl/<<123464:474748=<<84848484 But note that these URIs (the above and your isa/ one below) are defined by HL7 FHIR, not SNOMED International. Technically

Re: SNOMEDCT - correct representation

Hi Koray, The implicit FHIR ValueSets for SNOMED do not need to be explicitly defined and cover the finite set (with respect to a specific release) of ValueSets that correspond one-to-one with SNOMED reference sets. They also cover the unbounded set of ValueSets that can be defined as

Re: SNOMEDCT - correct representation

I think this thread has gone a little off the rails. There are predefined (by FHIR) URIs for value sets that are defined just as descendants of a single concept, or members of a reference set. For an enumeration of concepts and/or a snomed ECL expression, then you can use a Fhir ValueSet and

Re: SNOMEDCT - correct representation

Hi Koray, as I started to read your message I was thinking "why not re-use the terminology infrastructure already defined by FHIR", and then you proposed exactly that! Big +1 There's a lot one can argue about with other parts of FHIR, but the terminology services part is self-contained and

Re: SNOMEDCT - correct representation

There is a spec that tells you how to identify different editions and versions of SNOMED CT - see http://snomed.org/uri In short, http://snomed.info/sct is the identifier for any version of SNOMED CT. for the Norway extension you need to know which module it is in (this is what will be used

Re: openEHR and terminology servers

I would argue the FHIR provides such an API. It also includes the SNOMED Expression Constraint Language (ECL) as part of the spec. This is why we chose it as the basis I for our terminology server, Ontoserver, which is now the basis for Australia's National Clinical Terminology Service

Re: SV: More generic reference model

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

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: SNOMED CT constraint syntax - for querying instances or terminology?

This is indeed the intent: the language has been design to cater exactly for this extension. I can't say that there's any international content about to come out with this addition numeric modelling, but Australia has been publishing this kind of content in the Australian Medicines Terminology

Re: SNOMED CT constraint syntax - for querying instances or terminology?

Imagine instead the example was using the corresponding AMT concepts (since snomed pure doesn't have any concrete domain modelling -- I.e. numeric values). Then the focus concept would be the AMT amoxycillin Medicinal Product concept 2141501136100 and the constraint matches would be MPUUs

Re: SNOMED CT constraint syntax - for querying instances or terminology?

Hi Thomas, These constraints are essentially queries over the snomed definitional content (ie the Relationships), not queries over external data (ie not EHRs). The intent is to identify sets of snomed concepts that satisfy the constraint criteria. These sets could be subsequently used to join