Implement ability to convert to other data formats (e.g. PRSB) - templating language and in the code repository #20
Description
A key guiding principle for the Alpha data model was to develop a model which laid the foundation for producing realistic patient
health records.
There are numerous formats and architectures for representing electronic health records - e.g. HL7v2, FHIR, art-decor (from PRSB), openEHR. Due to the time constraints in this project, we focussed on generating synthetic patient records in one of these: FHIR (v4).
There are then two potential ways of converting to other formats:
a. Finding or building a data converter which translates from the FHIR v4 to the desired format. E.g. there seems to be a HL7v2 to FHIR converter (https://github.com/LinuxForHealth/hl7v2-fhir-converter), although we have heard anecdotally that these converters are not very successful. As for PRSB formats, from our understanding, some of the PRSB standards (such as the Core Information Standard) are based on FHIR, hence this conversion may be possible as well (see also enhancement 1 under ‘Patient Agent’). There are also tools to translate between different versions of FHIR (e.g. https://www.hl7.org/fhir/r3maps.html)
b. Writing a converter directly to / from the internal language we have built. For user-friendliness, we have developed an “internal patient record representation” which is a simplified language for creating Patient Agent record entries. This saves the user from writing a lot of boilerplate code in the Intelligence Layer and simplifies the logic (for instance, names of fields representing dates dates in different FHIR resource types). To import / export to FHIR v4, we have written a converter which maps from this internal language to / from FHIR. Only a few important fields from the most common resources are currently used, but there is scope to include more depending on the need.
The converter could be built directly into the core codebase (as it currently is). Or, in a future version, it could be exposed to the user via a template language, which could allow the user to define new maps between fields and FHIR resources.
These converters should be built in a modular fashion.