We want to add ReferralOrder, which needs to have a location property, which TestOrder should get as well. Both will be ServiceOrders.
I was proposing ServiceOrder as an abstract class extending Order with all the methods of our current TestOrder. TestOrder and ReferralOrder would extend ServiceOrder and implement getOrderType() with their respective types (Test or a new Referral order type). @ibacher didn’t like having an abstract class extending Order… but, if we head this direction and create classes for each supported order type, we could deprecate creating a typeless Order (eventually making Order abstract). This approach would be backwards compatible by maintaining TestOrder as a thin implementation of ServiceOrder, and allow FHIR to treat TestOrder & ReferralOrder along with future service order types as ServiceOrder (aligning with FHIR).
@ibacher, do you have an alternative approach in mind?