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

(chore) O3-2120: Move OpenMRS ID patient search identifier to defaultIdentifierTypes #1061

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Original file line number Diff line number Diff line change
Expand Up @@ -123,13 +123,7 @@ const CompactPatientBanner = forwardRef<HTMLDivElement, CompactPatientBannerProp
{getGender(patient.gender)} <span className={styles.middot}>&middot;</span> {age(patient.birthDate)}
<span className={styles.middot}>&middot;</span>
{config.defaultIdentifierTypes.length ? (
<>
{patientIdentifiers.length > 1 ? (
<DefaultIdentifiers identifiers={patientIdentifiers} />
) : (
<FallbackIdentifier patient={patients[index]} identifierName={config.defaultIdentifier} />
)}
</>
<DefaultIdentifiers identifiers={patientIdentifiers} />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the configuration still specifies no patient identifiers? It seems like we still need some fallback here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ibacher how do you suggest we handle this callback, given that from the previous implementations it was checking for a static string OpenMRS ID if it existed in the patient identifiers

const FallbackIdentifier: React.FC<CustomIdentifierProps> = ({ patient, identifierName }) => {
  const identifier = patient.identifiers.find((identifier) => identifier.identifierType.display === identifierName);

  return identifier ? <IdentifierTag identifier={identifier} /> : null;
};

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@usamaidrsk Technically, it's checking for a user-configurable value, identifierName, right? I'm not sure there's a saner implementation than that. Maybe if that's also unset we could look for the preferred identifier?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically, it's checking for a user-configurable value, identifierName, right?.

Yes it is a configurable value, which makes it not safe.

I do agree with the idea of the preferred identifier, how do we get to it
cc @ibacher

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a property of patient.identifiers or available as one (if it's excluded via a custom representation).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have pushed an updated respective to that.
cc @ibacher

) : (
<>
<span className={styles.middot}>&middot;</span> {patients[index].identifiers?.[0]?.identifier}
Expand Down
11 changes: 5 additions & 6 deletions packages/esm-patient-search-app/src/config-schema.ts
Original file line number Diff line number Diff line change
Expand Up @@ -44,12 +44,11 @@ export const configSchema = {
_description:
'A list of identifier types to be displayed in the patient search results as banner tags. If no defaultIdentifierTypes are provided, the defaultIdentifier will be displayed.',
// These values correspond to the Patient Clinic Number and National Unique Patient Identifier (NUPI) identifier types respectively
_default: ['b4d66522-11fc-45c7-83e3-39a1af21ae0d', 'f85081e2-b4be-4e48-b3a4-7994b69bb101'],
},
defaultIdentifier: {
_type: Type.String,
_description: 'Identifer type to be displayed when no defaultIdentifierTypes are provided. Default is OpenMRS ID.',
_default: 'OpenMRS ID',
_default: [
'b4d66522-11fc-45c7-83e3-39a1af21ae0d',
'f85081e2-b4be-4e48-b3a4-7994b69bb101',
'05a29f94-c0ed-11e2-94be-8c13b969e334',
],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we shouldn't be hardcoding any identifier uuids here but this should come from the ref app configuration, but I know there's not agreement on that (and that this is existing code, not a change introduced as part of this code)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mogoodrich for the feedback.
The only uuid introduced is one for the OpenMRS ID, that's the last in the list.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the other identifiers then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, these first two identifiers are Palladium-specific. Those are the Patient Clinic Number and the NUPI number. They should be provided via distro configuration instead of being hardcoded in the Patient Search config schema. @donaldkibet, can @usamaidrsk proceed to remove them from here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the config file there is this comment, for the first two.

These values correspond to the Patient Clinic Number and National Unique Patient Identifier (NUPI) identifier types respectively

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @denniskigen ! In fairness to @usamaidrsk looks like those two identifiers constants existed prior to this PR, but if they are implementation-specific, they definitely should be removed as defaults. @donaldkibet

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks right @mogoodrich

},
};

Expand Down