FHIR Chat · Using Basic with multiple types/codes · hapi

Stream: hapi

Topic: Using Basic with multiple types/codes


view this post on Zulip Johan Nicklasson (Nov 17 2020 at 13:41):

Was wondering if anyone has any good advice/best practise of how to handle multiple types (resources) using the /Basic endpoint?
Our scenario is that we have two custom underlying resources with UUID as it's ID and we want to expose them through the /Basic endpoint. The problem that we have is that we can't do a READ on /Basic, since we dont know which underlying resource was intended.
One solution might be to disallow READ and only use SEARCH when getting resources, including the code parameter to distinguish between the two.
Any tips or thoughts are appreciated :)

view this post on Zulip Grahame Grieve (Nov 17 2020 at 14:34):

they aren't differentiated by id? why not?

view this post on Zulip Johan Nicklasson (Nov 17 2020 at 15:39):

O yes, they have their own ID's of course. But we don't know which underlying resource the belong to on a READ action. Hope I understood your question correct.

view this post on Zulip Grahame Grieve (Nov 17 2020 at 16:09):

but you could represent that in the id. i would, at least

view this post on Zulip Johan Nicklasson (Nov 18 2020 at 11:22):

You mean by prefixing the Id, as an example?
I started asking this question in the dotnet stream and they had the same solution :)
But as I wrote in that topic:

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.

view this post on Zulip Brian Postlethwaite (Nov 18 2020 at 13:50):

You have some of the same folks in both places too :wink:

view this post on Zulip Grahame Grieve (Nov 18 2020 at 14:22):

I don't follow how that is related to the question at hand. Perhaps you can explain more clearly... why wouldn't you use the same algorithm?

view this post on Zulip Johan Nicklasson (Dec 14 2020 at 15:39):

Hello again! We solved the problem with the Id's by extending the underlying api with a method where we could ask what resource type a specific Id belonged to.

But now I have another problem which I can't solve.
Our "custom" Basic resource has an extension with the type UUIDType, but the hapi parser throws an error when I do a POST request to our /Basic endpoint : Unknown element 'valueUuid' found during parse.
I have tried to debug to find out why this happens, and all I can see is that when parsing a Basic resource, it doesnt know what a UUIDType (valueUuid) is.

Does anyone have any idea what could be wrong ? Because surely I'm able to use an UUIDType on Basic resource ? :)
Using the hapi server version 5.1

Thanks!

view this post on Zulip Grahame Grieve (Dec 14 2020 at 22:14):

would you like to post an example of your resource?

view this post on Zulip Johan Nicklasson (Dec 15 2020 at 07:05):

Here's an example in json format which doesn't parse:
{
"resourceType": "Basic",
"meta": {
"profile": [ "http://mycustom.url" ]
},
"extension": [ {
"url": "http://myValue.url",
"valueUuid": "ae644c07-1d4b-4ca4-bbf3-bd2023e294e5"
} ]
}

view this post on Zulip Johan Nicklasson (Dec 15 2020 at 07:07):

And here's the java class:
@ResourceDef(name = "Basic", profile = PROFILE)
public class MyCustom extends Basic {
public static final String PROFILE = "http://mycustom.url";

@Child(name = "myValue")
@Extension(url = "http://myValue.url", definedLocally = false, isModifier = false)
@Description(shortDefinition = "")
private UuidType myValue;

}

view this post on Zulip Johan Nicklasson (Dec 17 2020 at 07:21):

Hi @Grahame Grieve, did you have time to look into our problem?

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:39):

what version of FHIR is this for?

view this post on Zulip Johan Nicklasson (Dec 18 2020 at 07:32):

We're using R4.
I do hope it's just me, having made some mistake...

view this post on Zulip Grahame Grieve (Dec 18 2020 at 11:31):

ok. anyway, @James Agnew I think this is an issue in the HAPI serialiser, not the object models themselves

view this post on Zulip James Agnew (Dec 18 2020 at 13:27):

Interesting... Let me see if I can reproduce this.

view this post on Zulip James Agnew (Dec 18 2020 at 13:50):

@Johan Nicklasson I've just whipped up a test with your examples, and it passes. Can you please examine for what is different about the test scenario from your scenario, and update the test so that it demonstrates your issue?

https://github.com/hapifhir/hapi-fhir/commit/5dc12b87876845e7f6f095c4f4f6cd8cbc218d2c#diff-6becf79d21ddbac4d4a25766de087756af0fe334016437d5215943f6a300597fR624

view this post on Zulip Johan Nicklasson (Dec 18 2020 at 14:00):

Thanks for helping out @James Agnew . If you change the parseResource()-method to using the Basic.Class instead of MyCustom.Class it won't work. And I guess that is what being used at runtime?

view this post on Zulip James Agnew (Dec 18 2020 at 14:20):

Ok yeah, I see that. Working on a fix.

view this post on Zulip Johan Nicklasson (Dec 18 2020 at 14:26):

Great! Looks like Santa's coming early this year :)

view this post on Zulip James Agnew (Dec 18 2020 at 14:26):

Looks like the UUID datatype somehow didn't end up in our property file that enumerates the data model types. A fix has been submitted: https://github.com/hapifhir/hapi-fhir/pull/2258


Last updated: Apr 12 2022 at 19:14 UTC