Yes, use the encounter endpoint to create a single encounter with a batch of orders.
Keep in mind that something like “Discontinue the prescription for Paracetamol 100mg daily” is also an order (which has the side-effect of closing a previous order).
I’m happy to have a voice call to give some more context about order entry, if that’s helpful.
When is the best time that @flavia and I can have a voice call with you concerning the order entry? @darius
@darius, Thank you for the detailed explanation on adding batch orders. I was thinking about another temporary hack to use for now as we figure out the ideal way of adding encounterTypes. The current admin portal provides an interface that allows one to add an encounterType, we could use this to create an encounterType and query for it when creating an order.
The code for this project should never create an encounter type. That is something that an administrator should do at a much earlier stage of configuring their server.
As a dev working on the project, you should go to the admin interface and create an encounter type with a name like “order entry” (just like you’re saying).
Please, the team would need some clarification about the concerns listed below when handling display of drug orders.
cc: @darius @dkayiwa @zeze @dkayiwa @larrystone @geofrocker @betty @flavia
I don’t understand what is leading you to ask 1 & 3. As Wyclif says, there’s nothing special about free-text drug orders in terms of their expiration.
To be clear, when you place an order, you can set an autoExpireDate. That would be the date/time where the order will automatically expire, if it isn’t discontinued first.
There is no callback or anything if an order expires though. If you repeatedly fetch all a patient’s active orders via REST, then eventually some of them would expire.
@wyclif @darius Thanks for your response.
To add more context to the question I asked. When a user creates a free text drug order, say for inpatient, the only field available is the dosingInstructions. This makes it difficult to determine when the drug order would expire. The workaround the team has been using so far is to edit the drug order using the Standard Dosing tab and specify additional fields such as duration. This is the reason why I asked about the proper way to handle free text drug order expiry.
Hopefully my explanation is clearer.
@fred, I understand now.
You have copied a mistake from my previous implementation. Let’s ask the doctors how this is supposed to actually work:
@burke, @jteich, they are implementing a drug order entry UI based on screens that I started but never finished years ago.
Standard dosing instructions look like this:
Free-text dosing instructions look like this:
In the free-text scenario, I assume that we should ask the prescriber for an end date to the order, right? What should that look like?
@fred can you give more details of what exactly you mean by when creating a drug order because I don’t know whether it is via REST or some sort user interface? Because I think this is an implementation issue in the user interface you are using that it doesn’t display the expiry date. In theory, if you place any order it should have no expiry date unless you explicitly set one except for Discontinuation orders which are designed to auto expire immediately after placing them, in case an order has an expiry date and it’s not displayed in the UI then that’s an issue in the UI and needs to be addressed in the UI.
@wyclif, he is on the andela team that is building a drug order entry UI. (And, per my previous comment, it is a UI issue, due to copying a mistake I made earlier.)
@darius thanks for the clarification. @wyclif sorry for my delayed response. Darius’s feedback covers the concern you raised. However, if you need more information please do well to add it here.
The team is awaiting feedback on this concern.
Was replying to Darius comment. You could check it out here for more clarity - Implementation of the Order Entry UI application in ReactJs
@fred please remind us again if you haven’t gotten any feedback by the end of the week.
(I assume this is not a blocker on your end, and you can be working on other things in the meantime.)
This is currently not a blocker but a concern that would need to be addressed at some point. Thanks.
@fred what am saying is I don’t seem to understand what the issue/concern is, autoExpiryDate is exposed via REST and you can set it’s value, unless the issue is with another field, if you copied and pasted code that doesn’t show the field as @darius pointed out, then you probably need to address it in your UI code.
@wyclif Fred needs advice/direction on what the UI and behavior should actually be. I mentioned Burke and Jonathan on my message, hoping to get some clinician/informaticist feedback. (And that’s what we’re waiting for.)