-
Notifications
You must be signed in to change notification settings - Fork 9
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
621: Order/Result Linking Fields Added to Metadata Table #983
Conversation
Quality Gate passedIssues Measures |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple of comments on the maximums for the fields, otherwise looks good to me
type: varchar(427) | ||
- column: | ||
name: sending_application_id | ||
type: varchar(227) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
227 seems a little high for these ids. Do we think it's possible for them to be over 100 characters?
columns: # the size of the varchars below are based on the field's HL7 spec size | ||
- column: | ||
name: placer_order_number | ||
type: varchar(427) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
427 seems high, do we expect for the placer order number to take a lot of space?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think his comment on 96 is that he's basing it on the HL7 spec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I missed that. This is an open question, but should we always use the maximum from the HL7 specs for these database fields if they seem unusually high? We could also consider using the text
data type which doesn't specify the max
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the placer_order_number
, I used this: https://hl7-definition.caristix.com/v2/HL7v2.5.1/Fields/ORC.2. Add up all of the fields and then add three for the ^
separators.
For the other four, I used this: https://hl7-definition.caristix.com/v2/HL7v2.5.1/Segments/MSH.
You can see that there is a lot more than just the ID in that documentation. There's also the namespace stuff. Do we think that is also important to capture?
I'm open to reducing the size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll only store ORC-2.3
there, but we can confirm that with Daniel. In any case, it's not a big deal and we can adjust it later if we decide on that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Talked with the SMEs.
For the MSH headers, the important fields are the first two. So 20 + 199 + 1 = 220.
For the ORC placer order number, the important fields are the first three. So 199 + 20 + 199 + 2 = 420.
But here's the thing: the last field is so small that I might as well include it.
Realistically, I can see the full size not being taken up, but I'd hate to truncate if, by chance, the message includes a full size field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, I'll merge this PR since I have an approval. As @basiliskus states, if we need to change them later on, we will.
Order/Result Linking Fields Added to Metadata Table
Added new columns to the
metadata
table to support our order and result linking.Issue
#621.