We are currently in the process of setting up and configuring a BAHMNI instance. A few questions already came up and I will simply send them one by one here.
We would like to store multiple patient identifiers for one patient, e.g. one ID based on the old paperwork and one automatically generated ID for every newly registered EMR patient.
I know how to configure and choose one from different patient identifier types, but the UI only seems to support only one ID per patient. Is there w way to chance this?
OK. A custom patient attribute might be a workaround. (I guess I will loose the ID Gen features, but this should be fine in my context.)
And I need to add this patient attribute to the patientSearch section of the JSON config and make the user understand that depending on the type of patient ID they are searching for, they need to enter the ID at different places.
Mostly as I reminder to myself: Haven’t yet looked into reporting details, but for some reports both IDs should appear. So the query and layout need to take this into account.
I have some concerns about the inability to configure patient identifiers within Bahmni and want to better understand your planned approach here. A couple of issues we’ve come across:
Bahmni hard-codes a single patient identifier, with a fixed name (called Bahmni Id). This identifier is required and it is not possible to change it’s name. This is not ideal, and is inconsistent with the emrapi platform that Bahmni depends on, which provides platform-level support for a configurable primary identifier type via a global property configured as “emr.primaryIdentifierType”. I propose that we modify Bahmni to respect the emr.primaryIdentifierType global property, or at least allow implementations to change the name of the “Bahmni Id” to an implementation-specific name.
Bahmni does not support collecting or assigning additional identifiers during registration. Using Person Attributes for this may be a workaround, but is not a solution. This is what the Patient Identifier domain object was created for - we should use it. Like above, the emrapi module has a global property named “emr.extraPatientIdentifierTypes” that we could leverage during the registration process to determine what Patient Identifier Types are displayed and collected. Auto-assignment and/or manual entry of these identifiers would be determined by any IdentifierSource and AutogenerationOption configuration associated with them by the idgen module.
Can you please comment on whether the above fits into your vision for Bahmni for the future and if there are existing tickets for these that need to make their way onto the roadmap can you highlight those here?
We are increasingly finding implementations that need more than one identifier. IMO, the issue with not having the feature is additional cost in terms of performance, and in terms of longer queries for reporting. To your specific queries.
Changing the patient identifier type to lookup emr.primaryIdentifierType.
If this helps one of your implementations, it should be rather easy to do, and can be added pretty easily. Just let me know.
Supporting multiple identifier types
This is currently not in the roadmap, and it involves quite a bit of change in both the product (registration, clinical, reports etc) and for specific implementations. Additionally, there is a workaround.
Having said that, there are several implementations that have the need for an additional identifier. I think the downsides of not using an additional identifier is that there is no auto generation option at registration, and that reporting/search is harder and more time consuming.
We will consider adding this to the roadmap (based on current commitments, the earliest we can attempt this would be Q3-Q4 2016.
Thanks for the quick response. Particularly if we are limited to only one identifier type, I do think it would be very helpful to allow implementations to name that whatever they want, rather than to hard-code this as named Bahmni Id. Using the emr.primaryIdentifierType GP is the current conventional way to do that.
Just to clarify your point about additional identifiers, would things go badly wrong with Bahmni if an implementer were to define some additional identifier types using the OpenMRS administration pages? Would this break assumptions made in reports and other parts of the application?
@mseaton, @cine - Part 1 (looking up emr.primaryIdentifierType) has been incorporated into release 0.83 (planned release late July). Analysis for part 2 (support for multiple identifier types) is complete, and we are planning to include this in 0.84 planned to release around September. Please see details of the feature here.
I wanted to reach out to you to see if you wanted to plan anything around this, and would love to get some ongoing feedback when the feature is underway, so that it suits your needs when released.
@vinay - great, I think this will be a big help. We are definitely willing to test drive some of these features as they get built out. I’m looping in @ddesimone who is most involved in analyzing our upcoming requirements and where this might best fit in. Thanks for looping back with us on this!
@mseaton: Definite use case for multiple patient identifier is to find patient using registered identifier(s). Is there any other use case? Currently, the reports are having primary identifier in the report. Will it be useful to have extra identifiers in the reports?
@shanmugam yes, that’s including on reports is definitely a use case. Basically, right now the recommendation is to use person attributes for these extra identifiers, which we are doing (as are many others I believe). So it would be worth looking at how implementations are using these attributes, and the same will be needed to migrate these to identifiers.
hello @vinay,
When you say that IDs setup as attributes are harder and more time consuming for reporting/searching, could you elaborate?
I thought patient search based on attributs is easy to configure and reporting based on attributes should be as well…
Thanks, Khaled