Stream: terminology
Topic: v2 support
Grahame Grieve (Feb 25 2019 at 06:16):
Terminology Service Maintainers (@Carol Macumber @Michael Lawley @Peter Jordan @Rob Hausam @Robert McClure @Ted Klein @Reuben Daniels @Alexander Henket), I have a question for you about v2 terminology validation (sorry if I missed tagging anyone important)
Grahame Grieve (Feb 25 2019 at 06:17):
if you want to use the FHIR terminology service while validating a v2 message, the basic idea is that same as if you're validating a FHIR resource, using $validate-code. There's a significant difference, though
Grahame Grieve (Feb 25 2019 at 06:18):
in v2, instead of using the FHIR specified URI for a ode system, which is what is used across the FHIR interface, implementations use a code out of table 0396
Jim Steel (Feb 25 2019 at 06:19):
So those codes need to be mapped to ValueSet URIs?
Grahame Grieve (Feb 25 2019 at 06:20):
yes. on the FHIR side, we are able to represent mappings between table 0396 codes and FHIR code system URLs using the NamingSystem resource (so code systems, not value sets)
Jim Steel (Feb 25 2019 at 06:20):
Or searched using identifiers perhaps (i.e. the ValueSet includes a 0396 code as an identifier code, with some appropriate system)
Grahame Grieve (Feb 25 2019 at 06:21):
my feeling is that storing and managing the mappings should be on the terminology server side, to make life as simple as possible for the consumer
Grahame Grieve (Feb 25 2019 at 06:22):
this means that we need to decide how to make a validate code request using a table 0396 code instead of a system uri
Jim Steel (Feb 25 2019 at 06:22):
Or its a 2-step call
Grahame Grieve (Feb 25 2019 at 06:22):
the same argument applies directly to CDA, where it's OIDs instead of code systems URIs
Grahame Grieve (Feb 25 2019 at 06:23):
so it could be a 2 step. there is already an operation for the id wrangling:
Jim Steel (Feb 25 2019 at 06:23):
I wonder if this is a case for chaining, e.g. "chaining" a search result into $validate-code
Grahame Grieve (Feb 25 2019 at 06:23):
http://hl7.org/fhir/namingsystem-operation-preferred-id.html
Grahame Grieve (Feb 25 2019 at 06:25):
so you could require the client to use this $preferred-id operation first, and then make the terminology call
Grahame Grieve (Feb 25 2019 at 06:26):
or we could say that you can send a oid= or code0396= param instead, which then the server does an internal $preferred-id equvialent function
Grahame Grieve (Feb 25 2019 at 06:26):
(or implicit chaining)
Grahame Grieve (Feb 25 2019 at 06:27):
as far as chaining goes.... we've found that difficult because you have to do parameter name mapping and parameter form wrangling. There's no general case that's not too difficult to implement
Grahame Grieve (Feb 25 2019 at 06:28):
so - I'm looking for a straw vote: do you want some alternative parameters for the system url for oids and table 396 values
- thumbs up: yes, I think we should do something like that
- thumbs down: no, make it the clients problem
(either answer will lead to follow up questions...)
Jim Steel (Feb 25 2019 at 06:31):
I feel like you put http://terminology.hl7.org/CodeSystem/v2-0396|DCM as an identifier (or the identifier) of the ValueSet for that element, then to use it you search for a ValueSet with that id, and use that for $validate-code
Jim Steel (Feb 25 2019 at 06:32):
Then down the track, maybe servers could support /fhir/ValueSet?identifier=http://terminology.hl7.org/CodeSystem/v2-0396|DCM/$validate-code?code=1234
Grahame Grieve (Feb 25 2019 at 06:33):
it's not value sets. It's code systems
Grahame Grieve (Feb 25 2019 at 06:33):
and $preferred-id is simpler for the client than asking the code systems to be correct
Jim Steel (Feb 25 2019 at 06:34):
ok
Grahame Grieve (Feb 25 2019 at 06:35):
though a server could inform it's answer to $preferred-id from identifiers in code system resources
Michael Lawley (Feb 25 2019 at 06:43):
Why is it code systems & not an 0396-named value set?
Grahame Grieve (Feb 25 2019 at 06:45):
table 0396 as used in CNE / CWE identifies the code system, not the value set (v2 also uses OIDs for value sets, like CDA), and we could have the discussion about how the value sets are identified. But I wanted to start with code systems first (build from the foundation, rather than in fantasy land)
Jim Steel (Feb 25 2019 at 06:51):
Why NamingSystem/$preferred-id= rather than CodeSystem?identifier= ?
Michael Lawley (Feb 25 2019 at 06:51):
oh, of course you need the code system when you reference the code in the validate-code call
Alexander Henket (Feb 25 2019 at 06:53):
I think that for v2 and v3 both the calls should be as native as possible. Preferably no concepts introduced in a different HL7 family should be introduced. FHIR is all about implementers, these services should be too. So being able to work with what the instance provides directly seems key
Jim Steel (Feb 25 2019 at 07:02):
If we're adding a parameter to CodeSystem/$validate-code, could it just be an identifier parameter that matches the identifier of a CodeSystem resource ?
Jim Steel (Feb 25 2019 at 07:03):
so /fhir/CodeSystem/$validate-code?identifier=http://terminology.hl7.org/CodeSystem/v2-0396|DCM&code=1234 ?
Grahame Grieve (Feb 25 2019 at 07:15):
Yes that could be. What exactly the parameter would be was going to be my first follow up to a thumbs-up vote above
Jim Steel (Feb 25 2019 at 07:16):
I feel like identifier is less usecase-specific than something specific to 396 or oids
Peter Jordan (Feb 25 2019 at 09:06):
It would be interesting to hear the view of someone from UTG on what the parameter might be - @Ted Klein , @Robert McClure
Yunwei Wang (Feb 25 2019 at 14:48):
the same argument applies directly to CDA, where it's OIDs instead of code systems URIs
OID value can be treated as url parameter, like
?url=urn:oid:2.16.840.1.113762.1.4.1010.2
Grahame Grieve (Feb 25 2019 at 23:08):
OID value can be treated as url parameter
That's syntactically valid, but not actually semantically correct, since URL is defined as the canonical value, and the OID is not (always, or even usually) the code system URL
Last updated: Apr 12 2022 at 19:14 UTC
