How to Convert a Medical Record
Converting a medical record from one format to another (e.g. HL7 CDA to HL7 FHIR) is a common need by health plans, facilities, and the federal government.
As such, a large portion of the opensource community on Github, as well as private companies (Tenasol included) have devoted themselves to these processes for various use cases.
Overview of reasonable medical record conversions
Why Convert a Medical Record?
Medical data is usually stored in flat databases and accessed via SQL statements inside of electronic medical record systems (EMRs). However there are standard formats and filetypes this data is turned into when its moved outside of an EMR. Unfortunately, there are a lot of types of these.
Data Analysis: Learning more about a population or an individual patient may be much easier if a data process can use extracted information from multiple data types. Tenasol, as a regular part of our business performs routine data extraction from all data types, and can output that data in a number of formats for HEDIS, risk adjustment, disability detection, and prior authorization use cases among others.
Healthcare Interoperability: As shown in the diagram below, a medical record can be transmitted in numerous ways. The file format used when it is transmitted is dependent upon the two facilities involved in the exchange of records. This means that the second facility may receive data in a more unstructured manner, or different format than they would like, making medical record conversion post-transmission palatable depending on the operation.
PDF/Image Conversion
Conversion of PDF (or TIF/TIFF/JPG/JPEG/GIF) medical records to other formats is problematic as they are entirely unstructured in nature. Medical records have both extremely high variation in structure, length (median 30 pages, mean 80 pages) and can have shuffled pages, and even mixed patients.
PDF to ADT: Rare need, extremely difficult. ADT messages are not really medical records, more so status messages so converting a patient medical record to ADT is in 99% of cases non-sensical.
PDF to CDA: Best efforts or wrapping are the two ways to do this:
Best efforts: data is extracted from the PDF using a combination of OCR and NLP on a best efforts basis, possibly with some error, and then that information is inserted into the CDA format.
Wrapping (more common): The PDF itself is wrapped inside the CDA file. This may be done by zipping the PDF in with a new CDA or by storing the PDF as a binary file inside of field of an XML CDA file.
PDF to FHIR: Also via best efforts or wrapping the file just like PDF-to-CDA.
HL7 ADT Conversion
ADT to PDF: Rare need, but possible. ADT messages may be converted to PDF file representations as they are very difficult to understand without a visual representation, but usually this information is rendered in a user interface instead.
ADT to CDA: Extremely rare need, but possible. ADT messages are mostly discharge status indicators, not medical records, so converting them to a CDA/CCD is mostly nonsensical, however ADT messages do contain some data that can be represented as a patient record.
ADT to FHIR: Common need. There is a direct mapping of ADT to HL7 FHIR that is described by HL7. However, you will need an implementer such as Tenasol to perform this for you, and it is dependent upon the implementation of HL7 FHIR that you plan on using (R4, USCDI, etc)
HL7 C-CDA Conversion
CDA to PDF: This is a common need. You will need a piece of software to perform this rendering action for you though.
CDA to ADT: Extremely rare need, best efforts. CDA is largely a medical record format, whereas ADT largely indicates patient discharge status. As such, they are not very equal, however they both have some overlap on elements that are possible to be stored.
CDA to FHIR: This is a common need, but either by best efforts or wrapping. Said short and sweet, CDA does not directly convert to FHIR. Even more than this, how it should be performed is dependent upon the implementation of FHIR used.
Best efforts: data is extracted from the CDA using xpaths, jsonpaths, advanced custom parsing, or a standalone parser like bluebutton.
Wrapping (more common): The C-CDA medical record is wrapped inside an HL7 FHIR payload using the DocumentReference FHIR Resource.
HL7 FHIR Conversion
FHIR to PDF: Common need. More often than not, a FHIR message is fed into an EMR, which then generates a PDF based on how the EMR stores and represents patient data. This may be done differently depending on what FHIR data is being rendered. Is it a patient record, or is it medical device data, or appointment data?
FHIR to ADT: Extremely uncommon, very difficult / limited best efforts. Converting FHIR data to ADT is rare as FHIR offers significantly more advantages, however this need could arise if trying to feed ADT data in FHIR format to a legacy system. In this case, only data that could be held by ADT would be able to be converted. A solution that does this is not known today but could conceivably be built.
FHIR to CDA: Uncommon, very difficult, limited best efforts. Converting FHIR data to CDA is rare as FHIR is the more modern format. Furthermore, CDA does not permit the wrapping of FHIR data. The last option then is placement of FHIR resource data on a best-efforts basis into a CDA Continuity of Care Document.
Other Formats
Other formats can occur but are far less common. They mostly include the following:
Text Files (TXT): Text files may simple be treated as unstructured strings of text. Patient data is, but very rarely stored in this format.
Rich Text Format (RTF): These files are fairly rare. They may be:
Treated as an unstructured string of text like a text file by using opensource parsing engines
Converted to a PDF using software such as OpenOffice to retain structure and formatting. This is a better but more complex approach.
Word (DOC/DOCX): These are best interpreted by converting them to a PDF using OpenOffice. This retains structure and formatting.
If you would like to talk about how can Tenasol can help more in this space, reach out to our team!