Auto-generation options can be duplicated and all set to "false"

Hi guys!

As we are working on the auto-generation of patient identifiers in MF (issue MF-218), we want to use the auto-generation options to determine whether the screen should allow manual entry of an Identifier Type or not.

An auto-generation option is a mapping between an Identifier Type , a Location (optional) and an Identifier Source .

to which we apply 2 possible options:

  • auto-generate: true/false
  • allow manual entry: true/false

Now my first remark is, it seems that currently the model does not restrict to a unique set of [Identifier Type/Location/Identifier Source]. Therefore we can end up with conflicting options for a given set.

And second, it is possible to save an option with both options values to false:

  • auto-generate: false
  • allow manual entry: false

Which feels shouldn’t be possible, as that would be equivalent to ‘disabling’ the identifier source altogether.

In the docs (Idgen Module - Documentation - OpenMRS Wiki):

Auto-Generation Configuration

Kept deliberately separate from the notion of Identifier Sources is the ability to enable auto-generation and allocation of a Patient Identifier from a particular source

I am curious to understand the background and ideas behind. @mogoodrich, @mseaton, @dkayiwa, @samuel34.

@mseaton may be able to weigh in more, but that generally makes sense to me:

  • I can’t see a reason for having two sources assigned to a single identifier type, and I’m not sure how that would work… I assume that was just validation that was never implemented

  • Similarly, the false/false case may also just have been validation that had never been implemented, though I suppose you have a use case where you wanted to disable assigning new identifiers but wanted to keep the association for reference.

  • The use case may be rare, but it seemed like it should be possible to use a single generator for multiple sources, which may be the reason for separating out auto-generation and linking of a source to an identifier type

Take care, Mark

1 Like

I think you can assume that this was not given a huge degree of intense design thought, and was added to the module to meet a need before it was a generally adopted module in the community. I think the validation you suggest makes sense.

1 Like

Thanks @mksrom for posting this here.

This makes sense to me if an identifier type having more than one identifier source is not seen as a design flaw or something like having no validation coverage. I think an autogeneration option should directly be linked to either (With a one to one mapping):

  • Identifier type(With n identifiersources - the identifier source having no link to the option)
  • Identifier source(Identifier type having no link to the option)

But not both.

@mogoodrich Why would an identifier type have more than one auto generation option?

Whoops, sorry about that… I think there was a typo in my point, I meant identifier types, not sources

  • The use case may be rare, but it seemed like it should be possible to use a single generator for multiple identifier types which may be the reason for separating out auto-generation and linking of a source to an identifier type

So, yes, I would agree that there’d be a one-to-one mapping between identifier type and auto generation source.

I think we should allow a many-to-one mapping between auto_generation_option and identifier sources.

So you could have two identifier types, each with their own auto_generation_option entry, that link to the same source.

How does that sound?

Take care, Mark

Thanks guys for the input!

I have created IDGEN-122 to fix the issue.

In the mean time @samuel34, we’ll apply a filter in the front-end that simply considers the option to be invalid when the abovementioned cases happen.