I think we may consider (primary care networks), where a community pharmacy is attached to a physician’s clinic, and the patients are referred from the clinic to the attached pharmacy. What do you think about this?
Are you looking for this? https://wiki.openmrs.org/display/docs/Order+Entry+API
@norman we are looking at two projects for CommCare integrated with Partners in Health OpenMRS, referrals are central to both. We don’t have a best practice for how we implement thse in OpenMRS yet (but we should). But it looks like from your Welcome section comment that the integration can share observations (and presumably encounters) but not orders or dispositions yet?
If that is the case we need to have our referrals be an observation in order to work with the integration, is that right?
Did this work ever happen to create Referral Orders? Or anything done towards doing this?
Yes, @dmunson the referral needs to be included in the encounters atom feed for CommCare to discover it. I know bed assignments appear in the encounters feed. Can it also include orders? … I’m not sure, but assuming it doesn’t, the referral would need to be an observation.
I’m circling back to this thread. We would like to create any backend extras to support referrals. @burke, we would depend on you (others) to lead data modeling efforts.
Once this is modeled, we will figure out how to get done in coming months.
Of course, we would love to collaborate with any interested parties.
We might be able to cover most use cases with the base order class (i.e., an order type that doesn’t need its own table).
Of course, we’d want to align with FHIR.
Do you have a list of attributes of
ServiceRequest that we’d need to support for referrals?
@burke, I don’t think we can get away with just using the data model as is. There’s now way I can see to support where + what the patient is being referred to in the existing openmrs data model.
I’m worried though that we would need to add in this table to core which could potentially take more time than we have.
Could we place in fhir2 module? Too hacky? Other ideas (orders extension module)?
@jdick introducing order attributes wouldn’t have to be too overwhelming unless the deadline is next week of course.
Generally, considering how attributes have helped us enhance the data model in other areas, i would also vote with a YES to introducing order attributes.
Also to add more on this, and connecting with the last TAC discussion, the most inexpensive way to doing so could be:
- Make orders attributable. That will have to go in Core, no way around it.
- Introduce a referrals API in EMR API for the time being.
The latter would leave some room for error until we get things right. Of course this implies that you’d depend and require the EMR API module @jdick.
I’m in favor of making Orders attributable, although without real implementations of the methods I complained about here (I opened a ticket to mark them deprecated). This would hopeful stop the need to have a TestOrder class (too late on that), a MedicationOrder class, a ReferralOrder class, etc.
Please schedule patient in Webuye Cardiology Clinic
Otherwise, I’d favor anything that takes us in the direction of aligning our model with
ServiceRequest – whether changes to core or changes to core initially introduced through a module.
Attributes are our equivalent to FHIR’s extensions (e.g., ServiceRequest extensions). They can be useful for implementation-specific needs and workarounds, but aren’t a good choice for standard functionality.
Chanced upon this thread. For referrals, couldn’t we enhance the “orders” model to have “location” info (textual & coded)? FHIR ServiceRequest has provision for that, Older ReferralRequest had “recipient”.
I continue to favor any changes that take us toward FHIR’s model.
While order attributes could allow implementations greater flexibility in associating additional information with orders, the core code should never be referencing specific order attributes. If, for example, we depend on attribute for a specific type of order within the core API, it should be part of the data model and not an “order attribute”.
While I favor the design of a base
Orders object to manage those features needed across all types of orders, I’m not a fan of simply expanding
Orders to have all the attributes for all order types. For example, dosing & administration information is needed for medication orders, but has no place on an order for a lab test or for a referral.
The model we currently have is:
orders– contains properties common to all types of orders
drug_order– adds anything beyond
ordersneeded to support medication orders
test_order– adds anything beyond
ordersneeded to support test orders
FHIR has conflated test orders (labs & procedures) and referrals into ServiceRequest. So, I would favor changes that take us the same direction. Specifically, adapting our
test_order to become more like FHIR’s
For referral orders and including location info as mentioned in this thread, this could mean adding
test_order.location_code (to align with FHIR’s
ServiceRequest.locationCode) and either holding our nose and using
TestOrder for referrals or renaming
ServiceOrder (or even
ServiceRequest) and adding
TestOrder as a deprecated alias of it for backwards compatibility.
ServiceRequest looks like another candidate item for 2.5.
I could be wrong but in my opinion ServiceRequest/Order sounds to me like what we have as the base Order class
- location (locationCode, locationReference)