FHIR Chat · Terminology-powered search · terminology

Stream: terminology

Topic: Terminology-powered search

Josh Mandel (Mar 11 2022 at 19:53):

From discussion on the DaVinci "Formulary IG" call, they have a use case where a "Formulary Item" describes the details of how a particular drug is included in a formulary. Logically the "Formulary Item" says things like:

"acetaminophen 325 MG / oxycodone hydrochloride 5 MG Oral Tablet" is covered on Formulary A with a quantity limit of 60 pills per 30 days

Today, they want to support things like searching by various brand/generic names or different dose forms. All this information lives in vocabularies like RxNorm, but it's not easy to search, so instead of just listing an RxNorm code in the Formulary Item, the IG adds a new resource called "Formulary Drug" -- a profile on MedicationKnowledge that basically acts an an "index" for drug properties (name, generic equivalents, dose forms, etc). This pattern is useful because it lets you use search params to find, say, brand name drugs via a query like:

 /Basic?code=formulary-item&subject.drug-name=percocet&doseform=tablet

Josh Mandel (Mar 11 2022 at 19:54):

... but it strikes me that this pattern (creating a FormularyDrug resource to staple together terminology details into a resource, to enable search) is creating a whole new problem -- lots of state to manage, even when the underlying data already exist in terminologies (concepts, hierarchies, properties, etc). It would be nicer if a FormularyItem could just list a drug (say, by RxNorm code) and queries could ask these kinds of questions directly against the FormularyItem.

Josh Mandel (Mar 11 2022 at 19:57):

In other words, it'd be nice to write queries like:

/Basic?code=formulary-item&drug:terminology=(rxnorm.type = SBD, rxnorm.doseform = Tablet, rxnorm.preferredTerm ~ Percocet)

(Never mind my ad-hoc syntax, hopefully you understand the kind of thing I mean.)

Has there been discussion about this kind of capability, pushing terminology details (beyond above/below) into queries? (It's something the semantic web stack expresses really well, but I'm wondering if there's some practical application in FHIR too.

Particularly interested whether @nicola (RIO/SS) or @Jim Steel have built features like this (standardized or non).

nicola (RIO/SS) (Mar 11 2022 at 20:13):

We provide Concept resource with first-class extensions - i.e. rxnorm can be loaded with extra info. Custom resources can be used for formulary item, and query is quite trivial join with our SQL on FHIR

Josh Mandel (Mar 11 2022 at 20:32):

Thanks! Do you support a generic kind of query syntax where anytime you are searching by "token" type search parameter, there is a way to leverage properties from a terminology? And if you're defining a custom resource can it be (essentially) just a "materialized view" on a terminology? Or are you thinking about another model for supporting a Formulary Drug?

Michael Lawley (Mar 13 2022 at 04:29):

These are the kinds of things you can do with ECL for snomed (which translate directly to an implicit valueset URI).
I've long thought a similar capability (and syntax) that approximates the Valuset compose functionality would be a great addition to FHIR Terminology services

Josh Mandel (Mar 15 2022 at 14:34):

Interesting @Michael Lawley ! Do you have any thoughts about what a good starting point for this would look like? And what do you think about the idea of surfacing this as a capability within FHIR search?

Michael Lawley (Mar 15 2022 at 23:08):

I see the main use-case for such a VCL (ValueSet Constraint/Compose Language) as being the basis for implicit valueset URIs much as ECL can be used to specify them of the form http://snomed.info/sct?fhir_vs=ecl/[ECL].

So, off the top of my head, I'd limit to a single codesystem (based on the base of said URI), and focus on simple & common aspects of ValueSet.compose functionality, building from the existing ECL syntax pattern:
[focus] : [property] [op] [value]
where [focus] includes * as a wildcard, and <<, < etc operators for hierarchy traversal, and then add in simple AND / OR / MINUS and bracketing to compose sub-expressions.

The would give you things like:

• <! LP43571-6 MINUS 5932-9 (equivalent of http://hl7.org/fhir/ValueSet/example-intensional)
• << _ActClassROI MINUS _ActClassROI (equivalent of http://terminology.hl7.org/ValueSet/v3-ActClassROI), but more simply: < _ActClassROI
• * : {{ C STATUS = ACTIVE, CLASSTYPE = 1, CLASS != regex:"CYTO|HL7\\.CYTOGEN|HL7\\.GENETICS|^PATH(\\..*)?|^MOLPATH(\\..*)?|NR STATS|H&P\\.HX\\.LAB|CHALSKIN|LABORDERS" }} (equivalent of http://hl7.org/fhir/uv/ips/ValueSet/results-laboratory-observations-uv-ips)

That last one is perhaps stretching what might be needed in practice, but is a real-world example and shows how property filters would be expressed. The others just constrain based on hierarchy.

Finally, one might introduce the rule for implicit ValueSets that allows [uri]?vcl=[expression] to be used as an implicit valueset for the CodeSystem where [uri] is the "all code ValueSet", ie. the value of CodeSystem.valueSet

Josh Mandel (Mar 16 2022 at 01:16):

Cool! I like the idea of exposing the same machinery (or a subset) as ValueSet definitions inline. I'll try to write out examples from the RxNorm cases above.

Josh Mandel (Mar 16 2022 at 03:53):

So if you wanted to find meds that included tylenol you could do a query using the generic (161) and branded (202433) ingredients like:

MedicationUsage?code=(tty in ['scd', 'sbd'], has_ingredient in [161, 202433])

... though I'm not sure how to say "we're talking about RxNorm". I'm also not quite sure how to write a search over concept names (e.g., preferred terms or synonyms that match "tylenol") based on the properties defined in https://www.hl7.org/fhir/rxnorm.html (I haven't worked with this page in the FHIR spec before, and the syntax is not super clear to me, so I may just be misunderstanding)

Michael Lawley (Mar 16 2022 at 04:11):

For what I was brainstorming above, the ValueSet URI would be something like:
http://www.nlm.nih.gov/research/umls/rxnorm/vs?vcl=*: has_ingredient = (161 OR 202433) {{ C tty = ("scd" "sbd") }}
with appropriate %-encoding.

This is saying match any (*) RxNorm code (http://www.nlm.nih.gov/research/umls/rxnorm/vs is the all-codes valueset) with a has_ingredient relationship to either of the codes 161 or 202433 and a tty property of "scd" or "sbd".

If you want to limit matches to those with "tylenol" in the display/designation text, then you would append a clause like {{ D term="tylenol" }}

( I'm basing all this on a straightforward re-use of SNOMED's ECL - http://snomed.org/ecl )

Michael Lawley (Mar 16 2022 at 04:13):

Putting it together we'd end up with:

MedicationUsage?code:in=http://www.nlm.nih.gov/research/umls/rxnorm/vs?vcl=*: has_ingredient =  (161 OR 202433) {{ C tty = ("scd"  "sbd") }} {{ D term="tylenol" }}

Michael Lawley (Mar 16 2022 at 04:16):

This pushes all the interpretation off to the terminology server layer, rather than extending FHIRPath or _search syntax

nicola (RIO/SS) (Mar 16 2022 at 09:55):

@Josh Mandel You can add first-class extensions to Concept resource with rxnorm and formulary item attrs, then define search params for it. Is it what you call "materialized" terminology? Or you can create custom resource for formulary item and join/filter with rxnorm concepts

nicola (RIO/SS) (Mar 16 2022 at 10:00):

I think, what you want may be expressed as chained search/_search (with only one join) with Concept resource. I do not like idea of one more "new ad-hock search syntax"

Josh Mandel (Mar 16 2022 at 13:26):

@Michael Lawley thanks, those references are helpful. I'll read up on the ECL syntax (it's not totally transparent at first, which is fair). In your proposed example, I'm assuming this uses (depends on?) the definitions from https://www.hl7.org/fhir/rxnorm.html? Even though none of those properties are defined (? I think?) as supporting subsumption?

Josh Mandel (Mar 16 2022 at 13:42):

@nicola (RIO/SS) yes, I'm thinking about a world where a FHIR server generically "loads RxNorm" to support diverse use cases -- not specifically to populate a FormularyDrug resource or a ReconciliationRecommendation in particular, but in a way that any search on any Coding can ask questions like the ones above.

Maybe it'd be good to work through similar examples with your architecture. How would a client ask for:

• All MedicationUsage resources where patient is 123 and the drug code is an RxNorm code with "tylenol" or "acetaminophen" as part of the preferred name?

• All MedicationUsage resources where patient is 123 and the drug code is an RxNorm code that "has_ingredient" of RxNorm CUI 161 or 202433?

Robert McClure (Mar 16 2022 at 14:55):

Folks, we've bantered about a generic terminology query and representation syntax and it's never gotten anywhere. Apelon DTS uses "TQL" and obviously SCT uses ECL. I strongly agree that we need to expose a common general hierarchical and filter-based query syntax for use in defining value sets and performing inline queries as @Josh Mandel wants. Can we get some folks to come and play at connectathon? @Davera Gabriel This discussion is perfect for connectathon topic.

nicola (RIO/SS) (Mar 16 2022 at 19:45):

@Josh Mandel now it can be done with something like this:

select mu.* from medicationusage mu, concept c where mu.resource#>>'{patient,id}' = '123' and mu.resource->'code' = c.resource->'code' and c.resource#>>'{rxnorm, prefName}' in ()

nicola (RIO/SS) (Mar 16 2022 at 19:48):

If we introduce chain by code - it can be GET /Mu?pid=...&code:Concept.rxnormPerf=a,b

nicola (RIO/SS) (Mar 16 2022 at 19:51):

The key is Concept resource and application of FHIR search framework to it! Concept may be extended and profiled for specific terminology like rxnorm

nicola (RIO/SS) (Mar 16 2022 at 19:52):

So we do not have to reinvent the wheel

Josh Mandel (Mar 16 2022 at 20:12):

Neat! Can you write out a full example for the search query? I'm not 100% sure I follow the chaining, and whether/where composite search parameters are needed

nicola (RIO/SS) (Mar 16 2022 at 20:14):

I will prepare working notebook for aidbox tomorrow with sql - ok?

nicola (RIO/SS) (Mar 16 2022 at 20:16):

Search query is hypothetical - means we can "join" concept by code - but maybe implemented

Josh Mandel (Mar 16 2022 at 20:20):

Thanks! I'm looking to understand how this would appear on the search API (I mean, the underlying SQL is great too but it doesn't quite answer my question).

Josh Mandel (Mar 16 2022 at 20:20):

Example syntax is fine if you identify it as such.

Michael Lawley (Mar 16 2022 at 21:53):

@Josh Mandel Yes, I've used the filters from https://www.hl7.org/fhir/rxnorm.html, and in general I would expect any filter to be usable since a design goal would be that all expressions are transformable into an explicit ValueSet.compose element. However the expressions above don't depend on subsumption wrt properties, only wrt the concepts themselves.

Wrt syntax, SNOMED's ECL was modelled on its post coordination syntax which makes a lot of sense in that domain. It's also quite succinct.
It doesn't quite seamlessly translate to FHIR CodeSystems since it distinguishes concept properties and concept relationships (properties that reference other concepts in the same CodeSystem), distinguishes concept properties from designation properties (hence the {{C and {{D parts of the syntax), and doesn't cover all the FHIR datatypes (eg Coding).
We could probably define a prettier syntax, but coming from SNOMED-land, I like the idea of building something that's aligned with an existing domain-oriented syntax because there's less to learn. It's also an implementation-independent syntax (i.e., doesn't leak out relational table design elements).

Wrt @nicola (RIO/SS) 's point of new syntaxes, ad hoc or not, his approach depends on a new Resource and associated additional extensions, which could also be labelled ad hoc :-). I'm not sure why, in such an approach, you'd need to introduce extensions to carry the rxnorm attrs; I would have expected generic attrs to be a fundamental aspect of such a Concept Resource?
However, use still requires some way to "chain" through a code/concept. This pushes a pile of implementation logic into the FHIR Server itself, rather than leaving it all in the terminology subsystem sitting in an existing re-usable abstraction (ValueSet).

Michael Lawley (Mar 16 2022 at 22:31):

@Robert McClure wrt TQL, I think the advantage here is that we'd be looking at an 80% approach that doesn't try to get at every possible underlying aspect of a code system, but rather covers off the core parts that are exposed using existing ValueSet functionality. This would be my argument as to why this might get traction where other things remain niche / proprietary -- an open syntax that compiles down to existing standard capability that could even be provided as part of the standard libraries.

Josh Mandel (Mar 16 2022 at 23:20):

Really enjoyed reading examples at https://confluence.ihtsdotools.org/display/DOCECL/6.+Examples (in lieu of the spec itself ;-)). The main difference I see for terminologies like RxNorm is that the detailed relationship types aren't modeled as concepts in the terminology (whereas in SCT they are), but that's not any great impediment to reusing the syntax.

Josh Mandel (Mar 16 2022 at 23:37):

I'm quite interested in how well a "regular FHIR server" (as opposed to a specialty terminology server) could join together clinical resources with (standardized / consistently modeled) concept tables to support this kind of thing. Of course, maybe the answer is "send the terminology piece to a terminology subsystem to resolve it into a set of concepts first" -- but with this approach you don't have the advantage of query optimization across the clinical and terminology data.

Observation?_id=123&code:tx=(*: {term="*e*"})

Observation?code:tx=(*: {{term="*excited*"})

Michael Lawley (Mar 16 2022 at 23:40):

Since SCT now has non-concept relationships, and ECL supports those. I think that aligns very well with the kinds of properties you'd see in RxNorm.

Michael Lawley (Mar 16 2022 at 23:45):

I guess I am assuming that 1. a "regular FHIR Server" already needs to support queries like Observation.code:in=http://example.com/SomeValueset and this proposal would leverage that capability, 2. if it doesn't, then both approaches require a bunch of server-side implementation. It would not be hard for a server to recognise a trailing ?vcl=... in a valueset URI and do local evaluation as an optimisation step (both approaches would require the raw terminology data to be available in the data server).

Michael Lawley (Mar 16 2022 at 23:51):

In terms of optimisation, the FHIR (data) server can always (internally) compute the unique set of codes for Observation.code (which will be much smaller than the # unique Observation records) and then dynamically compose a ValueSet with these codes and the (compiled) VCL expression as an intersection resulting in a single call to the terminology server, and avoids the blowout in # of codes matching the unconstrained query. Also, if desired/needed, the set of unique Observation.code values could be maintained incrementally rather than being computed on-demand.

Josh Mandel (Mar 16 2022 at 23:51):

Thanks for the info on SCT non concept relationships!

For (1) some servers do ":in" today but don't have all the data or infrastructure in place to support more sophisticated queries. I'm thinking that the more we can support "raw terminology data" (with properties and relationships packaged and distributed in ways that facilitate querying "at the edge") in all kinds of FHIR services, the more choices server developers have about how to optimize.

Josh Mandel (Mar 16 2022 at 23:53):

I also agree with all the suggestions you're making about how to optimize the communication between a data server and a terminology server, when that architecture is in play. These seem like excellent techniques to have in the bag of tricks.

Michael Lawley (Mar 16 2022 at 23:58):

I think a key aspect is that if a server also has the relevant terminology data available locally (even for only some code systems), this approach is not really a stretch -- I'd probably limit the syntax to non-nested constraints in the first instance (since, as you say, most terminologies don't have intra-code system relationships), and then it would be pretty straightforward to turn into SQL with the main requirement being that you have parent-child edge and path (transitive closure) tables available if the code system has hierarchy.

Josh Mandel (Mar 16 2022 at 23:59):

Yes! This is exactly why I'm excited about the idea. It should not be overly ambitious and opens up quite a lot of expressive capability.

Josh Mandel (Mar 17 2022 at 03:08):

One other bit of semantics for RxNorm: relationships are described between atoms asserted by various sources and it would make sense to surface the "source" as a restriction on attribute queries. I.e. a way to request not just "any concept with property x having value y" but more specifically, "any concept with property x having value y as asserted by source z". (Syntactically this could use an optional "sab=" clause similar to the description filters in ECL taking optional clauses like "lang=" in {{term="", lang=""}}. But does FHIR CodeSystem have a way to assert such properties of properties?)

Michael Lawley (Mar 17 2022 at 14:48):

hah! FHIR Tx has a way to return subproperties (I think of them as grouped properties), but currently no way in the FHIR CodeSystem resource to specify such things.
SCT has them (for historical reasons its call "role grouping") and a server is supposed to know how to do this stuff (since its accepted that their isnt' a FHIR CodeSystem rendering of SCT).

I'm not really across RxNorm details, but I don't recall the rxnorm page saying anything about grouping a set of properties with another that is the source of their assertion. However, if one did follow this path, then ECL has syntax to suit with { and '}' to group the properties together (SCT and thus ECL doesn't actually care what the properties are "sub" of since it's always the same.

This property grouping idea also comes up in meds terminologies with multi-ingredient drugs and their associated ingredient strengths; you can't just say this thing has codeine and paracetamol and strength 50mg and strength 200mg. To resolve this in a FHIR CodeSystem for dm+d in the UK, Ontoserver (6.7.0, due end of the month) uses some extensions to capture the grouping . Hopefully in R5 we'll be able to add this as a 1st class capability.

So, these are not really properties of properties since that would be more like an association class, but it does result in a similar capability.

Conceptually it is like this:

{
  "code": "123",
  "display": "p 200mg + c 50mg",
  "property": [{
    "name": "status",
    "valueCode": "active"
  },{
    "name": "prop",
    "subproperty": [{
      "name": "ingredient",
      "valueCode": "codeine"
    }, {
      "name": "unit",
      "valueCode": "mg"
    }, {
      "name": "strength",
      "valueDecimal": 50
    }]
  },{
    "name": "prop",
    "subproperty": [{
      "name": "ingredient",
      "valueCode": "paracetamol"
    }, {
      "name": "unit",
      "valueCode": "mg"
    }, {
      "name": "strength",
      "valueDecimal": 200
    }]
  }]
}

and in your case you'd have each "x = y, source = z" assertion grouped in a subproperty. If a source was making multiple assertions then they'd all be in the same subproperty group.

Josh Mandel (Mar 17 2022 at 15:00):

Very interesting. Yeah, the UMLS (and RxNorm) have a top level notion of Concepts and Atoms, and the question is whether FHIR can or should account for atoms and their sources. Will try to make some time to play with all this.

Josh Mandel (Mar 21 2022 at 20:56):

It struck me that one other DSL we have is FHIRpath, and it could conceivably be bent into shape for things like (newlines added for clarity)

GET MedicationRequest?code:tx=
  Concept
  .where(terms.IN.matches('acetaminophen'))
  .select(rels.ingredient_of)
  .select(rels.constitutes)

i.e. "tell me all meds that have ingredients with tylenol in them", or whatever. Basic point being: there's a tree of Concepts each with terms, attrs, and rels as defined in an underlying terminology.

I made a quick demo of this at https://termquery-demo.fhir.me (note: this loads like 30MB into your browser and will probably run jankily because I have sqlite running in the UI thread ;-) -- you can link to a query by appending #).

Bottom line: this was a fun diversion and FHIRpath has some interesting expressive capabilities here; it's approachable for the things it covers, but nowhere near as sophisticated as SNOMED ECL.

Josh Mandel (Mar 21 2022 at 21:00):

Looking back at this thread, I think the "low hanging fruit" would be:

1. A publication format that makes it easier for servers to load common vocabularies and make use of terms, attributes, and relationships from them
2. Maybe a couple of standard modifiers on the token search param for simple jobs, like :tx-term that searches a token's terminology entries across all official terms, like MedicationRequest?code:tx-term=acetaminophen, and could specify prefixes to lock down term types or languages, like code:tx-term=BN|Tylenol. And a similar concept for attributes like code:tx-attr=RXTERM_FORM|Tab to look for tablets.

Michael Lawley (Mar 22 2022 at 03:49):

1. Isn't CodeSystem itself already such a publication format? It is, in fact, what we use.

Michael Lawley (Mar 22 2022 at 03:50):

2. Interesting, that would be a very stripped-down semantics. Perhaps something modelled on ValueSet.compose.include.filter like code:filter=[name].[op].[value] leading to code:filter=RXTERM_FORM.=.Tab(although this doesn't really address language-specific matching as you've suggested, and I'm not sure whether you can do that in a ValueSet compose anyway)

Josh Mandel (Mar 22 2022 at 04:53):

(1) I haven't seen how to publish large terminologies in CodeSystem with terms, attributes, and relationships included. It's possible this works; does someone host RxNorm, LOINC, and SNOMED in this format? (I was thinking formats that allow streaming processing would be preferable, but I don't think it's a strict requirement. http://tx.fhir.org/snomed/900000000000207008-20200731/?type=snomed&id=* seems to be broken at the moment and http://tx.fhir.org/r4/CodeSystem/snomedct?_format=json doesn't include concepts)

(2) it seems like detailed terms might just be absent from the FHIR models, or they're intended to be treated as a kind of property? The examples from (1) would help to clarify.

Kai Kewley (Mar 28 2022 at 08:39):

This SNOMED example from tx shows terms, attributes and hierarchical relationships https://tx.fhir.org/snomed/900000000000207008-20210731/?type=snomed&id=780128004
And a LOINC code with terms, attributes and categories https://tx.fhir.org/loinc/en-US?srch=60048-6
Doesn't look like RxNorm is on tx.

Rob Hausam (Mar 28 2022 at 11:13):

@Kai Kewley RxNorm version 20210208 is available on tx.fhir.org (example). Since it's now over a year old it needs to be refreshed (I'll plan to do that as soon as I have a chance).

Josh Mandel (Mar 28 2022 at 13:21):

In the snomed example, It looks like the UI is showing me this information but I don't know how to access it through the API. Is this information about concepts exposed directly? (For example https://tx.fhir.org/snomed/900000000000207008-20210731/?type=snomed&id=780128004 didn't include anything like a "see JSON" link.)

Josh Mandel (Mar 28 2022 at 13:25):

Of course there are FHIR servers that load and manage these vocabularies
My key questions for this thread are:

1. Is there a consistent way to distribute them for easy sharing/loading into any FHIR server
2. Can the FHIR search API provide ways to surface information from these terminologies in clinical data search

For (1) I haven't seen this commonly done, and I've made some proposals for discussion

For (2) I've submitted Jira issues to surface more terminology in information as standard/implicit "filters", but I think additional search modifiers are needed in order to surface these terminology filters in search

Michael Lawley (Mar 28 2022 at 21:59):

The problem with (1) is that a SNOMED distribution (RF2 SNAPSHOT) contains a lot more stuff than just the CodeSystem; it contains Reference Sets in various formats, and a whole pile of technical (meta)data that is 99% of the time[*] irrelevant to clinical / runtime use of SNOMED, and only of interest to tool developers supporting SNOMED authoring.

If you're a TX developer and want to support SNOMED properly (which you should), then you need to implement the implicit ValueSets, understand grouped relationships (subproperties in FHIR) and ECL, etc. For this you need the RF2 distribution.
If you're only going to do a limited implementation, then a transform similar to the approach you did for LOINC with sqlite into a FHIR CodeSystem will get you some of the way there (subproperties would require an Extension, as we've done here: https://ontoserver.csiro.au/docs/6/ext-subproperties-cs.html).

[*] made up stat

Grahame Grieve (Mar 30 2022 at 00:37):

I haven't seen how to publish large terminologies in CodeSystem with terms, attributes, and relationships included.

@Josh Mandel it's not necessary to actually publish them - the existing terminology servers make the data available as if they were published (it's an engineering question)

Grahame Grieve (Mar 30 2022 at 00:37):

the problem with all this approach is that we can do all sorts of super clever things on the terminology server side, but a search like this:

Grahame Grieve (Mar 30 2022 at 00:38):

GET MedicationRequest?code:tx={some clever syntax}&date=2022-01-01

Grahame Grieve (Mar 30 2022 at 00:39):

is really hard for a server. it needs to turn whatever syntax this :tx thing is into a list of codes - and the list may be infinite in size - and then join that in to the rest of the criteria

Grahame Grieve (Mar 30 2022 at 00:40):

that's why the syntax only supports value set - :in.

Grahame Grieve (Mar 30 2022 at 00:40):

so that servers can line this up in advance, and perform whatever optimisations they believe are needed in order to support this search

Grahame Grieve (Mar 30 2022 at 00:41):

None of this thread has convinced me that this is not an unreasonable trade-off. Particularly given that very few servers support :in as it is. Significantly increasing the complexity isn't going to help

Grahame Grieve (Mar 30 2022 at 00:42):

I didn't see anything in your thinking that couldn't be done with value sets as they are.

Grahame Grieve (Mar 30 2022 at 00:43):

my own server maintains a join table in the background, and a robot that iterates through the observed codes and the observed value sets asking the terminology server whether the code is a member of the value set using $validate-code, and then it can join across that table as part of it's other queries.

Josh Mandel (Mar 30 2022 at 01:13):

is really hard for a server. it needs to turn whatever syntax this :tx thing is into a list of codes - and the list may be infinite in size - and then join that in to the rest of the criteria

Right -- my assertion is that there's a common set of property based search functionality that would enable diverse use cases and could be fueled by publishing data in consistent and reasonably complete format. This pattern could work with or without a dedicated/distinct "terminology server".

Effectively these capabilities are shy of the needs that terminilogy developers might have, but similar to the use cases we already know how to index using search parameters on regular old FHIR resources. Indeed we are seeing groups like DaVinci Drug Formulary inventing FHIR resources just for this purpose, because there's no reliable access to terminology properties in search.

To be clear, I quickly swung away from proposing a very expressive search functionality like SNOMED ECL, in favor of proposals that are based on simple property filters.

Grahame Grieve (Mar 30 2022 at 01:17):

I don't believe that there's a sweet spot

Josh Mandel (Mar 30 2022 at 01:18):

None of this thread has convinced me that this is not an unreasonable trade-off. Particularly given that very few servers support :in as it is. Significantly increasing the complexity isn't going to help

I think you have one too many negatives there ;-)

I'm suggesting that publishing terminology data in an interoperable format that's aligned with fhir's terminology features lowers the implementation bar for servers or anyone else that wants to "do more" with terminologies. The fact that many (most?) severs today don't support :in even ok on simple terminologies is a symptom of the problem, and we should be offering anything we can to give severs pathways to successful implementation.

Josh Mandel (Mar 30 2022 at 01:18):

If there's no sweet spot, do you think we should just encourage IG developers to design more "terminology proxy" resources to index the properties they care about?

Grahame Grieve (Mar 30 2022 at 01:19):

for servers or anyone else that wants to "do more" with terminologies. The fact that many (most?) severs today don't support :in even ok on simple terminologies is a symptom of the problem

yes, though at least part of it is legacy, and around division of labor on the server and the dev teams

Grahame Grieve (Mar 30 2022 at 01:20):

your minimal syntax will never be enough until it's too much. You need at least intersections and unions of filters

Josh Mandel (Mar 30 2022 at 01:55):

So again, do we just embrace/encourage the use of domain specific resources to act as termination caches (per Da Vinci Drug Formulary)? They don't seem to require intersection or union FWIW.

Grahame Grieve (Mar 30 2022 at 01:58):

not generally, though I could speak in favour of that particular approach. For the big terminologis we will inevitably define resources

Rxnorm = MedicationKnowledge
LOINC = ObservationDefinition
SCT (Clinical arm) = ConditionDefinition

you can build a set of the resources from the terminology, and there's reasons why that's a solid arrangement, since everyone has their own formulary, observables, and condition predicates that build on and extend beyond the underlying code systems

Grahame Grieve (Mar 30 2022 at 01:58):

I have spoken on this repeatedly and walked though the logic with, for instance, NLM RxNorm team

Grahame Grieve (Mar 30 2022 at 01:59):

but that doesn't mean we are generally in favor of it, or that I agree with what the project has done

Josh Mandel (Mar 30 2022 at 02:01):

Hmm, I'm not sure I understand your position. But I'm confident that not every terminology will fit neatly into these resource types (e.g., your parenthetical on SNOMED above), so we'll have more and more resources and profiles to contend with as we travel down this path.

Grahame Grieve (Mar 30 2022 at 02:03):

yes agree with that

Josh Mandel (Mar 30 2022 at 02:06):

In any case, I have more humility about this topic than I'm letting on here :) I just want to make sure we're giving FHIR servers (and their users) a chance to take advantage of the incredible amount of knowledge that gets poured into terminology development.

Grahame Grieve (Mar 30 2022 at 02:06):

going back to the start of the thread... they created a 'FormularyDrug' resource - though why they wouldn't use that resources we already had defined, I don't know. I hope that's been discussed with Pharmacy WG ( #Medication).

But I did want to ask back when I read the start of the thread: why do you think that the formulary is limited to RxNorm? that seems like a clear problem in your approach to me

Josh Mandel (Mar 30 2022 at 02:09):

Formulary Drug is a profile on Medication Knowledge (looking back: I did call this out when introducing the topic, but I can see it may have gotten lost) -- so that's reusing the existing resource, just with use case specific profiles, no?

Josh Mandel (Mar 30 2022 at 02:09):

Re: RxNorm, it doesn't have to be limited but it currently is specified that way.

Josh Mandel (Mar 30 2022 at 02:10):

https://build.fhir.org/ig/HL7/davinci-pdex-formulary/StructureDefinition-usdf-FormularyDrug-definitions.html#MedicationKnowledge.code.coding:semantic-drug

Josh Mandel (Mar 30 2022 at 02:12):

Specifically they want to ensure that each formulary item is indexed for search based on RxNorm SBD/SCD/BPCK/GPCK designations as well as dose form.

Grahame Grieve (Mar 30 2022 at 02:17):

so can't use local drugs?

Grahame Grieve (Mar 30 2022 at 02:18):

so I don't think it's that bad an approach then

Lloyd McKenzie (Mar 30 2022 at 02:35):

I believe that's changing. FormularyDrug isn't about the Medication, it's about the formulary information for a drug for a particular type of insurance. It's a "joining" structure.

Josh Mandel (Mar 30 2022 at 03:17):

The current design has a FormularyItem specifying the policy details (coverage, price tiers, etc), and that points to a FormularyDrug that acts as a search index for terms/properties that exist in RxNorm, to facilitate querying for FormularyItems.

Grahame Grieve (Mar 30 2022 at 04:31):

that's... not what I expected. (I was going to say weird, but that's not the same)

Davera Gabriel (Apr 04 2022 at 14:27):

Hello All ... We have discussed this thread in both the Vocab Working group and TSMG calls over the past few days and agree with @Robert McClure that this would be a very good breakout topic for the upcoming May Connectathon. I am eyeing 7-8p Tuesday 5/3 to schedule this discussion. @Grahame Grieve @Michael Lawley @Josh Mandel @Lloyd McKenzie are you gentlemen available to attend a breakout on this topic at that time? Please advise & Thanks! Davera

Lloyd McKenzie (Apr 04 2022 at 14:55):

Tuesday night doesn't work well for me. I might be able to make the first 30 minutes.

Davera Gabriel (Apr 04 2022 at 16:20):

Lloyd McKenzie said:

Tuesday night doesn't work well for me. I might be able to make the first 30 minutes.

@Lloyd McKenzie would the prior hour work for you? Will also see what our other discussion members have to say...

Lloyd McKenzie (Apr 04 2022 at 16:25):

It would work better.

Michael Lawley (Apr 05 2022 at 02:19):

That would be 8am UTC+10 I think which works for me

Davera Gabriel (Apr 10 2022 at 18:40):

Hello All:
I have scheduled a breakout session in the May Connectathon Terminology Services track on Tuesday 5/2, from 6-7:30p entitled "Terminology Queries & Representation Syntax" and have tagged @Lloyd McKenzie @Michael Lawley @Josh Mandel and @Grahame Grieve as leading the discussion.

The following is the session description: "The need to expose a common general hierarchical and filter-based query syntax for use in defining value sets and performing inline queries has come up yet again as evidenced by a recent Zulip chat in the Terminology stream. This session aims to provide a real-time discussion of the topic, and identify the next steps to resolution."

Please suggest any alternative text for the description & If I have abused your time / schedule @Grahame Grieve & @Josh Mandel by indicating you will help led this discussion - my apologies, and I'm happy to remove this designation.

Does this work for everyone?
Cheers
Davera

Lloyd McKenzie (Apr 10 2022 at 19:53):

I'm not sure I'm essential for the discussion, but will do my best to be there.

Davera Gabriel (Apr 10 2022 at 20:32):

Lloyd McKenzie said:

I'm not sure I'm essential for the discussion, but will do my best to be there.

@Lloyd McKenzie I do not have to list you as a lead if you'd rather not I not do that :)

Michael Lawley (Apr 10 2022 at 22:35):

Er, Tue 3rd May?

Josh Mandel (Apr 11 2022 at 02:31):

And what time zone?

Michael Lawley (Apr 11 2022 at 02:42):

I've been working on "Eastern" (and hoping that no daylight saving changes happen before 3/5 (or 5/3 ;-)

Last updated: Apr 12 2022 at 19:14 UTC