Suranga,
I would suggest that trying to merge both those things together is misguided, and an implementation should be using one method or the other but not both. If they used to use obs, but then started using the new allergy modules, it should be the implementation's job to migrate their data, not OpenMRS's job to forever be merging those things together.
But your question is equivalent and meaningful without the "AND using the allergyUI table" bit...
I suggest using the Strategy pattern, so the implementation configures which strategy the FHIR module should use to select their allergies.
As out-of-the-box-included patterns I would suggest one that uses the allergyapi module, and a second that selects observations based on having obs.concept equal to the value of a global property like "concept.allergicTo".
(I quickly searched CIEL and did not find a set construct that represents allergies, so I guess our out-of-the-box example can just support a simple obs like "Patient Allergic To" = "Sulfa", rather than a structured obs group.)
You definitely don't want to do it based on concept class. The class of the value of an obs tells you nothing about the meaning. E.g. you don't know if obs.concept is "what is the patient allergic to" or "what allergies have we ruled out". :-)
-Darius
PS- Don't forget that the core API has actually had allergies in it since 1.7, though that implementation will go away soon, so you might also want to consider that option.