## 4 Discussion
### Drawing Conclusions for Designing LUMA  
In summary, we can conclude that existing approaches regarding the mapping of proprietary units to UCCUM for laboratory testing are noticeably less automated and formalized than LUMA. We argue that the most important hurdle for more active mapping efforts lies in the lack of an official and explicit outline of how UCCUM and LOINC relate to one another, and we proposed the idea of creating such a connection via formulating a UCCUM base unit representation for LOINC's _Property_ axis. Our approach improves upon the capabilities of the currently available methods in every way. By turning the initially mentioned aggregations of UCCUM units into FHIR ValueSets we leverage them for use within the LUMA framework. Although these lists are available in a digital format, they are not officially embedded within any software tools that aid users in their mapping efforts. Users have to rely on manually scanning them for a unit that might fit their intended use, and there is no way to involve LOINC codes to simplify the process as it lacks a direct association with the standard. A slightly more automated approach makes use of the LOINC data set via either RELMA or SearchLOINC, where users can look up specific LOINC codes. Although some LOINC codes are associated with one or sometimes two example UCM units, not all of them are. Our approach improves upon existing solutions, firstly by being at least as good as the LOINC data set itself meaning that if an example unit exists, LUMA highlights it separately. By additionally having a way to automatically compare these example units to the expected UCM base units we postulated, there is a way to detect invalid entries. Moreover, LUMA not only provides the example units themselves, but it can also leverage existing lists of UCM units in order to source recommendations from them. We demonstrated this by including aggregations of UCM units into the framework which were not intended for this purpose without having to extensively modify them beforehand. Even though the usability aspect of LUMA was not the main focus of our evaluation with the five participants of the LADR, we nonetheless received feedback on two aspects that we want to incorporate in future iterations. Firstly, example units should be highlighted in our list of recommendations or be able to be mapped directly as a default option when possible. Secondly, if a user decides to deviate from the example units, this aspect should be reflected in the mapping table. When designing the back-end for LUMA, we built upon locally pre-existing infrastructure in the form of the FHIR terminology server Ontoserver. In doing so, our idea was to create and make use of standardized FHIR resources that we would be able to share easily via its syndication mechanism and that might be useful even outside the scope of this application. That being said, the framework itself--meaning a FHIR terminology server, a UCM service and the Controller handling the machine-to-machine communication between them--is not very portable. In theory, it is possible to set up a dedicated service with the same capabilities, but due to the modular approach we took when initially sketching ideas on how to design our solution, it is much easier to encapsulate the back-end via numerous possible views. For this purpose, we created a graphical user interface for internal testing and are now shifting our efforts towards a web interface that can easily be exposed and flexibly accessed even via mobile devices capable of connecting to the web. Our intended target audience was people with only very little knowledge about the intricacies of LOINC and UCM. Regarding the quality of mappings created, we are faced with the inherent issue of not knowing the exact semantics of the proprietary units users are trying to map to UCM. As the user is the final bottleneck in this situation, we tried to minimize the amount of unsound associations that could be created.