Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
The Reference Application includes a built-in Registration app that is configured for a common one-size-fits-all use case. However it is possible to disable the built-in app, and set up your own customized version. For example, you can integrate the address hierarchy module and add additional person attributes. You can see the full list of configuration options in the template definition found at this link, which describes the config fields.
Follow the basic instructions to disable an App and add a custom App found at System Administration: Manage Apps.
Save the new App configuration.
Notes:
To add a person attribute follow these simple additional steps after completing the Initial Steps above.
In the list of sections you can add a new section, or you can simply add the person attribute to an existing section. Sections and fields are separated with a comma. The code to add a question of Mother's Name is...
{ "type": "personAttribute", "label": "Mother's Name", "formFieldName": "mothersName", "uuid": "8d871d18-c2cc-11de-8d13-0010c6dffd0f", "widget": { "providerName": "uicommons", "fragmentId": "field/text" } }
If you want to add the question in a section of it's own, you would use something like this, placed in the list of sections...
{ "legend": "My Person Attribute", "id": "myPersonAttributeLabel", "fields": [ { "type": "personAttribute", "label": "Mother's Name", "formFieldName": "mothersName", "uuid": "8d871d18-c2cc-11de-8d13-0010c6dffd0f", "widget": { "providerName": "uicommons", "fragmentId": "field/text" } } ] }
Notes:
You can make a particular field required by adding a "cssClasses": ["required"] after the "widget" declaration in the field. The following code block shows the cssClasses declaration that makes the phone number required:
"fields": [ { "type": "personAttribute", "label": "registrationapp.patient.phone.question", "formFieldName": "phoneNumber", "uuid": "14d4f066-15f5-102d-96e4-000c29c2a5d7", "widget": { "providerName": "uicommons", "fragmentId": "field/text" }, "cssClasses": ["phone","required"] } ]
A complete Json configuration with Mother's Name Person Attribute would look like this...
To use the Address Hierarchy Module in the Reference Application Registration App requires a little configuration to a custom App. The steps are outlined below.
Under the address section, replace...
"widget": { "providerName": "uicommons", "fragmentId": "field/personAddress" }
with...
"widget": { "providerName": "registrationapp", "fragmentId": "field/personAddressWithHierarchy", "config" : { "shortcutFor": "address1", "manualFields": ["address2"] } }
Notes:
A complete Json template including the Mother's Name Person Attribute, and Address Hierarchy would look like this...
The registration app allows you to manually override the primary patient identifier. When you set the variable allow manual override to "true", it presents the user with a question that allows them to manually override the primary identifier, which is often the OpenMRS ID.
The following line can be added to the config section of the JSON that allows you to manually override the default identifier:
"config": { "allowManualIdentifier":true }
Combining registration subsections into one for each section is achievable by setting "combineSubSections" to true. This combines all sub-sections' fields into one sub-section. The following line can be added to the config section of the Registration App Definition to allow for combining of subsections.
"config": { "combineSubSections":true }
Combining registration sections into one section is achievable by setting "combineSections" to true. This combines all the registration sections' questions/sub-sections into the demographics section. The following line can be added to the config section of the Registration App Definition to allow for combining of sections into one
"config": { "combineSections":true }
Providing genderOptions to the config as a combination of one or more of the characters M,F,U,O provides respectively a menu with Male, Female, Unknown and Other gender options. The following module versions are required, Registration App 1.15.0, Uicommons 2.9.0 and Coreapps 1.24.0.
"config": { "genderOptions":"M,F,U,O" }
Support for collecting multiple patient identifiers is being introduced in Registration App v1.7, which is scheduled to be released in spring 2017. This support allows users to collect multiple person identifiers by configuring their own application.
What's not supported:
Additional identifiers can be collected by adding a section in the config, just as you would when adding person attributes. The primary difference has to do with the field type which is "patientIdentifier" and the UUID is the UUID of the patient identifier, found in grey in the patient Identifier types page for that identifier.
In the list of sections you can add a new section. Sections and fields are separated with a comma. The code to add a section to collect the Old Identification Number is...
{ "id": "patient-ids", "label": "Patient-Identifier", "questions": [ { "legend": "Old Identification Number", "id": "Old_Identification_Number_patientIdentifier", "fields": [ { "type": "patientIdentifier", "label": "Old Identification Number", "formFieldName": "oldIdentificationNumber", "uuid": "8d79403a-c2cc-11de-8d13-0010c6dffd0f", "widget": { "providerName": "uicommons", "fragmentId": "field/text" }, "cssClasses": ["required"] } ] } ] }
This allows you to collect the patient identifiers in the registration app, but it doesn't allow you to collect them elsewhere in the user interface. To add the ability to edit patient identifiers to the patient header in the clinician facing dashboard, you need to add the UUID of each identifier to the global property "emr.extraPatientIdentifierTypes":
Here's where it's exposed in the UI where users can click on the identifier to edit it.
The next release of the Registration Core and Registration App modules will include initial support for integrating OpenMRS with a Master Patient Index (particularly, OpenEMPI).
When you enable this integration:
Note: The app needs to have an address field. If it does not, such as in the "registrationapp.basicRegisterPatient" (defined in openmrs-module-registrationapp/omod/src/main/resources/apps/registrationapp_app.json) you will receive the following errors:
ERROR - PixPatientExporter.exportPatient(47) |2018-06-25 15:07:18,328| java.util.NoSuchElementException
ERROR - PatientCreationListener.performMpiAction(71) |2018-06-25 15:07:18,339| PIX patient push exception occurred
this is because the fields sent to the MPI through PIX/PDQ is hardcoded (defined in openmrs-module-registrationcore/api/src/main/java/org/openmrs/module/registrationcore/api/mpi/pixpdq/PixPdqMessageUtil.java)
Thus, if you use a registration app that has all the required fields, such as the referenceapplication.registrationapp.registerPatient that comes with the reference application, it will not produce that error.
------------------------------------------------------------------------------------------------------------------------
To map identifiers from MPI server to local OpenMRS application, you have to specify how they maps on each other. Of course, first of all you have to create proper identifier types in Managing patient identifiers console& (For example: you can see that in screenshot above there is ECID identifier, which was created for mapping).
How to specify mapping? You have to create property in Global properties which names:
registrationcore.local_mpi_identifierTypeMap.{name_of_identifier_type} : {local_identifier_type_id} : {mpi_identifier_type_id}
Example: registrationcore.local_mpi_identifierTypeMap.ECID : 5:60
------------------------------------------------------------------------------------
To configure the registration app to support the collection of patient fingerprints and other biometrics, please refer to this page.