Patient Program Identifiers

Hello there.

I have found the need for us to start identifying patients in a specific program other than using a patient-based identifier.

Treatment programs such as Antenatal, Tuberculosis, Covid management, may be addressed as programs where a patient might be enrolled. In any of them. However, there is no way of identifying a patient with a number that is tied to a program. At the moment we do have identifiers attached to a patient.

Wen also needs to acknowledge that ProgramPatientIdentirfier is attached to each PatientProgram.

I have also noticed that Patient Program in OpenMRS objects can be equated to EpisodeOfCare resource in FHIR. The FHIR object for Episode of Care has a field for Identifiers.

Is it possible to add an Identifier field in the Patient Program and make it a field that can be used to search for patients?

@dkayiwa @ibacher @ssmusoke @burke Your thoughts.

Have you evaluated using the Patient Program Enrolment Attributes which we added in openmrs platform 2.2? [TRUNK-4755] Implementing Program Enrollment Attributes - OpenMRS Issues

I would support the addition of a patient program identifier. It’s common for study protocols and treatment programs to have a program-specific identifier like this.

I wouldn’t consider Patient Program and Episode of Care as the same thing. Patient Program involves enrollment, workflows & states, etc.; whereas, an Episode of Care can be as lightweight as a simple grouping of encounters across visits related to an episode of care or treatment. I would, instead, think that, once we have Episode of Care formally added to the OpenMRS model, episodes of care and patient programs should be optionally related (I’d imagine a many-to-many relationship).

This is something we raised and pushed for years ago, but it never materialized. One thing we need to think about is how identifiers are handled in the system relative to other types of metadata (eg. you can use idgen to generate them, you can search for patients by them, etc). I’d think we’d want to consider directly linking PatientProgram with PatientIdentifier, either in a one-many or many-many relationship, and to implement this as normal Patient Identifiers that are associated with one or more program enrollments.

@dkayiwa actually we have tried using them how ever they don’t really offer the solution one looks for in Identifying a patient through their program they are enrolled into.

Exactly my thoughts.

When you read the details about EpisodeOfCare. For some reason programs look relatable. Especially on the part of Expected Implementation 8.10.3.1 https://www.hl7.org/fhir/episodeofcare.html

It’s a good point that there are cases where you would want to be able to find a patient by study or program enrollment identifier and it would be nice to re-used identifier generation functionality rather than re-invent it; however, I wouldn’t assume program identifiers to always be used like a standard MRN. Some programs (e.g., treatment programs) may simply use the patient’s MRN and not need a separate identifier and some studies would not want to expose their identifier (i.e., in some cases, the link between study identifier and patient is protected/privileged information). So, assuming we can make patient identifiers that are not searchable, we could use patient identifiers for this.

So, I’m suggesting something along these lines:

  • Adding patient_identifier.searchable (boolean, default true) to allow patient identifiers that aren’t shown in searches.
  • Add an optional patient_identifier_type.program to link an identifier type to a patient program.
  • Add something like program.identifier_required (boolean) property that would specify whether or not patient should be assigned a program identifier upon enrollment.

Interesting. So, it looks like FHIR EpisodeOfCare is evolving closer to our Program. So perhaps we should imagine evolving Program the same direction (i.e., ability to link to a condition, linking encounters related to the program). But we’ve also imagined Program being used for studies as well as treatment programs and FHIR has a separate Study resources. We’ll need to investigate and make sure we’re evolving OpenMRS toward alignment with FHIR over time. Thanks!

@here Seems to me that we are agreeing to the need to add Patient Program Identifier to the OpenMRS Patient Program’s table. Should I go ahead and add the ticket in “issues”

@burke what happens to the validation of patient Identifiers that ensures a single Identifier of a given type to a patient? Given a scenario like pregnancy where It might occur multiple times??

Like you, I initially imagined patient program identifier as an additional attribute on Patient Program (i.e., an attribute added to enrollment of a patient into the program). However, I think @mseaton was challenging us to think, instead of adding patient program identifiers as a separate entity within Program, we might allow patient identifiers to be used as a patient program identifier. In other words, do we create PatientProgramIdentifier or, instead, do we create a link from PatientProgram (an enrollment) to a PatientIdentifier?

There are advantages to leveraging PatientIdentifier (using idgen, showing program identifiers to the user leveraging the same approach as other identifiers, etc.) if we can address the issues I listed above (e.g., avoid adding program identifiers to patient search results by default).

I would suspect that a patient identifier type for a program would require uniqueness of identifiers within that program, but would generate an identifier for each enrollment (i.e., a patient enrollment gets only one identifier, but a patient could have multiple if they are enrolled into the same program multiple times).

@here Just not to lose the conversation. Can we come up with Designs basing on the discussion here and we add this to Issues.

@here The ticket to this Conversation is here. I will be working around it [TRUNK-6070] Add Patient Program to Patient Identifier - OpenMRS Issues

@here the changes in core have been made in OpenMRS 2.6.x ready and merged. We are working on backporting the changes to 2.5.x and 2.4.x. After we will look into adding this to the general webrest and also the fhir2 module.