That’s kind of intentional. We have a few global properties, but right now I can’t think of anything we need an admin page specifically for.
We haven’t currently implemented Swagger and I don’t know if we’re going to. If we have automated docs, I’d rather they be generated from the conformance statement than from a lot of manual fussing.
So how is the user supposed to interface with the client , i thought fhir2 was to take the position similar to what was held by fhir at /openmrs/admin/index.htm
The url to access FHIR is
/openmrs/ws/fhir2/. The actual API for FHIR is extensively documented and more specifically for our implementation on the Wiki, but can easily be tested with Postman or more difficultly with cURL. However, for a realistic scenario, I would expect that someone actually wants to connect with any of the available FHIR clients.
All that’s to say, I don’t see the real value add of maintaining pages on the Admin interface. This may change as we add functionality (subscriptions, messaging, etc.) where an administrative page could actually be doing something useful.
Alright Thanks @ibacher
@ibacher this is slightly off context , i realised most of the Service API Interfaces repeat almost the same thing is it possible to create some sort of Generic FhirBaseService interface , so next time we just have to extend it and rapidly develop ?
@tendomart You’re right, that’s an absolutely great idea! We will be looking into adopting it!
And the same applies for the Data Access Layer , it will take some pain to refactor but will save us alot for future usages.I don’t Know how it will be effected without breaking some things.
Hi @ibacher. Our OpenMRS is now set up and we are attempting to make the first FHIR REST calls to it. I saw that the old FHIR settings menu has permitted IP addresses that can be configured, but this is not present in the FHIR2 settings.
How do I set up OpenMRS privileges to provide access to the OpenMRS FHIR URLs for a specific client? I don’t see a security/access control tab in the Wiki documentation. Is this function subsumed by the SMART on FHIR approach with OAuth2 and the use of established OpenMRS user-ids and password access, or is there anything I need to set up in OpenMRS first?
@keithduddy Admittedly, we haven’t implemented any kind of IP filtering in the FHIR2 module, though it wouldn’t be too hard to add if that’s a real need. Without a SMART-on-FHIR implementation, the only real security that the FHIR2 module provides is
If you’re looking at authenticating a specific client application, then SMART-on-FHIR is probably the way to go, primarily because the OAuth2 specification it is built on embodies some best practices around confirming a client’s identity.
That said, one of the reasons I haven’t implemented, e.g., IP filtering is that it’s easy enough to layer a reverse proxy in front of OpenMRS with a more sophisticated series of rules, e.g., to restrict calls to only certain known IPs or to provide request rate limiting, etc.