FHIR Chat · Capability statement and openAPI · implementers

Stream: implementers

Topic: Capability statement and openAPI


view this post on Zulip Hans van Amstel (Mar 16 2020 at 10:37):

I am trying to use the capability statement to describe the role a fhir server plays in a scenario. Using the IG publisher tool the openapi spec is generated that I would like to use. As inspiration I look at: https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html this nicely shows the search parameters, combinations of these etc.
the following I have not been able to do and would like to know of it is possible and how to do this:
-In the generated openapi spec I would like to have a post message e.g. $apply how to code this in the capability statement inorder to achieve this?
-How do I define the response as a bundle of certain resources in the capability statement?
-The table with all the search parameters in the IG generated by IG publisher can that table be generated from the capability statement by the IG publisher tool, how do I do this?

view this post on Zulip Grahame Grieve (Mar 16 2020 at 11:21):

I'm not exactly sure what the openapi bit has to do with the other questions...

view this post on Zulip Grahame Grieve (Mar 16 2020 at 11:21):

what's "$apply"

view this post on Zulip Grahame Grieve (Mar 16 2020 at 11:22):

you need a profile on the bundle

view this post on Zulip Grahame Grieve (Mar 16 2020 at 11:22):

the page you refer to is hand written, I think

view this post on Zulip Hans van Amstel (Mar 16 2020 at 14:21):

The $apply is just an example of an method that I would like to represent in the capability statement in such a way that the generated openAPI spec marks it as post and not get,put etc.
OK, I kinda hoped that this table was generated as the information is available in the capability statement.

view this post on Zulip Gino Canessa (Mar 16 2020 at 14:40):

I'm working in this area right now (generating OpenAPI). Once I finish jumping through hoops, it will be available on GitHub.

The capability statement does not have enough information to produce the output you want, you also need to parse the various definition files.

For example, there are files for everything core to the standard in the relevant FHIR NPM (e.g., OperationDefinition-ActivityDefinition-apply.json, SearchParameter-AllergyIntolerance-verification-status.json, etc.).

For profiles, this gets trickier. Essentially, you have to manually discover where the computable files are (if they are posted) and add them that way. In some cases, the URL listed in the statement will lead you to a computable version, other times it leads to a human-readable page, which may or may not contain links to the files you want (e.g., they may or may not exist). A note here is to make sure you then grab the correct version of those files (e.g., DSTU2 vs R4). I started a thread on this the other day (1-2 weeks ago?).. either here or in the #conformance stream.

For things published 'officially', there is a general pattern, for non-official versions there's a lot of hope in the process.

view this post on Zulip Hans van Amstel (Mar 16 2020 at 15:36):

@Gino Canessa Really interesting. I was looking into a way to use the generated IG + openAPI spec as a formal description for setting up a new FHIR server.

view this post on Zulip Eric Haas (Mar 16 2020 at 19:40):

The template for the narrative generation for USCore-like capabilty statements is available in Jupyter here:

![Binder](https://mybinder.org/badge_logo.svg)

under CapStatement/Narrative_generator.ipynb

It requires the CS resource json file and the IG NPM package as inputs. I have not completed all the documentation.

view this post on Zulip Grahame Grieve (Mar 16 2020 at 21:37):

For profiles, this gets trickier. Essentially, you have to manually discover where the computable files are (if they are posted)

this makes no sense to me

view this post on Zulip Grahame Grieve (Mar 16 2020 at 21:38):

use the package

view this post on Zulip Josh Mandel (Mar 16 2020 at 21:42):

For core content, it's all published in npm; but a Capability Statement can also point to profiles and search parameters outside of core.

view this post on Zulip Grahame Grieve (Mar 16 2020 at 21:44):

any IG we publish, all references will be to something in a package

view this post on Zulip Josh Mandel (Mar 16 2020 at 21:44):

But a server isn't limited to using IGs we publish. (Also, re: IGs we publish: what's the best/easiest way to find a complete set of all packages that exist?)

view this post on Zulip Gino Canessa (Mar 17 2020 at 14:09):

Grahame Grieve said:

any IG we publish, all references will be to something in a package

Yes, anything published by HL7 will have a package. However, unless I missed something the other day, they are NOT required to use versioned links. So, you can try to grab a package, but it may not be valid for you.

As Josh mentioned though, not everything gets published via HL7. For anything 'external', it's checking and hoping (e.g., the server may have the relevant definition on the server, the URL may be to a page that points to one, the URL may be the definition file, etc.). Unless I missed something?

view this post on Zulip Grahame Grieve (Mar 17 2020 at 18:46):

for stuff not published by HL7 and some affiliates, yes, you're right


Last updated: Apr 12 2022 at 19:14 UTC