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

Consider adding "CUI" date format to the API as an additional response parameter #199

Open
pacharanero opened this issue Nov 29, 2023 · 1 comment
Assignees
Labels
design-decision An issue that documents a past, present or future design decision in the project feature-request New feature or request nice-to-have A feature which would be nice to have but is not essential not-mvp

Comments

@pacharanero
Copy link
Member

In discussions with some implementers it has become clear that some wish to use "NHS Common User Interface" style dates:

YYYY-MMM-DD (where MMM is a three-letter Month name, not a number, for example 'AUG'). The advantages of this are said to be that it is virtually impossible to misinterpret the Month for Day of Month. Compare with other common date formats such as DD/MM/YYYY within which it's quite easy to get confused with MM/DD/YYYY (American date format). In this regard it could be said that the CUI date format is 'human-friendly'

Currently we use ISO8601 date format which has the advantage of being very 'computer-friendly' in that it is trivial using standard date libraries to convert to and from ISO8601 dates. Whereas converting to and from CUI dates may be harder and potentially less easy to validate in both directions.

I stressed to all stakeholders that although this could be implemented in the API, the actual place the implementation needs to be done is in the implementer's client application. So although we can and will consider adding this feature as a 'convenience' to the API response, it is NOT the whole story and I was very careful to request that we have a proper technical discussion with implementer-side developers to ensure that we are not being asked to chase a spurious 'NHS DTAC Project Manager Jobsworth Requirement' which they have not fully understood but intend to fully demand.

@pacharanero pacharanero self-assigned this Nov 29, 2023
@pacharanero pacharanero added feature-request New feature or request design-decision An issue that documents a past, present or future design decision in the project nice-to-have A feature which would be nice to have but is not essential not-mvp labels Nov 29, 2023
@pacharanero
Copy link
Member Author

This is the original text from the team which requested this change, for reference:

"....would it be possible to have a change to the “Date of measurement”. It currently shows as yyyy-mm-dd, whereas the standardised date format used by DHCW is dd-Mmm-yyyy, eg 02-Apr-2023. (We have had some instances where clinicians from the US have confused the date when it is solely in number format eg, 05-01-2023 is being read as being 1st May hence why the month needs to be in letters). Is there any possibility that this could be changed within the API Results table by Marcus or Simon?

We are also aware that the date format is in number too on the tooltips, reading as dd/mm/yyyy. Again for the same reason as above, would it be possible to have the format changed on these to dd-Mmm-yyyy?"

To implement this it would require changes across

  • Python package (to return CUI date in the Measurement return object)
  • React Client (to add CUI date to some UI elements)
  • React Component (to add CUI date to tooltips)

I don't think this is necessarily something we should prioritise, but it's here just to think about and plan around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design-decision An issue that documents a past, present or future design decision in the project feature-request New feature or request nice-to-have A feature which would be nice to have but is not essential not-mvp
Projects
None yet
Development

No branches or pull requests

1 participant