Hl7 Message created from PDF only

[Kahless2040]

I am very new to Mirth Connect. I don't understand Java yet.
I think I understand the simple stuff. All my channels are working. I am sending and receiving HL7 messages.
But I have hit a roadblock when trying to send a PDF to the EMR tagged with the PID data.
What I need is a way to take a PDF . Then extract the PID information like the Patient ID (PID 1) and the Patient Name.
Then transform all of this into a HL7 message with the PID information and the actual original PDF document embedded in OBX 5.5
Or an HL7 message with all the PID information and a "attachment" that contains the original PDF document.

I have sent just the PDF both ways to my EMR. As a base 64 binary file and as an "attachment" but they are never tagged!
You actually have to open it up and look at the PDF to see what patient it belongs with. Which makes it useless.
I was hoping that someone could create a channel that does this, to show me how it's done. Because I am clueless.
Below I will describe my approach so far:

I have created a "print to folder" to print the PDF into.
I have a File Reader that reads the document then erases it after processing.
So the "print to folder" is always empty ... ready for the next document.
After I have the "read" PDF, I can send it out as either an "attachment" or as a "base 64"
That always works..... But it is untagged with any PID information. (which makes it useless!)

I really don't know how to proceed.
Any help is appreciated.
If you could post a working channel, I could look at it and learn a lot.
I am using Mirth 4.3.0 as a relay, So I would like to transform the file there if possible.
The Origin Mirth is 3.2 where the PDF is originally read.

Thanks in advance.

[pacmano1]

Do you mean "I have a PDF and I need to extract data from the PDF to get patient demographic information to then use in the PID and/or other segments"? In other words you have no discrete metadata separate from the PDF that describes its contents and has the needed fields for HL7?

If yes then you must do OCR on the PDF. It involves making java calls and potentially using custom java libraries. Look at https://forums.mirthproject.io/forum/mirth-connect/support/7041-mirth-tools-user-defined-functions?p=95725#post95725.

As for your ask to "write a channel for me". That approach doesn't typically work here, but people jump in when you post problems with what you have already tried.

[Kahless2040]

Yes, PacMano1 You are correct.
You are right I have a PDF file and want to merge it into an HL7 with the Patient information pulled out of the PDF.
You mentioned OCR... Does that mean that the information cannot be pulled out of the binary base 64 file at all?
I guess I thought it could.

How do other people get a PDF to the EMR in an HL7 Message that is tagged with the PID information?
Apparently I am going about this all wrong?
It's just that I need to send the ECG PDF reports over to the EMR and the Telemetry Station that creates them does not send out or create on it's own these reports to HL7.

I thought if I could just capture the printouts , then I could then forward them to the EMR.
Which I have done.... But they are not tagged in any meaningful way.
The EMR does not know what to do with them.
They need at least the "key" field" which is the "patient ID" so they can be linked to that patient's files.

Maybe if you can tell me how other people accomplish this, I could get on the right track.
I am clueless, but I am trying to learn.

[pacmano1]

You cannot just capture and forward PDFs without the appropriate data in an HL7 message in general. The other side expects your PDF base64 encoded in either an MDM or ORU message with appropriate segments for who the report is for and what visit or order it is associated with and perhaps other information. That data is usually a combination of inbound data from a feed that asked you to do a test and discrete data from your testing tystem.

The telemetry station creates the PDFs I assume - can't it name the file names such that you can parse them? If you are doing something like pritning to a virtual printer that generates PDFs that in turn you want to send downstream, that can get even more complex because the PDF may in fact not be OCR capable, rather it is just images.

As for how others do this? Depends on the place, but more often than not it is a combination of data in from your client and out data from your device that has the patient context information discretely available to send.

Labratory Information Management Systems (LIM) coupled to their testing equipment work in this way. Radiolgy Infromation Systems (RIS) coupled to their diagnostic systems like a CT/MRI works in this way.

Some devices also communicate via ASTM E1381, you might read up on that.

[Kahless2040]

Thank you for your reply And I am sorry I left this out earlier, but the PDF's must be printed manually to a PDF virtual printer using Windows "Print to PDF". The PDF file name can be named to anything ...but it has to be named by the operator of the Telemetry Station. The operators are nurses and they will probably make mistakes when naming the PDF files. That is why I wanted to pull the information from the Patient Data, so no one can make a mistake. Once again thank you for everything you have said. I am here to learn. Rome was not built in a day, And I am still waiting for the first load of concrete to be delivered.

…

________________________________ From: pacmano1 ***@***.***> Sent: Wednesday, July 5, 2023 9:09 AM To: nextgenhealthcare/connect ***@***.***> Cc: Kahless2040 ***@***.***>; Author ***@***.***> Subject: Re: [nextgenhealthcare/connect] Hl7 Message created from PDF only (Discussion #5842) You cannot just capture and forward PDFs without the appropriate data in an HL7 message in general. The other side expects your PDF base64 encoded in either an MDM or ORU message with appropriate segments for who the report is for and what visit or order it is associated with and perhaps other information. That data is usually a combination of inbound data from a feed that asked you to do a test and discrete data from your testing tystem. The telemetry station creates the PDFs I assume - can't it name the file names such that you can parse them? If you are doing something like pritning to a virtual printer that generates PDFs that in turn you want to send downstream, that can get even more complex because the PDF may in fact not be OCR capable, rather it is just images. As for how others do this? Depends on the place, but more often than not it is a combination of data in from your client and out data from your device that has the patient context information discretely available to send. Labratory Information Management Systems (LIM) coupled to their testing equipment work in this way. Radiolgy Infromation Systems (RIS) coupled to their diagnostic systems like a CT/MRI works in this way. Some devices also communicate via ASTM E1381, you might read up on that. — Reply to this email directly, view it on GitHub<#5842 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBCBESHTIB4XWCOFODSPYETXOVYP3ANCNFSM6AAAAAAZ64NDN4>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[pacmano1]

That is what I meant by a "virtual printer" in my last post. Your PDF may just be an embeeded image. That may be different than extracting text from a PDF. Best wishes with your project. I expect your leadership team needs to invest in proper hardware and software to properly integrate with EHRs.