Stream: dotnet
Topic: Using two custom Basic resources
Johan Nicklasson (Nov 16 2020 at 16:10):
We have two custom resources that both inherits from the Basic resource. But how do we call these resources using the dotnet client? I tried to set up our server (Hapi) with two resource providers listening on /MyResource1 and /MyResource2, which works good.
The dotnet client app has a custom class inheriting from Basic that I intended to use. But that did not work since the parser in the dotnet library could not find a correct ClassMapper.
Has anyone had this problem and can share some tips?
Brian Postlethwaite (Nov 16 2020 at 16:26):
Basic is not a derivation for customization, it's always that class and you add extensions to it.
https://brianpos.com/2018/05/03/code-generation-fhir-custom-resources/
/MyResource1 and /MyResource2 are not fhir standard resources, however /Basic is a standard FHIR resource, and the code property is how you split between multiple different "types" of basic resource, but they are all at the same .Basic endpoint
Johan Nicklasson (Nov 17 2020 at 07:11):
Ah, didn't know that 'code' is what you should use for that. Great :).
Thanks Brian!
Johan Nicklasson (Nov 17 2020 at 07:43):
Hmmm... a question... how do you do a read on those particular resourses then? /Basic/<id> could be either MyResource1 or MyResource2.
René Spronk (Nov 17 2020 at 08:10):
'code' is a search parameter, so that's one option if you're not sure about the <id>. If you already have the <id> then a GET /Basic/<id> will return your resource, regardless of the value of its code data element
Johan Nicklasson (Nov 17 2020 at 08:26):
If the server receives an <Id> in this case, then it wont know if it's the <Id> of the underlying resources 'MyResource1' or 'MyResource2'.
What is best practise in this scenario? To use a custom request header specifying what resource intended? Or using the endpoint as this: /Basic/<Id>/MyResource1.
Brian Postlethwaite (Nov 17 2020 at 09:51):
The fhir seriizer can always handle the Basic resource, as all the extras are there through the standard extensibility.
Brian Postlethwaite (Nov 17 2020 at 09:51):
No need for a special handler.
Stefan Lindstrom (Nov 17 2020 at 10:15):
But if you have a Read operation, and a number of different resources encapsulated in Basic (different profiles/underlying resources), is there any mechanism to tell which profile to read?
Mirjam Baltus (Nov 17 2020 at 10:44):
If you do a Read of a Basic resource, after getting the response your code path can split on the Basic.code field.
Stefan Lindstrom (Nov 17 2020 at 10:54):
Mirjam Baltus said:
If you do a Read of a Basic resource, after getting the response your code path can split on the Basic.code field.
Hi Mirjam
Thanks for your response.
My problem is that the project I am working on is not a pure FHIR-project, rather it is to add a FHIR layer as external access technology for an old, existing system. And that system makes it difficult to read the different underlying resources . I nstead we must know what to read and map so to speak.
There's some ideas how to get around that problem that does not involve creating new endpoints, but I thought to explore if there was some existing support for this. So I guess a custom solution that does not violates the standard is what we'll have tp implement. :)
Mirjam Baltus (Nov 17 2020 at 11:03):
@Stefan Lindstrom Thanks for the explanation. I was thinking client side, not server side. :) In order to stay FHIR compliant, you could perhaps choose not to support Read interactions on Basic, but only searches that search on code field/id combination. Or you could keep a list of id/profile server side, so you can use that to reach out to the correct part of the existing system.
Stefan Lindstrom (Nov 17 2020 at 11:08):
Mirjam Baltus said:
Stefan Lindstrom Thanks for the explanation. I was thinking client side, not server side. :) In order to stay FHIR compliant, you could perhaps choose not to support Read interactions on Basic, but only searches that search on code field/id combination. Or you could keep a list of id/profile server side, so you can use that to reach out to the correct part of the existing system.
Yes, it's something along those lines we've been thinking (and some others). Thanks for the replies and ideas.
Johan Nicklasson (Nov 17 2020 at 12:14):
I think we might reach out to the hapi stream, to see if anyone has any tips on this scenario, since the question might be more server-related than client related. For info, we did try calling our custom /MyResource endpoint with the hapi client and that actually worked. But it didn't work using the .net library unfortunately.
Brian Postlethwaite (Nov 17 2020 at 12:27):
You might also choose to have your id's (since they sound like they will be facaded too) have a prefix in them, eg id="R1-1234" and "R2-1234" and the ID contains the non fhir resource type.
But you'd still need to do what Mirjam suggests in terms of search, requiring the code to be there too.
Do note that you only have limitted char count (64) available in the id property.
Johan Nicklasson (Nov 17 2020 at 13:27):
Unfortunately the Id's are UUID's and not facaded. So we have no power over them.
One solution, even though it might be a little bit special, would be to disallow READ and use SEARCH on the /Basic endpoint instead. In that case the server can receive an Id _and_ a code (or type). The client must then be made aware of this, and expect a Bundle as output.
Michele Mottini (Nov 17 2020 at 14:19):
Unfortunately the Id's are UUID's and not facaded.
This sound strange to me, they are resources you implemented, surely you should be able to control how their ids are generated and used (?)
Johan Nicklasson (Nov 17 2020 at 15:34):
Sorry to say that we don't. Our layer (the fhir server layer) is just one of many consumers of the internal services (new and old).
Michele Mottini (Nov 17 2020 at 16:39):
So the FHIR server layer receives GET [base]/Basic/R1-[guid], sees the R1 prefix, strips it and go get the data for the [guid] resource 1 from the internal services, and when creating the FHIR resource appends the R1- prefix to the internal GUID to create the FHIR id ?
Brian Postlethwaite (Nov 17 2020 at 17:10):
This is exactly what I've done on 2 projects.
One of them was splitting Observations types from different sql tables.
Johan Nicklasson (Nov 18 2020 at 11:20):
It could be a valid solution.... Hmmm...
We have other consumers (for example a web app), besides our fhir server, that are using the underlying resources and their Id's. If the Id's get exposed to the end client from the other consumers, we would then be in a position where we would expose the same resource but with different Id's depending on which application you are using.
Last updated: Apr 12 2022 at 19:14 UTC
