This repository has been archived by the owner on Jan 9, 2023. It is now read-only.
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.
feat(imaging): link image with visit #2309
feat(imaging): link image with visit #2309
Changes from 2 commits
553011a
3db29b7
001cf12
7ecf581
e2a6b2a
5b8ec7e
daff902
37a309c
0278f76
bf14f0e
04d67fd
68adcb5
9c34af0
38962fa
d6de3bb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
this should store patient id rather than the patient full name
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.
If this store as patient id, the
patient
field on the table in requested imagings page would display its patient id instead of full nameThere 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 the label should be something like
${visitType} at
${startDateTime}or
${visitType} (${startDateTime)}`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.
do the visits need to be a state variable? seems like we could just reference
patient.visits
wherever we use the visits.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 believe we need the visits to be a state variable. Because we can only fetch the visits data inside the
onPatientChange
method using the patient parameter (as we fetch the patient using this lineonSearch={async (query: string) => PatientRepository.search(query)}
). Using state variable ensures that the visits data will be re-rendered whenever the patient field value is changed.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.
Just curious why we decide to add Visit here? Aren't we already looking at Visit* fields? if we have to do it for one should we maybe not also do it for all of them? i.e. Visit Start Date, Visit End Date etc for consistency? Also not sure if this is related to the issue that this PR is meant to be addressing? I stand corrected should it be.
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.
What I was originally thinking is to create a translation key for the visit type so that it can be used in the new request imaging page
<div className="visits"> {newImagingRequest.patient && visitOption ? ( <SelectWithLabelFormGroup name="visit" label={t('patient.visits.type')}
Maybe it will make more sense to create a new translation key in the imaging locale index.ts file to prevent some confusion. What do you think?
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.
You can keep the translation key in patients since visits are part of the patients module. Maybe just call it Visit rather than Visit Type because visit type makes me think (outpatient/inpatient/emergency etc) where here we are giving the user a list of all visits for this patient regardless of the type of visit it is, what do you think?
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.
On it