Stream: implementers
Topic: Terminology Services
Jon Zammit (Mar 08 2016 at 19:07):
Grahame does your server support the Concept Lookup operation? I am getting an error: "Lookup does not take an identified value set"
Grahame Grieve (Mar 08 2016 at 19:11):
yes it does. it sounds like you are invoking it wrongly
Jon Zammit (Mar 08 2016 at 19:13):
Sorry I was trying to follow the example in the spec, i.e.) GET [base]/ValueSet/$lookup?system=http://loinc.org&code=1963-8
But I am using a concept from your Clinical Finding value set.
Grahame Grieve (Mar 08 2016 at 19:19):
http://fhir2.healthintersections.com.au/open/ValueSet/$lookup?system=http://loinc.org&code=1963-8 works, yes?
Jon Zammit (Mar 08 2016 at 19:43):
Yes it does and I have corrected my syntax. Turns out, I misunderstood the parameters. Thanks for your help!
Grahame Grieve (Mar 08 2016 at 19:47):
great
Grahame Grieve (Mar 08 2016 at 22:38):
so the current build has now fully separated code system and value set. There's still some publishing issues. but I need to take a break and work on other things
Grahame Grieve (Mar 08 2016 at 22:38):
comments are welcome
Jon Zammit (Mar 10 2016 at 15:44):
@Grahame Grieve on the topic of Subsumption testing... I see the example in which you check if one concept is subsumed by another. Is there a query to retrieve all concepts subsumed by another? i.e. the "is a" relationship? I believe there is, just trying to nail down the syntax.
Grahame Grieve (Mar 10 2016 at 20:20):
instead of validating the value set, expand it using the same basic principle
Jon Zammit (Mar 10 2016 at 20:26):
Are you saying that all supertype concepts in SNOMED CT are represented as value sets?
I was under the impression you created clinical-findings as an example.
Grahame Grieve (Mar 10 2016 at 20:27):
there's a implicit value set for each concept that includes all it's children. So you can expand that implicit value set
Grahame Grieve (Mar 10 2016 at 20:27):
but if you want to the concept itself, it's not a value set
Jon Zammit (Mar 10 2016 at 20:34):
I want to list all children with a filter applied. Will try again based on your latest information...
Grahame Grieve (Mar 10 2016 at 20:35):
y expand e.g.
Grahame Grieve (Mar 10 2016 at 20:36):
GET [base]/ValueSet?identifier=[sct implicit url]&filter=[your text]
David Hay (Mar 10 2016 at 20:37):
shouldn't that be GET [base]/ValueSet/$expand?identifier=[sct implicit url]&filter=[your text] ?
Jon Zammit (Mar 10 2016 at 20:40):
In looking at @Michael Lawley 's VSTool, I thought he was doing something with "is a" in the query, against your server, Grahame.
Grahame Grieve (Mar 10 2016 at 20:41):
will have to wait for Michael to comment
Michael Lawley (Mar 10 2016 at 21:39):
yes, that's right. The second example valueset uses an isa/{sctid} style implicit ValueSet - you can substitute in any SCTID and the $expand will use the ISA relationships to compute the members of the ValueSet
Michael Lawley (Mar 10 2016 at 21:40):
e.g., [base]/ValueSet/$expand?_format=json&count=10&filter=aaa&identifier=http:%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F138875005
Peter Jordan (Mar 10 2016 at 22:27):
@Michael Lawley I've managed to implement subsumption queries, but would also like to be able to query for immediate parent and child concepts. I'm assuming that this requires an expression query - but cannot see how this can be done in the SNOMED CT Expression Constraint Language itself.
Grahame Grieve (Mar 10 2016 at 22:36):
what is it you want?
Grahame Grieve (Mar 10 2016 at 22:38):
Peter Jordan (Mar 10 2016 at 22:39):
The immediate parent concepts of a passed Concept ID and the immediate child concepts of a passed Concept ID. Subsumptions give me all the child concepts down to the bottom of the tree.
Grahame Grieve (Mar 10 2016 at 22:39):
well, check that link
Peter Jordan (Mar 10 2016 at 22:42):
What in that query is telling the server to lookup anything other than that particular code?
Robert McClure (Mar 10 2016 at 22:43):
I don't want to sound like a broken recod here but I'm going to be a stickler that we must keep the exchange from a service that when you obtain a subset of the value set exapnsion s defined by the value set definition, that thing you get is not representitive of the value set, it is a subset of that expansion. So @Michael Lawley , you are computing the members of a value set expansion subset, not the members of the value set.
Grahame Grieve (Mar 10 2016 at 22:44):
I don't follow the distinction you are making here.
Grahame Grieve (Mar 10 2016 at 22:44):
Peter, it returns information about the code, including the parents and children
Peter Jordan (Mar 10 2016 at 22:45):
Grahame, the examples in the spec don't have the parent and child concepts, and what if I only want information about that particular code - .e.g. for validation purposes, or to obtain the description?
Grahame Grieve (Mar 10 2016 at 22:46):
? you use that operation
Robert McClure (Mar 10 2016 at 22:48):
Note that if you create an "implicit" value set - a name I'm not happy with - that is simply a query for concepts that happens to have a URI you can stick to it, I see that not as a value set but simply a query result.
Peter Jordan (Mar 10 2016 at 22:50):
Grahame - ok, validate-code for validate operations! But just to lookup the description for a particular code - would I need to pass child and parent concepts - isn't something more explicit required here?
Grahame Grieve (Mar 10 2016 at 22:50):
you have a better name?
Grahame Grieve (Mar 10 2016 at 22:51):
you get back the value set expansion, not the value set definition. that's because you asked for an expansion.
Grahame Grieve (Mar 10 2016 at 22:51):
we haven't defined an operation to get the definition, since the definition can be built from url
Grahame Grieve (Mar 10 2016 at 22:52):
Peter - don't know what you mean - I look up a code, and get it's display and parents and children back
Peter Jordan (Mar 10 2016 at 22:53):
Grahame - the specification doesn't tell me that I'm getting that back....http://hl7-fhir.github.io/terminology-service.html.
Grahame Grieve (Mar 10 2016 at 22:59):
no. but I added it to my server by request. You could make a task to add that to the description of the operation
Grahame Grieve (Mar 10 2016 at 23:00):
which would be timely since I'm about to edit that operation - move it to code system from value set
Grahame Grieve (Mar 10 2016 at 23:03):
I'm about to update my stu3 server to split value set and code system
Peter Jordan (Mar 10 2016 at 23:04):
OK - but, IMHO, it would still be preferable to have a filter that enables a client to request just the passed code and not the parent and child concepts...and, of course, not all code systems have hierarchies.
Grahame Grieve (Mar 10 2016 at 23:05):
is it a problem to get back extra information?
Peter Jordan (Mar 10 2016 at 23:14):
Grahame - If the client only wants a description for the passed code, it's another overhead (in terms of DB querying), and why pass back more than is strictly necessary - particularly if that concept has a lot of children?
Peter Jordan (Mar 10 2016 at 23:15):
...but I am liking the fact that I won't have to engage with SNOMED CT Expression Language to get this information, when it's requested!
Grahame Grieve (Mar 10 2016 at 23:47):
well, yes, there could be a lot of children, I guess. Make that part of the task
Michael Lawley (Mar 11 2016 at 00:40):
@Peter Jordan in fact the SNOMED CT Expression Constraint Language does not support what you want (it was actually explicitly excluded from the scope of that language despite my protests)
Michael Lawley (Mar 11 2016 at 00:41):
The $lookup option (non-standard behaviour) is all you get for this
Michael Lawley (Mar 11 2016 at 00:41):
@Grahame Grieve yes, especially with parts of teh AMT there might be >10000 immediate children
Grahame Grieve (Mar 11 2016 at 00:42):
sounds like we should standardise this. I'm going to be redefining look up in terms of the code system resource this weekend
Grahame Grieve (Mar 11 2016 at 00:43):
so when I do this - I'll allow a client to indicate what properties it wants back for a code. If it doesn't say, the server can choose what to return
Grahame Grieve (Mar 11 2016 at 00:43):
sounds reasonable?
Michael Lawley (Mar 11 2016 at 00:45):
fine-grained control over populated properties an a FHIR response is a good way to manage this and also could go some way to addressing other issues that people have with the size of the payloads
Peter Jordan (Mar 11 2016 at 00:54):
@Grahame Grieve That sounds good to me and I've included that point in the gForge Task. Will you also be moving the $validate-code operation to the CodeSystem Resource? @Michael Lawley pity that IHTSDO didn't agree with you!
Michael Lawley (Mar 11 2016 at 01:18):
@Peter Jordan It was pushed to being in-scope for the greater "SNOMED CT Query Language". The cost of that is the delay in delivering the QL - there are several other pieces of work to be delivered before the QL stuff will arrive.
Michael Lawley (Mar 11 2016 at 01:19):
If the IHTSDO had more visibility on the desire for such a feature in the ECL, then that would be a good thing, so I encourage you to raise it directly with them
Peter Jordan (Mar 11 2016 at 01:32):
@Michael Lawley I might get the chance to mention it at the SNOMED Expo in Wellington later this year. I'm also interested in anything out there that might parse ECL into SQL and/or the upcoming SCT QL. I almost feel like cheating and have clients pass SQL, rather than ECL, in FHIR...almost!
Grahame Grieve (Mar 11 2016 at 01:37):
I wouldn't know what to do with SQL and I'm not writing a sql parser and I don't have SCT in tables
Peter Jordan (Mar 11 2016 at 01:52):
I'm not suggesting that you write one @Grahame Grieve and appreciate that there are alternative ways of persisting SNOMED-CT data. It's really implementation-specific, but might be useful for those who need to query relational DB sources...and I did say 'almost'. :) Incidentally, what are you doing with ECL?
Grahame Grieve (Mar 11 2016 at 01:56):
nothing with ECL at the moment
Grahame Grieve (Mar 11 2016 at 02:22):
Question for terminology service implementers:
Grahame Grieve (Mar 11 2016 at 02:23):
at the moment we say that you indicate what code systems you support by looking for an extension in the conformance statement.
Grahame Grieve (Mar 11 2016 at 02:25):
now that we've defined the code system resource, we could change that. Here's the options I can think of:
- leave it as is - the extension declares the system uris that you support
- change the extension so it's a reference to a code system resource instead
- chance the extension so it can be one or the other
- drop the extension, and list code system resources directly as a property of the conformance statement
- drop it from the conformance stateement altogether, and assume that GET [base]/CodeSystem returns a list of all the code systems the server supports
Michael Lawley (Mar 11 2016 at 02:41):
There is a doc that describes the semantics of ECL in terms of the underlying RF2 tables (up to be not including concrete domain data). I can't recall if that made it into the spec or not.
Reuben Daniels (Mar 11 2016 at 02:55):
Grahame: I'm assuming you are referring to the "https://hl7-fhir.github.io/extension-conformance-supported-system.html" extension. If so, can you please clarify what is meant by the word "supported" in the statement "A code system that is supported by the system that is not defined in a value set resource."
Grahame Grieve (Mar 11 2016 at 03:30):
one that you can refer to in value sets and then do an expand on, or one that you do a $lookup on
Grahame Grieve (Mar 11 2016 at 03:31):
http://fhir3.healthintersections.com.au/ is now up and running a terminology service with code system separated out from value set
Peter Jordan (Mar 11 2016 at 03:55):
@Grahame Grieve If ValueSet $expansions can still be filtered by CodeSystem, then I'd be inclined to 'leave it as is'...because that extension could refer to either resource. I'd definitely leave it as an extension as 80% of FHIR servers probably won't directly support terminology services. It would also be good to include the version in the URI where, like SNOMED CT, the code system supports that syntax. I like the fact that it's in the Conformance Statement - a one-stop shop for implementation details.
Grahame Grieve (Mar 11 2016 at 04:01):
the extension can only refer to code systems
Reuben Daniels (Mar 11 2016 at 04:02):
Grahame: thank you for clarifying. In that case, I would support the idea of making this field a part of the core Conformance resource (i.e. not an extension) . Further, it would be nice to support assertions that you support multiple versions of a particular system (unless the expectation that you simply use multiple versioned URIs in which the version of the system is part of the URI). I don't necessarily see that the FHIR CodeSystem is necessary for assertions like this, but happy to be convinced :)
Grahame Grieve (Mar 11 2016 at 04:03):
you don't think that listing all the code system resources should achieve the same thing?
Reuben Daniels (Mar 11 2016 at 04:12):
I think it would. I just need to understand how it would work in practice. In particular, does this impose the need to have FHIR CodeSystem resource instances available (or created) for all the code systems you would like to assert support for. And if so, is that practical for all users of a deployed FHIR terminology server. That said, I would have no issues in allowing the new field to support both kinds of assertions of supported code systems: i.e. URI | Reference .
Grahame Grieve (Mar 11 2016 at 04:16):
well, it constrains both ways - you have to declare the code systems, potentially in depth, and you can't carry code system definitions for things you don't implement. it would make it active. but I think, for a terminology server, why would you have a code system but not implement it?
Grahame Grieve (Mar 11 2016 at 04:16):
I'd have to filter out and not upload the cpt-4 code system resource, but I know what I do support and can do that ok
Reuben Daniels (Mar 11 2016 at 04:20):
well, I guess I'm thinking of terminologies like LOINC and SNOMED CT. You may support (for value set expansion) SCT or LOINC because you've stored/indexed it. Does this now mean you need to create separate CodeSystem resource purely to assert that it is available instead of simply asserting the URI for the terminology as supported.
Reuben Daniels (Mar 11 2016 at 04:20):
I take your point for stored/indexed FHIR Code Systems of course.
Reuben Daniels (Mar 11 2016 at 04:20):
*FHIR CodeSystem resources.
Grahame Grieve (Mar 11 2016 at 04:22):
not purely to assert that is available; you also get to declare the version, the properties you support, the filters you support, and whether you are capable of post-coordination
Grahame Grieve (Mar 11 2016 at 04:22):
I think those things are pretty useful
Peter Jordan (Mar 11 2016 at 04:45):
Changed my mind! If the CodeSystem resource describes all this stuff, it probably makes the extension in the Conformance Statement redundant. So one vote for GET [base]/CodeSystem.
Reuben Daniels (Mar 11 2016 at 05:00):
Grahame: Now I'm wondering whether another option could be a TerminologyServerCapability resource which FHIR Terminology Servers can expose (alongside the conformance statement) to assert those supported capabilities ?
Grahame Grieve (Mar 11 2016 at 10:49):
Well, what else would it say?
Rob Hausam (Mar 11 2016 at 13:31):
Hmm. Maybe I'm not thinking about this correctly, but if I post a CodeSystem resource to your server, Grahame, say for cpt-4, does that mean that you "support" it (obviously not)? Or am I somehow not allowed to post CodeSystem resources to your server for terminologies that you don't support (and then where is that defined and exposed)? It's seeming to me that this belongs in the conformance statement in one way or another - and I think core would be preferable to extension.
Jon Zammit (Mar 11 2016 at 17:15):
@Grahame Grieve When expanding a SNOMED CT implicit value set and applying a text filter, what concept metadata does the text filter apply to? Just terms or other metadata associated with a concept? (i.e.parents & children)
Grahame Grieve (Mar 11 2016 at 21:01):
Jon, that's up to the server
Grahame Grieve (Mar 11 2016 at 21:02):
rob, I would not allow you to post a code system resource unless content= complete
Rob Hausam (Mar 11 2016 at 21:16):
ok - I haven't seen anything in the documentation for CodeSystem.content or the resource in general that specifies that behavior
and does that mean that CodeSystem is being treated "specially" in that regard compared to other resources?
Reuben Daniels (Mar 14 2016 at 00:16):
Grahame: to your question, some of the things this resource could assert include a) code systems (and specific versions of them) which are available to support expansions of value sets with codes from said code systems b) whether post-coordination is supported c) which expansion profiles are supported for value set expansion d) policies around paging e) which implicit value sets are supported for expansion. Probably a few more, but you get the idea.
Michael Lawley (Mar 14 2016 at 01:13):
In a ValueSet I can "import" the codes from another ValueSet, but I cannot "exclude" the codes from another ValueSet.
As an example of when I want to do this, see SNOMED CT's "Grouper Exclusion" reference set - this is a collection of codes that you might use in retrieval queries or for analytics, but you wouldn't normally want to appear in the patient record
Grahame Grieve (Mar 14 2016 at 07:16):
well, you can, by excluding codes based on the ref set membership
Michael Lawley (Mar 14 2016 at 07:19):
that works if it starts as a refset, but what if I have a "better"/alternate version that's only a refset?
if "import" were a child of include/exclude then we'd be okay
Grahame Grieve (Mar 14 2016 at 07:35):
there is a task for this in the system somewhere. From Lloyd
Grahame Grieve (Mar 14 2016 at 07:35):
not sure what you 'only a refset'
Brian Postlethwaite (Mar 15 2016 at 05:48):
Maybe I'm out of context here, but under what conditions am I filtering where I don't have a valueset as the context to search on?
All resource definitions bindings go to a valueset, not the codesystem directly.
René Spronk (Mar 15 2016 at 08:05):
"A code system specifies a set of codes drawn from one or more code systems." (on the new CodeSystem page) - cool recursive defintion ;-)
Peter Jordan (Mar 15 2016 at 08:15):
@Brian Postlethwaite In the ValueSet $expansion operations, it's possible to use SNOMED CT and LOINC in their entirety (and possibly other code systems) as implicit ValueSets and filter on them...e.g. ValueSet/$expand?identifier=http://snomed.info/sct?fhir_vs&filter=midlife and ValueSet/$expand?identifier=http://loinc.org/vs&filter=diastolic
Brian Postlethwaite (Mar 15 2016 at 08:18):
It might be possible to do, but from a usage point of view to aply to use in other fhir resoures, will always have the context. Unless I'm missing something.
Peter Jordan (Mar 15 2016 at 08:26):
Not sure that I understand, do you have an example Brian?
Robert McClure (Mar 15 2016 at 16:36):
I hope the code system page says "A code system RESOURCE specifies a set of codes drawn from one or more code systems."
Grahame Grieve (Mar 15 2016 at 17:21):
it does now
Michael Lawley (Mar 15 2016 at 20:48):
oops, I meant "only a ValueSet" ie., is not a refset
René Spronk (Mar 16 2016 at 11:53):
@Grahame Grieve wrote: The terminology service - the current build - does have relationships etc in the code system resource, and so that part of CTS2 is now possible in the FHIR terminology service.
René Spronk (Mar 16 2016 at 11:54):
Help me - where's the documentation on that?
Grahame Grieve (Mar 16 2016 at 12:01):
http://hl7-fhir.github.io/codesystem-definitions.html#CodeSystem.property
Stefan Lang (Mar 16 2016 at 12:07):
So you define properties like "can-be-combined-with" or "excludes" and so on in CodeSystem.property and use these in CodeSystem.concept.property (and it's concept children)?
Grahame Grieve (Mar 16 2016 at 12:07):
yes
René Spronk (Mar 16 2016 at 12:15):
Not being a terminologist, so I could define a property "is-anatomically-related-to", and create a property value for the code "arm" to be the tuple ("is-anatomically-related-to", code for "hand") ? That would indeed allow for any ontological relationship to be represented.
Patrick Werner (Mar 16 2016 at 15:22):
i'm not sure about the scope of FHIR in the Terminology Services context. in terminology topic it was stated, that putting the content of a Terminology onto a FHIR server would be bad practice, it would be better to just link an external terminolgy service. But now codesystems got extended in FHIR to store the contents of a terminology. I'm really confused (not an terminology expert).
Grahame Grieve (Mar 16 2016 at 20:41):
the content of the terminology services page needs adjustment for adding code system, so it might be a bit out of sync
Grahame Grieve (Mar 16 2016 at 20:41):
I'm still dealing with tehcnical broken bits
Grahame Grieve (Mar 16 2016 at 20:42):
but we shouldn't say anything like that anywhere.
Grahame Grieve (Mar 16 2016 at 20:43):
what we do say is that you shouldn't represent bit terminologies in the CodeSystem resource - they should be implicit. But you could try generating ICD-10-gm into a code system resource and see how you go.
Grahame Grieve (Mar 16 2016 at 20:43):
OntoServer and my FHIR reference server will support that out of the box if you do, and Apelon will soon
Peter Jordan (Mar 17 2016 at 02:10):
Looking forward to implementing the new CodeSystem/$lookup operation with the various properties that can be returned - including parent and child. Nice one Grahame! :)
Patrick Werner (Mar 17 2016 at 11:21):
the $lookup concept is nice, is there a concept how to lookup equivalent Codes over different versions of a Codesystem like changed ICD Codes over time? Same question for includse/excludes?
Grahame Grieve (Mar 17 2016 at 11:23):
you know, that's never come up. but it sounds.... yucky
Grahame Grieve (Mar 17 2016 at 11:23):
I can't even imagine what you mean with includes/excludes
Patrick Werner (Mar 17 2016 at 11:25):
simplified excludes means "these two codes shouldnt be used together"
http://www.hcpro.com/HIM-276496-865/Understand-ICD10CM-excludes-notes.html
Grahame Grieve (Mar 17 2016 at 11:26):
ah well, we could define properties for that in the ICD-X code system resources, and then you could query for them in the $lookup operation
Michael Lawley (Mar 18 2016 at 06:40):
@Peter Jordan can you tell me the context in which you want the child/parent codes for a SNOMED CT code? I'm putting together a case to get this into the ECL
Grahame Grieve (Mar 18 2016 at 07:08):
I added parent and child to $lookup
Peter Jordan (Mar 18 2016 at 07:25):
@Michael Lawley I'm mainly thinking from the UI perspective where being able to view parent and child nodes is a valuable aid to searching and selecting using any control that presents data in hierarchical structure. @Grahame Grieve I'm looking forward to implementing the new parameters on the $lookup operation, but it would be nice if SNOMED CT ECL also had this feature. A few other scripting & query languages have it (e.g. jQuery, Xpath, etc.).
Michael Lawley (Mar 22 2016 at 11:34):
@Peter Jordan it makes sense to have these in graph-based languages, but not so much in a Description Logic (DL)-based environent because there is no intrinsic meaning to there being no (named) class sitting between a 'parent' and 'child'. The link to the DL is really why this was originally omitted, but I'm now hopeful we can get it added in.
Gana Pemmanda (Mar 23 2016 at 00:58):
Question on Valueset expansion & filter - I searched the documentation and chats here, but couldn't figure out how filter should be applied. For eg. Let's take.. ValueSet/condition-code/$expand?filter=Lung Cancer. Looking at http://fhir3.healthintersections.com.au/open/ValueSet/condition-code/$expand?filter=Lung%20Cancer it seems like its not strictly a text search, since I see "Secondary malignant neoplasm of lung" in results.. If it does subsumption, what is the logic?
Eric Haas (Mar 23 2016 at 00:59):
we just talked about that here...
Eric Haas (Mar 23 2016 at 00:59):
Gana Pemmanda (Mar 23 2016 at 01:07):
Thanks @Eric Haas.. I just saw that. But my question was more along the lines of ValueSet expansion rather than searching within the resource itself.
Grahame Grieve (Mar 23 2016 at 01:09):
Yeah, Eric's thing is different. The rule is that the server can apply the text filter by whatever method it thinks best serves the user. In my case (the server you are referencing), I stem the search filter words, and then matches against all the words associated with the concept, weighting for distance from preferred display
Gana Pemmanda (Mar 23 2016 at 01:19):
Thanks @Grahame Grieve ! I wish that I asked the question a bit earlier.. Would have saved me some time :)
René Spronk (Mar 23 2016 at 13:17):
Do we have a list somewhere of terminology servers that support a FHIR interface ? I'd like to add such a list to the 'terminology' module we present in our FHIR training course..
Jon Zammit (Mar 23 2016 at 14:59):
Did you see the servers listed in Michael's VSTool? http://ontoserver.csiro.au/vstool/
Jon Zammit (Mar 23 2016 at 15:00):
May not be a complete list.
René Spronk (Mar 23 2016 at 15:34):
@Jon Zammit That's the Australian list I see ;-) ... others at http://wiki.hl7.org/index.php?title=201601_FHIR_Terminology_Services
René Spronk (Mar 23 2016 at 15:38):
Current list in my slide deck: Apelon, apelon.com
CSIRO Ontoserver, ontoserver.csiro.au
Health Intersections
HealthConnex, healthconnex.com.au
IMO - Intelligent Medical Objects, e-imo.com
NLM Value Set Authority Center (VSAC)
Jon Zammit (Mar 23 2016 at 15:55):
Ok thanks for the clarification, Rene!
Grahame Grieve (Mar 23 2016 at 19:16):
I would add art-decor.
Grahame Grieve (Mar 23 2016 at 19:16):
some of these are very far along the path of implementing a real production service, and others are on the path
Brian Postlethwaite (Mar 28 2016 at 05:04):
Hi all, I'm looking for a Valueset to reference that can represent the service-types that you could book an appointment for.
So far I've come across these valuesets which seem to describe bits n pieces of these.
http://hl7.org/fhir/valueset-service-pharmacy.html
http://hl7.org/fhir/valueset-service-product.html
http://hl7.org/fhir/valueset-service-provision-conditions.html
http://hl7.org/fhir/valueset-service-uscls.html
http://hl7.org/fhir/ValueSet/encounter-type
Is there a more comprehensive list anywhere, or is this too jurisdiction specific?
and also looking for a ServiceCategory that could segment this list - or is that just a grouper in the valueset - how can I represent this Have currently mapped as an example binding:
http://hl7.org/fhir/v2/0265/index.html
Michael Lawley (Apr 06 2016 at 13:47):
I would gladly add additional (public, working mostly) endpoints to VSTool for anyone who would like to provide me with theirs.
Michael Lawley (Apr 06 2016 at 13:48):
@Gana Pemmanda Ontoserver by default uses a word-prefix, any order strategy for matching and a custom scoring function for rankingthe matches
Grahame Grieve (May 02 2016 at 20:39):
A group at HSPC have identified something that is apparently missing on the FHIR terminology service
Grahame Grieve (May 02 2016 at 20:41):
say I have a SNOMED CT concept ID, 123456789. I want to know whether the code - post-coordinated or not - has a laterality
Grahame Grieve (May 02 2016 at 20:41):
that's ok - is it in the value set 'codes with laterality'
Grahame Grieve (May 02 2016 at 20:42):
but what if I want to know what the SNOMED CT laterality actually is?
Lloyd McKenzie (May 02 2016 at 23:06):
So you're asking for a coded expression to be de-constructed and extract a specific piece?
Rob Hausam (May 02 2016 at 23:17):
It sounds to me like to do this completely you would ultimately need to be able to fully parse arbitrary SNOMED CT compositional grammar expressions. For example, in the US extension there are concepts such as "Closed fracture of left upper limb" (446601000124102. That concept is fully defined with a Finding site of "Structure of left half of body" (31156008). And "Structure of left half of body" in turn has "Laterality " (272741003) = "Left" (7771000). It wouldn't necessarily be too hard to pull laterality out of that , but it's definitely not limited to a single level of nesting. And I suspect that it would get even more complicated in some cases - especially if full post-coordination is supported.
Peter Jordan (May 02 2016 at 23:17):
Can't you filter by using a SNOMED CT query expression as per...http://hl7.org/fhir/2016May/snomedct.html ... assuming, of course, that the concepts with the laterality attribute values are held on the relevant Terminology Server - either as fully-defined concepts or post-coordinated concepts in extensions.
Lloyd McKenzie (May 02 2016 at 23:22):
The real challenge is that if we're going to define this as a generic service, it should function with an arbitrary post-coordination/knowledge model. And that sounds pretty ugly to me.
Grahame Grieve (May 03 2016 at 03:21):
well, I don't think that we need to get too involved in the details. We have code system properties, so, it's an operation on the server: give the server a code, and ask for a property back (or perhaps a property with a value), and get back the property for that code.
Grahame Grieve (May 03 2016 at 03:21):
you could see a use for that in LOINC, RxNorm, SCT, ICD-X, PBS, MIMS
Grahame Grieve (May 03 2016 at 03:22):
sorry for random Australian terminologies in that list ;-)
Grahame Grieve (May 03 2016 at 03:22):
and you could also do the other - give a whole lot of properties, and ask for a single code that includes them all - if one exists
Grahame Grieve (May 03 2016 at 03:23):
none of that means that the API buys into the messy details of the actual work in the background, which, yes, you need to be parse sct grammar. but the existing terminology servers can mostly do anyway - that's what we do
Dave Carlson (May 03 2016 at 21:20):
Grahame, I still get an internal server error attempting snomed code $lookup on your server, e.g. http://fhir3.healthintersections.com.au/open/CodeSystem/$lookup?system=http://snomed.info/sct&code=404684003
Robert McClure (May 04 2016 at 16:16):
Graham has this right I believe. I assume that you all agree since there was no reply to his comment. What I take him to mean is that the sort of detailed terminology service function needed to support something like "Give me all the concepts that are a descendent of "disease" that have "laterality: "Left"" would not be a FHIR terminology service function. Instead this would be something that could be done by an "external" terminology service that has the functionality noted. BTW, the just about to be published Characteristics of a Value Set Definition (VSD) STU has an HL7 Expression for defining a value set definition (based on MIF) where this sort of "request" could be defined. See http://wiki.hl7.org/index.php?title=Value_Set_Definition_Standard_Project
Grahame Grieve (May 04 2016 at 16:17):
why do you think it would not be a FHIR terminology service function?
Robert McClure (May 04 2016 at 16:18):
Because there are other choices available. But I understand that someone could propose that it's fully defined in FHIR.
Robert McClure (May 04 2016 at 16:19):
I do agree that FHIR would benefit from clarifying the syntax for the request. I assume the returned set is just a list of oncept representations (codes).
Grahame Grieve (May 04 2016 at 16:20):
more than one code?
Robert McClure (May 04 2016 at 16:20):
My example would bring back multiple concepts that satisfy the request
Grahame Grieve (May 04 2016 at 16:20):
I think that it makes sense to define the API: given a code, get a property value from it. But we shouldn't be the ones that define the termnological functionality that this is a window to
Robert McClure (May 04 2016 at 16:21):
agreed
Grahame Grieve (May 04 2016 at 16:22):
great. Is defining the terminological functionality in scope of the vsd? it's beyond that isn't?
Robert McClure (May 04 2016 at 16:40):
Existing VSD PSS is limited to semantics of of the metatdata needed to define a value set, including the sematics of how to characterize the expression that identifies concepts to be included in the expansion set. I suspect our next PSS will focus on the informative parts we touched on in VSD: 1) How to define what should be included in an expansion *in addition to* the list of concept representations (codes). i.e.: how to specify I want the description, the code system ID and name, etc. We also need to define a syntax for the VSD metatdata - perhaps we can use FHIR - to support exchange. I suspect what you are asking for is not in either of those portions of work.
Grahame Grieve (May 04 2016 at 16:44):
no I didn't think it was. or should be. Just making sure
Grahame Grieve (May 04 2016 at 16:44):
we could look at using FHIR for VSD metadata syntax
Grahame Grieve (May 04 2016 at 16:44):
a discussion for elsewhere, but requirements and options would be my first question
Grahame Grieve (May 04 2016 at 17:24):
@Dave Carlson fixed the lookup problem
Dave Carlson (May 04 2016 at 17:27):
@Grahame Grieve just tested lookup and working, thanks! See you on Saturday.
Grahame Grieve (May 04 2016 at 17:28):
great
Michael Lawley (May 05 2016 at 17:08):
@Grahame Grieve One "problem" with asking for the laterality property is that in the general case there may be more than one - eg a postcoordinated expression talking about a closed fracture of left leg and open fracture of right leg. Or, more immediately, the ingredient(s) of a medication.
Note that the SNOMED expression constraint language can be used to query for the laterality: << |side| : |laterality| R= 123456789
Grahame Grieve (May 05 2016 at 21:58):
yes. it means that the cardinality is >1.
Michael Lawley (May 07 2016 at 04:58):
It seems nearly half of the 836 example CodeSystems have an asserted profile of http://hl7.org/fhir/StructureDefinition/valueset-shareable-definition - e.g., codesystem-questionnaire-display-category.canonical.json codesystem-teeth.json
http://fhir3.healthintersections.com.au/open/CodeSystem/questionnaire-display-category
Grahame Grieve (May 07 2016 at 05:27):
only half?
Grahame Grieve (May 07 2016 at 05:27):
nearly all of them should
Michael Lawley (May 07 2016 at 05:31):
360 by my rough calculation, but am I missing something? How can a CodeSystem satisfy the profile for a ValueSet?
Grahame Grieve (May 07 2016 at 05:40):
right, that's an error. I'm fixing that in the current build.
Angus Millar (May 07 2016 at 15:46):
Can I ask Terminology question? If I need a term and I happen to find the term I want in a value set and that value set has sourced the term from a known code system, maybe LOINC. Then what system do I use in formig my coding, the ValueSet referance or the known codesystem. Is it true to say I could uses either depending on my policy?
Lloyd McKenzie (May 07 2016 at 15:58):
It must always be the URL for the code system.
Lloyd McKenzie (May 07 2016 at 15:58):
The value set URL can be conveyed in the Coding as well with an extension, but the meaning of the code is conveyed by the code system URL + the code value.
Angus Millar (May 07 2016 at 15:59):
Thanks Lloyd
Peter Bernhardt (May 09 2016 at 21:58):
Question about the ConceptMap resource. Let's say I have a concept map for RxNorm to NCD (or any vocabularies that may represent a very large number of maps). This would have thousands of elements, wouldn't it? And that would make it virtually impossible to exchange data. What am I missing about how mappings should be constructed and/or how they may be represented between a client and server?
Grahame Grieve (May 09 2016 at 22:06):
yep they can be very large. We haven't really come to terms with all the ramifications of that, but as far as the client is concerned, just use $translate
Peter Jordan (May 09 2016 at 22:11):
I wouldn't use $translate for large-scale data mappings (e.g. READ to SNOMED CT over a primary care data set), but certainly for individual codes and reasonably-sized collections of codes. From a client perspective, I'd probably persist the results if the query was unlikely to be one-off.
Grahame Grieve (May 09 2016 at 22:13):
well, if you're gong to be doing large scale data mappings - not what I intended to address - I don't really understand the point of a subset..
Peter Jordan (May 09 2016 at 22:20):
It's entirely possible, in an exchange use case, for an endpoint system to receive a small number of codes, from a system they don't implement and wish to translate those to a system that they do implement. I can certainly foresee this happening in NZ when a new system that has never implemented Read Codes receives them in a legacy record and wishes to translate them to SNOMED CT. There might be fewer than a dozen, so why request the entire map?
Grahame Grieve (May 09 2016 at 22:21):
well, use $translate with multiple codes then
Peter Jordan (May 09 2016 at 22:23):
Yes, a subset of the codes that need to be translated at that time?
Grahame Grieve (May 09 2016 at 22:25):
well, just ask for translations on all the codes you want - see http://hl7-fhir.github.io/terminology-service.html#2.5.1.9
Peter Jordan (May 09 2016 at 22:27):
Indeed. That was the whole intention of my reply - but perhaps I didn't use the correct terminology...and you've provided a translation!
Chris Grenz (May 10 2016 at 19:16):
Is it expected that a :above or :below search for a code will take ConceptMap into account or only the nesting in CodeSystem?
Grahame Grieve (May 10 2016 at 19:38):
I don't think it's expected
Grahame Grieve (May 10 2016 at 19:38):
it's allowed
Chris Grenz (May 10 2016 at 20:03):
Is there any way to know?
Grahame Grieve (May 11 2016 at 10:27):
not at the moment. Do you really need to know? (you who complained about the size of the conformanr resource!)
Chris Grenz (May 11 2016 at 13:09):
This is the kind of "feature" conformance that may be valuable. Can think of a few...supporting of @profile slicing, support of search by (new) profile, etc....
Grahame Grieve (May 11 2016 at 15:48):
yay for more features ;-0
Brian Postlethwaite (May 31 2016 at 01:14):
Did we ever get to deciding on if we should add Operations to CodeSystem (Think I requested on Valueset before was seperated) for adding/removing concepts to a codesystem?
Grahame Grieve (May 31 2016 at 01:17):
given the stated scope of code system, I don't think we'd add that to the spec
Brian Postlethwaite (May 31 2016 at 01:18):
ok. Might have a private implementation then for internal maintenance of internal codesystems.
Grahame Grieve (May 31 2016 at 01:19):
you could still consider publishing it - I would probably implement it before next month in Sydney
Rob Hausam (May 31 2016 at 01:20):
this statement in Scope and Usage addresses that: "The Code system resource is not intended to support the process of maintaining a code system."
Rob Hausam (May 31 2016 at 01:22):
and I guess we need to change that to "The CodeSystem resource ..."
Michael Lawley (Jun 03 2016 at 00:43):
Maybe it's a PATCH operation?
Grahame Grieve (Jun 03 2016 at 00:44):
the problem with path is that it's offset dependent. You can only patch if you have current. So it doesn't save that much. unless we beef up patch. and interest in that is pretty tepid
James Agnew (Jun 07 2016 at 22:35):
@Grahame Grieve How come the v3/RoleCode codesystem on your server doesn't include the _PersonalRelationshipRoleType code?
The PersonalRelationshipRoleType ValueSet references this code, but this is failing for me because that code can't be found. Am I missing something?
Grahame Grieve (Jun 07 2016 at 23:39):
because it's not in the generated code system in the spec
James Agnew (Jun 07 2016 at 23:40):
I guess my question is why isn't it there?
Grahame Grieve (Jun 07 2016 at 23:41):
yeah, debugging that now
Grahame Grieve (Jun 07 2016 at 23:52):
a typo in a string constant in the v3 MIF processing code
Grahame Grieve (Jun 07 2016 at 23:53):
looking for the heirarchy as "Sompecializes" instead of "Specializes"
James Agnew (Jun 07 2016 at 23:53):
Ah cool. That's very sompecial of you to fix it.
Grahame Grieve (Jun 07 2016 at 23:54):
lol
Peter Jordan (Jun 08 2016 at 05:08):
Now that a $subsumes operation has been added to the CodeSystem resource, is the subsumption test (isa) part of the ValueSet$validate-code operation redundant?
Grahame Grieve (Jun 08 2016 at 05:24):
notionally, but the $subsumes operation is not approved yet...
Peter Jordan (Jun 08 2016 at 05:32):
Thanks, I'll implement CodeSystem$subsumes and leave the $validate-code functionality as is...just in case. Looking at the operation definitions, CodeSystem looks like its natural home.
Peter Jordan (Jun 10 2016 at 03:07):
Looking at this example in the latest version of the spec GET [base]/CodeSystem/$subsumes?system=http://snomed.info/sct&codeSub=3738000&codeSuper=235856003
I'm not sure why the outcome code issubsumes rather than subsumed-by.
Last updated: Apr 12 2022 at 19:14 UTC
