Bug in /browser/{branch}/descriptions?

[eirikconteir]

I don't if it's a bug or by design, but this endpoint returns inactivated refset members when the parameter conceptRefset is defined. For me, this was not expected.

The endpoint has two active parameters: active (for the description) and conceptActive. Would it be useful to have a third one; refsetMemberActive? Or just leave out inactivated members?

I'm not quite sure, but now I have to force a delete of the member (instead of deactivate) in order to get the implementation right.

Best,

Eirik

[rorydavidson]

Hi @eirikconteir, this is designed to return all members of a refset (inactive and active) on purpose. It might be easier if you could tell us what you are trying to do? We would not expect to use the description endpoints to retrieve refset members.

[eirikconteir]

Thank you, @rorydavidson . We're using this endpoint in several applications. The implementation is typical a search field where clinicians search for a clinical term. The search is always limited, and search only within a defined population (e.g. subsets for diagnoses, symptoms and complaints within primary care).

These subsets, of course, change over time. New members are added and other members are deactivated.

In the current state state the endpoint doesn't give us the opportunity to filter out the deactivated members. A workaround is of course to force a delete. But the side effect is loss of historical data.

[rorydavidson]

Hi @eirikconteir , you should look to use the /GET /{branch}/concepts endpoint. The descriptions endpoint is not one we would recommend using in most contexts.

On the concept find end point, there are filters which are more than likely going to meet most of your requirements in a single API call. You can search by term, and you can use ECL to restrict the search scope (including by reference set membership as active concepts), amongst other things.

I would recommend having a look at that endpoint and seeing if that will help.

[jmidtgaa]

Hi @rorydavidson,

The use case is also including the browser user experience. The expected behaviour from my point of view is when you do a search; you set if you want inactive content or not. Default is only active content.

When you do a search, and want to use the postfiltering on a refset. The result I would expect to only get the active members not any historical members, when I'm searching only active content. (even if the concept still Is active it isn’t part of the refset, due to inactive member)

Best regards, Johannes

[kaboyles]

@eirikconteir , which exact endpoints are you using? You mention descriptions, but then discuss RefSets as well. So just want to be clear.

Thanks, Kim

[kaicode]

I would expect a refset member search to be able to return inactive refset members. But when searching for descriptions, filtered by the concept's refset membership, I would not expect descriptions to be returned when the concept is no longer a member of the refset. When the refset member is inactive we consider the concept to no longer be a member of the refset.

This /browser/{branch}/descriptions endpoint was designed to drive the public browser and the filtering of search results. In the case of the conceptRefset parameter when a user selects one of the "Filter results by Refset" options in the left panel then the search results should be filtered down to just include the concepts that are in the selected refset.

If Snowstorm is returning concepts and descriptions where the concept is no longer a member of the refset then I would consider that a bug. I don't think any user would want or expect that.

Do we know of any examples of this behaviour for further analysis? Active concepts are not removed from refsets very regularly.

[eirikconteir]

Thank you, @kaicode !

Actually we do deactivate refset members from time to time. It's part of the refinement of our national reference sets.

This is an example from the Norwegian GP subset with map to ICPC-2. The concept Ear problem is still active, but it's removed from the refset (it's too general to make clinical sense).

As you can see here, the concept is still returned

http://demo.terminologi.ehelse.no/snowstorm/snomed-ct/browser/MAIN%2FSNOMEDCT-NO%2FREFSETS/descriptions?term=ear%20problem&active=true&conceptActive=true&conceptRefset=68101000202102&groupByConcept=true&searchMode=STANDARD&offset=0&limit=50

[eirikconteir]

(... and here you can see the membership is deactivated: http://demo.terminologi.ehelse.no/snowstorm/snomed-ct/MAIN%2FSNOMEDCT-NO%2FREFSETS/members?referenceSet=68101000202102&referencedComponentId=300197009&offset=0&limit=50 )

[kaboyles]

@kaicode thoughts?

Thanks, Kim

[kaicode]

Thanks for the examples. I have raised a ticket for triage internally. I have asked someone from the technical team to check that our thinking is aligned before proceeding further.

[kaicode]

This has been confirmed as a bug and is now being tracked internally as INFRA-12126.