I completely agree that we should make a generic way for any kind of order to be sync’d to ERP. So here is a thread to discuss how we’d like that to behave…
To anyone familiar with ERP workflows and use cases (cc @ramashish, @arjun, @pkanchankar), what could an implementation want to happen when some new kind of order (for example a procedure order) is placed?
I guess you’d want this to appear on the bill, but I also assume that the order type is not enough to tell you the cost, and this needs to be driven by the order’s concept. Would there be a concept->price mapping stored in ERP?
We have this requirement from everywhere actually. (The Bangladesh Project team even once offered to fix it)
I know of requirements of “Procedures”, Equipments (like HSG procedure tray) that needs Clinician’s advice/orders etc. Basically all sorts of “Orderables”.
Currently the code
inspects the “Concept Class” and raises the event for syncing to ERP
I would think this should be more generic of what we consider as “order-able”. (My idea would be to use something like a concept attribute that you can just set “orderable: true”. Our metadata should be able to describe more details (hence we brought in Concept Attribute support) and other systems should be able to interpret/decide what they are interested in.
At ERP side, we associate the Orderable to certain categories. there is a mapping for this. If not found associated, it puts it under a default category.
I am not sure about associating the price with the concept in MRS side. For a category, it might be wrong to assume certain price.
I liked the idea of using Concept Attribute like “Orderable”, which can be used while creating an entry in quotation.
Product Category sync on the ERP side is Concept Class, right? This should have no effect of “Orderables”.
I agree. From functional standpoint as the “Administration” department shall decide the rate card which can get really complex as there cab be various price lists, let the price be part of ERP rather than associating with concept in OpenMRS.
Can you point me to where this happens? I’m having trouble finding it.
Is it enough to just say orderable=true, or would we want to have something like “OrderableInErpAs: Drug”. (I.e. I’m assuming that there’s some special logic on the ERP side that treats different types of orders differently. E.g. a drug order has a quantity.)
When an orderable (concept) is created in mrs, should create a corresponding product in the erp, under correct category. (Solutioning : So i think two attributes might be required here. One to indicate that this has to sync to erp and other to indicate which category it has to sync to.).
Additionally, implementations might want certain orderables to sync only to billing (erp) and certain orderables to sync only to fullfillment system (elis, dcm4chee).
[The admin person can then go an update unit price, etc in erp]
When an order is placed, corresponding order should get synced with quantity 1 (can’t think of any usecase where quantity would be more than 1)
A comment put by the provider should get synced. Having an ability to provide separate comments for biller and fulfiller and syncing them to specific systems would be something desired.
The above i think would be true for all orderables except drugs
Drugs is a really special case. The quantity as well as unit is provided by the provider which gets synced to the erp. This happens as of now.
Additionally, generic name to product is something that is desired. As in, doctors prescribe in generics in emr but a specific product gets picked up in erp. I think this could get complex with different scenarios within but might be worthwhile sometime to see if it’s feasible to support.
Echo what others said, that is cost should be maintained on the erp side.
In certain settings, doctors need to specify what rate to charge, what fund to put the patient in, what discount to give. But I think one of the features could be sufficient to achieve that (Comments or another order)
Everyone agrees with the need to be able to sync all types of orders from MRS to ERP (and LIS), in a way that is generic.
We want to start using Concept Attributes to allow the implementation to tag certain concepts with semantically-meaningful data that can be used to configure the synchronization.
for example tag a concept with the attribute Sellable=true, or Lab Test=Done Locally | Referred Out
Architecture vision is the same as before: all orders go in the atom feed; it’s up to the connector/reader to determine which orders they want to take action on. But these new concept attributes will help make writing that business logic easier.
In the future we may want the ERP connector to support multiple possible strategies and configurations for what to do with an order based on the orderable concept’s metadata. But for now it’s sufficient to handle Drug Orders (as we already do), and then to have other order types handled in the following simple way (neither requiring nor permitting additional configuration):
for each “sellable” order, add a quotation for 1 unit for the orderable’s concept name, with an optional comment
creating/editing an OpenMRS concept flagged as “sellable” needs to add it to the ERP reference data
To those on the call, does this reflect our consensus?
Adding little bit more here especially for “drug orders”.
Concept Attribute (e.g. “sellable”) is only applicable for concepts (obvious) - and this is a good enough solution for “orderable”/“sellable” concepts like tests, panels, fees/charges, procedures.
However, for drug orders, the ordered items are “concept drugs” and they are not “concepts”, which means “concept attributes” can not be defined for them.
So, 2 suggestions for drug orders (assuming some are sellable and some not because the clinic does not stock them)
Introduce attributes for “Concept Drugs” - I prefer this. it allows for the drug model to be enhanced and the solution is similar to other entities in openmrs. However, this will take some development effort - build the domain model, enhance REST API, probably build over legacy UI etc etc
Lookup (from somewhere) - whether the drug is “sellable” or not. the lookup mechanism
can be a simple file which lists all “sellable” drugs - before adding onto the quotation, a simple check can be done whether the drug is listed there or not. Challenges foreseen would be obviously the upkeep of the lookup list file.
Have a Misc Concept “Sellable Drugs” defined with type as coded and all the “sellable” drugs added as answers there. (Why coded? - well that allows concept drugs to be added as answers, rather than a set definition which only allows concepts as members). Then on inspection of any raised order, we can check whether the drug is listed as a answer and if yes, add to quotation.
