Stream: implementers
Topic: Use of FHIR resources in a non-FHIR API
Ken Sinn (Nov 28 2019 at 21:22):
We have two sibling APIs - one FHIR-conformant, and one non-FHIR (returns mimetype=application/pdf). Their request input parameters are identical, so we plan to re-use the same FHIR resources for the non-FHIR API, simply as json, The non-FHIR API will be at a separate endpoint, and will not claim FHIR-conformance. Is there anything preventing us from using this approach (aside from being slightly unsightly)? This simplifies the transactions for our implementers -- just pass the same input to both endpoints, rather than stripping the FHIR structure for the non-FHIR API call.
Ken Sinn (Nov 28 2019 at 21:24):
As a follow-up question, would the use of error code "422 - FHIR Validation Error" for the non-FHIR API be wrong (i.e. breaking terms of use of FHIR), or just simply confusing?
Grahame Grieve (Nov 28 2019 at 21:39):
neither would be wrong, just potentially confusin.
Grahame Grieve (Nov 28 2019 at 21:40):
but note that if your FHIR end-point returned application/pdf on request, that would be perfectly conformant. you don't need a different end-point for that
Ken Sinn (Nov 28 2019 at 21:52):
Thanks @Grahame Grieve . For business purposes, we need to call and resolve the PDF-endpoint before calling the FHIR-endpoint, both passing in a Consent Resource, so we can't return the PDF as part of the FHIR-endpoint response. We considered using a custom $operation, but can a FHIR $operation return an application/pdf as a response, without any additional FHIR wrappers? We didn't think the response type could be application/pdf on its own, and that it needed a DocumentReference or something other FHIR wrapper/redirection.
Grahame Grieve (Nov 28 2019 at 22:06):
We didn't think the response type could be application/pdf on its own
If the client asked for it, it could be, I think. FHIR only sets expected responses for the FHIR meida types. Other media types are considered outside the spec
Ken Sinn (Nov 28 2019 at 22:57):
Interesting. Can a FHIR $operation only support Accept headers of application/pdf and nothing else?
Grahame Grieve (Nov 28 2019 at 22:58):
I don't think we've discussed that. But an end-point that only works for non-FHIR media types and isn't declared in the capability statement is not a FHIR end point and so is not subject to any considerations of conformance
Grahame Grieve (Nov 28 2019 at 22:58):
I think
Ken Sinn (Nov 28 2019 at 23:14):
This proposed endpoint would have an OperationDefinition resource, so it could be declared in the CapabilityStatement.rest.resource.operation; however, there isn't any place to document that there is only support of an application/pdf type. There's CapabilityStatement.format which doesn't distinguish (at least not in the current description) whether this is the supported formats of the request, or the format of the response. (Additionally, there is no way to define separate supported formats for different restful interactions under the single CapabilityStatement for this endpoint.)
Grahame Grieve (Nov 28 2019 at 23:30):
no you've moved into an area that we've not covered
Ken Sinn (Nov 28 2019 at 23:32):
Thank you for your responses! Are there any plans to look at this kind of use case?
Grahame Grieve (Nov 28 2019 at 23:35):
no particular plans unless people ask. And here you are asking. though where we go from here, I'm not sure. has anyone elese run into this situation before?
Brian Postlethwaite (Jan 31 2020 at 09:59):
That could be a binary resource result, which could then do that sort of thing?
Last updated: Apr 12 2022 at 19:14 UTC
