FHIR2 and basic authentication

Tags: #<Tag:0x00007f5ff8a1a590> #<Tag:0x00007f5ff8a1a4c8>

Sorry if this thread is dragging out a bit… but we’re still unsure how to use the FHIR2 module without OAuth, now that we have put that off until a later stage.

I think I have read all the REST2 Wiki manual pages, but I don’t see any instructions for using different kinds of authentication (username/password would be our default starting point).

When making REST calls, e.g.

http://our.domain:8080/openmrs/ws/rest/v1/person/f8d9a876-7d88-11eb-88ec-028261138cac

And I’m not authenticated, I get back an authentication request using username/password - when called from my Mozilla browser, and then a JSON file with the correct result. My colleagues have also done this using Java and embedding the username/password with the same successful result.

However, when looking up the same resource via the rest2 URL:

http://our.domain:8080/openmrs/ws/fhir2/Patient/f8d9a876-7d88-11eb-88ec-028261138cac

I just get back a plain:

HTTP Status 401 – Unauthorized

What is the default authentication/authorisation mechanism for FHIR2? Did I miss a documentation page? Or a module configuration step?

[BTW: We also tried invoking the Swagger documentation URL, and get the same 401 response.]

Thanks, Keith

If you don’t already have a valid session started, the FHIR2 module assumes that you’re using pre-emptive HTTP Basic authentication. That’s a bit hard to do in the browser (I mostly assumed this would be done by clients), so we should probably fix that. I’ll also add some docs to the Wiki.

BTW, the URL should be something like:

http://our.domain:8080/openmrs/ws/fhir2/R4/Patient/f8d9a876-7d88-11eb-88ec-028261138cac

1 Like

Thanks Ian,

I think we may have discovered the problem (in the URL that you give as an example). Unfortunately all the Wiki pages for the mapped resources give URLs of the form: “/ws/fhir2/{resource, e.g. Patient}/{uuid}”, and so we had not been using the “/R4/”.

I refer to Patient Resource - Projects - OpenMRS Wiki and all the other pages under the header page: Mapped FHIR Resources - Projects - OpenMRS Wiki

Perhaps the documentation should state: “/ws/fhir2/{release}/Patient/{uuid}”, and a cross-reference given to how to discover that the {release} is currently “R4”.

Is this Release 4 the same for all FHIR Resources implemented in the module, or does it depend on the maturity level of the FHIR Resource releases?

I know that Wiki edit privileges are limited for good reasons, but I would happily volunteer to edit such changes as a contribution back to the community for all your assistance to us.

Finally - I also didn’t expect to be able to use a browser to access REST or FHIR resources, I was just cutting and pasting URLs, and was pleasantly surprised to see that in the REST case, Firefox intercepted the No Auth response, and popped up a UserName/Password dialog, and the completed the request for me. It doesn’t seem to do this with the correct (/R4/) URL for FHIR, so I’m handing this back to my colleagues using Java and Javacript toolkits to make their REST/FHIR calls.

Cheers, Keith

That would be awesome!!! Just ask help desk for access to the wiki. :slight_smile:

That’s an unfortunate artefact of how the module has developed… At one point /ws/fhir2/Patient/{uuid} was actually correct.

The R4 derives from the FHIR Release numbering so “R4” means FHIR Release 4 (the current version of the FHIR spec). We also support “R3”, meaning the FHIR Release 3. When it’s released, we’ll likely add support for R5. This is independent of the FHIR maturity model and more to do with accommodating syntax differences between the different releases of FHIR (e.g., in R3 the resource that handles orders for lab tests is called “ProcedureRequest”, but is part of the “ServiceRequest” resource in R4).

Thanks again for your timely advice guys,

I’ll look into the Wiki editing soon…

Ian - thanks - that’s exactly what I expected (R4 = FHIR release)… are there any legacy R3 implementations in the module for Release 3? If you could write a Wiki page that mentions the meaning of “{release}” in the URLs, and what’s supported in the current OpenMRS Module, I’d appreciate it. Then then I can refer to that page, and in future you can just update the valid “R__X__” documentation in one place, and all the other pages can stay the same.

cheers,

Keith

I thought I already covered something something like that in the first paragraph of the Wiki page under FHIR Support in 1.0.0:

Note that all URLs are prefixed with the OpenMRS URL prefix (usually " /openmrs “) and the FHIR module-specific prefix (” /ws/fhir2/ "), the FHIR version, and then the resource name. The FHIR module suppports both FHIR R4 and DSTU3. For R4, use URLs with /R4 . For DSTU3, use URLs with /R3 . So, for example, the full URL for a Patient resource might be something like: http://localhost:8080/openmrs/ws/fhir2/R4/Patient/{uuid} .

If you have any suggestions for how that can be improved or made more obvious, please let me know!

Almost everything supported by the main module is supported for both release 4 and release 3. The parts that are unsupported are only in SNAPSHOT builds and aren’t yet released.

Hi @ibacher and the FHIR2 team.

I have now been granted Wiki editing privileges, and I assume you will now have received notifications for the updates I made to most of Mapped FHIR Resources - Projects - OpenMRS Wiki documentation pages. If you didn’t see my edit notes, most of them say:

“edited the URLS to include the {release} part, and added a note explaining the values that can be used for {release}, i.e. R3 and R4”

In one case, where “R4” was already in the URL verbatim, I changed the URL to use {release} for consistency, and the note to say that only “R4” was a valid {release} version, and asked the page author to verify.

I have a few questions about other inconsistencies that I noticed.

  1. AllergyIntolerances does not follow the format of the other FHIR2 documented mappings - i.e. it is missing the attribute mapping table that is present in most other pages. Can someone please encourge the implementer to document the mappings. (I am self-interested here, as it’s one of the resources we are planning to import from OpenMRS. If the module/mapping author is not available, I can deduce the mappings once we successfully create and transfer instances of AllergyIntolerance - but this is best validated by someone with clinical knowledge of the OpenMRS data attributes, which I don’t have).
  2. Some pages are left over from the original FHIR implementation, and do not have FHIR2 URLs for their RESTful APIs. Should these be left there? Are they also mapped like this for FHIR2? Should they be retired, or moved to another location? IMO the mixture of FHIR and FHIR2 mappings is not useful, as people are unlikely to be using both modules at once.

cheers, Keith

1 Like