Managing missing data

How does the SHR Adapter module manage missing data or objects?

We will walk through the code to understand how the module behaves in the event that-

                   - Provider does not exist

                   - Patient does not exist

                   - Matching encounter does not exist

   - FOSAID does not exist

First, lets consider behavior in the event of a POST request.

• Provider does not exist.

The SHR Adapter module will search for Providers by the provider EPID (Enterprise Provider ID number). 

If a matching provider is not retrived, then a new provider will be created as follows -

We will create a new person, and allocate two Person attributes to it. One attribute will be the EPID, which will contain the ID number included in the hl7 message. The second attribute will be of Attribute type 'role'. We will use this to store a stirng value 'Provider' to indicate that it represents a provider.

Q) Why cant we define the new Person object as a provider by setting its role to 'Provider' (as is the normal OpenMRS workflow) ?

This is because to do so, we would also need to set a user name and password for the new Person object. Doing so programatically would of course affect the safety of our application. Therefore, we followed this alternative method.

When searching for already existing providers by their EPID, the newly created Person objects (identified by their roles)  are also considerd as potential candidates.

•  Patient does not exist

The SHR Adapter module will search for Patients using the ECID, which is passed in as a mandatory parameter of the POST encounter URL.

If a matching patient is not retrived, then a new patient will be created as follows -

We will create a new Patient object.

Create a new PersonName object, assign first name and last name using the PID.5 segment of the HL7 message.

Create a PatientIdentifier object, and assign its values using the PID.3 segment of the HL7 message.

Assign Patient gender as 'N/A' and patient birthdate using the PID.7 segment of the HL7 message.

Save the new Patient object.

• FOSAID does not exist

If the FOSAID does not exist, a matching location object containing the FOSAID will be created in the SHR server.

The value stored in obr.getFillerField2() will be used as the name of the location. 

Now lets consider the module's behavior in the event of a GET request

• Patient does not exist.

If the Patient specified in the GET request URL does not exist in the system, we will return an exception to the user.

The user will be displayed an appopriate error message, while a detailed description will also be stored in the database.

• Matching encounters do not exist

If the filtering criteria specified in the GET request result in no matching encounters retrived, them a skeletal HL7 message with no OBR segments is returned to the user.