Thanks Norman!
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.
JJ
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)?
Just skimming super quick here. While this will also require Core changes it looks more scalable to introduce order attributes, @burke / @jdick thoughts?
@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.
The where could be put in orders.instructions
and the what could be defined in orders.concept_id
. For example:
CARDIOLOGY REFERRAL
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 beyondorders
needed to support medication orders -
test_order
ā adds anything beyondorders
needed 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 ServiceRequest
.
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 TestOrder
to ServiceOrder
(or even ServiceRequest
) and adding TestOrder
as a deprecated alias of it for backwards compatibility.
TestOrder
becoming ServiceOrder
or 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
Itās a good point, @wyclif (miss seeing you!). The properties of FHIRās ServiceRequest that might be specific to service requests (tests, referrals, etc.) and not belong on a base order would be:
- bodySite
- location (locationCode, locationReference)
- occurrence
- quantity
- relevantHistory
- requisition
- specimen
- supportingInfo
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
orders
andrest_order
onto 1 - Stand
drug_order
on 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.