Define ORM objects for EMIS v2 observations and medications tables#2736
Closed
Define ORM objects for EMIS v2 observations and medications tables#2736
Conversation
We will be asserting more definitions within this test, so rename it `test_schema` and lightly refactor the imports and variable names.
Connecting to the EMIS staging environment via SQLAlchemy revealed that: - `patient_id` is defined as `VARBINARY` without a specified length. Previously 16 was assumed based on the example value provided by Optum, but it seems safer not to assume a specific length. - `date_of_birth` uses the Trino `TIMESTAMP` type rather than SQLAlchemy's `DateTime`. Use the types obtained from the staging environment instead. I chose the `trdt` shorthand for `trino.sqlalchemy.datatype` somewhat arbitrarily, but it seems distinct enough from `t` and not too long to be cluttering in the file. Note that I was unable to obtain primary key / foreign key information from connecting to the staging environment. I have nonetheless kept the `unique` constraint on `patient_id` since the schema spreadsheet provided by Optum indicates that this is a unique identifier.
- Types were obtained from connecting to the EMIS staging environment via SQLAlchemy. - Test values used were adapted from the excel sheet provided by Optum, except for the binary patient_id which is `bytes(range(16))` for clarity. - Tables are ordered alphabetically to be consistent with the TPP schema file. - This commit does not include the `consultation_id` column in the two tables; the next commit will do so.
We might decide in the future to use the datetime of the consultation as the effective datetime for the observation and medication issue records. Add a consultation schema to allow for this possibility. Note that I was unable to obtain primary key / foreign key information from connecting to the staging environment. I have nonetheless used a `unique` constraint on `consultation_id` since the schema spreadsheet provided by Optum indicates that this is a unique identifier.
Contributor
Author
|
Discussed on Slack: moving the bit for the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2725.
The schemas were added semi-manually in that column types were obtained via connecting to EMIS's staging environment, and cross-referenced with the spreadsheet provided by the Optum team.
The types were obtained by extending @rebkwok's jupyter notebook and adding a cell that pulls out the columns using
sqlalchemy.inspect(engine).get_columns(schema=schema, table_name=table_name).The cell's code is here, where the
schemaandtable_namesused for this extraction were"explorer_open_safely"and['patient','medication_issue_record', 'observation','consultation']respectively.I leave it up to the reviewer of this PR to decided whether to review the code snippet as well: I think it is reasonable to choose to only review the added schema definitions themselves, which I have checked to be consistent with the information in the spreadsheet linked in the ticket.
Based on this slack conversation about the possibility that we might use consultation datetime for medications and observations instead of the
effective_datetimevalues on the tables themselves, I have added a commit that defines the consultation ORM object as well.