In QICoreCommon there are two overloads that differ only by a profiled type. After compilation by the Java stack, these profiled types are erased and replaced by the actual unprofiled resource, which in both cases is MedicationRequest. This means that we have two overloads with exactly the same signatures, resulting in an error in our compiler stack. For now, we have fixed this in our ELM preprocessing using the AmbiguousOverloadCorrector.
It is unclear whether this is allowed or not, in any case, the resulting ELM is ambiguous. This should be discussed with the community and when the solution has been implemented, we should remove the AmbiguousOverloadCorrector from our ELM preprocessing.
using QICore version '4.1.1'
/*
@description: Returns true if the given MedicationRequest has a category of Community
*/
define fluent function isCommunity(medicationRequest MedicationRequest):
exists (medicationRequest.category C
where C ~ Community
)
/*
@description: Returns true if the given MedicationRequest has a category of Community
*/
define fluent function isCommunity(medicationRequest MedicationNotRequested):
exists (medicationRequest.category C
where C ~ Community
)
In
QICoreCommonthere are two overloads that differ only by a profiled type. After compilation by the Java stack, these profiled types are erased and replaced by the actual unprofiled resource, which in both cases isMedicationRequest. This means that we have two overloads with exactly the same signatures, resulting in an error in our compiler stack. For now, we have fixed this in our ELM preprocessing using theAmbiguousOverloadCorrector.It is unclear whether this is allowed or not, in any case, the resulting ELM is ambiguous. This should be discussed with the community and when the solution has been implemented, we should remove the
AmbiguousOverloadCorrectorfrom our ELM preprocessing.