I am fairly new to the modelling side of OpenEHR and am trying to use the Archetype Designer to avoid creating my archetype/template by hand, though if the tool is the constraint I am happy to modify by hand or using SDKs as needed.
Essentially I want to know the correct way to go about having a DV_CODED_TEXT constrained to some SNOMED CT ECL query - as an example ‘^999003051000000109’
I have tried constraining to external coded, binding to SNOMED-CT and putting in ‘ecl/^999003051000000109’ but a) am not sure if that is correct to include ‘ecl’/’ and b) this all disappears in the OPT of the template created from the archetype
I have asked similar questione earlier in the openEHR SEC years ago “how do we represent post-coordinated SNOMED CT ecpressionr in opneEHR?” - but then did not follow up. I do think there will be cases when we actually do want to use ECL in archetypes (but likley more often in Templates or forms).
Storing postccordinated SNOMED CT “scentences”/expressions is one use. Value set expansions is another one.
We should also think about standardizing a way to at a coarse level of an archetype/template be able to, in data instances (COMPOSITIONs etc), “build” post-cordinated SNOMED CT expressions from the selections picked (e.g. at runtime) in more granular parts of the archetype/template. Perhaps ECL with variable/path-expressions could work for this?
You can use snomed-ct uris if you want, it’s basically the ecl encoded for being sent as an uri
For example:
404684003 |Clinical finding|: 47429007 |Associated with| = 79654002**|Edema|** ends up as URI http://snomed.info/scg/404684003%3A47429007%3D79654002
No, you need the terminology://fhir.hl7.org to let the CDR know that you are trying to talk to a FHIR terminology service and not some other proprietary service. In practice, the `terminology://fhir.hl7.org’ will be substituted at runtime by the physical endpoint that is hooked up to the CDR e,g
The problem with SNOMED is that there is no standard API - each terminlogy service has its own variation. What FHIR introduced was a vendor-neutral interface - even SNOMED itself recommends using FHIR.
You absolutely could talk directly to a SNOMED service (not sure if that is the exact syntax, perhaps @yampeku could advise?.)
However you then have the problem of hooking your CDR up directly to that SNOMED API service, which may or may not be supported or standardised
Strategically, I would always advise going via FHIR to maximise vendor-neutrality, and TBH you are almost certainly going to need support for terminologies other than SNOMED.
I like Henry’s thinking - why force a FHIR terminology server into the SNOMED-CT term bindings? What if something like Hermes is used instead of FHIR server.
The description of ARCHETYPE_TERMINOLOGY.term_bindings defines Uri as:
The indexed Uri objects represent references to externally defined resources, either terms, ontology concepts, or terminology subsets / ref-sets.
The description doesn’t mention that Uri can hold implementation details and FHIR server is not one of the 4 allowed external resources. I would expect that Uri should start with http://snomed.info/sct (some tools validate that Uri must be a valid SNOMED uri for SNOMED_CT terminology ids).
I expect that at some point in the past, a requirement arose to use post-coordinated SNOMED-CT expressions, and the quick&dirty fix was to use the FHIR terminology server URI.
It works but it smells like a hack. openEHR CDR could implement support for SNOMED-CT post-coordinated expressions or allow configuration settings for external services (where a FHIR terminology server can be configured for SNOMED_CT terminology id).
A problem with quick&dirty fixes is that “quick” is forgotten and only “dirty” remains.
I agree with @henrydwright that http://snomed.info/sct?fhir_vs=ecl/^999003051000000109 should be used as term binding Uri and the CDR should use it as part of the full url for the configured server. For example http://localhost:8080/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl%2F%5E999003051000000109&count=20&includeDesignations=true&filter=append.
if I remember correctly, it has become quite a standard practice in Germany to express these things like ECL within a FHIR ValueSet. In General, it’s quite uncommon to directly reference a terminology without a valueSet constraint. So I can second what @ian.mcnicoll is saying. I don’t think its dirty, its how standardization works and FHIR Terminology Service is the only thing that I know that actually finds some adoption in reality in this area.
What payload format do you expect the server to provide as a result of the request? And why should we be interested in supporting many flavors of the same kind of requests?
Let’s stick to the original question about “having a DV_CODED_TEXT constrained to some SNOMED CT ECL query” in archetypes/templates.
I pointed out that I suspect the current use of terminology://fhir.hl7.org results from mixing implementation with defining constraints in ADL. I believe the question about payloads is even more implementation-specific.
I prefer to first get answers to the simple questions in my previous post.
I agree that it would be great to have a clean short/compact way of representing SNOMED-CT expressions in openEHR since Snomed has actually done the job of inventing the nice language ECL. Preferably the URI form for that should come from Snomed International themselves rather than openEHR or FHIR inventing something.
