How to specify format required in SSP retrieval request?

ShCR suppliers have been asked use a single pointer/document reference and detail in that pointer the multiple different ways that content/record can be retrieved.

International Patient Summaries are the first pointer types that are likely to be retrievable as unstructured and structured data.

The current working assumption is that SSP will be the retrieval mechanism for retrieving the pointer regardless of whether it is structured or unstructured.

What is not clear is how consuming will specify in their request to SSP, what format they want the document back in.

Consumers can add a new bespoke value or the HTTP Header to indicate whether they want to receive a structured or unstructured IPS.

The Spine team have confirmed that the SSP will forward the HTTP header to providers as received and that bespoke values can be added.

New header value - Ssp-ResponseFormat

The valid values for the Ssp-ResponseFormat will be mime values:

  • application/fhir+xml (FHIR IPS in XML format)

  • application/fhir+json (FHIR IPS in JSON format)

  • application/pdf (IPS document PDF)

  • text/html (IPS in HTML5 format)

The SSP will not validate these values, it will be the responsibility of the provider system to validate that a valid value has been provided.

In the event of a consumer asking for an IPS in an unsupported format the provider system will return an exception.

1 Like

I’m possibly implementing this, we will be asking a NHS England programme they will support us taking a PDF approach in advance of them going for a FHIR Document format (same format as IPS and our project has similar approach to National Imaging Registry, we are also a diagnostic service).

Internally (the actual repository) behind our SSP, I’m planning to support http Accept header. Accept header - HTTP | MDN
Mapping your header to this won’t be a problem.

So if a document consumer says application/fhir+json or application/fhir+xml, I would return the FHIR Document.

Previously when I did this before (for NHS Digital Transfer of Care demonstrator), we also accept application/pdf or text/html. These are not difficult to generate from a FHIR Document (creating the FHIR Document itself though is a different matter)