Not accepting a transaction bundle about pyro HOT 29 CLOSED

The official validator, throws an exception when testing this content...

Weird.

from pyro.

from pyro.

The bundle isn't too large; heap is getting blown for some reason.

The device resource maturity is 0 so hasn't likely been tested a whole lot - maybe Angus has an explanation.

from pyro.

from pyro.

from pyro.

Just saw this guy, can't look now but will try to over the weekend.

from pyro.

from pyro.

I've found the issue.
The version of the R4 .Net FHIR API that is currently being used in my R4 Pyro server has a bug in that Device.Property.valueQuantity has been miss spelt and that spelling mistake flows right through to the JSON & XML serialization and de-serialization.
So the server expects the following spelling of 'valueQuantity':

"valueQuanity": [{"value": 120000000, "code": "us"}]

rather than the correct spelling which would be:

"valueQuantity": [{"value": 120000000, "code": "us"}]

I can see the spelling mistake has been fixed in the FHIR .NET API V1.2.1 (if not earlier) however the public Pyro R4 server is using FHIR .NET API V0.96.1.

So the root resolution is for me to update to the latest FHIR .NET API version V1.2.1. That in its self will have a few knock one effects I will need to work through.

The other short term workaround is for you to change your resources to use the incorrect spelling of "valueQuanity" or to remove that element form your Device resources for the time being. The later would be a better workaround as once the root problem is fixed the server will then struggle to return any misspelt resource it may have consumed before the fix. So my advice in the short term is to not include the Device element "valueQuantity": [{"value": 120000000, "code": "us"}] for the time being until I can update the server.

I will now look into how much work the update will take me.

from pyro.

from pyro.

from pyro.

I am working on it. As I said their are knock on effects from upgrading the .Net Fhir api libraries in order to get the fix you require. This introduces changes to the way Fhirpath works with the fhir .net libraries ElementModel which mean work for me to integrate these changes into my existing server implementation. That is what I'm working on.
You seem to have some form of deadline, what date are you looking at?

from pyro.

from pyro.

from pyro.

Good to hear Brian, I now have a working V4.0.0 but a little more housekeeping to do before I deploy to the public server. Maybe another 2 days.

Yes, the current server is based on FHIR V3.5.0 as it states in the server's own CapabilityStatement, but point taken I should have said as much in the public server's Wiki page.

And thanks for raising this as it made me do the task I've been ignoring for some time, upgrade the server to V4.0.0 as it is the official R4 release now.

from pyro.

The said issue is now resolved in the new repo branch named release-r4 which now supports V4.0.0 of the FHIR spec and therefore resolves the issue of the spelling of valueQuanity to valueQuantity in the Device resource.
I will update the public R4 Pyro server tomorrow.

from pyro.

from pyro.

I have now as of Sunday 10:50 AM +10:00 deployed the new Pyro FHIR Server that supports FHIR Version 4.0.0. I did not persist the old data stored in the public server, it is a clean database.

Do you support subscriptions?
No, not as yet. However, most of the infrastructure parts have been done to support it. Had to implement an out of band processor to service the subscriptions. That is done but I have not done the work to utilise for the FHIR subscriptions as yet.

from pyro.

from pyro.

Try this: [BaseUrl]/Patient?identifier=12345678
No doubled quotes, no comma '_sort', no 'contains'.
The '_sort' parameter is not supported by the server it just sorts by date by default. I don't understand why you would want to use 'contains' for an identifier. 'contains' is not supported for token search parameters, which 'identifier' is one of.
The reason it returns all patients is because the 'contains' is not supported so it ignores that parameter. Also, you used a comma between the patientIdentifierValue and '_sort' therefore the word _sort is treated as an OR. So it says where identifier contains patientIdentifierValue or _sort=date. You should use an ampersand '&'. Although as i said _sort is not supported so no need to use it.
Hope this helps.
Can we close this issue as resolved?
I'm happy to provide more help but best we just do that by email: [email protected]

from pyro.

from pyro.

No, no comma:
/Patient?identifier=sisansarahId|urn:iso:1.2.3.4.5.6.7.8.10&_sort=-date

The syntax is:
/Patient?identifier=[system]|[value]&_sort=-date

Yet it is also valid to do this:
/Patient?identifier=[value]&_sort=-date

from pyro.

from pyro.

from pyro.

Hi Brian,

How to use search is documented in the FHIR specification here: http://hl7.org/fhir/R4/search.html, and each of the search parameters that are available for each Resource is found on each resources’ page in the specification. For instance, looking at the Patient resource found here http://hl7.org/fhir/R4/patient.html you can find all the available search parameters at the very bottom of the page under the heading “Search Parameters”.

Let me go through each of your queries and explain what is happening in the Pyro server.

Query 1
http://r4.test.pyrohealth.net/fhir/Patient?identifier=sisansarahId,&_sort=-date
Again the ‘,’ comma after the value of the identifier is the problem. It treats what is after the coma as an OR, so that is identifier=sisansarahId OR . That is an error just as this would be an error. identifier=. Actually, my server ignores ‘identifier=’ but cannot ignore the ‘identifier=sisansarahId OR ’. And again, I don’t support the ‘_sort=-date’ parameter but I do just ignore it so no error on that.
Here is a tip. Use this http header ‘Prefer : handling=strict’, as documented in the FHIR spec here: http://hl7.org/fhir/R4/search.html#errors . This will force the server to report on all errors rather than just skipping each parameter that has an error. So, if you were to use this on the query above you would have gotten this message:
“Unable to process a search parameter: The search parameter 'identifier' for the resource type 'Patient', was unable to be processed as expected, the whole parameter was : 'identifier=sisansarahId,'.Additional information: Unable to parse the Token search parameter value of '' as there was no Code found.,”

Query 2
http://r4.test.pyrohealth.net/fhir/Observation?subject=Patient/IHIStatusExample,&_sort=-date
Again the ‘,’ comma. The error message returned here is correct but not obvious. Because of the comma, it tries to process the second value which is an empty string. It then can not find the leading Resource name and then complains about it not being there. So the correct way to make this query would be: [BaseUrl]/Observation?subject=Patient/IHIStatusExample&_sort=-date.
However, I should point out that when I deployed the latest release to the Pyro server to bring in support for Version 4.0.0 of FHIR I also dumped the database. So, the server is empty, there are no Observation resources in the server at present. I will try injecting some for you.

Query 3
http://r4.test.pyrohealth.net/fhir/Subscription with JSON string {"resourceType":"Subscription","status":"requested","end":"2019-04-28T09:31:35.569-04:00","reason":"Notified of patient measurement","criteria":"Observation?_profile=http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation","channel":{"type":"rest-hook","endpoint":"http://r4.test.pyrohealth.net/fhir","payload":"application/fhir+json"}}
This is a bug in my R4.0.0 server. Between STU3 and R4 they changed the datatype of the property Subscription.channel.endpoint from the type Uri to the type Url. I have just fixed this
and uploaded a new release to the GitHub repository. Will try publishing to the public server later.
However, as I said earlier the server currently does not support FHIR active Subscriptions. It can consume and return Subscription resources just as it can all the other FHIR resource types. Yet it will not monitor changes in the server and notify subscribers.

Query 4
Perform a GET request to URL http://r4.test.pyrohealth.net/fhir/Patient?identifier=sisansarahId,&_sort=-date works and finds one patient
No, it does not work it ignores the parameter ‘identifier=sisansarahId,’ due to the comma and therefore runs then query as http://r4.test.pyrohealth.net/fhir/Patient?_sort=-date which just retunes all Patient resources of which there is only one of as I dumped all the resources on the last release. I then added that single resource as a test.

Query 5
Perform a GET request to URL http://r4.test.pyrohealth.net/fhir/Patient?identifier=sisansarahId&_sort=-date works but finds no patients
True because there is no Patient resource in the server with an identifier of ‘sisansarahId’ because I dumped all the resources on the last release.

Query 6
Perform a GET request to URL http://r4.test.pyrohealth.net/fhir/Patient?identifier=sisansarahId works but finds no patients
Same as above yet with no parameter _sort. The _sort is always ignored by the server.

Query 7
This works http://r4.test.pyrohealth.net/fhir/Observation?subject=Patient/IHIStatusExample but finds no observations ( I am expecting some)
There are no Observation resources in the server at all, I dumped all the resources on the last release.

Query 8
http://r4.test.pyrohealth.net/fhir/Observation?subject=Patient/IHIStatusExample&_sort=-date fails
I just cut and paste this query and it worked, although retunes no resources as there are no Observation resources in the server at all, I dumped all the resources on the last release.

Query 9
http://r4.test.pyrohealth.net/fhir/Observation?subject=Patient/IHIStatusExample,&_sort=-date fails
Yes, it fails due to the comma on the identifier parameter.

from pyro.

from pyro.

Hi Brian,
I looked into the _profile issue and fixed it. The root issue was with the SearchParameter Resource from the base R4.0.0 FHIR specification. The SearchParameter Resource for _profile was changed between STU3 and R4 to be of search parameter type Reference, from Uri in STU3. Yet in making this change no one added the appropriate target Resource element for the reference. So the SearchParameter definition does not say what Resource type the reference is to reference. It needed to state the target as StructureDefinition as all Resource.meta.profile elements must point to StructureDefinition resources.

So without this the search for _profile always failed as it could not match your search's reference Resource type which would have been StructureDefinition. It actually expected no resource type which is just wrong.

For example: [base]/Patient?_profile=https://hl7.org/fhir/uv/phd/StructureDefinition/PhdPatient

This also most likely explains why none of the other FHIR servers work because they all suffer the very same problem. I really need to report this error to the FHIR spec team.

So it is now fixed and your search below now works:
[base]/Patient?_profile=https://hl7.org/fhir/uv/phd/StructureDefinition/PhdPatient

from pyro.

I'm going to close this issue now, but feel free to create more as you find them.

from pyro.

from pyro.

from pyro.