Implementation of the Order Entry UI application in ReactJs

I think some of your colleagues have already done this for other OWAs. Ask them. :slight_smile:

You might also look at:

Ok Will ask my other colleagues about it as well as look into the documents.

While working on the redesign for the Order Entry UI module, the team found out that the existing JavaScript convention was last modified on 2014-07-03, and it does not specify a guide to be used while working with modern day JavaScript libraries such as React and Redux, which the team is working with. Based on this, the team is suggesting the adoption of the Airbnb JavaScript convention which is more modern and offers support for both updates to the JavaScript language and implementations used in recent libraries. cc: @darius @dkayiwa @geofrocker @zeze @larrystone @betty @flavia

Links:

3 Likes

I completely agree! :slight_smile:

I am trying to access the web services API to get the quantityUnits, route, durationUnits etc. These are foreign keys to Concepts. From the documentation, there is no example on how to retrieve these foreign keys. Pointers on how to do this would be greatly appreciated. Thank you.

cc @darius, @dkayiwa, @betty, @geofrocker, @zeze, @fred, @larrystone

Have you tried checking out how to use the API versioning query. I guess you should look particularly into the ?v=custom option, I guess it seems quite promising for joining tables in your query

@flavia could you give some more detail on what is the REST response you are getting, and what your expectation is?

@darius, in order to retrieve the careSettings , I used axios get with this curl -X GET "http://localhost:8081/openmrs-standalone/ws/rest/v1/caresetting?v=custom:(uuid,display)" -H "accept: application/json". However, to get routes, doseUnits and durationUnits, I understand that I will be using the concept endpoint. I am requesting for pointers on how to specify the class you want to retrieve. I have tried curl -X GET "http://localhost:8081/openmrs-standalone/ws/rest/v1/concept?v=default&class=doseUnit" -H "accept: application/json" but I am got getting the expected results. The response is a 200 with quite long results. I expected to see kilograms, grams etc in the response. results.txt (260.0 KB)

@flavia try the orderentryconfig resource. (https://github.com/openmrs/openmrs-module-webservices.rest/blob/master/omod-1.10/src/main/java/org/openmrs/module/webservices/rest/web/v1_0/resource/openmrs1_10/OrderEntryConfigResource1_10.java)

thank you very much @darius. It summarizes my entire day’s work. I have been trying to fetch the different resources independently :weary: .

Please look at the existing code in the never-fully-complete Angular version of this. It will help you find things like this:

and the other two files in https://github.com/openmrs/openmrs-module-orderentryui/blob/master/omod/src/main/webapp/resources/scripts/

1 Like

Does the style guide have any other documentation apart from this link or is there any other way to use the style guide minus copying elements from the the console? @darius @jteich @dkayiwa

I have been working on adding a drug order. In order to make a POST request to /encounter, an encounterType is required as part of the payload.

Looking through the existing orderentryui module, I noticed admission encounter type being used when making orders for both outpatient and inpatient. Then I saw some description of encounter types here https://demo.openmrs.org/openmrs/admin/encounters/encounterType.list and I couldn’t understand why admission is being picked for both (especially in the case of outpatient).

What determines an encounter type to use when ordering drugs?

I will like your input on this. Thanks. cc @darius @dkayiwa @flavia @larrystone @fred @zeze @geofrocker

I’m surprised my old code works that way, but if so it was definitely a temporary hack just to get moving, and it’s definitely wrong. :slight_smile:

The way I think it should work is that the administrator needs to set a global property specifying what Encounter Type to use when saving a set of orders. This requirement needs to be documented for someone who’s starting to use this app. (E.g. we suggest that they create an encounter type called “Order Entry”)

In case no value is set, the most correct thing to do would be to not allow the UI to be used at all and have a big error message saying “configuration required”. Before failing it might make sense to look for an encounter type with a known UUID that would be included in the reference application. (But save that for later.)

Just so you know, the ideal behavior from the perspective of an EHR system is a bit more complex, e.g. entering the orders likely happens during the same encounter where you recorded some diagnoses and clinician notes. But we should ignore this complexity for now, and get things working in a straightforward way first.

I’d also imagine that the user should be able to select an existing encounter if they are not creating a new one for the drug order.

Thank you for your suggestion. I now have an idea of what to do.

Thank you for this idea.

@darius, @Betty and I are trying to create a new drug order. We noticed that Order Entry API uses the .../CONTEXT-PATH/ws/rest/v1/order resource to create a new new drug order. We have a few questions.

  1. Why did you use the .../CONTEXT-PATH/ws/rest/v1/encounter resource instead of the one above?
  2. We were also looking at the demo add encounter form https://demo.openmrs.org/openmrs/admin/encounters/encounter.form, creating a new encounter requires a patient id. Therefore a patient can have one or many encounters, does that mean that in the order entry implementation, a clinician should be able to select an encounter type. Which also brings us to the next question, what privileges are required for one to add an encounter, is it an admin right or any clinician can do it? cc @zeze @dkayiwa @larrystone @geofrocker @fred
  1. The order resource allows you to work with individual orders, but the encounter resource lets you create multiple orders at a time, which is the workflow that we want here. (If you look at the old UI for this you’ll see that it allows you to create multiple orders, and then you can click “Sign And Save” which will save all of them as a batch.)

  2. In general any clinician (or data entry clerk) can create an encounter. It’s not a high-privilege operation, but rather a standard operation while recording medical data.

In the ideal version, the user should be able to add orders to an existing encounter, or to create a new encounter, however I don’t think the current API makes it easy to add a batch of orders to an existing encounter.

Therefore I suggest that for now, whenever the user clicks “Sign And Save” this creates a new encounter. This should work like I mentioned in an earlier post:

To summarize:

  1. Document that the administrator needs to set a global property saying what encounter type to use for new order entry encounters.
    • There is already a UI for this, you just need to document that it’s a step.
    • this is a one-time setting for an admin after they install the OWA, it’s not something to be chosen every time you save orders.
  2. As you are loading up the react application, get this global property, and get the encounter type that it points to. If this fails, then throw up a big error message, and don’t allow the app to be used until it’s configured.
  3. Otherwise, when the user clicks Sign And Save, you create a new encounter, with the configured encounter type.

Later we can add support for either creating a new encounter, or else choosing an existing one.

According to this, does it mean we should consider making requests to the encounter endpoint and not order endpoint?