Discussion about enhancements to the new relationships field in RefApp 2.6

[craigappl]

Hi Everyone,

I’m excited about the new feature to collect relationships during the registration process. I’ve been brainstorming how to operationalize this in iSantéPlus.

Person Relationship Requirements: We currently have a few types of person relationships that we track:

1. Parent/Child relationships allow us to track guardians and people responsible for children
2. Emergency Contact relationships allow us to identify people to contact in the event of a medical emergency
3. Medical Disclosure relationships allow us to identify people who can review a patient’s medical record

The person relationships feature in RefApp 2.6 allows us to connect a person to another person that’s already registered in OpenMRS. There are times when a person isn’t already in OpenMRS and shouldn’t necessarily be registered in the system.

Brainstorming solutions to this, it seems as though we would want the option to check if the person of a particular relationship type is in the system, then collect their information if they aren’t registered.

Field 1 RelationshipType: This would be a hardcoded relationshipType like “Emergency Contact” Field 2 patientSearch: Search for that patient (return UUID of patient) Field 3 notFound Boolean: If the patient isn’t found in the system, check a box to collect the relationship information in the registration app. If this box is checked, display the following fields:

• Name
• Address (based on address hierarchy)
• Phone number

Questions:

• Do others have a similar use case?
• Does this sound like an appropriate solution?
• If a person isn’t in the system, would it be appropriate to collect a minimum amount of information and register them in the system as a person?
• Could this be done in a generic way in the registration app?

Thanks, Craig

[mogoodrich (Mark Goodrich)]

Will try to respond in more detail later, but we are looking to add relationships in Haiti has well, so wanted to @ddesimone and @cioan who are actively working on relationships functionality.

Take care, Mark

[craigappl]

Thanks @mogoodrich. FYI: @ball, @ddesimone, @cioan

Here are some additional thoughts:

• We would want to be able to collect these three relationships for all patients

Here’s a mock-up of how the screen might look:

• The dropdown would be hardcoded for each patient.
• Clicking the + sign would allow the patient to add that type of contact
• Clicking the “Not Found” checkbox would display another section that would capture the patient information (name, relationship, addressHierarchy and phone number)
• The Emergency contact relationship is a required field. If the “Not Found” box is checked next to the emergency contact, the person Name would no longer be required, but the new section would then be populated with required fields.

Thought: I’m not sure if the new relationships widget should be used for this. It seems like we could hard code the relationship type, display the text “person-typeahead” field, and display a checkbox. We could then use JavaScript to build the relationships if the person is found in the system before the form is submitted.

[ssmusoke (Stephen Senkomago Musoke)]

@craigappl An interesting concept:

1. It may also be good to be able to restrict the potential matches to people with specific roles or person attributes otherwise for a large site it would be tricky.

2. Would these not be specific relationship types, whereby one would pass the uuids of these types to the widget (so that later can be set to parents, siblings, doctors etc)

3. I tend to find the + problematic and difficult to use since across OpenMRS it would add a new row for entry.

[craigappl]

Thanks for the feedback @ssmusoke

1. @mogoodrich could probably answer this

2. The current widget doesn’t appear to have the ability to a) define the items in the drop-down b) define a default item c) allow you to pre-define “n” relationships to be collected (see answer 3)

3. Brainstorming another approach: Instead of putting all relationships on one screen, we could add a relationship widget as the first question to each of the three sections. The current widget has a repeating group “relationship in relationships” class that’s manipulated by angular.

[ssmusoke (Stephen Senkomago Musoke)]

@craigappl

Brainstorming another approach: Instead of putting all relationships on one screen, we could add a relationship widget as the first question to each of the three sections. The current widget has a repeating group “relationship in relationships” class that’s manipulated by angular.

@craigappl if you can specify a list of relationship types this could either show one at a time or limit the selectable types in case you need to add more of one type

[cioan (Cosmin Ioan)]

Another option would be to configure three separate instances of the relationships widget. Each instance would only create one relationship type, e.g. Emergency Contact, Power of Attorney and Medical Disclosure

Instead of the Not Found checkbox, we could embed inside the Search Person widget the ability to trigger the creation of a new Person. Something similar to the old UI relationships widget:

[craigappl]

Thanks Cosmin,

This is definitely an approach we could take. Has anyone done this in production? If so, are there implications downstream when creating these stubs?

For example:

• What happens when that person walks into the same clinic?
• What happens when a merge event occurs at a later date? Will the patient relationship correctly link to the merged record?
• Would this have an impact on when a person shows up in multiple clinics?
• I assume these patient stubs would need to push to the Master Person Index. What are the implications there?

Sincerely, Craig

[mogoodrich (Mark Goodrich)]

@craigappl all good questions, I’m not sure exactly what the right answers are.

Currently, at PIH we are not storing contact person as a relationship, but as a separate set of observations. This means we keep the contact person completely separate from the Patient/Person model in OpenMRS, and there are pros and cons to this.

Note that in OpenMRS a Patient is an extension of a Person, so all Patients are Persons, but not all Persons are Patients. If we use Relationships to keep track of Emergency Contact, and a new Emergency Contact who is not in the system is added, I would see them initially added as a Person.

But, to your question, if that person later walks into the clinic as a Patient, we could want to “promote” the Person record to a Patient. Not sure if that it the right thing to do, and we’d need to build the functionally to do this (shouldn’t be too hard technically, but might be a bit more confusing from a usability perspective–after you search existing Patients, would you search existing Persons?)

Also, if you did do this, if Patient who is also an Emergency Contact changes their phone number, would you want their emergency contact phone number in the the other Patient’s record automatically updated? One might say yes–but what if a Patient comes in and changes the phone number of their Emergency Contact–would we really want the phone number for that person’s Patient record to be updated?

Confusing! The more I write this, I’m thinking we may want to keep the Emergency Contact as a observation, or at least perhaps keep Persons and Patients separate in this situation–ie, if someone is both an Emergency Contact and a Patient, they would have two separate Person records.

At PIH, there is a specific case where we are looking to start using Relationships, which seems like a clear-cut use case for a Relationships–for linking newborns born in the hospital to their mothers, so a clear patient-to-patient relationship.

Let’s continue the discussion.

Take care, Mark

[darius (Darius Jazayeri)]

@mogoodrich

Confusing! The more I write this, I’m thinking we may want to keep the Emergency Contact as a observation, or at least perhaps keep Persons and Patients separate in this situation–ie, if someone is both an Emergency Contact and a Patient, they would have two separate Person records.

I would take this further and say that you should just store emergency contact details as observations, visit attributes, or person attributes on the original patient.

There’s no business value in storing this contact as a linked person stub and this would add a bunch of extra complexity. (“Was the emergency contact of patient xyz” is not actually useful clinical information that we’d care about if the contact later shows up as a patient.)

[mogoodrich (Mark Goodrich)]

@craigappl let us know what approach you end up taking… based on my thoughts and Darius’s feedback, I’m definitely leaning towards keeping things as they are (emergency contact stored as a set of observations), and not cluttering the Person/Patient tables with what is really just supplemental information.

Take care, Mark