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
orders needed to support medication orders
test_order – adds anything beyond
orders 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
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.