Hi Ben,

The fields that are defined in the assay provider (in the results.xml file, for example) are currently considered locked and can't be edited by the user. Unfortunately for this scenario, since they're snapshotted at assay definition creation time, even if you update the definition in the file within your module, your design won't be affected. We don't have a good solution for this right now. There's a possibility of direct database fixup. Would changing to use a lookup work with the existing values that are stored on the assay side, or would they need to be translated to the lookup target's primary key?

Thanks,
Josh

hi josh,

knowing that DB fix might be useful. at this stage the assay in question are in sort of a beta phase so it's inconvenient to delete/re-create them i guess that's ok.

in this situation they are not related to the primary key, but I will be aware of situations in which it might. the fact that deleting assay records requires a convoluted batch update method (ie. new values for primary keys) makes me wary of anything linked to those.

applying superficial metadata (ie. not datatype, but things like lookups, format string, etc) using query metadata might be a reasonable route if that would work here.

for what it's worth, i ended up creating a standalone postgres schema called 'lookups' with hard tables that will house the tables used for most EHR lookups. I didnt see any real benefit in using labkey lists and it's a lot easier to sync this between servers. this is convenient b/c I can add the same schema to multiple folders as needed.