MHS Adaptor - Be able to get the attachments and the attachment attributes from the MHS Adaptor

[robert-joscelyne]

Any Attachments in the GP2GP message are not available is the json.

[briandiggle]

This is probably around the fact that, for GP2GP messaging, some of the business domain messaging has leaked out into the ebXML wrapper. This is lost presently as the MHS Adaptor throws away the ebXML wrapper information, and does not pass it back to the client.

[bartek-sarul]

https://gpitbjss.atlassian.net/browse/NIAD-135

[bartek-sarul]

@robert-joscelyne @fishey2
I think that attachments are already in place.
I was using https://github.com/nhsconnect/prm-deductions-gp2gp-adaptor/blob/master/docs/example_conversations/patient/9442964410/gp2gp-response.xml as an example

Here we have the manifest which describes payload and attachments

<eb:Manifest SOAP:mustUnderstand="1" eb:version="2.0">
    <eb:Reference xlink:href="cid:[email protected]/SystmOne/GP2GP1.1A">
        <eb:Schema eb:location="http://www.nhsia.nhs.uk/schemas/HL7-Message.xsd" eb:version="2.0" />
        <hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
    </eb:Reference>
    <eb:Reference xlink:href="cid:[email protected]" eb:id="_31B75ED0-6E88-11EA-9384-E83935108FD5">
        <eb:Description xml:lang="en-gb">31B75ED0-6E88-11EA-9384-E83935108FD5_patient-attachment.txt.txt</eb:Description>
    </eb:Reference>
</eb:Manifest>

and the attachment itself at the bottom

Content-Id: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGk=

(translating to Hi)

which ends up on queue as following json (I'm omitting the payload as it's large)

{
    "payload": "...",
    "attachments": [
        {
            "payload": "Hi",
            "is_base64": false,
            "content_id": "[email protected]",
            "content_type": "text/plain",
            "description": "31B75ED0-6E88-11EA-9384-E83935108FD5_patient-attachment.txt.txt"
        }
    ]
}

What else would you need here in reference to attachments array?

Apart from that I wonder about the description field. Is it needed?
If we add the manifest as requested in #159 (or even the whole SOAP message as in the bottom of my comment #159 (comment)) then having this description is redundant.
Can we remove it?

I think the less "custom" format we design here the better. I would prefer the end user to parse and process the data whatever way they like.

[fishey2]

@bartek-sarul

The example you have given is correct, and the information extracted correctly. This did not seem to work previously, so that is great news.

One comment that i'd make regarding the above is:

When dealing with larger attachments > 5MB, it is quite likely that we may need to stitch multiple attachments back together from different messages. Therefore, it might be better to do no processing on the message at all, so we instead get something similar to:

{
    "payload": "...",
    "attachments": [
        {
            "payload": "SGk=",
            "is_base64": true,
            "content_id": "[email protected]",
            "content_type": "text/plain; charset=UTF-8"
            "description": "31B75ED0-6E88-11EA-9384-E83935108FD5_patient-attachment.txt.txt"
        }
    ]
}

Regarding #159, we expect to have things in the Manifest that are not part of the same multipart message. These instead will be part of future messages - which all make up the overall health-record. Therefore the information we have in the Manifest is still required in addition to what you have provided with the attachment.

[bartek-sarul]

@fishey2
If I understand correctly, you mean to not decode base64 attachments and leave as is right?

In #159 I'm not talking about skipping manifest but instead adding whole SOAP message so end user of the queue will extract anything they need.
This also means I suggest skipping "description" from attachments json object as it's in the soap/manifest anyway and can be found using attachment ID

[fishey2]

@bartek-sarul

Yes, please leave the attachments encoded. I also understand the plan for adding the SOAP envelope into the response body.

Skipping the description field from the attachments is not advised, as it is about the only thing we have to be able to link the attachment to the entry in the manifest effectively. Considering in a lot of cases, the content_id we are receiving is not particularly useful (i.e. attachment1@something, gp2gp2.2@something).

Another reason would be if the attachment is received as part of a COPC_IN000001UK01 message, we'd also need a way of linking it back to the original GP2GP response message's manifest (RCMR_IN010000UK06) to be able to determine if a health-record is complete.

It is best for us to maintain as much data about the attachments and overall health-record as possible.

[bartek-sarul]

@fishey2
I still don't get how extracting the "description" by MHS is different from doing this by end user.
Currently MHS does this process: check attachments, find the description and put in the json.
The same thing can be done by end user code as all the pieces are in the queue message body json.
Since the whole SOAP (with manifest) will be in the json why not let the end user do this task and leave the json as "generic" as possible without any customizations?

[fishey2]

Apologies @bartek-sarul, you are correct. I was thinking it was part of the multipart data.

In that case, we don't need that to come with the attachments as it is part the Manifest information only.