FHIR Chat · TerminologyCapabilities · hapi

Stream: hapi

Topic: TerminologyCapabilities


view this post on Zulip Jim Steel (Aug 02 2019 at 01:43):

Has anyone tried to implement TerminologyCapabilities in HAPI? I'm having some trouble - the @Metadata annotation, which is how I'm responding to a /metadata request, won't let me return a resource of type TerminologyCapabilities (i.e. /metadata?mode=terminology)

view this post on Zulip James Agnew (Sep 04 2019 at 21:09):

I don't think this is currently supported unfortunately. The implementation of the @Metadata method hasn't really been changed since DSTU2 days..

I'm assuming you're getting a clascastexception or something?

view this post on Zulip James Agnew (Sep 04 2019 at 21:09):

(I do bet this would be really easy to fix, btw)

view this post on Zulip Michael Lawley (Sep 05 2019 at 11:28):

Our "fix" was to extend TerminologyCapabilities and add in implements IBaseConformance :-)

view this post on Zulip Jim Steel (Oct 24 2019 at 07:08):

Bump. In my latest attempt at this (with HAPI 4.0.1), I was hoping that by implementing @Metadata getServerConformance(HttpServletRequest theRequest, RequestDetails theRequestDetails) one of either theRequest.getParameter("mode") or theRequestDetails.getAttribute("mode") would give me the "mode=terminology" URL parameter that had been passed in.

Alas, both seem to be empty

view this post on Zulip Jim Steel (Nov 04 2019 at 04:09):

On further investigation, our problem seems to be caused by this change: Server CapabilityStatement/Conformance repsonses from the /metadata endpoint will now be cached for 60 seconds always. This was previously a configurable setting on the ServerConformanceProvider, but it is now handled directly by the method binding so the provider now has no responsibility for caching. The first request is coming in without any parameters, and the response is being cached and reused for a second request that comes in with ?mode=terminology

view this post on Zulip Jim Steel (Nov 04 2019 at 04:10):

Is there a way to turn off this caching?

view this post on Zulip James Agnew (Nov 05 2019 at 11:00):

Oh man, interesting.

There is an attribute on @Metadata you can set to disable caching, but it's only in 4.1.0-SNAPSHOT

view this post on Zulip Michael Lawley (Nov 05 2019 at 12:09):

yeah - we're hanging out for 4.1.0 (or a 4.0.4 :-)

view this post on Zulip James Agnew (Nov 05 2019 at 12:15):

Would the right way to go here to be an additional attribute on @Metadata that specifies the mode that your specific method handles? That would be pretty easy to handle, and then you could keep the caching too

view this post on Zulip Michael Lawley (Nov 05 2019 at 22:03):

Hmm, at the very least the caching needs to be parameter-sensitive, and in this case that's (at least) mode, noting that some values for mode act like _summary in that they subset the response, while others change it entirely.
Adding the attribute sounds like a good plan -- would also assist with varying the type of the result, but @Metadata would also need to look for an interface as return type so that it can support a TerminologyCapabilities result in case one wants to handle all cases in one method.
Re the caching, we would probably want to always handle that ourselves, but having the timeout attribute set to zero works for that.

view this post on Zulip James Agnew (Nov 06 2019 at 14:02):

Yeah, I hear that.

In all honesty thinking about this more, I'm more inclined to drop the caching entirely from the CapabilityStatement method binding. It's useful for HAPI JPA servers because we dynamically generate some of the output based on stuff in the database (so caching is a big win there) but it seems like it's actively harmful to everyone else. The whole concept should probably be offloaded to an interceptor.

view this post on Zulip Peter Williams (Jan 31 2020 at 03:40):

I've also been struggling with returning a TerminologyCapabilities resource, and raised https://github.com/jamesagnew/hapi-fhir/issues/1681 to ask about the best way to do it. I'll try extending the class as @Michael Lawley suggests above. Thanks!

view this post on Zulip Sanjay Kandula (Dec 11 2020 at 14:45):

@Shreshta Balachandar #hapi
Hi All,

Can some one please clarify us on below point. We are currently working on loading the terminology data to HAPI and exploring the options for the same.

  • Is Hapi Fhir looking for any specific format when uploading the terminology data. We currently have the csv file and expecting the data to be stored in HL7 FHIR Json format. Or if there is any documentation around it, please let us know

view this post on Zulip Lin Zhang (Dec 12 2020 at 01:09):

http://hl7.org/fhir/terminology-module.html


Last updated: Apr 12 2022 at 19:14 UTC