Closed makuser closed 3 years ago
Thanks for the report!
It looks like FHIR gateway was not able to replace the Location
header returned from FHIR server in the previous call. Could you please attach your nextcloud server logs as well. Anything seen there?
Could you please attach your nextcloud server logs as well. Anything seen there?
I set the loglevel to debug and performed the action again, but I do not get any log entries for the ehr app or any other module either.
I do have note that an observation object gets created, I asked my fhir server and got a list of several observations I created via ehr.
Unfortunately even on page reload no data will be displayed in the physical data or vitals section. This is because ehr queries for code 34565-2 and does not get any objects, but for example if I ask for 8302-2 I do get height objects.
Is the fhir server supposed to return objects based on their loinc code hierarchy, because by following the guide on kailona.org neither ibmcom/ibm-fhir-server:4.4.2 nor updating to ibmcom/ibm-fhir-server:4.7.0 return them.
Do I have to import profiles or codes first or is some parameter missing from the query?
https://cloud.domain.eu/fhir-server/api/v4/Observation?patient=Patient/178ff57cb00-7227c644-e66d-45ad-8559-e71fe34960f5&category=http://hl7.org/fhir/ValueSet/observation-category|vital-signs&date=ge2019-09-24T22:00:00.582Z&date=le2021-04-25T21:59:59.582Z&code=http://loinc.org|34565-2&_include=Observation:has-member&_count=25
Kailona creates individual observation resources for each data, e.g. one for height, one for weight, etc. Then, it gets the created individual observations and group them in an observation category to display them in a single row in table, so that is why it queries observation categories by panel loinc codes such as 34565-2.
It gets the individual created observation using Location
header in the response of its POST call when it is created. However, i think Location
header is retrieved with your FHIR server url instead of FHIR gateway (nextcloud url) in your environment, so it can't get individual created observations and can't create observation category to display them in the table although individual observations are created.
Here is the code where it replaces FHIR server url in Location
header: https://github.com/Kailona/ehr/blob/master/lib/Service/FhirService.php#L173
Could you please check and let me know Location
header in the response of an individual observation POST call to confirm this issue?
Oh man... FHIR is really really really lacking transactions :/ So if I understand this correctly the resource objects (containing values and actual value types, eg. height, weight, etc) have been created, but not the virtual linking object, the vital data panel? Sad that this still has not been addressed in the FHIR spec...
Unfortunately I have not been able to see a request where the Location header was set to the FHIR server.
I now tried to create a height entry, but the API proxy seems to return a 404 on the newly created Observation history, even though it even returns the actual history item...
I asked my fhir server at https://fhir.domain.eu/fhir-server/api/v4/Observation/1790e74a1e3-b8128d96-6e7d-43ec-b604-2bd9fc9921f8/_history/1, so basically the same query, it returns 200 for the xml data.
After a bit of investigation in your network, Location
header was set to https://cloud.domain.eu/apps/ehr/fhir/Observation/1790e74a1e3-b8128d96-6e7d-43ec-b604-2bd9fc9921f8/_history/1
, but your environment runs on https://cloud.domain.eu/index.php/apps/ehr
, so it misses index.php
in the url. Looks like $this->urlGenerator->getAbsoluteURL
here sets it without index.php
That is why you got 404. It should be fixed, but that does not explain your original issue with FHIR url.
After a bit of investigation in your network,
Location
header was set tohttps://cloud.domain.eu/apps/ehr/fhir/Observation/1790e74a1e3-b8128d96-6e7d-43ec-b604-2bd9fc9921f8/_history/1
, but your environment runs onhttps://cloud.domain.eu/index.php/apps/ehr
, so it missesindex.php
in the url. Looks like$this->urlGenerator->getAbsoluteURL
here sets it withoutindex.php
Wow, that really does not make any sense, except if the nextcloud router somehow injects the 404, because it expects the URL to contain index.php..... So strange?
the API proxy seems to return a 404 on the newly created Observation history, even though it even returns the actual history item...
https://cloud.domain.eu/apps/ehr/fhir/Observation/1790e74a1e3-b8128d96-6e7d-43ec-b604-2bd9fc9921f8/_history/1
is reachable, returns the Observation object, but with a 404 code.
https://cloud.domain.eu/index.php/apps/ehr/fhir/Observation/1790e74a1e3-b8128d96-6e7d-43ec-b604-2bd9fc9921f8/_history/1
is also reachable, returns the same Observation object, just with a 200 code instead of 404.
What the hell 🤣
{"resourceType":"Observation","id":"1790e74a1e3-b8128d96-6e7d-43ec-b604-2bd9fc9921f8","meta":{"versionId":"1","lastUpdated":"2021-04-26T13:53:15.235364Z"},"status":"final","category":[{"coding":[{"system":"http:\/\/hl7.org\/fhir\/ValueSet\/observation-category","code":"vital-signs","display":"Vital Signs"}]}],"code":{"coding":[{"system":"http:\/\/loinc.org","code":"8302-2","display":"Body height"}],"text":"Body height"},"subject":{"reference":"Patient\/178ff57cb00-7227c644-e66d-45ad-8559-e71fe34960f5"},"effectiveDateTime":"2021-04-26T13:53:00Z","valueQuantity":{"value":175,"unit":"cm","system":"http:\/\/unitsofmeasure.org","code":"cm"}}
On a side note: I wanted to remove the index.php from my NC URLs forever, but never found the time to figure out how. I am already rewriting all index.php/* URLs properly, so that in theory I could access everything without index.php (such as the ehr observation resource above), I would just have to tell NC that it can actually omit that file from the path.... Looks like I'll be figuring this out after all and finally set it up today :)
Well would you look at that 😆 😆
I set htaccess.RewriteBase
to '/' and regenerated my htaccess with occ maintenance:update:htaccess
and now the ehr app works properly, as the URL in the Location
now fits the resource that returns a 200. Great!
I would still consider this a bug, since apps should work either way, but at least you now found the origin of the bug.
Great to hear that it worked for you. I also reproduced it with index.php
in nextcloud url. We will fix it asap.
Thanks for your help identifying this issue.
I also had a problem with the ContentSecurityPolicy. Using apache it was resolved telling fhir via the reverse proxy to still use https / 443:
RequestHeader set X-Forwarded-Port "443"
RequestHeader set X-Forwarded-Proto "https"
I also had a problem with the ContentSecurityPolicy. Using apache it was resolved telling fhir via the reverse proxy to still use https / 443:
RequestHeader set X-Forwarded-Port "443" RequestHeader set X-Forwarded-Proto "https"
as in #51
Very interesting you were able to solve it with that options, as the config I posted in #51, which contains those two options, is indeed the actual config that led me to experience the bug in the first place.
Before applying those two settings I saw in the browser that links where called with http only which was blocked.
Steps to reproduce
Expected behaviour
CSP is set properly (https://nextcloud-server.netlify.app/classes/ocp-appframework-http-contentsecuritypolicy) or FHIR Proxy service is used
Actual behaviour
Server configuration
Operating system:
Debian GNU/Linux 10 (buster)
Web server:
apache2:amd64/stable 2.4.38-3+deb10u4
Database:
mariadb-server:all/stable 1:10.3.27-0+deb10u1
PHP version:
php7.4-fpm:amd64/buster 7.4.16-1+0~20210305.42+debian10~1.gbpbbe65e
Nextcloud version: 21.0.1
Where did you install Nextcloud from: Nextcloud 11 and upgraded regularily
List of activated apps:
Nextcloud configuration:
or
Client configuration
Browser: Firefox 87.0+build3-0ubuntu0.20.10.1 Operating system: Ubuntu 20.10
Logs
Nextcloud log (data/nextcloud.log)
Browser log