FHIR Chat · How to determine which Resources a FHIR server supports? · implementers

Stream: implementers

Topic: How to determine which Resources a FHIR server supports?

John Silva (Nov 30 2017 at 14:29):

Is there a standardized query or something that is part of a FHIR server's conformance statement that allows a programmatic (API) way of determining which FHIR resources a server supports?

Vadim Peretokin (Nov 30 2017 at 14:34):

Well - yes, the capability statement spells out the resources the server supports along with the operations and search parameters the resource. What are you looking at specifically?

John Silva (Nov 30 2017 at 14:46):

Thanks Vadim. I was looking for an API query method that would return the list of supported FHIR resources, e.g.

http://fhir.hl7fundamentals.org/baseDstu3?Resources (or http://fhir.hl7fundamentals.org/baseDstu3/Resources )

This is so a UI for searching could determine which FHIR resources a server supports. For example, the ClinFHIR server supports a query build which provides a choice list for choosing which FHIR resource to query ( http://clinfhir.com/query.html ) --- it would be helpful if this Resource list contained only those resources the specific server supports, not simply the full list of HL7 specified resources.

Vadim Peretokin (Nov 30 2017 at 14:53):

http://hl7.org/fhir/capabilitystatement.html

the capability statement describes the capabilities of a deployed and configured solution available at a particular access point or set of access points. The statement describes exactly how to interface with that deployed solution and thus provides for a degree of self-configuration of software solutions.

It's exactly what you are asking for, it's not just a full list of FHIR resources :)

John Silva (Nov 30 2017 at 18:27):

Yes, but I checked some of the FHIR public servers out there (finding the list from those on ClinFHIR's query page) and not many of them return the rest->resources list of supported resources, some do not even support the CapabilityStatement! So, theoretically it is supposed to be there but maybe in practice implementations aren't supporting it.

http://fhir.hl7fundamentals.org/baseDstu3/CapabilityStatement
https://syntheticmass.mitre.org/fhir/CapabilityStatement
http://snapp.clinfhir.com:8081/baseDstu3/CapabilityStatement
http://52.72.172.54:8080/fhir/baseDstu2/CapabilityStatement

http://sqlonfhir-stu3.azurewebsites.net/fhir/CapabilityStatement (returns a very style'd HTML page)
https://stu3.simplifier.net/open/CapabilityStatement (does but is returning HTML -- probably just need to set headers correctly to get JSON or XML)

Brian Postlethwaite (Nov 30 2017 at 21:04):

Not speaking for all the others, but the sqlonfhir server will return a HTML rendering if you come in from a browser, if you pass in the Accept header with either xml or json, it will return you the type you'e requests. Others are likely the same too.

Grahame Grieve (Nov 30 2017 at 21:17):

@John Silva servers SHALL support the capability statement. That's what the spec says. If they aren't, adding an additional way to get the same information won't change their choice to not conform - just increase it's likelihood.

John Silva (Nov 30 2017 at 22:24):

I wasn't suggesting adding and additional mechanism -- just noting that some of the public servers out there do not support it even though it's a "SHALL' requirement ;-) @Brian Postlethwaite yes, I used PostMan with the Accept header and was able to retrieve XML or JSON version of the CapabilityStatement on some of the servers, thanks.

Jenni Syed (Dec 04 2017 at 20:00):

@John Silva I haven't checked all those servers you listed, but at least the first few DO have a CapabilityStatement, published at the metadata endpoint. EG: https://syntheticmass.mitre.org/fhir/metadata?_format=json returns a CapabilityStatement

Jenni Syed (Dec 04 2017 at 20:02):

http://hl7.org/fhir/stu3/http.html#capabilities
or http://hl7.org/fhir/dstu2/http.html#conformance

Jenni Syed (Dec 04 2017 at 20:03):

@Grahame Grieve is it ever supposed to be published directly out of a "CapabilityStatement" resource in addition to the metadata endpoint?

John Silva (Dec 04 2017 at 21:06):

Thanks @Jenni Syed -- but when I tried this, even with PostMan and the Content Type header set to 'application/fhir_json' it didn't return the CapabilityStatement at this URL: https://syntheticmass.mitre.org/fhir/CapabilityStatement

Jenni Syed (Dec 04 2017 at 21:06):

I don't think it should - but looking to Grahame for sanity check

Jenni Syed (Dec 04 2017 at 21:08):

It should use that URL I posted above. CapabilityStatement is a "weird" resource that's available at /metadata instead of /CapabilityStatement

Jenni Syed (Dec 04 2017 at 21:08):

To clarify: it's always available at /metadata

Jenni Syed (Dec 04 2017 at 21:08):

I've not seen it available at /CapabilityStatement before

Lloyd McKenzie (Dec 04 2017 at 21:30):

[base]/CapabilityStatement would be different - that would be the endpoint where a system would host CapabilityStatements of others - e.g. if it was a registry.

Lloyd McKenzie (Dec 04 2017 at 21:30):

The capability statement for a specific server is always made available at [base]/metadata

Andy Stechishin (Dec 04 2017 at 21:53):

The statement that the capability statement for a specific server is available at [base]/metadata is, I think, clear from the docs. However the previous statement about what is available at [base]/CapabilityStatement is not as clear. Perhaps some additional text on the resource page would help?

Lloyd McKenzie (Dec 04 2017 at 22:58):

Feel free to submit a change request :)

Grahame Grieve (Dec 04 2017 at 23:01):

@Jenni Syed yes you're right and I missed that. thanks
@Andy Stechishin : the difference between these two is found at http://build.fhir.org/http.html#capabilities

Andy Stechishin (Dec 04 2017 at 23:14):

Clear enough for me

Yunwei Wang (Dec 06 2017 at 19:34):

Should server include CapabilityStatement resource in /metadata response?

Grahame Grieve (Dec 06 2017 at 20:37):

if it supports it like a normal resource

Peter Jordan (Dec 06 2017 at 21:37):

Given that the spec states "All servers are required to support the capabilities interaction"...and "shall" return a Capability Statement (that term links to the eponymous resource) from a GET [base]/metadata request - isn't it the case that a Server shall return a CapabilityStatement resource in response to that request?

Grahame Grieve (Dec 06 2017 at 21:42):

yes, but that's not the question

Peter Jordan (Dec 06 2017 at 23:08):

Thought that I'd answered Yunwei's question - other than my reading of the optionality requirement is that it's 'shall' rather than 'should'.

Grahame Grieve (Dec 06 2017 at 23:30):

• servers are required to return a capbilities statement for /metadata.
• servers are not required to support anything at /CapabilityStatement - and doing so says nothing about the server itself
• for the same reason, servers are not required to talk about the /CapabilityStatement resource in the CapabilityStatement they return from /meta - unless hey provide services at /CapabilityStatement

Peter Jordan (Dec 06 2017 at 23:44):

Thanks for the clarification. At one time, I believe (please confirm @Richard Ettema) that Touchstone failed the Capability Statement that my server returned from a /metadata request because it didn't cite support for the CapabilityStatement resource.

Richard Ettema (Dec 07 2017 at 14:49):

@Peter Jordan - Yes, that does sound familiar. I'll be verifying that today to make sure we're not reporting a false negative. Thanks.

Richard Ettema (Dec 07 2017 at 15:59):

@Peter Jordan Your previous failures were due to a check of the ETag header. The capabilities (/metadata) tests previously had an assert to check for the existence of the ETag header. The ETag header is a SHOULD support. This has been updated in the current tests so that they now have a warningOnly set for these asserts.

Peter Jordan (Dec 07 2017 at 20:29):

@Richard Ettema. The ETag header error comes from another (HAPI-based) server that I've been testing. If at all possible, I'm really seeking advice as to whether a Capability Statement, returned from a /metadata request, should contain a reference to the CapabilityStatement resource. At one time my Terminology Server didn't do this and I'm pretty sure that Touchstone reported that as an error.

Richard Ettema (Dec 09 2017 at 18:02):

@Peter Jordan As Grahame stated (above), a FHIR server does not have to support the CapabilityStatement resource type. This means that a FHIR server's capablities (/metadata) returned CapabilityStatement does not need to contain a rest.resource entry for the CapabiltyStatement resource type. I'll be testing this (negative) test case out in Touchstone over the next couple of days and let you know. -Thanks.

Christiaan Knaap (Dec 13 2017 at 09:03):

@John Silva For stating the intended response format you should use the Accept header. The Content-Type header is about the format of data you send to the server.

John Silva (Dec 13 2017 at 13:35):

Lloyd, wow, that's not very clear (from what I could read in the specs and from what answers I've seen posted here.) I'm also not clear then if the metadata info would really give a client the list of known FHIR resources supported by a particular server! I want to be able to retrieve this information programmatically. Can you point us to the spec page where it defines the metadata page?

Michel Rutten (Dec 13 2017 at 13:45):

http://hl7.org/fhir/http.html#capabilities

Michel Rutten (Dec 13 2017 at 13:47):

This interaction SHOULD return a CapabilityStatement resource that describes the supported features, including a list of supported resources.

Lloyd McKenzie (Dec 13 2017 at 15:58):

And Lloyd wasn't part of the conversation... :)

David Hay (Dec 13 2017 at 17:11):

@John Silva sorry to be late to the conversation - the clinFHIR query tool does list the available resources based on the conformance/capabilityStatement resource, and the search parameters also are derived from that statement - or at least they should be!

John Silva (Dec 13 2017 at 22:59):

Thanks @David Hay -- I'll try it later. I'm still trying to figure out from the response (the metadata) how it "makes known" the set of supported FHIR resources. I tried querying for /metadata?format=application/json on the HL7 FHIR3 website and it seemed like all the resources were under extensions; maybe that's true that their implementation has done extensions for every FHIR resource, I'm not sure. I've looked at the spec page for CapabilityStatement and it seems like the rest property has a resource property (array) under it that would be where I'd expect to find the set of supported FHIR resources -- I just haven't seen this on the FHIR servers I've queried.

Grahame Grieve (Dec 13 2017 at 23:02):

the FHIR website itself is a static set of html that isn't quite conformant to itself. That's a work in progress - making the spec conform to itself when it's hosted by a dumb IIS server

Grahame Grieve (Dec 13 2017 at 23:03):

you will absolutely get this from the test server. Let's try something:

Grahame Grieve (Dec 13 2017 at 23:06):

http://test.fhir.org/r3/metadata?_graphql={rest{resource{type}}} - but no, I haven't hooked up graphQL to my server metadata operation. but in principle that's the operation you want

David Hay (Dec 14 2017 at 00:14):

Hi @John Silva

here's a code snippet:
```resourceCreatorSvc.getConformanceResource($scope.server.url).then(
function (data) {
$scope.standardResourceTypes= [] //resource types supported by this server...
data.data.rest[0].resource.forEach(function(res){ ///just look in the first element...
$scope.standardResourceTypes.push({name:res.type})
...

Michael Lawley (Dec 20 2017 at 00:05):

And you'd need to know the server supported _graphql before you could rely on that approach to get the information :)

Last updated: Apr 12 2022 at 19:14 UTC