COVID-19 pandemic has accelerated innovation in the healthcare technology industry. Research scheduled in years is now happening in months. Every healthcare solution provider is racing to launch their products to cash in the market, even in beta versions. Speed is the key here. AI has transformed and keeps transforming the healthcare sector.

Even before COVID-19 healthcare providers were always finding ways to speed up information sharing whether between different EMRs, Practices, or even with Governments.

In this article, we are focusing on two essential items in the healthcare domain. Which are Requisition and the HL7.

Understanding Requisition/Report

Requisitions are the common data-gathering form used by Doctors. When patients come to the practice or doctor, for diagnosis purposes the doctor suggests some tests. Requisition document stores information such as patient data, medical tests, etc. Requisition also contains other useful information, for example, “Whether a patient is fasting?”.

When this requisition reaches the Laboratory, Lab performs specified tests and sends back a report to the practice or doctor. The following graphics summarize it.

The following screenshot helps us understand clearly. This is how a sample requisition and report look like.

What is HL7?

Health Level 7 (HL7) standard is very helpful for storing and sharing patient health data across laboratories and Practices. HL7 provides a rich set of specifications and is generic in nature.

It can store almost all kinds of information, such as patient information, provider information, practice information, test and result information, diagnosis or ICD 9/10 codes, AOE information, and more.
HL7 also has segments to store PDF data into base64 format! HL7 segments like NTEs are useful to store all communication between patient, doctor, and lab.

Let’s take a look at what HL7 looks like.

PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 MYSTREET AVE^^MYTOWN^OH^44123^USA||(216)123-4567|||M|NON|400003403~1129086|
PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN MYLASTNAME^BONNIE^^^^|||||||||||2688684|||||||||||||||||||||||||199912271408||||||002376853

Here, the first word in each line represents unique data segments. For example, MSH which is an abbreviation for “Messaging Header” contains information about sending and receiving entities along with the timestamp of transactions. PID (Patient Information) segment contains patient information such as name, DOB, phone no, etc.

Please visit the HL7 standard official website to know more about it. There are many useful tools available for HL7. For example, Smart HL7 is a very useful tool to parse HL7.


In the HealthCare domain, medical vendors provide EMR solutions to the practices. Each practice uses its unique EMR solution which has its own kind of requisition format. In many cases, practices develop custom requisition formats based on their preference.

In Older days, a patient was carrying requisition with himself and handling it at the Laboratory. Laboratory then performs listed tests and handover test result reports back to patients. Then, Patients carry a report to the doctor and the doctor writes a prescription.

Nowadays, Smart Healthcare solutions also known as Data Plumbers do the data transfer between practice and laboratory. Data Plumbers takes a requisition, converts it to HL7 format, and injects it into Laboratory software/API. When requisition HL7 is uploaded, a patient test schedule is generated and tests are done. When tests are complete, the resulting report is converted into HL7 and automatically sent back to the Practice or Doctor.

As we have noticed, converting requisition or test reports to HL7 is a key element here for making automated systems. Creating generic HL7 from thousands of practices and labs which has lots of customization is quite a challenge. Data Plumbers often have back-offices to just do these manual data entry work for each requisition and report type. In some cases, large teams of developers are hired, so that they create these customized solutions for each requisition and report type. This process is very costly and time-consuming.

Why go through all these troubles only to map fields from requisition/reports to a proper HL7 segment? There must be a better way!

A Simple Solution!

With help of’s document parser, we can easily convert the source PDF file to predefined JSON format. And we’ll be using this generic JSON structure to build up a target HL7 file.

This is how it’ll look like.

  1. Map Fields from input PDF and create document parser template.
  2. Use document parser API and export pre-formatted JSON data
  3. Use this fixed-formatted JSON data and create HL7

We’ll be taking up a sample requisition document and demonstrate converting it to an HL7 file. Please get full source code from this GitHub repository.

Let’s discuss each step of this solution.

Map Fields from input PDF and create a Document Parser Template

The Document Parser template is a YAML format file. This template contains all mapping information such as field name, field coordinates, type, etc. Following is a sample template snippet.

- name: LabName
  objectType: field
    fieldType: rectangle
    regex: true
    - 98.4065933
    - 33.2967033
    - 90
    - 8.24175835
    pageIndex: 0

You can use the free Document Parser Template Editor to map all fields and generate templates. This tool is very simple and easy to use hence we won’t go into much detail about it.

Following is how our field mapping looks like.

Here, Each field is marked with a rectangle and we can add additional properties if any. For example, to get a “LabName” in the final JSON result we are marking it up with a rectangle. Also, We can specify data type and regex if needed.

To Summarize, Document Parser Template is a cloud-based tool to generate document parser templates. ByteScout also provides on-premises solutions to generate templates.

Use Document Parser API and export Pre-Formatted JSON data endpoint ‘/v1/pdf/documentparser’ is useful to retrieve data from PDF or image document as per template specification. We won’t be going into source code details, but here’re the logic highlights.

  • Uploading input documents to cloud and getting a public URL. endpoint “/v1/file/upload/get-presigned-url” is used here.
  • endpoint “/v1/pdf/documentparser” request is made with template and source file URL. We’re executing this request in asynchronous mode, hence in output, it’ll return JobNo.
  • Job-status is checked with endpoint ‘/v1/job/check‘ and once the job is completed, output JSON is retrieved.

Use this fixed-formatted JSON data and create HL7

Now we have all the necessary fields in the proper format to generate HL7, we can implement our own logic to generate HL7. Following source code logic overview.

  • We’ve created a class named JsonHL7Fields, and we’re parsing all extracted JSON data and building up a modal with help of ParseJsonHL7Fields method.
  • Reference of open source library HL7-dotnetcore added. This library is very well created and useful to fill-up all segments of HL7.
  • We’ve built a method GetHL7Format which uses the logic of HL7-dotnetcore and mapping each class property to the HL7 segment.

Simple and Straightforward! Following is the output demo.

To Summarize, Instead of re-inventing the wheel we can use includes Document Parser Editor to simply create a template for each requisition or report type and use common logic to generate HL7.

Though is fast and secure, sometimes organizations need on-premises APIs. If that’s your requirement you can go with an on-premises API solution – Cloud API Server. You will get hosting packages, you can host them as per your infrastructure requirements.

If you do not want API execution but instead want to directly consume SDKs into your project, then explore Document Parser SDKs.

I hope this article will help you improvise your product offerings and benefit your product end-users. Thank you for reading!