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)
Yes ServiceRequest seems to map to TestOrder in OpenMRS, I guess what I was trying to say is that ServiceRequest is not an intuitive name for us to adopt in OpenMRS in place of TestOrder because it ‘suggests’ a plain Order
@burke if we add a
test_order.location_code, then it can serve intended destination for a lab test.
To model a Referral (to external hospital) request,. I prefer capturing as different
order_type. which maps to FHIR ServieRequest.category. Instead of introducing additional tables (or changes to sub-types), it would be simpler to just add “orders.location_code” as optional (nullable).
And yeah, In OMRS, we have both ServiceRequest and MedicationRequest mingled.
- We could deflate
drug_orderon its own.
there is also the aspect of correlation to observation
obs … that would now to potentially need to have different references as new FKs.
I think that FHIR-wise the performer field is actually what you’d use to say “get this done at lab XYZ” (as a reference to an organisation) assuming that it’s referring to an external service. Location code seems to be a bit higher level (“get this done at an external lab”). In either case, I don’t see anything in the OMRS data model we can use to capture this information.
@ibacher - speaking fhir - yes. more meant as reference to OMRS data model. the closest to Organization, HealthcareService or Location resources we have in OMRS is location, which i think can be well leveraging location attributes and tags.
Just following up on this thread - were any tickets created to support this discussion? Will they be part of release 2.5?
@jdick am following up on this .
@dkayiwa do you think we’re ready to forge a ticket/s out of this for Plat 2.5 ?
@tendomart i have read this thread again and it does not seem to have a real concrete agreed upon way forward with the exact details. As we wait on that, let us just go ahead and create a ticket for making orders attributable, for the upcoming 2.5 release.
Alright let me look into that .
We got it at https://issues.openmrs.org/browse/TRUNK-6027
- Extend and deprecate
TestOrder(the intent would be to eventually replace all references to
ServiceOrder, in alignment with FHIR’s
- In the database, we would adding
order_test.location, with the goal of eventually renaming the
ServiceOrder would become the preferred class/resource for tests & referrals (matching FHIR’s approach) and we’d slowly phase out use of
Does this sound like a viable way forward (initial step) to others?