@mik – Thanks so much for your willingness to entertain proposals. This is on my to-do list.
Some initial half-baked thoughts:
-
The API should support bi-temporal versioning. That is, the ability to
REST get
concepts from the API based on their valid start/end dates or based on their repository create/update dates. We should also be able to query based on the ATHENA version number, once a system has been established. -
I think the JSON object for a given concept should include its associated records in the other OMOP vocabulary tables, like
concept_relationship
,concept_ancestor
, etc. -
I think there is an opportunity to replace the
domain
,vocabulary
, andconcept_class
physical tables with database views. Why? Because every record in these tables also has a one-for-one corresponding record in the OMOPconcept
table. (Yes, these records are stored twice!) Reducing the number of physical vocabulary tables would greatly simply an ATHENA RESTful API, with no loss of functionality. -
At one point, I also questioned whether the
concept_ancestor
table could be merged withconcept_relationship
(as long as therelationship
records were defined appropriately). I must confess I haven’t had the change to parse @Dymshyts’s response in detail to understand the nuances (Missing RxNorm mappings for cholesterol medications).
More to come…