gms | German Medical Science

Introduction: With the increasing number of standardized data in healthcare, the opportunity for improving care is high [1]. One such standard is HL7 Fast Healthcare Interoperability Resources (FHIR) [2]. Mobile applications are an important factor for data collection [3]. However, the development for multiple platforms often leads to the redundant re-implementation of the same applications, whereas it would be more efficient to use only one codebase to build the various applications [4]. In this abstract, we have implemented Kotlin Fire Forge, a tool that generates Kotlin data classes from FHIR’s JSON schema definition that can be used in a Kotlin Multiplatform project. This way, the use of JVM dependent functionalities is omitted and by using Kotlin Multiplatform, the classes can be transformed into source code files for other platforms like JavaScript, WebAssembly, Android, iOS or native operating system libraries.

Methods: The implementation was done using the Kotlin programming language and incorporates Kotlin Serialization, as well as a custom fork of the json-kotlin-schema-codegen project [5] to automatically generate Kotlin data classes out of the JSON schema definition downloaded from the official FHIR website. The resulting data classes are tested and validated by serializing JSON resource files into the data classes, deserializing them back into JSON files and uploading them to a standard FHIR server like HAPI FHIR. The uploaded resources will then be compared to the unprocessed files.

Results: The generator was customized so that all resource classes inherit from a shared interface in order to enable dynamic development that evaluates the data types during runtime with reflection. After generating the classes, they can be uploaded to a Maven repository so they can be imported into other Kotlin projects. With Kotlin Serialization, JSON resources can be encoded into the data classes. Since the data classes are only intended for the storage, mutation and validation of FHIR data, their size is negligible. Additionally, the generator uses the JSON schema definition from the FHIR website itself, so it can be used for future versions of the FHIR specification without having to change the implementation. When comparing the uploaded resources with the unprocessed files, no deviations from the original resources and thus the FHIR standard could be detected.

The implementation is available under: https://imigitlab.uni-muenster.de/published/medic/kotlin-fire-forge

Discussion: While the generated data classes show the potential to be used in projects for several different platforms, the real-world functionality has yet to be tested, especially when using the classes with different target platforms. In order to do so, we plan to incorporate the data classes in future projects that make use of the Kotlin Multiplatform functionalities. To improve the usability, we also plan to implement processors for XML and JSON. However, this project does not offer any additional functions such as a REST client or FHIR Search.

Conclusion: Kotlin Multiplatform libraries have great potential to solve the problem of redundant development to support multiple platforms. By implementing FHIR data classes for such a project, a simple integration of the FHIR standard can be achieved while minimizing the development effort.

The authors declare that they have no competing interests.

The authors declare that an ethics committee vote is not required.