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
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.
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
@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)
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â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.
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.
@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.
Why did you use the .../CONTEXT-PATH/ws/rest/v1/encounter resource instead of the one above?
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
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.)
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:
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.
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.
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.