Stream: terminology
Topic: Using resources for list items
Paul Lynch (Jun 12 2018 at 15:59):
One of the ideas discussed on last night’s vocab call was using specialized resources (e.g. Medication) to describe lists of things (rather than ValueSet) if there are additional properties beyond “code” and “display”. I am curious about the implications of this, and have some concerns. For one thing, there is an advantage to having a generic structure so that a form rendering widget (like our LHC-Forms) does not need to know about individual resources when rendering a Questionnaire or handling keystrokes in a field with a list.
Also, our Clinical Table Search Service (https://clinicaltables.nlm.nih.gov/) has 22 different tables, which have a uniform URL-based query format and a uniform output form. In order to serve these to FHIR-based apps (e.g. for Questionnaires), would this service need to be returning 22 different FHIR resource types?
Lloyd McKenzie (Jun 12 2018 at 16:23):
Terminologies generally provide flat collections of properties and the properties are unordered. They can't have hierarchy to the organization of the properties. So if you want to convey that Medication X contains 10mg of ingredient 1 (active ingredient) and 5mg of active ingredient 2 and also contains non-active ingredient 3, that's hard/impossible to do using properties.
Lloyd McKenzie (Jun 12 2018 at 16:24):
Also, we prefer to not have two ways to share the same information. The Medication, Location, ObservationDefinition and other resources exist for the purpose of sharing such definitional information whether associated with a terminology or not.
Paul Lynch (Jun 12 2018 at 17:02):
A flat collection of properties does not necessarily mean the properties themselves are flat-- speaking generally, though maybe FHIR has that restriction. For instance, on the Clinical Table Search Service, if you request the "STRENGTHS_AND_FORMS" property for the "Propranolol XR (Oral Pill)" record (https://clinicaltables.nlm.nih.gov/api/rxterms/v3/search?ef=STRENGTHS_AND_FORMS&terms=Propranolol+XR) you get back an array like [" 60 mg 24 HR XR Cap"," 80 mg 24 HR XR Cap","120 mg 24 HR XR Cap","160 mg 24 HR XR Cap"].
I do get the motivation for wanting to use the resources for (what seems to me to be) a handful of cases that are covered by those existing resources, to avoid defining things in two places. However, given that the number of types of database-backed lists someone might want in a Questionnaire, or might want to make available for Questionnaires, has no limit, I would think a more general solution needs to exist. Does it make sense to define a new resource each time there is a new list, or a new source for an existing list that offers some additional properties?
Lloyd McKenzie (Jun 12 2018 at 19:02):
We define the resources when there's a need to create/read/update/maintain/share definitional information. In your example, 60, mg, 24 Hr XR Cap are all separate data elements. You're combining them together for convenience in a particular questionnaire lookup, but you can't calculate dosage or do other knowledge-base things with the data in that form.
Paul Lynch (Jun 12 2018 at 21:05):
True. The purpose of that API for RxTerms is to provide web applications with a way to create an autocompleting drug name lookup that also allows the user to pick from a strength/form list in a second input field (as in https://rxterms.nlm.nih.gov/). There are many other purposes for which its form of output would not be suitable. Nonetheless, for its specific use-case, it does serve its purpose, and it gets used. But, I think you are helping to make my case, in that here is an example of a useful lookup list for which it would not make sense to create a separate FHIR resource. I would still like to be able to use it in a Questionnaire, though.
Lloyd McKenzie (Jun 12 2018 at 21:36):
The look-up list is really a specialized query against the overall set of information that exists in the resource. We can't practically maintain the full set of medication definition information inside CodeSystem - at least not without significantly expanding its capabilities. How much redundancy do we add the simple code system that is a list of drug codes and names to provide look-up lists for different purposes?
Paul Lynch (Jun 12 2018 at 22:07):
I am not suggesting that CodeSystem know about medication definitions. My goal is make the APIs at https://clinicaltables.nlm.nih.gov/ accessible to Questionnaires, and I am prepared to make new versions of those APIs that speak FHIR. I think it is a general problem that people will have, that they have a data table somewhere, and would like to be able to autocomplete in a Questionnaire's form field to select a record. I don't think FHIR can or should try to create resources for every possible data table. Possibly the people serving up those data tables could create specialized resources, but in any event how it is done is less important (though not unimportant) to me than that there be some way to do it.
In LHC-Forms, the burden of selecting which fields are retrieved via the https://clinicaltables.nlm.nih.gov APIs the and what those fields mean (i.e., which fields receive that data after the record is selected) is placed in the form definition. It is up to the form designer to know that a certain API has a a certain field/property that is a drug strength list, and that after a selection there will be an RxCUI available that can be displayed. The API returns a generic structure with the requested field data. There is no need for a hand crafted resource for each kind of data the API serves.
Grahame Grieve (Jun 12 2018 at 23:35):
at heart, this is a question about levels of abstraction. The rule of thumb is that you're not very interested in the details, you'll prefer abstractions, while if you are in interested in the details, abstractions will be painful.
Michael Lawley (Jun 12 2018 at 23:40):
For the record, SNOMED CT (at least the Australian extension) includes codes for branded medications fully modelled with the pack sizes, strengths of ingredients etc, and this information is accessible via several paths - the normalForm property which gives the corresponding SNOMED post coordinated expression, and the SNOMED Expression Constraint Language (ECL). The latter allows for quite sophisticated ValueSets to be defined (on the fly, with implicit ValueSet URIs).
For example, this demo UI (https://plnkr.co/bpXxat?p=info) allows you to search and select a specific medication then see all the alternate brands, purely based on the modelled ingredients & their strengths. It is done only by building ECL expressions on the fly and issuing $expand GET requests.
For other kinds of CodeSystems that publish codes with properties you can do similar things by constructing "real" ValueSet resources with appropriate filter constraints and issuing POST requests.
Paul Lynch (Jun 21 2018 at 15:36):
@Michael Lawley That sounds interesting. I was out for a few days, and when I tried to click on the link you shared (https://plnkr.co/bpXxat?p=info) I got a "not found" page. Could you make that link work again, or provide a new one?
Paul Lynch (Jun 21 2018 at 17:30):
I got Michael's link to (https://plnkr.co/bpXxat?p=info) to work. (I was being redirected to "next.plunkr.co", where the link didn't work, but when I clicked "go back to the old version", then it worked.)
In the demo, I saw two different expansions happening. The first is when the user is typing into the field (autocompletion), and the ValueSet's URL is "http://snomed.info/sct?fhir_vs=isa/30537011000036101", and the entries in expansion.contains each contain a single code and display string without any additional properties.
The second expansion I saw was more interesting. Although the returned entries under expansion.contains still only had "code" and "display" without additional properties, the ValueSet URL was much more complicated: http://snomed.info/sct?fhir_vs=ecl/(< ((> 68893011000036106 AND ^ 929360081000036101|Medicinal product pack reference set|) MINUS >(> 68893011000036106 AND ^ 929360081000036101|Medicinal product pack reference set|)) : [0..0] 30409011000036107 |hasTPUU| = ( * : 700000081000036101|has ingredient| != (68893011000036106. 30409011000036107 |hasTPUU| . 700000081000036101|has ingredient|) )) . 700000101000036108 |hasTP|
The ValueSet spec for the its "url" property says, "A canonical url for a value set." That URL (above) probably does not meet the definition of canonical. However, with that kind of freedom, we could specify which properties get searched (and perhaps that is part of what that expression is doing). So, if that were allowed, that would solve half the problem I am facing. I still don't see a way of retrieving additional properties though (for display in the list the user sees as they type).
Michael Lawley (Jun 23 2018 at 00:52):
The URI here pretty much corresponds to this implicit ValueSet URI pattern ?fhir_vs=ecl/[ecl] documented here: http://build.fhir.org/snomedct.html#4.2.1.0.7.4 (strictly speaking, all the text between | symbols and extraneous whitespace should be removed, but Ontoserver is accommodating)
If you need designations, you can add &includeDesignations=true to the $expand call.
If you really need the codes' properties, then currently you need to do additional $lookup calls per-code (this is how we do it with our code-system browser, Shrimp: https://ontoserver.csiro.au/shrimp
Rob Hausam (Jun 23 2018 at 04:02):
@Grahame Grieve is working on a strategy and syntax for "chaining" the output of the $expand and $lookup operations, which should (when available in the spec and implemented) be able to do what @Paul Lynch is asking for.
Last updated: Apr 12 2022 at 19:14 UTC
