-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Base url used in responses from FHIR service use internal urls when behind an Application Gateway #3526
Comments
Hi @dfjones1981, thanks for the detailed report. We don't currently support a way to customize the absolute URIs in response bodies that point to the FHIR Service. I've had success with this in the past using Azure API Management (with or without Application Gateway) as APIM makes this easy with the I do not think Application Gateway can modify the response body but am not an expert on Application Gateway. @EXPEkesheth - the feature request here is to use the This has been requested in the past: #1481 |
Thanks for the response @mikaelweave. It's disappointing that the feature isn't available today and we evaluated Azure API Management but didn't find it offered much value for our specific needs at this time. We are at the end stages of rolling out a FHIR service for use by an entire province of Canada and will expect requests to integrate from many departments and applications over the coming months, it would be really valuable for us if this feature was prioritised again as we expect we'll have to ask integrators to replace urls on their side until it is supported. Do we have any way of influencing the roadmap/prioritisation to show that this feature is valued by customers? |
Thanks @dfjones1981 for sharing the need for feature ! Can you please help me understand if you are Microsoft FHIR service managed service customer? If yes, will like to get more details. |
We're using instances of Azure Health Data Services FHIR Service rather then deploying our own instance of a FHIR Service into other infrastructure. |
Thanks ! I would like to get more details. Can you please help create support ticket with information on usage expected, timeline and current workaround you have? |
Just want to chime in to say that we're dealing with the same issue. Right now we're using asp.net core Middleware to do the rewrites ourself. |
I'd just like to add my support for adding this functionality. Currently we use AFD to an OSS instance in which we can set the url however we would like to move to AFD -> Managed Instance but this sounds like it will be an issue for us. Thanks |
Describe the bug
We have a FHIR server running in an Azure Health Data Services workspace. The FHIR server is not accessible directly, all requests are routed through a public endpoint at an Application Gateway. This means the url of the FHIR server is not exposed or usable externally. When we make requests to the FHIR server via the application gateway, the responses contain hateoas links to things like the next page of search results, but those links are using the internal url and therefore do not work. Is it possible to configure the FHIR server or the Application Gateway so that those urls use the correct external base url?
We've tried various options in the gateway backend settings for "Host name - Override with new host name". If we select No then every request returns 502 Bad Gateway.
If we select Yes and choose a specific Host Name other than the host name of the backend FHIR service i.e. xxx.fhir.azurehealthcareapis.com we get 502 Bad Gateway
If we select Yes and set the Host Name to the host name of the backend FHIR service then we get a correct response, but all the links in the response are internal links.
FHIR Version?
R4
Data provider?
SQL Server (Azure Health Data Services FHIR Service so inaccessible to us)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The next and current properties should be in the form https://my-external-url.com/
Actual behavior
The next and current properties are in the form https://xxx.fhir.azurehealthcareapis.com/
The text was updated successfully, but these errors were encountered: