HL7 output use cases for the RHEA SHR Adapter module ( Jembi Health Systems)

The SHR Adapter module deals with two specific use cases pertaining to hl7 output.

User requests a single encounter (the requested encounter may be identified by encounter id or uuid)
User requests one or many encounters.

The query for multiple encounters will be made using the following mandatory parameters :

PatientID == patient identifier
idType == uuid/name of patient identifier type

And the following optional parameters,

enterpriseID (singles out one encounter for output)
dateStart (encounters that started before this date)
dateEnd (encounters that ended before this date)

Multiple encounters retrieved by the request will be merged into a single ORUR01 object.

structure of an ORUR01 message which contains multiple encounters


MSH
PID
{
[ORC] There will only be one of these, in the very first loop.  It shows who asked for the data and why.
OBRenc [enc -- encounter|enc – encounter] This OBR represents the encounter.  It includes encounter date, provider and site.
It does not have any OBXs after it -- so far.
{
OBRclnGrp [clnGrp -- Clinical Group|clnGrp – Clinical Group] This one represents the maternal health tabs.  It has a Parent ID to tie it back to the encounter.
        {
            OBX
        }
}
}

The GET requests are triggered via a call to the SHR adapter module.
They are managed synchronously, (We dont use a queue) and the results are returned to the user in xml message format.

Additional points to consider

What will be the structure of our hl7 message ?
Will we return one ORUR01 per each request, or one ORUR01 per encounter returned ? this is an importaint decision. It will have a great impact on the structure of our ORUR01 message.
How will we share identifiers across different databases ?
How do we manage missing or incorect data ? for example, assume that the provider, location or encounter type specified in the hl7 message does not exsist in the receivers database. How will we ignore such a scenario ?
Considering that the hl7 message may be triggered by various events, we need to identify which fields should be constant, and which the user should be able to set based on their needs.

Notes

Since we may have captured a lot of Information per each encounter, the generated hl7 message may be very large. Therefore, we need to decide what information is required per each request.
For example, if a user requests information of an encounter, do we need to send him (multiple) NK1 segments or a PV1 segment ? wont the PID + ORC + OBR + OBX be adequate ?
Furthermore, I see merit in returning several types of response formats for each message. Something like ?v=ref or ?v=full which we use in the REST Web Services module.
I hope that our ORUR01 wont contain values for every possible field. Lets,
1. Streamline message data using different response formats,
  OR
2. Fill in only a set of mandatory fields we definitely will need.