As an aside, I don’t think that you need to set concept because this will be inferred from the drug.
Also, I think the API should be able to infer the correct order type. Maybe also try adding "t":"drugorder" to the payload (in addition to type=drugorder).
And, verify that you have an OrderType for drug orders with the UUID given here: https://github.com/openmrs/openmrs-core/blob/1.10.0/api/src/main/java/org/openmrs/OrderType.java#L34
@darius, we do not have same concept uuid for drugorders. But we did not set this ourselves. The uuid we have is 53eb466e-1359-11df-a1f1-0026b9348838. Is it possible that our openmrs code has that uuid?
@dkayiwa, you are right we don’t have any rows that link to the drug order type in our order_type_class_map. Is there a recommended concept class that we map the drug orders to?
By “concept uuid” you mean order_type.uuid, right? Can you share the contents of your order_type table?
@jdick I don’t know why your UUID is different from the one currently hardcoded in openmrs-core, but I’d speculate it’s because AMRS was the first installation, and maybe your uuid was generated before we standardized.
Do you think you can modify your order_type entries to be consistent with what’s on the demo server now? Or do you have some sort of stored/transformed data that relies on the current uuids in this table?
GET demo.openmrs.org/openmrs/ws/rest/v1/ordertype?v=default
{
"results": [
{
"uuid": "131168f4-15f5-102d-96e4-000c29c2a5d7",
"display": "Drug Order",
"name": "Drug Order",
"javaClassName": "org.openmrs.DrugOrder",
"retired": false,
"description": "An order for a medication to be given to the patient",
"conceptClasses": [],
"parent": null,
"links": [
{
"rel": "self",
"uri": "http://127.0.0.1:8080/openmrs/ws/rest/v1/ordertype/131168f4-15f5-102d-96e4-000c29c2a5d7"
},
{
"rel": "full",
"uri": "http://127.0.0.1:8080/openmrs/ws/rest/v1/ordertype/131168f4-15f5-102d-96e4-000c29c2a5d7?v=full"
}
],
"resourceVersion": "1.10"
},
{
"uuid": "52a447d3-a64a-11e3-9aeb-50e549534c5e",
"display": "Test Order",
"name": "Test Order",
"javaClassName": "org.openmrs.TestOrder",
"retired": false,
"description": "Order type for test orders",
"conceptClasses": [],
"parent": null,
"links": [
{
"rel": "self",
"uri": "http://127.0.0.1:8080/openmrs/ws/rest/v1/ordertype/52a447d3-a64a-11e3-9aeb-50e549534c5e"
},
{
"rel": "full",
"uri": "http://127.0.0.1:8080/openmrs/ws/rest/v1/ordertype/52a447d3-a64a-11e3-9aeb-50e549534c5e?v=full"
}
],
"resourceVersion": "1.10"
}
]
}For the past six months or so, we have been using test orders. We are (obviously) yet to implement drug orders.
Changing the uuid should not affect anything within OpenMRS. It would only be a problem if you have serialized/exported the old uuid and saved it somewhere else. For example if you have a custom reporting module query that uses order type as a parameter, and you have one of these stored in your serialized_object table. Or if you’ve fetched orders from REST and saved them elsewhere. E.g. if the analytics setup you’re generating via ETL depends on being able to link via order_type.uuid. (I doubt that you’re actually relying on this, but you’d want to check.)
It could be. The link I posted above also will show the hardcoded UUID for test orders.
Thanks Darius.
Running that query on the production machine yields the same uuids as I had pasted above. Does this mean that those are uuid’s hard coded in our version?
We don’t use the order type uuid for any analytics so we’re safe there.
We’ll override (using sql) the uuid tomorrow and see what happens.
On the concept class issue, is there a recommended (or required) concept class that we map the drug orders to? Is it odd that this isn’t already configured (i.e. does a clean install have this pre-configured)?
This would tell you what comes with an out of the box install: https://github.com/openmrs/openmrs-core/blob/2.1.0/api/src/main/resources/liquibase-core-data.xml#L911
Personally I would take a look at what’s in the CIEL dictionary and copy the Drug class from there (including the UUID).
Ok, we’ve added the mapping and changed the uuid of the order_type. Now getting the error below. We have confirmed that the patient and encounter exist and are not voided. Is the encounter property the uuid of an existing encounter?
As a side note, it seems odd that an encounter has to be created before you add orders to it.
{ “error”: { “message”: “Invalid Submission”, “code”: “webservices.rest.error.invalid.submission”, “globalErrors”: [], “fieldErrors”: { “encounter”: [ { “code”: “error.null”, “message”: “Cannot be empty or null” }, { “code”: “error.null”, “message”: “Cannot be empty or null” } ] } } }
@dkayiwa, I think we have solved this and have succeeded in submitting several drug orders!
We now are able to submit new orders. We will now attempt to discontinue an order and provide feeback.
Thanks to everyone for their assistance!
It’s intentional that posting to the order resource does not let you create an encounter (just like posting to the obs resource doesn’t do this either).
Something I should have said much earlier on the thread…depending on how exactly you’re building the UI, you might want to use the encounter resource to create an encounter along with a batch of drug orders in a single POST.
I.e. you may create orders via the encounter resource also (just like you can do for obs).
E.g. when I was working on the orderentryui module I let the user create a few orders (within the UI), but nothing was saved on the server side until the user clicks a “Sign And Save Orders” button, which would proceed to create a new Encounter with one or more Orders in it, however many the user wrote before clicking Save.
im facing similar issue, where my error message is an invalid submission field errors being code: “DrugOrder.error.durationUnitsNotMappedToSnomedCtDurationCode”,
i can post a drug order, effectively but once i add duration and duration units on my payload i encounter this error
{“patient”:“2642d969-a8b5-467f-9d05-d0d7841a75ae”,“careSetting”:“6f0c9a92-6f24-11e3-af88-005056821db0”,“orderer”:“b691b281-4d8d-40f9-86ff-36b3eb3fa539”,“encounter”:“5fb0dcd3-4f80-4939-82a8-53cfe45d63a9”,“drug”:“2edd97ef-6642-4052-b86b-ab33aaebe579”,“dose”:100,“doseUnits”:“a8a07f8e-1350-11df-a1f1-0026b9348838”,“route”:“db0c5937-3874-4eae-9566-9a645ad7ac65”,“frequency”:“bc1369f2-6795-11e7-843e-a0d3c1fcd41c”,“asNeeded”:true,“duration”:2,“durationUnits”:“a8a05e82-1350-11df-a1f1-0026b9348838”,“asNeededCondition”:“js”,“instructions”:“jd”,“numRefills”:2,“action”:“NEW”,“quantity”:10,“quantityUnits”:“a8a0630a-1350-11df-a1f1-0026b9348838”,“type”:“drugorder”}