Patient List for OpenMRS - Updating cohort data model

[corneliouzbett (Bett Kipchumba)]

Pertinent links:

• Openmrs Cohort Object
• OpenMRS CohortMembership
• FHIR Group resource

As discussed at the last FHIR-Squad call meeting, in regards to support for the patient-list, we intend to extend/evolve the current OpenMRS core cohorts to meet the needs of the Group resource.

The current cohort data-model

Here are a few suggestions/modifications to the cohort table:

Adding of the attributes stated below:

• characteristic (Group - FHIR v4.3.0) - How to be represented in OpenMRS (yet) to be determined. From my perspective, we will need a new entity cohort-characteristic. How would you represent this?
• type : openmrsObject | (anyResource) - Not necessary at this time. (I will be contented having Group.type → always patients for now)

FWIK, OpenMRS/ OpenMRS cohorts is 100% used for patients, howbeit if there is a use case for other entities/resources e.g animal, practitioner, device, medication, or substance. We will need to add a new attribute - type, which should map to the values of this value set group-type (Valueset-group-type - FHIR v4.3.0). That will require subsequent modification to the cohort membership entity.

To generate the list, you can use the defined characteristic or add members to the list manually - (this only applies when you have no defined characteristic). When both characteristic and members are present, then the members are the individuals who were found who met the characteristic. It’s possible that there might be other candidate members who meet the characteristics and aren’t (yet) on the list.

With large datasets, this poses a performance challenge, generating/querying the patient list on request… I would go for generating the list ahead of time with the specified characteristic and have a mechanism of updating the patient list frequently.

Hopeful at the end of this discussion, we should have an agreed plan for implementing/supporting patient-lists.

CC: @burke @ibacher @mseaton @mksd @jdick @mogoodrich @grace @jennifer @bashir @dkayiwa

[mksd (Dimitri R)]

Thanks @corneliouzbett, that’s helpful! This all makes sense to me.

@ibacher what’s the FHIR meaning of having no characteristic?

@corneliouzbett

With large datasets, this poses a performance challenge, generating/querying the patient list on request… I would go for generating the list ahead of time with the specified characteristic and have a mechanism of updating the patient list frequently.

@mseaton looks like this is where the “cursor pattern” could come handy (ref. REPORT-873)?

[ibacher (Ian Bacher)]

@mksd

@ibacher what’s the FHIR meaning of having no characteristic?

A group without a characteristic is likely to be a manually defined list.

@corneliouzbett

(I will be contented having Group.type → always patients for now)

The value should be “person”, but other than that I agree.

@corneliouzbett

How would you represent this?

One way would be as an attribute applied to cohort. That said, one of the things that stuck out to me from the discussion was that the manually and automated populated patient lists are slightly different discussions. My preference in how we approach this would be something like these three phases:

1. Get Cohort mapped to Group for manually managed cohorts.
2. Create backend mechanism for automatically updating cohort membership based on criteria.
3. Worry about how we express those criteria in FHIR (i.e., what characteristic looks like).

This is because I have some worries that the FHIR “characteristic” is possibly not as rich as we would like for driving cohort / list membership.

Finally, I think one important aspect of this is the security around patient lists, and for this, I think that at a minimum, we need to somehow figure out how to populate the managingEntity property in an acceptable way.

[corneliouzbett (Bett Kipchumba)]

@ibacher

The value should be “person”, but other than that I agree

@ibacher

Finally, I think one important aspect of this is the security around patient lists, and for this, I think that at a minimum, we need to somehow figure out how to populate the managingEntity property in an acceptable way

For me, I would map managingEntity to the creator ( user | provider → practitioner) of the cohort. But also, there is the aspect of who can access the list and who cannot.

[ibacher (Ian Bacher)]

@corneliouzbett

But also, there is the aspect of who can access the list and who cannot

Yeah, it would be great if OpenMRS had some way of supporting something like a proper ACL, but those are somewhat complicated to implement. One key question here is how important is the level of granular access control for AMPATH? I.e., can we get away with (for now) implementing protection via a simple permission and look towards migrating things to a more complete security solution later or if this is something we need to built-in from the start (normally I’m of the opinion that security needs to be baked in from the start, but in this case, the question is to what extent do our existing security mechanisms meet the need).

[mksd (Dimitri R)]

@ibacher

Yeah, it would be great if OpenMRS had some way of supporting something like a proper ACL,

This can be done with Data Filter, and it’s great that @corneliouzbett raises the topic so early. The only caveat would be that the mechanism that populates the group must not bypass Hibernate.

For instance, if the mechanism that populates the groups leverages the Reporting module, then it cannot be through SQL datasets.

[corneliouzbett (Bett Kipchumba)]

@ibacher

One key question here is how important is the level of granular access control for AMPATH?

For the moment, we can do away with the “access control”, as it’s not really important to us now. Having said that, we should plan to implement soon.

[mksd (Dimitri R)]

We cannot do away with it for our implementations, so let’s just keep in mind that we need to use Hibernate, no raw SQL shortcuts.