Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Ability to create a patient when adding a related person that does not exist #2106

Open
jackcmeyer opened this issue May 29, 2020 · 16 comments
Assignees
Labels
core-team indicates that the issue will be completed by a core team member critical indicates that the issue/pull request needs to be urgently worked on 🚀enhancement an issue/pull request that adds a feature to the application help wanted indicates that an issue is open for contributions in progress indicates that issue/pull request is currently being worked on LOE - medium indicates that the level of effort to complete issue is medium needs clinical feedback needs requirements indicates that an issue needs more requirements in order to be worked on patients issue/pull request that interacts with patients module
Projects
Milestone

Comments

@jackcmeyer
Copy link
Member

🚀 Feature Proposal

When creating a Related Person, it assumes that the patient that you want to add as a related person already exists. If the related person does not exist, it is cumbersome to exit the related person modal and go create that patient, then come back to finally add the related person.

Users would like the ability to have some sort of "quick add" that allows me to create a new patient without leaving the related person modal.

Motivation

Be able to quickly add related persons that aren't currently existing patients.

@jackcmeyer jackcmeyer transferred this issue from HospitalRun/hospitalrun May 29, 2020
@jackcmeyer jackcmeyer added help wanted indicates that an issue is open for contributions LOE - medium indicates that the level of effort to complete issue is medium patients issue/pull request that interacts with patients module 🚀enhancement an issue/pull request that adds a feature to the application labels May 29, 2020
@jackcmeyer jackcmeyer added this to To do in Version 2.0 via automation May 29, 2020
@jackcmeyer jackcmeyer added this to the v2.0 milestone May 29, 2020
@WaseemAlkurdi
Copy link

Example scenario: Let's take the context of a fertility/family planning clinic, where the doctor is creating an entry for an example patient John Doe:
image

That John Doe is married to Jane Doe, who should share the same record, as the clinic's context needs that . Currently, we have to create a separate entry for her:
image
then we would have to search for John Doe's record, open it, select Related Persons from there, Add Related Person, then search Jane Doe and select her as Wife. (The "Patients List" page didn't work at the time of posting this, but I will update with screenshots once it becomes available again).

In addition to being cumbersome and very anti-HospitalRun, this approach simply won't work in a fertility clinic, where a couple, not an individual patient, is the focus of the diagnosis and treatment.
Currently, the changes to one person's record would not automatically propagate to the other person's, as the database would consider them as separate patients who just happen to be related. But, as we have seen, this might not be wanted in an obstetrics/gynaecology/fertility/family practice, among others.

A solution would be to move Related Persons to the Add Patient page, where the doctor would be able to enter both John Doe and Jane Doe's details at once, then it would offer the user a checkbox to "join" records (like in the case of a fertility clinic), or leave them detached.

@JDarke
Copy link
Contributor

JDarke commented Jun 1, 2020

I'd like to take a shot at this one, please.

@fox1t
Copy link
Member

fox1t commented Jun 3, 2020

@JDarke nice! We need to wait for this since we need to define more specific requirements. Would you like to be involved also in requirements planning and user story definition?

@fox1t fox1t added the needs requirements indicates that an issue needs more requirements in order to be worked on label Jun 3, 2020
@matteovivona matteovivona added core-team indicates that the issue will be completed by a core team member critical indicates that the issue/pull request needs to be urgently worked on in progress indicates that issue/pull request is currently being worked on LOE - large indicates that the level of effort to complete issue is large needs clinical feedback and removed LOE - large indicates that the level of effort to complete issue is large labels Jun 3, 2020
@JDarke
Copy link
Contributor

JDarke commented Jun 3, 2020

Absolutely!

I've got my own projects in react/typescript to finish off today, then I'll take a deeper look at the issue and come back with some suggestions.

@ghost
Copy link

ghost commented Jun 3, 2020

A solution would be to move Related Persons to the Add Patient page, where the doctor would be able to enter both John Doe and Jane Doe's details at once, then it would offer the user a checkbox to "join" records (like in the case of a fertility clinic), or leave them detached.

Please note that this "join" feature will be a separate ticket if wanted.

@JDarke
Copy link
Contributor

JDarke commented Jun 9, 2020

So it'd been a while since I last updated my hr-fe fork, and having just done so and pulled to my local repo, I'm getting a failure to compile.

Is anyone else getting this error?

TypeScript error in /.../hospitalrun-frontend/src/components/Navbar.tsx(70,11)

@matteovivona
Copy link
Contributor

No. Try deleting node_modules folder, yarn.lock, package-lock.json and relaunch an npm i

Screenshot 2020-06-09 at 20 28 45

@JDarke
Copy link
Contributor

JDarke commented Jun 10, 2020

Possible user journey...

  1. User needs to add/find a specific related person of current patient, so goes to Related People tab:

hrfe1

  1. No existing relationships listed, so user clicks on 'Add Related Person'. Instead of triggering the existing pop-up, this action opens the same fields in the space below:

hrfe2

If an existing match is found, the Add Related Person button performs as normal.

  1. If no match is found, the button reveals a further ' Add Related Person as New Patient' section below:

hrfe3

  1. New patient is saved as per New Patient, along with the relationship to current patient.

Optional: The 'Add Related Person as New Patient' section could potentially be reproduced as a collapsed section at the bottom of the New Patient screen, to allow for simultaneous input of related patients, such as couples registering together.

@fox1t
Copy link
Member

fox1t commented Jun 15, 2020

That John Doe is married to Jane Doe, who should share the same record, as the clinic's context needs that . Currently, we have to create a separate entry for her:
In addition to being cumbersome and very anti-HospitalRun, this approach simply won't work in a fertility clinic, where a couple, not an individual patient, is the focus of the diagnosis and treatment.
Currently, the changes to one person's record would not automatically propagate to the other person's, as the database would consider them as separate patients who just happen to be related. But, as we have seen, this might not be wanted in an obstetrics/gynaecology/fertility/family practice, among others.

Hi, I thought a lot about what you said here, @WaseemAlkurdi, and I disagree that "auto-propagation" and "sharing" would be what we want here. There are more contexts where sharing diagnosis and conditions is more harmful than useful. However I perfectly understand your point of being able to see the relations between patients and fastly check conditions of relative ones. We are going to make this more explicit and easy to do.

For sharing the record between patient thing, I think we can make an optional flag that, that renders a clickable link on a patient detail that let the user (doctor) go directly to an "important external patient condition". However we need to put some boundaries on what can be considered "a linked condition". We will work on this as soon as possible and we will publish a user story about this.

@fox1t
Copy link
Member

fox1t commented Jun 15, 2020

@JDarke What you propose is really nice. I like it a lot. @HospitalRun/core-contributor what do you think about it? If we all agree we can elaborate a bit and make a new issue/PR to handle it.

@JDarke
Copy link
Contributor

JDarke commented Jun 15, 2020

Thanks.

I also noticed a potential issue: when searching for a match in existing patients, it only searches by name, and doesn't display any other info to the user before they confirm the match as a related person.

This seems likely to cause issues if say, I'm searching for a person with a fairly common name, and they are presented as a match when in fact I'm looking for someone completely different who is not yet on the system.

hrfe2

It seems as though it should also display part of their address, for example, so that the user can distinguish between multiple matches with the same name, or can tell straightaway if the match is someone in a different city, when it's a person from the same household that they're looking for.

I'm not sure of the etiquette/process here for reporting issues, as I can't join the slack channel without a hospitalrun account, so I didn't want to raise a ticket for it without asking first...

@WaseemAlkurdi
Copy link

WaseemAlkurdi commented Jun 15, 2020

Hi, I thought a lot about what you said here, @WaseemAlkurdi, and I disagree that "auto-propagation" and "sharing" would be what we want here. There are more contexts where sharing diagnosis and conditions is more harmful than useful. However I perfectly understand your point of being able to see the relations between patients and fastly check conditions of relative ones. We are going to make this more explicit and easy to do.

For sharing the record between patient thing, I think we can make an optional flag that, that renders a clickable link on a patient detail that let the user (doctor) go directly to an "important external patient condition". However we need to put some boundaries on what can be considered "a linked condition". We will work on this as soon as possible and we will publish a user story about this.

Thanks for the insight!
As for the "auto-propagation" part, you definitely have a point here. But the rest of the objection isn't as clear to me, especially when our problem (sans record linking, which is acceptable for the reasons you cite) was very eloquently solved by @JDarke in the screenshots provided above. Can you tell me what I might be missing?

@WaseemAlkurdi
Copy link

Thanks.

I also noticed a potential issue: when searching for a match in existing patients, it only searches by name, and doesn't display any other info to the user before they confirm the match as a related person.

This seems likely to cause issues if say, I'm searching for a person with a fairly common name, and they are presented as a match when in fact I'm looking for someone completely different who is not yet on the system.

hrfe2

Nicely spotted!

I'm not sure of the etiquette/process here for reporting issues, as I can't join the slack channel without a hospitalrun account, so I didn't want to raise a ticket for it without asking first...

You could actually join by creating a Slack account (no HospitalRun email address needed), I tried that and it worked. You can request an invite using this link: https://hospitalrun-slackin.herokuapp.com/

@lauggh
Copy link
Member

lauggh commented Jun 17, 2020

Would it be possible to also pull in a date of birth next to the person's name as a qualifier? This would help identify patients as well as show age.

Jane Doe (1980-06-17)

@JDarke
Copy link
Contributor

JDarke commented Jun 17, 2020

Yup, seems sensible.

It's been raised as a separate issue - #2132 .

@JDarke
Copy link
Contributor

JDarke commented Jul 7, 2020

Just realised I haven't actually been assigned to this yet...can someone assign me, please?

I'll have a WIP ready for review shortly.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core-team indicates that the issue will be completed by a core team member critical indicates that the issue/pull request needs to be urgently worked on 🚀enhancement an issue/pull request that adds a feature to the application help wanted indicates that an issue is open for contributions in progress indicates that issue/pull request is currently being worked on LOE - medium indicates that the level of effort to complete issue is medium needs clinical feedback needs requirements indicates that an issue needs more requirements in order to be worked on patients issue/pull request that interacts with patients module
Projects
Version 2.0
  
To do
6 participants