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.