endpoint REST del Test Catalog

Uncategorized
1

Hello,

Yes, I meant to post this question on OpenELIS Global Talk. Thank you for pointing me in the right direction.

I am working on an integration between OpenELIS Global and OpenEMR. My goal is to access the OpenELIS test catalog programmatically, including information such as:

  • Test ID

  • Test name

  • Test description

  • Test section

  • Sample type

  • Units

  • Active/inactive status

  • Other related catalog information

I understand that there has been work on exposing the Test Catalog through a REST endpoint.

Could you please provide information about:

  1. The REST endpoint(s) currently available for accessing the Test Catalog.

  2. Whether the endpoint is already available in the develop branch.

  3. The authentication method required to access it.

  4. Whether it is possible to create a dedicated API/service user with read-only access.

  5. Any available documentation, OpenAPI/Swagger definition, or examples.

I am currently running OpenELIS Global 2 from the develop Docker images.

The purpose is to synchronize or query the OpenELIS Test Catalog from OpenEMR without accessing the PostgreSQL database directly.

Thank you very much.

2

Hloo @luis.uriarte

Incase u havent already… you could try GET /OpenELIS-Global/rest/TestCatalog from here? It seems to already be in develop… with the fields it fills as u want all there, see.

There is also a newer &paged one under /rest/test-catalog/tests here

And about the auth question, i think plain http basic should do, and i see both classes are also gated at the top.. i wonder if these cover u needs?

1 Like
3

Hi. Thank you so much.

@wodpachua, this was incredibly helpful. What I need to figure out now is that the user accessing the system must have the Global Administrator role (I don’t like that).
Thanks again, my friend.

1 Like
4

Hloo @luis.uriarte

Glad it helped…

the other direction could be widening the gate itself.. i see other controllers already doing hasAnyRole(...)..

@Moses_Mutesasira @Agaba_Derrick_Junior what would be ur take on this one? would u say widening the catalog GETs to hasAnyRole be something acceptable, or is a read-only role already planned somewhere??

5

Thanks for the quick response and for bringing this up with the team.

I completely agree that widening the GET endpoints or introducing a dedicated read-only / API integration role would be the best approach. Requiring full ADMIN privileges just to fetch reference data like test catalogs goes against the principle of least privilege, especially when managing automated system-to-system integrations.

Having a dedicated ROLE_API_READ (or expanding hasAnyRole on GET catalog endpoints) would allow us to safely query metadata using restricted service accounts without exposing administrative capabilities.

Looking forward to hearing thoughts from @Moses_Mutesasira and @Agaba_Derrick_Junior on this!

6

Hi @luis.uriarte, @wodpachua,

Thanks for tagging me on this,I think you’re both landing on the right instinct.

Widening the existing gate to hasAnyRole(...) with current admin-adjacent roles would work as a quick fix, but I’d rather we not just fold API integrations into roles that carry other permissions they don’t need. A dedicated read-only role (something like ROLE_API_READ or ROLE_CATALOG_READ) is the better long-term design:

  • It keeps service accounts scoped to exactly what they need, no more, no less.
  • It makes it easy to tell from config/logs which accounts are machine integrations vs. human admins.
  • We already have precedent for hasAnyRole(...) gating elsewhere in the codebase, so this isn’t a new pattern, just a new role added to it.
  • As more systems (OpenEMR and others) want to pull reference data, this saves us from repeatedly loosening admin’s implicit surface area.

I don’t think a read-only role is currently planned as far as I know, happy to be corrected if someone’s already working on it. If not, I’d suggest we scope this as a small, contained change: introduce the role, annotate the catalog GET endpoints (TestCatalogRestController and TestCatalogEditorRestController) with hasAnyRole("ROLE_ADMIN", "ROLE_API_READ"), and document how to provision a service account with just that role.

@luis.uriarte, if that direction works for you, I’m happy to help in other way.

1 Like
7

@Agaba_Derrick_Junior Thanks for the quick and thoughtful response — ROLE_API_READ sounds like the right direction to me too, for exactly the reasons you listed (scoped service accounts, clearer audit trail as more systems start pulling catalog data).

I don’t have deep familiarity with the codebase yet (I came in through the OpenEMR integration side), so I’ll hold off on committing to drive the implementation myself for now — but I’m glad to help test against a real deployment once there’s something to try, or pick up smaller pieces if that’s useful. Appreciate you looking into it either way.

Luis

2 Likes