Multiple Relationship widgets

We are looking to add relationship management to the PIH EMR, and when looking at our existing code, it looks like we have three different Angular widgets for managing relationships…

One is in the registration app, and is for adding relationships during registration:

Another in core apps (and may not be complete) from a couple years ago and is for adding and deleting relationships for an existing patient:

And a third one in core apps for viewing existing relationships on the clinicial dashboard:

Not quite sure exactly what I’m suggesting here–and it may be that we want to maintain all three widgets (or two of them) as they have different use cases–but it seems like there’s potential for some better integration here. For one thing, the two widgets in coreapps live in completely different folders within the scripts hierarchy.

It just took @cioan and I awhile to thread through the code and determine what is available.

We currently are working on adding relationship adding, editing, and viewing to our system, so have some bandwidth to work on this. Any suggestions on what path to take? We could just use the coreapps “dashboard” widget to display the relationshps on the dashboard, and provide an edit link that links to the coreapps “add and remove” widget (and then confirm that widget is working properly) or we could go further in terms of integrating the widgets more.

Any thoughts?

Take care, Mark

I’d add an edit link to the dashboard widget pointing to

It would be nice to make the link part of a widget config so that it can be customized, see

The edit functionality needs to be fixed though as the search when adding a relationship doesn’t seem to be working.

Thanks @rafal!

I think that generally makes sense to me, but as @cioan pointed out to me, the dashboard widget is an angular app (I originally assumed it was just a UI Framework fragment) so incorporating the edit functionality into that widget (via a popup?) could be a better option–especially since the original edit widget was just a prototype that @darius built, as, as you said, doesn’t work 100% correctly, so we are going to have to do some work on it anyway.

My thought, however, would be to start by wiring everything up as you suggest, and then we can take a look at how it looks and feels and go from there.

Take care, Mark

@mogoodrich A question how are the 2 editable widgets mentioned integrated with the HTML Form Entry tag? I am happy to help and test this out (as you move forward)

They aren’t integrated at all. The HTML Form Entry tag is a completely separate widget. Honestly, I hadn’t given the Html Form Entry widget that much thought. I believe it was developed for our Rwanda system, but I don’t know if they are still using it. We aren’t using it anywhere else, and it hasn’t been touched in 5 years, so it wouldn’t shock me if it doesn’t work with the latest versions of OpenMRS and/or doesn’t provide the level of functionality or ease of use we’d need/want in the Ref App.

Take care, Mark

@mogoodrich, adding the edit functionality to the dashboard widget as a popup would be ideal. If you can afford spending a bit more time on that, it’s great. Let me know, if you need any assistance implementing it.

Cool, thanks @raff!

fyi, @cioan

@mogoodrich is it possible for one to restrict the relationship types for example if I want to find mothers only in the registration app (for PMTCT)

I forget if the functionality is there in the widget used on the registration form, but @cioan recently added that functionality to the dashboard widget (might not be in the current release as it was just in the past couple days). I believe he was going to add it to the documentation. @cioan what is the attribute to use again?

Take care, Mark

In order to be able to edit relationships via the widget you have to add the “editPrivilege” config parameter as it is indicated in RA-1342 ticket and to give this new edit privilege to the user.

config: {
"widget": "relationships",
"editPrivilege", CoreAppsConstants.PRIVILEGE_EDIT_RELATIONSHIPS,
"icon": "icon-group",
"label": "Family"

@cioan I would like to be able to restrict the only relationship to parent and search to only females. Is this possible?

Hi @ssmusoke, you could restrict the relationship types by using the “includeRelationshipTypes” config parameter which we added recently. We have not added the capability to filter patient search on gender. I think it could be easily added via another config parameter.

config: { “widget”: “relationships”, “editPrivilege”, CoreAppsConstants.PRIVILEGE_EDIT_RELATIONSHIPS, “includeRelationshipTypes”, PihCoreConstants.RELATIONSHIP_PARENT_CHILD, “icon”: “icon-group”, “label”: “Family” }

@cioan Does this configuration work for the relationships widget on the registration page? Is this the same widget?

@ssmusoke: This widget works on the Here is how we configure it to work on the registration dashboard:

config: {
	"widget", "relationships",
	"baseAppPath", "/registrationapp",
	"editable", "true",
	"editPrivilege", CoreAppsConstants.PRIVILEGE_EDIT_RELATIONSHIPS,
	"patientPage", "/registrationapp/{{patientUuid}}&appId=registrationapp.registerPatient",
	"includeRelationshipTypes", PihCoreConstants.RELATIONSHIP_SIBLING + "," + PihCoreConstants.RELATIONSHIP_PARENT_CHILD + "," + PihCoreConstants.RELATIONSHIP_AUNT_UNCLE,
	"icon", "icon-group",
	"label", "pihcore.relationshipsDashboardWidget.label" 

@cioan That is on the registrationSummary page, is this the same configuration for the Register Patient functionality?

@ssmusoke For registering a patient, @mogoodrich has included a different relationships fragment:


I get this error as i inspect the reason as to why patient registration fails silently given an unexistent person and a certain relationship type.

Does anyone know how where PersonService.getPersons should have been declared ?

This especially happens when then "Enter person name " field is doing a typeahead for the text entered by the user .

found in personRelation.js

 $scope.getPersons = function (searchString) {
           return PersonService.getPersons({'q': searchString, 'v': 'full'});

Are you able to reproduce this on?

I will try again to and see if it can be reproduced there.