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

621: Order/Result Linking Fields Added to Metadata Table #983

Merged
merged 1 commit into from
Mar 28, 2024

Conversation

halprin
Copy link
Member

@halprin halprin commented Mar 27, 2024

Order/Result Linking Fields Added to Metadata Table

Added new columns to the metadata table to support our order and result linking.

Issue

#621.

Copy link

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

Copy link
Contributor

@basiliskus basiliskus left a 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)
Copy link
Contributor

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)
Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Member Author

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.

@halprin halprin changed the title Order/Result Linking Fields Added to Metadata Table 621: Order/Result Linking Fields Added to Metadata Table Mar 28, 2024
@halprin halprin merged commit eee8c35 into main Mar 28, 2024
15 checks passed
@halprin halprin deleted the story-621-metadata_db_migration branch March 28, 2024 19:47
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

Successfully merging this pull request may close these issues.

3 participants