OHDSI Home | Forums | Wiki | Github

Standard from non standard using API endpoint

@Chris_Knoll

Please see http://www.ohdsi.org/web/atlas/#/conceptset/1718587/details
Input is a non-standard code. In concept-set expression, ‘mapped’ is selected.

The relevant API end points are
1. API endpoint that returns header information
http://api.ohdsi.org/WebAPI/conceptset/1718587

{"id":1718587,"name":"Non standard to standard crosswalk  (NDC to RxNorm)"}

2. API endpoint that returns concept set expression
http://api.ohdsi.org/WebAPI/conceptset/1718587/expression

{"items":[{"concept":{"CONCEPT_ID":45111557,"CONCEPT_NAME":"valacyclovir 1000 MG Oral Tablet","STANDARD_CONCEPT":"N","INVALID_REASON":"V","CONCEPT_CODE":"00093725998","DOMAIN_ID":"Drug","VOCABULARY_ID":"NDC","CONCEPT_CLASS_ID":"11-digit NDC","INVALID_REASON_CAPTION":"Valid","STANDARD_CONCEPT_CAPTION":"Non-Standard"},"isExcluded":false,"includeDescendants":false,"includeMapped":true}]}

3. API endpoint that return the concept items
http://api.ohdsi.org/WebAPI/conceptset/1718587/items

[{"id":1718589,"conceptSetId":1718587,"conceptId":45111557,"isExcluded":0,"includeDescendants":0,"includeMapped":1}]

Similarly, is there a way to obtain the mapped standard concepts? If there is no API end-points, can OHDSI R-tools do it?

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.

1 Like

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.

  1. Resolve a concept set expression to an array of concept id’s.
  2. If the resolved concept id’s are non standard, then cross walk them to standard concept id’s.
  3. 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.

can OHDSI R-tools do it?

I have R code that takes all Athena vocabulary and uses R functions that help in mapping NDCs.

Not all my code is posted. But some of it is here: https://github.com/vojtechhuser/Athenian

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.

1 Like

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.

1 Like

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’ ;))

1 Like
t