The endpoints above are for fetching expression definitions from the server. The endpoints for expression and items looks a bit strange since they look like they are returning the same information, but in any event, those are just definitions.
The endpoint for resolving a concept set expression is by POSTing the expression and you will get back all the concepts that will be selected (both descendants and mapped) via /WebAPI/vocabulary/{SourceKey}/resolveConceptSetExpression. This call is simply to return the concept IDs that will be selected from your concept set expression. if you have selected ‘mapped concepts’ or if you’ve directly included non-standard concepts, you’ll get them back in this query because the query is just about resolving the expression to the included concepts. Note: this only returns conceptIDs, you then use the /lookup/identifiers to resolve the list of conceptIDs to the full-fledged concept objects.
Separately, there is endpionts for getting mapped concepts based on a set of concept IDs: /WebAPI/vocabulary/{sourcekey}/lookup/mapped which takes a set of conceptIDs and returns those concepts that have mapped to relationships. Again, you only get concept IDs from this query, you would need to call the /lookup method to resolve the IDs to full concept objects.
You can see these things in action if you go tot he concept set tab under the cohort definition, select a concept, and look at the code behind the ‘included concepts’ and included source codes.
After giving this a lot of thought, I think it would be great to have an end point that returns an array (set) of standard concepts, after resolving a concept set expression.
The api end point or end points needs to do the following.
Resolve a concept set expression to an array of concept id’s.
If the resolved concept id’s are non standard, then cross walk them to standard concept id’s.
Return an array of standard concept ids with crosswalk where needed.
Current endpoint for mapped concepts, does not allow for passing an array of concept-ids
Method/Function that crosswalks an array of concept ids within a concept set expression to Standard concept ids
· Example URL: [baseURL]/WebAPI/vocabulary/standardizeConceptSet/
· POST request body: a concept set JSON object containing non-standard concept ids or a combination of both non-standard and standard
· Response: standard concept ids mapped from the concept ids from the concept set.
I agree. This is something that would be useful. From a user point of view within Atlas, it would be great to select codes that I’m used to and have Atlas suggest the standard codes that I should use.
Agreed! It’s much easier than finding the concept_code > concept_id in the Concept table, transversing the Concept Relationship with a look up to the Concept table to obtain the standard concept ids. Also, this UX enhancement may encourage people to use the standard concepts more often by #1 handing them a standard concept set from the input of non-standard concepts (keep the non-standard concept set option, too) and #2 providing the difference in RC from a source ICD concept set to a standard SNOMED concept set. Granted, this isn’t the most accurate way to compare (#s can remain the same while the included persons may change), it will let users know if there is a large difference between the two.
Totally agree with the above. We had multiple case where we supported researchers who preferred (with reason) to define their concept sets in e.g. ICD10. An ‘Include Maps to’ button besides the existing ‘Mapped from’ button would be a great extension. (although it would be supporting ‘bad habits’ ;))
