Stream: implementers
Topic: Check Server if Supported
robert karp (Jan 23 2021 at 15:33):
Newbie here. I'm trying to check if a fhir server supports us-core-allergyintolerance. I tried [fhir/baseR4]/metadata , but didn't give enough info. So I tried [fhir/baseR4]/CapabilityStatement/us-core-allergyintolerance. Doesn't seem to be the right way to get the Capability Statement. Could get it to work for any profile. Looking for an answer or even just point me to a place that will explain.
Lloyd McKenzie (Jan 23 2021 at 16:13):
[base]/metadata is the correct place to look. If supported, it would be in the CapabilityStatement.rest.resource.supportedProfile. However, there's no requirement for systems to declare all of their profiles, and no chance systems will declare every profile you might care about - or any guarantee that all of their data will comply with profiles they support. In R5, we're exploring defining operations that will make it easier to ask simple questions about the capabilities of a system without having to download a 10+ megabyte capability statement, but nothing is landed yet.
robert karp (Jan 23 2021 at 16:17):
Aww ok. If I wanted to download all the CapabilityStatements is that just a GET [fhir base]/CapabilityStatement request? I'm just looking at different ways to test a server setup.
Lloyd McKenzie (Jan 23 2021 at 16:23):
A given server should only have one CapabilityStatement that defines what it 'does' - and that's at the /meta endpoint. The CapabilityStatement endpoint would be used if the server happens to act as a registry for CapabilityStatements - either providing a shared place to look up what a whole bunch of servers do, or more typically, CapabilityStatement defining requirements as part of one or more implementation guides.
robert karp (Jan 23 2021 at 16:26):
ok, I'm very new to FHIR trying to learn the API. ty
robert karp (Jan 23 2021 at 17:18):
Could I try to request the structureDefinition from server?
Lloyd McKenzie (Jan 23 2021 at 18:10):
Not sure what you mean by "the" StructureDefinition. Servers may have a StructureDefinition endpoint that contains the profiles they reference in their CapabilityStatement (if they reference any at all), but there's no requirement for them to do so and lots won't.
robert karp (Jan 25 2021 at 13:47):
I guess I need to read more about profiles, Implementation Guides, Extensions and StructureDefinitions. I don't think I'm understanding the relationships between them. Any good links that explain this would be appreciated.
Lloyd McKenzie (Jan 25 2021 at 15:36):
StructureDefinition is a resource syntax used to exchange resource definitions, data type definitions, profiles and logical models. (Only HL7 is allowed to define the first two). Extensions are a special type of profile on the 'Extension' data type. ImplementationGuides package up a whole bunch of artifacts - typically including various kinds of profiles and sometimes logical models too - that provide guidance on using FHIR to solve a particular interoperability problem. CapabilityStatements are another type of artifact. Every conformant FHIR server must expose a CapabilityStatement at their 'meta' endpoint that indicates what that server does. The CapabilityStatement may point at profiles it supports or uses. ImplementationGuides can also include CapabilityStatements that define what systems should do. If you do a search on "fhir implementation guide video" or "FHIR profiling video", you'll find a bunch of recorded tutorials.
Yunwei Wang (Jan 26 2021 at 18:10):
robert karp said:
Newbie here. I'm trying to check if a fhir server supports us-core-allergyintolerance. I tried [fhir/baseR4]/metadata , but didn't give enough info. So I tried [fhir/baseR4]/CapabilityStatement/us-core-allergyintolerance. Doesn't seem to be the right way to get the Capability Statement. Could get it to work for any profile. Looking for an answer or even just point me to a place that will explain.
There is no guaranteed method to tell if a server support certain profile. Some servers may publish that in profile or supportedProfile elements in CapabilityStatement.rest.resource. Some may indicate that in each resource's meta.profile. Some may not say at all.
Grahame Grieve (Feb 02 2021 at 21:49):
@Eric Haas US core should start mandating that CapabilityStatement.implements refer to US Core
Eric Haas (Feb 02 2021 at 23:22):
@Brett Marquard FYI. @Grahame Grieve do you mean CapabilityStatement.instantiates or CapabilityStatement.implementationGuide?
Grahame Grieve (Feb 03 2021 at 01:18):
oh yes. Whoops. the second.
Eric Haas (Feb 03 2021 at 02:40):
This seems like it should apply not just to US Core but to all IGs
Grahame Grieve (Feb 03 2021 at 02:59):
it would be good policy in most cases, yes
Grahame Grieve (Feb 03 2021 at 02:59):
it does depend on the nature of the IG though
Yunwei Wang (Feb 03 2021 at 17:09):
The original question is asking if server support one specific profile not the whole ig. Does the .instantiate help resolve that?
Lloyd McKenzie (Feb 03 2021 at 17:32):
Only if the CapabilityStatements are narrow enough
Uday Kiran (Oct 11 2021 at 10:41):
As per the Jira: FHIR-30889 and from this forum the requirement was to mandate the CapabilityStatement.implementationGuide refer to the US Core. However, in the version history (screenshot below) of the US Core, it is mentioned to mandate the CapabilityStatement.instantiates refering to the aforementioned Jira. The link on "See Change here" redirects me to the CapabilityStatement of US Core, however there is no mention of instantiates nor implementationGuide over there.
link to the version history: http://hl7.org/fhir/us/core/history.html
Can you please confirm if the recommendation is to use implementationGuide but not instantiates for referring to a US Core? I see that it was confirmed earlier however wanted to make sure since the website is referring to instantiates.
Lloyd McKenzie (Oct 11 2021 at 13:09):
@Eric Haas @Brett Marquard
Brett Marquard (Oct 11 2021 at 14:00):
4.0.1- ...I think we may have gotten mixed up in this commit and made change on instantiates .
...
"instantiates" : [
"http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server"
],
"_instantiates" : [
{
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation",
"valueCode" : "SHALL"
}
]
}
],
Brett Marquard (Oct 11 2021 at 14:00):
@Eric Haas is out this week, but before making any changes I want to make sure we aren't missing any discussions on this commit
Uday Kiran (Oct 20 2021 at 10:58):
Hi @Eric Haas , following up on the above query related to instantiates and implementationGuide.
Also, curious to know if the following statement will change to implementationGuide as well?
link: http://hl7.org/fhir/uv/bulkdata/STU1.0.1/operations/index.html
Eric Haas (Oct 20 2021 at 15:30):
Here is why it is instantiates and not implementationGuide (or imports)
- instantiates: Reference to a canonical URL of another CapabilityStatement that this software implements. This capability statement is a published API description that corresponds to a business service. The server may actually implement a subset of the capability statement it claims to implement, so the capability statement must specify the full capability details.
- implementationGuide: A list of implementation guides that the server does (or should) support in their entirety.
- imports: Reference to a canonical URL of another CapabilityStatement that this software adds to. The capability statement automatically includes everything in the other statement, and it is not duplicated, though the server may repeat the same resources, interactions and operations to add additional details to them.
US Core Capabability Statements is used to document a set of expected requirements. In other words it is not implementable out of the box to be used to describe an actual implementation. For example, it has a "patient +1" clause ...
The US Core Server SHALL:
Support the US Core Patient resource profile.
Support at least one additional resource profile from the list of US Core Profiles.
So there is no way to instantiate it without deciding exactly what parts you support and documenting them in your own capabilities. Hence instantiates is the appropriate element to use to reference a requirements type CapabilityStatement provided in an implementation guide. We discussed whether to document how to transform this requirements type to an Instance type CapabilityStatement, but for now that is an exercise left to the implementer.
Robert Scanlon (Oct 20 2021 at 17:46):
I get confused sometimes when these elements are about the US Core CapabilityStatement itself (e.g. title, kind -- which obviously are), and when they are defining requirements on implementations. To be clear here, the expectations is that implementation CapabilityStatements (served from /metadata) SHALL have 'instantiates' referencing this US Core CapabilityStatement? Or are you not saying that?
Robert Scanlon (Oct 20 2021 at 17:54):
We discussed whether to document how to transform this requirements type to an Instance type CapabilityStatement, but for now that is an exercise left to the implementer.
Has anyone tried representing these requirements as constraints in a CapabilityStatement profile (CapabilityStatement.kind='instance', CapabilityStatement.rest.resource is 2..n, CapabilityStatement.rest.resources includes Patient, CapabilityStatement.instantiates includes us core..')? We are essentially doing this in a non-standard way within our tests. And I know I've made mistakes in our translation in the past.
Eric Haas (Oct 20 2021 at 20:01):
To be clear here, the expectations is that implementation CapabilityStatements (served from /metadata) SHALL have 'instantiates' referencing this US Core CapabilityStatement?
Yes and use conformance expectation on everything that is an expectation.
Uday Kiran (Nov 08 2021 at 07:12):
Thank you @Eric Haas for clarifying on the difference among instantiates, implementationGuide and imports. This clarifies my question on the question related to the link [http://hl7.org/fhir/uv/bulkdata/STU1.0.1/operations/index.html]. The way I interpret from the above discussion is CapabilityStatement.instatiates will refer to the US Core profile ( as indicated in the specification: http://hl7.org/fhir/us/core/conformance-expectations.html) but not CapabilityStatement.implementationGuide as indicated in the Jira: FHIR-30889: mandating that CapabilityStatement.implementationGuide refer to US Core? Please confirm if its otherwise.
Eric Haas (Nov 08 2021 at 15:35):
I am confused by your question. The tracker you referenced led to instantiates being used and the guidance on the page and CapabilityStatement.implementationGuide not being used. We have provided no guidance on using .implementationGuide in US Core
Uday Kiran (Nov 09 2021 at 08:53):
I apologize for the confusion. I was referring to the statements where I noticed a difference between the summary of the Jira: FHIR-30889 which says to "mandate CapabilityStatement.implementationGuide to the US Core" and the US Core specification which says to mandate CapabilityStatement.instantiates. I was not sure which statement to follow, hence posted the question initially here. However, based on the discussion above, we need to use .instantiates and ignore the summary in the Jira. This was just my interpretation, hence posted again for confirmation on this.
Yunwei Wang (Nov 09 2021 at 15:22):
The JSON file (http://build.fhir.org/ig/HL7/US-Core/CapabilityStatement-us-core-server.json.html) is more clear:
a server SHALL instantiate us-core-server and SHOULD implement bulk-data and smart app lunch (?).
@Eric Haas is the first url correct?
"implementationGuide" : [
"http://fhir-registry.smarthealthit.org",
"http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata"
],
Eric Haas (Nov 09 2021 at 17:03):
from the current package:
{
"resourceType": "ImplementationGuide",
"id": "ig",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>SMART Application Launch Framework</h2><p>The official URL for this implementation guide is: </p><pre>http://fhir-registry.smarthealthit.org/ImplementationGuide/ig</pre></div>"
},
"url": "http://fhir-registry.smarthealthit.org/ImplementationGuide/ig", //<<<<<<<<<<<<< I guess not :-(
"version": "1.0.0",
"name": "SMART Application Launch Framework",
\\...
Eric Haas (Nov 09 2021 at 17:04):
can you make a tracker as a technical correction?
Eric Haas (Nov 09 2021 at 17:05):
I think this changing too when we publish smart
Yunwei Wang (Nov 09 2021 at 17:54):
https://jira.hl7.org/browse/FHIR-34281
Virginia Lorenzi (Jan 05 2022 at 03:47):
There are now a good amount of EHR endpoints out there and I am guessing that most support at least one IG but that some of the vendors support a multitude of Implementation Guides. When I teach people about FHIR I tell them trust me when they say R4 they mean this US Core spec, when they say DSTU they mean this Argonaut spec, etc. Sure would be nice if they could be counted on to list the implementation guides they supported. Do any prod fhir endpoints list IGs?
Rik Smithies (Jan 05 2022 at 11:05):
Hi Virginia, not to answer your question directly, but "supporting R4" is definitely not "supporting US Core". Even if we ignore non-US servers (which have no particular need to support US Core), R4 and any profile are somewhat orthogonal concepts.
I can have a server that only supports one resource, e.g. Organization, but what it supports (which may not even be all of that resource), conforms to the R4 definition of Organization, not the STU3 version.
Basically, version is not a scope. An IG would say what scope/parts of FHIR you support (and would normally specify a certain target FHIR version also). But supporting a FHIR version says nothing about what parts of FHIR you support, only that what you do support conforms to how it is from R4.
Last updated: Apr 12 2022 at 19:14 UTC
