Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discuss how to handle measurement_detail string and concept id use #102

Open
markdanese opened this issue May 22, 2017 · 2 comments
Open

Comments

@markdanese
Copy link
Contributor

Should we use concept ids for results? Should they be used only for string results (i.e., string is the source value that goes with concept id)?

@markdanese
Copy link
Contributor Author

If a data source uses LOINC, it is likely that the data will have a LOINC code for the "question" and the "answer" (result). In that case, we would need to use a concept id for both. Hence, we need "result_as_concept_id". So, there are 3 ways we can report a result (numeric value, string, and concept id). We should only have one of the 3 completed on each row. Strings should not be interpreted as a description field for the concept id. If we want to report a source value for the concept id, we can do that. It would give us a way to use a code for the result and also include a text string.

@markdanese
Copy link
Contributor Author

leaving open until we decide whether to include a "result as concept id source value" field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant