FHIR Chat · OpenAPI Support · implementers

Stream: implementers

Topic: OpenAPI Support

Grahame Grieve (Sep 04 2018 at 23:43):

So the Java reference implementation includes code to produce openAPI documents from CapabilityStatement resources. Yesterday, some one told me that the big problem with FHIR is that it doesn't support openAPI....

Grahame Grieve (Sep 04 2018 at 23:44):

so I presume that the problem is, the tool to produce openapi documents from capability statements is not deployed in a way that implementers can find/use.

Grahame Grieve (Sep 04 2018 at 23:44):

what would change that?

Eric Haas (Sep 05 2018 at 00:06):

Well I think we could add to the downloads page, I haven't had a chance to really integrate into the published output yet.

Grahame Grieve (Sep 05 2018 at 00:06):

add what to the downloads page?

Eric Haas (Sep 05 2018 at 00:07):

are we talking the spec or IGs??? I may be thinking of something else

Eric Haas (Sep 05 2018 at 00:10):

I meant the link to download the openAPI artifacts that are produced in the IG.

Eric Haas (Sep 05 2018 at 00:12):

But for the spec could add to the openAPI Implementation Tools section here: http://build.fhir.org/downloads.html
if its a standalone tool, (not really sure how it works )

Grahame Grieve (Sep 05 2018 at 05:31):

at the moment what I have is code. what kind of tool would be useful?

Nick Hatt (Sep 05 2018 at 13:05):

It sounds like an SEO problem. The first result from FHIR openapi that comes up in google is a Github gist from @nicola (RIO/SS) https://gist.github.com/niquola/b7bce73d581425f147bad4a6f674a363. Searching for FHIR Swagger yields this: https://github.com/bobby-brennan/fhir-swagger.

In terms of what kind of tool would be useful, it probably depends on the user. openAPI can be used to:

• auto-populate routes in an API management tool (so a CapabilityStatement works fine)
• generate structs based on the JSON schema within (so you need to get into the IG and structure definitions to make it work)

Grahame Grieve (Sep 05 2018 at 13:07):

I think that my interest is producing OpenAPI. I think we expect that other communities to provide the tools that consume openAPI

Grahame Grieve (Sep 05 2018 at 13:07):

I'll to a post on it once we figure out what our tooling strategy is

Nick Hatt (Sep 05 2018 at 13:13):

Swagger was "donated" to become OpenAPI, so some will still refer to them as one in the same.

Michael Knoll (Sep 06 2018 at 02:57):

Our team also has some received wisdom that Swagger/Open API doesn't work well with FHIR. Someone thinks it has to do with Swagger not supporting the full capabilities of JSON and that the FHIR spec uses those features of JSON. Does this have any merit? If our project is just to make data available in FHIR format and not describe any specific things about the FHIR files then we should probably be fine with Swagger/OpenAPI to do our documentation right?

Grahame Grieve (Sep 06 2018 at 03:04):

early versions of JSON schema were not up to supporting FHIR at all. More recent versions are theoretically able, but getting a diverse set of json schema validators to agree about a valid json schema is a tough problem.

Grahame Grieve (Sep 06 2018 at 03:05):

the openAPI part is not difficult - there's things we say in our capability statement that are not part of an openAPI document and vice versa, but I think that these differences make sense.

Eric Haas (Sep 06 2018 at 16:31):

OK so here is my proposed approach to openAPI artifacts in IG publications. I will create a link to the openAPI json file on the conformance page. ( Eventually I want to replace the much my documentation with the OpenApi generated docs but still on my todo list.)

I think a nice to have would be a IG-like-Publisher to just create the openApi based on the CapStatements Or a command line tool like the validator...

Yunwei Wang (Sep 06 2018 at 16:42):

:thumbs_up:

Josh Mandel (Sep 06 2018 at 17:35):

@Michael Hansen FYI (since Michael has been doing some work on using OpenAPI representations of a FHIR server's endpoints to configure Azure API Management).

Grahame Grieve (Sep 06 2018 at 21:51):

so the IG publisher does just create the openAPI documents

Yunwei Wang (Sep 06 2018 at 22:34):

IG publishing tool is powerful but too complicated. It would be better to have a simpler tool to generate openAPI document from CapabilityStatement.

Grahame Grieve (Sep 06 2018 at 22:42):

what would that tool look like?

Eric Haas (Sep 06 2018 at 22:45):

a command line tool? inputs = Capstatement output = openAPi??? or is it not that simple?

Grahame Grieve (Sep 06 2018 at 22:46):

well, that's what the publisher is - a command line tool

Grahame Grieve (Sep 06 2018 at 22:46):

that's too complicated...

Josh Mandel (Sep 06 2018 at 22:57):

Michael has taken the a quick pass at building a tool that reads the capability statement and spits out and OpenAPI document matching the interactions listed in that statement. It doesn't get into details of data profiling, however. I wonder to what degree those kinds of details should be reflected?

Josh Mandel (Sep 06 2018 at 22:57):

(the tool is also wrapped as a web service so you can call it with a URL to a capability statement and it returns the JSON.)

Grahame Grieve (Sep 06 2018 at 22:58):

it should at least use the base JSON Schema for resources

Grahame Grieve (Sep 06 2018 at 22:59):

and it would be interesting to compare outputs.

Grahame Grieve (Sep 06 2018 at 23:00):

https://build.fhir.org/ig/HL7/US-Core/CapabilityStatement-server.json

Grahame Grieve (Sep 06 2018 at 23:00):

vs

Grahame Grieve (Sep 06 2018 at 23:02):

https://build.fhir.org/ig/HL7/US-Core/CapabilityStatement-server.openapi.json

Grahame Grieve (Sep 06 2018 at 23:02):

only that is not turned on for US core

Lloyd McKenzie (Sep 06 2018 at 23:05):

Does the OpenAPI spit out the JSON and RDF too?

Grahame Grieve (Sep 06 2018 at 23:05):

no RDF. just json

Grahame Grieve (Sep 06 2018 at 23:06):

and xml

Michael Hansen (Sep 07 2018 at 20:38):

Sorry for being late here. I did create a small service, which can be used to return an openapi definition from a capability statement. It's pretty simplistic right now, e.g. try

GET https://fhir2apim.azurewebsites.net/api/Swagger?fhirserver=http://hapi.fhir.org/baseDstu3/

Most notably it does not include the JSON schemas for the resources. I do have a version that does that, but I was struggling with the fact that there is so many references within each resource definition and a lot of services that ingest the openapi files struggle with that.

Grahame Grieve (Sep 07 2018 at 20:43):

there is so many references within each resource definition

which set of json schemas are you using?

Michael Hansen (Sep 08 2018 at 00:47):

there is so many references within each resource definition

which set of json schemas are you using?

https://hl7.org/fhir/fhir.schema.json

Grahame Grieve (Sep 08 2018 at 00:48):

try with these

Grahame Grieve (Sep 08 2018 at 00:48):

https://build.fhir.org/fhir.schema.json

Grahame Grieve (Sep 08 2018 at 00:49):

but in general, json schema is only now able to describe our json, and tooling support seems very hit and miss; I cannot get a consistent set of schema and resources and tools to all agree

Michael Hansen (Sep 08 2018 at 00:52):

I'll try a bit later on this weekend. Have to go back and rework some code, but looking at it quickly there are still a few issues that some tools will not like: 1) all the definitions refer to other definitions (that refer to other definitions), some import tools don't like that, even if it is technically OK, 2) some tools complain about things like:

"type": {
          "description": "The kind of specimen conditioned for testing expected by lab.",
          "$ref": "#/definitions/CodeableConcept"
        },

Having a description and then a reference (that may have a description). Not sure what is technically right or not, but I have seen errors due to that.

Lloyd McKenzie (Sep 08 2018 at 00:55):

Having descriptions on both property and type seems to be a pretty fundamental thing - I might well have three different properties all with a type of CodeableConcept. I'm certainly going to want different descriptions for each. And I'll want a description on CodeableConcept to explain what it's for. Any tool that can't handle that has a very simplified view of the world...

Michael Hansen (Sep 08 2018 at 00:59):

Definitely agree with that, but that was one of the things that were flagged in editor.swagger.io.

Grahame Grieve (Sep 08 2018 at 01:01):

all the definitions refer to other definitions (that refer to other definitions)

There should only be element/type in there, like the one you quoted. there shouldn't be anything else

Mario Hyland (Sep 17 2018 at 17:25):

Engaging @Mark Scrimshire - have you seen this thread

Mark Scrimshire (Sep 17 2018 at 21:35):

Engaging @Mark Scrimshire - have you seen this thread

@Mario Hyland If I come across anyone interested in FHIR, whether in Government or the Private Sector I encourage them to get to a Connectathon :)

Karl M. Davis (Oct 02 2018 at 03:47):

Has anyone dragged Kin Lane into this conversation?

Karl M. Davis (Oct 02 2018 at 03:48):

I know he expressed an interest in seeing this get resolved -- and maybe helping? I dunno', it was a while ago.

Karl M. Davis (Oct 02 2018 at 03:48):

Anyways, I'll point him here on the twitters.

Karl M. Davis (Oct 02 2018 at 03:55):

https://twitter.com/karlmdavis/status/1046971432507461639

Michael Hansen (Feb 19 2019 at 05:21):

I wanted to pick this discussion up again. @Grahame Grieve , any news on this? I have been searching here on Zulip and other places. As best as I can tell, the server.openapi.json files produced in the IGs are not valid. Even the most basic OpenAPI specs such as this example https://gist.github.com/hansenms/2cf6692186d98084343020244b2affaf cause editor.swagger.io to crash when inspecting the operation, etc. Do we have any tooling out there that can produce an OpenAPI spec (with schema references)?

Grahame Grieve (Feb 19 2019 at 05:23):

what's invalid about them?

Michael Hansen (Feb 19 2019 at 06:18):

what's invalid about them?

Well, take this one for instance: https://build.fhir.org/ig/HL7/cdmh/server.openapi.json , the references to the schema look like: http://hl7.org/fhir/STU3/fhir.json.schema#/definitions/OperationOutcome. The actual URL for the schema is https://www.hl7.org/fhir/STU3/fhir.schema.json so all the references are incorrect. There are a number of other structural and resolver errors.

Grahame Grieve (Feb 19 2019 at 06:19):

so this is a chronic problem that everyone has a different answer to: the difference between logical and literal references for schema. I am assured that the references are logical not literal

Michael Hansen (Feb 19 2019 at 06:47):

so this is a chronic problem that everyone has a different answer to: the difference between logical and literal references for schema. I am assured that the references are logical not literal

Sorry for being a bit slow here. Can't say that I am an OpenAPI expert by any stretch, so I may be totally misunderstanding something. I am not sure what you mean by the distinction between logical and literal references, but the references in the openapi specs in the IGs are URL references (OpenAPI spec: https://swagger.io/docs/specification/using-ref/). It is expected that they be resolved. The current URLs refer to schema URLs that don't exist. The reference within the schema, e.g. #/definitions/OperationOutcome may be correct, but the URL itself is not. Moreover, when they are actually corrected, they cause most commonly used tooling, e.g. https://editor.swagger.io, to break. There are also structural errors, e.g. info must have title, etc. So I am wondering, how are these OpenAPI specs validated?

Grahame Grieve (Feb 19 2019 at 07:04):

Even though the value of a $ref is a URI, it is not a network locator, only an identifier. This means that the schema doesn’t need to be accessible at that URI, but it may be. It is basically up to the validator implementation how external schema URIs will be handled, but one should not assume the validator will fetch network resources indicated in $ref values.

Grahame Grieve (Feb 19 2019 at 07:05):

https://json-schema.org/understanding-json-schema/structuring.html

Grahame Grieve (Feb 19 2019 at 07:05):

you might take this up with one of those communities....

Grahame Grieve (Feb 19 2019 at 07:05):

I validate the json schema with json schema tools

Michael Hansen (Feb 19 2019 at 15:07):

So if the URL is not meant to be accessible, what is it meant to do? If the schema cannot be found either in the openapi spec file itself or as a remote schema then what is the purpose of the reference?
I understand that our schema is a valid schema file, what I am saying is that the openapi spec generated by the IG builder is not a valid openapi spec. How is the openapi spec validated?

Grahame Grieve (Feb 19 2019 at 17:42):

it's not validated (obviously). How should it be validated?

Michael Hansen (Feb 19 2019 at 17:51):

it's not validated (obviously). How should it be validated?

Yeah, that is a good question ;) I think something like openapi-lint would catch the structural errors, but there are also tools that will try to resolve all the schema references and see if it is still valid.

So I think the challenge is that one can have a perfectly valid json schema that will not work well for an openapi spec. The json schema has uses beyond creating an openapi spec, but the question is if the current one can actually be used for an openapi spec. And if we have tooling, such as the IG publishing tools that generate an openapi spec, what can we do to validate it in that context.

The purpose of having an openapi spec would be to be able to leverage other tools out there that generate client libraries, connectors, etc. If it cannot be used for that purpose, then we should maybe rethink that?

Grahame Grieve (Feb 19 2019 at 17:54):

well, that's certainly the purpose. I've just found this whole area very troublesome - json schema itself has been a moving target and even now the tools differ over interpretations inside the the content. I think that 3 of the current 6 json schema tools agree enough to interpret the FHIR schemas correctly. I expect that we'll have more problems reported on them

Grahame Grieve (Feb 19 2019 at 17:54):

that openAPI deviates from json schema (this is the second place I've found that) makes matters worse...

Grahame Grieve (Feb 19 2019 at 17:54):

I

Grahame Grieve (Feb 19 2019 at 17:54):

I'll do a round of development on this next month (once I stop travelling). The code is here:

Michael Hansen (Feb 19 2019 at 17:57):

I'll do a round of development on this next month (once I stop travelling). The code is here:

Think the code link was missing. In any case, I have been doing quite a bit of exploring myself and I share your frustration. If there is something I can do to help, then I would be happy to.

Grahame Grieve (Feb 19 2019 at 17:57):

package org.hl7.fhir.igtools.openapi in the FHIR github https://github.com/HL7/fhir/tree/master/tools/java/org.hl7.fhir.igtools/src/org/hl7/fhir/igtools/openapi

Grahame Grieve (Feb 19 2019 at 17:57):

I was just digging it up

Grahame Grieve (Feb 19 2019 at 17:58):

well, I'll get back to you for testing help once I have revisited the generation

Jens Villadsen (Mar 01 2019 at 10:18):

@Grahame Grieve would you mind extracting either the openapi package from the publisher as a separate lib and put in eg. the https://github.com/hapifhir/org.hl7.fhir.core repo or extract the igpublisher and put it there (I'll also be willing to do it if you will accept my PR's).

I can tell that the OpenAPI package does not refer to any other libraries than the hapi r4 structure defs. Having it extracted and separated out makes it easier to enhance its generation for others (such as myself). I can't say that I've been digging deep into the OpenAPI spec, but I can say that https://editor.swagger.io have some complaints about the generated OpenAPI and branching the entire FHIR spec for introducing bug fixes and new features to the generation seems a bit overkill.

Grahame Grieve (Mar 01 2019 at 11:38):

I'm planning to move the igpublisher to maven (in a different repository). But I'll not be doing it until late April when there's no pressure on the publishing system - the downstream impact for moving core was considerable

Grahame Grieve (Mar 01 2019 at 11:39):

I will consider moving the OpenAPI stuff when I get a chance - internally, I'm midway through migrating the build to R5, and I need to commit that first

Zoltan Simon (Mar 01 2019 at 21:58):

Hi, A newbie on board. I was just about looking for tooling for generating swagger (openAPI) but there was no reference https://www.hl7.org/fhir/. I've actually found an external tool https://github.com/bobby-brennan/fhir-swagger/ but unfortunately it is generating faulty swagger file. (It seems actually the metadata on the test server contains duplications that the tool cannot recognize that). The tooling you referring is something similar? How someone new can find the toolbox around fhir?

Lee Surprenant (Mar 05 2019 at 13:54):

Dumb question: what is the scope of the https://github.com/hapifhir/org.hl7.fhir.core repo? I also recently saw an announcement for https://github.com/FHIR/packages and I'm having a little trouble following the intent of the various repos.

Lloyd McKenzie (Mar 05 2019 at 15:47):

@Grahame Grieve @James Agnew

Grahame Grieve (Mar 05 2019 at 17:36):

the core repository contains the code that is shared between the build and HAPI. Specifically: generated model code and related utilities, + the FHIR validator

Brian Postlethwaite (Apr 03 2019 at 11:38):

Should this be returning something, or is that value more like a canonical than an explicit thing?
https://hl7.org/fhir/STU3/fhir.json.schema
https://editor.swagger.io seems to want to resolve it explictly (it could be wrong too)

Brian Postlethwaite (Apr 03 2019 at 11:38):

(yes I'm no OpenAPI/Swagger expert either)

Grahame Grieve (Apr 04 2019 at 00:47):

the problem is that Json schema says that the URLs are not literal. And openAPI says that they are

Grahame Grieve (Apr 04 2019 at 00:47):

and I don't know how to resolve that

Brian Postlethwaite (Apr 04 2019 at 01:07):

Also, should I expect the search parameters to be extracted into it?

Grahame Grieve (Apr 04 2019 at 01:07):

yes.

Brian Postlethwaite (Apr 04 2019 at 01:07):

Ok, I must have something not quite right in my IG still.

Grahame Grieve (Apr 04 2019 at 01:09):

could be my code....

Grahame Grieve (Apr 04 2019 at 01:09):

no looks like I haven't got to that yet

Grahame Grieve (Apr 04 2019 at 01:10):

I'm doing a round of dev on the open api stuff in the next few days - will do that thne

Brian Postlethwaite (Apr 04 2019 at 01:12):

Cool. The other thing I spotted was that the parameters in the read calls aren't there too as in {rid} and {hid} aren't defined.

Grahame Grieve (Apr 04 2019 at 01:22):

can you show me an example of what you mean?

Brian Postlethwaite (Apr 04 2019 at 01:26):

pasted image
pasted image
I can go dig for what the OpenAPI should look like to define that...

Brian Postlethwaite (Apr 04 2019 at 02:12):

While you're looking at the OpenAPI stuff, the definition of many search parameters, and operation definitions will be from dependencies rather than local to the IG. I'm sure you're aware of that, but it's what my IG has and thought I'd put that fresh in mind while you're into it.

Brian Postlethwaite (Apr 04 2019 at 03:02):

And one more item, the Type History e.g. /ValueSet/_history

Brian Postlethwaite (Apr 04 2019 at 03:50):

Anyone know where can we find the latest https://hl7.org/fhir/STU3/fhir.json.schema file?

Grahame Grieve (Apr 04 2019 at 04:20):

doesn't matter where the content is declared

Grahame Grieve (Apr 04 2019 at 04:21):

https://hl7.org/fhir/STU3/fhir.schema.json

Brian Postlethwaite (Apr 04 2019 at 05:23):

Then should the value be the other way around that is generated, or doesn't that matter?
https://swagger.io/docs/specification/using-ref/ is where I was looking.
and here too:
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#document-structure

Grahame Grieve (Apr 04 2019 at 05:29):

well, that's the issue with literal vs logical. I deliberately chose not to use literal because of versioning problems

Brian Postlethwaite (Apr 04 2019 at 05:50):

The literal here is going to the versioned location, but I'm sure that's not what you're referring to right?

Brian Postlethwaite (Apr 04 2019 at 06:05):

Should the generation process save that file in each guide that its generated, and then reference the local file, rather than an absolute one?
Then versioning would be quite explicit?

Grahame Grieve (Apr 04 2019 at 06:06):

I don't know that that means

Brian Postlethwaite (Apr 04 2019 at 06:15):

copy the file at https://hl7.org/fhir/STU3/fhir.json.schema (or whichever version you need) into the local IG output (not an external reference) then the format is $ref: 'fhir.schema.json#/definitions/Bundle'

Brian Postlethwaite (Apr 04 2019 at 06:16):

Then its now an IG specific reference, still external to the core document problem, but will resolve relative to the location of the generated file.

Brian Postlethwaite (Apr 04 2019 at 06:16):

Thus ducking the version problem (as the IG Publisher has decided that) and is still relative to the generated code.

Grahame Grieve (Apr 04 2019 at 07:21):

doesn't help if you are working across IGs

Brian Postlethwaite (Apr 04 2019 at 09:30):

Nope.

Brian Postlethwaite (May 14 2019 at 02:41):

Have 3 more bug fixes for the OpenAPI support:
1. Parameters components casing is mixed
Upper case when used, lower case when defined

      parameters:
        - $ref: '#/components/parameters/summary'
        - $ref: '#/components/parameters/format'
        - $ref: '#/components/parameters/pretty'
        - $ref: '#/components/parameters/elements'

2. ETag definition is missing the schema

            ETag:
              description: Version from Resource.meta.version as a weak ETag
              schema:
                type: string

3. Need rid and hid parameters defined and included where required in the GET DELETE HISTORY and other operations

        - $ref: '#/components/parameters/rid'
        - $ref: '#/components/parameters/hid'

    rid:
      name: rid
      in: path
      description: The Resource.Id for a specific resourcetype
      allowEmptyValue: false
      required: true
      style: simple
      explode: false
      schema:
        type: string
    hid:
      name: hid
      in: path
      description: The Resource.Meta.VerionId for a specific resourcetype
      allowEmptyValue: false
      required: true
      style: simple
      explode: false
      schema:
        type: string

The other thing that would be a "nice to have" is to filter down the search parameter descriptions to only the resource type that is being output.
e.g. Don't show the description details for Patient, Person and RelatedPerson when outputting the Practitioner search operation

This is then very close to being able to work with the Swagger editor (even though it consumes a ridiculous amount of memory trying to process things.

Brian Postlethwaite (May 14 2019 at 02:46):

Is there any thought on generating the STU3 json schema files like this one?
https://www.hl7.org/fhir/R4/practitioner.schema.json.html
And the actual .json file isn't there, only the html version of that file.

Brian Postlethwaite (May 14 2019 at 13:05):

@Grahame Grieve was also thinking about producing a cut down version of the json schema embedded into itself based on the base profile for the resource defined in the guide, and not include any extensions or contained resources not defined in the profile, essentially then cutting it down to a restricted level, removing the issues with nesting. Thoughts?

Grahame Grieve (May 14 2019 at 13:20):

It’s on my todo list

Josh Mandel (May 14 2019 at 18:40):

This would be super valuable -- if as a rough test, It was something simple and limited enough to load in the default tooling from OpenAPI.

Brian Postlethwaite (May 15 2019 at 01:04):

I'm going to take a go at this, might take me a while though.

morgana de cássia oliveira ribeiro (Jun 05 2019 at 18:51):

How do you implement your FHIR HAPI API? Urgent for my TCC.
What resources can I use to represent this UML diagram?
WhatsApp-Image-2019-05-31-at-5.07.29-PM.jpeg

Jose Costa Teixeira (Jun 05 2019 at 18:55):

Hmmm. assuming that not everyone in this forum reads Portuguese...

Jose Costa Teixeira (Jun 05 2019 at 18:58):

@morgana de cássia oliveira ribeiro FHIR is for interoperability and is more specific, and it does not map 1:1 to your ER diagram.
You have patient and device there, which don't even map to your relations (because we have several ways to link patient to device)

Jose Costa Teixeira (Jun 05 2019 at 19:00):

Address is a datatype, not a resource, and could include your Endereco (address), municipio (city) and estado (state)

Jose Costa Teixeira (Jun 05 2019 at 19:01):

Pessoa juridica e pessoa fisica (juridical and physical person) do not really map to resources

Jose Costa Teixeira (Jun 05 2019 at 19:01):

Profissional may map to Practitioner

Jose Costa Teixeira (Jun 05 2019 at 19:02):

Event is not mapping to how we capture things.

Jose Costa Teixeira (Jun 05 2019 at 19:06):

If you need more insight, can you break down the problem and identify what information you are trying to exchange?

morgana de cássia oliveira ribeiro (Jun 05 2019 at 20:05):

Poderia me tirar uma dúvida?

Zulip missed messages <noreply@zulipchat.com> escreveu no dia quarta,
5/06/2019 à(s) 16:00:

Medi Harsini (Jan 08 2020 at 17:01):

@Grahame Grieve can you please advise if there are any progress on this for both to transform StructureDefinition and capabilitystatement from FHIR to OpenApi and potentially swagger ?

Medi Harsini (Jan 09 2020 at 17:29):

Has anyone used an automated tool to generate openapi. I only the tool which transform the capability statement, nothing on the profiles or resources or structure definition or code system etc

Grahame Grieve (Jan 09 2020 at 22:03):

the IG publisher publishes openAPI documents for capability statements, but there are many problems with open api in the json schema

Medi Harsini (Jan 09 2020 at 23:46):

Thanks @Grahame Grieve do you know any other tools which does the rest ?

Grahame Grieve (Jan 09 2020 at 23:57):

does the rest

?

Medi Harsini (Jan 10 2020 at 00:43):

Profiles, structure definitions, terminology and codings

Grahame Grieve (Jan 10 2020 at 03:23):

there's only a limited degree to which you can represent those things. The JSON schema does so the degree that jon schema supports that

Jordi Cabré (May 31 2021 at 10:11):

Hello everyone!
I'm using hapi-fhir-server-openapi.
I'm trying to configure OpenApiInterceptor.
However, when I'm trying to get [baseurl]/fhir/swagger-ui/ I'm getting this log message:

.ExceptionHandlingInterceptor : Failure during REST processing: ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: Unable to process request, this server does not know how to handle resources of type StructureDefinition - Can handle: [Coverage, Organization, Patient, Practitioner, SearchParameter]
2021-05-31 11:42:56.237  INFO 13233 --- [nio-8093-exec-6] fhirtest.access                          : ERROR - GET http://localhost:8093/fhir/swagger-ui/

Any ideas about how to set it up correctly?

Grahame Grieve (May 31 2021 at 12:33):

you might ask on #hapi

Patrick Ryan (Apr 10 2022 at 23:08):

Hi - it seems that the openapi generated by publisher is currently v3.0.2. Is it possible to get it to generate other versions of openap (speciifcally v2)

Grahame Grieve (Apr 11 2022 at 00:28):

@Gino Canessa ?

Felipe Soriano (Apr 11 2022 at 07:01):

Hi @Jordi Cabré, maybe this can help you: https://www.devdays.com/wp-content/uploads/2020/12/zupbb_201120_BrunoRNeves_GenerateAndExposeSwagger_OpenAPIDefinitionsForFHIR.pdf

Felipe Soriano (Apr 11 2022 at 07:07):

Oh no.. pdf implementation is from IBM. Try to see this documentation and not let the swagger enter into intercept
https://hapifhir.io/hapi-fhir/docs/security/authorization_interceptor.html

Gino Canessa (Apr 11 2022 at 14:53):

Looking at a couple of quick examples, it appears the generator is not using anything 'net new' in OAS 3 (e.g., oneOf, anyOf) that are not portable, so you should be able to do a simple conversion. There is not as much tooling for downgrading, but with any library that supports both versions you should be able to 'read 3.x' -> 'write 2.x'.

Alternatively, I have some tooling which can output pieces in either version, though I have not looked at OpenAPI specifically in a while. What is your goal with OpenAPI? If it is something I already support I can go into more detail.

Prince Matthew (Apr 11 2022 at 15:18):

Is this the right place to ask question about HAPI code?

Michele Mottini (Apr 11 2022 at 15:32):

There is a #hapi channel for that

Last updated: Apr 12 2022 at 19:14 UTC