## 2 Materials and Methods
### Bridging the Gap between LOINC and UCUM  
LOINC would be an ideal proxy between the locally used units and UCUM. Firstly, LOINC has garnered widespread usage in the context of clinical and laboratory settings [22], which makes it an ideal foundation to piggyback off. Secondly, it supplies critical information about the proprietary units that can be processed in an automated way, namely in the form of the _Scale_ and _Property_ axis that each LOINC code is associated with. In the same vein, each valid UCUM unit is associated with a specific base unit representation that serves to answer questions regarding the nature of the physical properties of that unit and how it relates to other UCUM units. By trying to establish a link between all of LOINC's quantitative _Properties_ and a base unit representation for each respective one, we could infer how any valid UCUM unit relates to the _Property_ axis and, by extension, the proprietary unit. Staying true to the spirit of curbing the effects of heterogeneity induced by proprietary codes, this idea would need to be formalized in a way that makes use of existing healthcare standards. FHIR offers the necessary components in the form of the provided resources CodeSystem, ValueSet and ConceptMap that can be deployed on FHIR terminology servers. Moreover, there is the need for a UCUM tool that is able to canonize and convert units in addition to being able to generate human-readable display names for them. Along with allowing machines to make use of this formalized knowledge, a tool is needed to support users with little expertise in either LOINC or UCUM to establish mappings between their units and UCUM, simply by providing the software with a valid LOINC code that has already been mapped to a certain procedure and offering them a set of curated UCDM units to map their local units to. Keeping the target audience for this tool in mind, it would need to be very streamlined, providing only the most basic of functions needed to accomplish this mapping in a way that minimizes the room for error. The recommendations for these units would ideally be sourced from aggregations of UCUM units that are \"tried-and-true\" for common use-cases. Both the FHIR and the LOINC web presence provide such lists, and they can be turned into standardized FHIR ValueSets for the terminology server to make use of. In addition, there are also the aforementioned UCUM example units in the LOINC data set. The recommendation mechanism could then be realized through a ConceptMap acting as a filter that examines the recommendations of the ValueSet used, making sure they match the _Property_ (and thereby the base unit representation) of the provided LOINC code.  
Figure 2 sketches the aforementioned ideas without going into detail about the actual implementation. Users utilize their proprietary units that are associated with LOINC as the  
input for the mapping tool, receive a curated set of recommendations and make an informed choice based on them. Additionally, they may also specify a quantity and proprietary unit to convert to a UCUM unit of their choice. Internally, the software makes use of a powerful back-end containing both the theoretical knowledge stored on the terminology server and the capabilities of a UCUM tool for dealing with tasks related to the standard, such as verifying the compatibility of units and performing conversions between them.