In our INPC system, we deal with imperfect messages
In the attached figure, you see 4 hospitals sending us data. They are “outside” the Regenstrief/INPC central core.
Hosp1 sends messages with appfac LAB|AA, RAD|AA, etc.
As the V2 message crosses the boundary (arc#1), we store a copy of the message in the “Raw Queue”, or “initial waypoint.” (diamond#2)
It should be exactly as sent from the edge node
However, our attitude is that “Every APPFAC will need to be cleaned up.
Every APPFAC has its own warts that need to be scraped off.”
Therefore, for each APPFAC, we are ready to apply a custom pre-processor. (Oval#3)
It takes the raw message, and makes it into a format that is compatible with our HL7 processor.
We then write down the pre-processed message into the PreProcessed queue.(Diamond#4).
Notice, that we have M1 in the raw queue, and M1’ (the edited image of M1), in the PP queue.
Finally, a generic HL7 processor crunches thought the PP messages, and writes the clinical data into our SHR.
Also, we are very happy to have our messages sitting statically in the PP. There may be several processors that act on messages, some of which are down for maintenance, others which have just now been written,
and we set their “sequence number” we back to two months ago and have them march forward. Item#6 shows the STAT’s processor and ORU processor’s each at different places as they march through the messages.
Aside: It may be tempting to call the PP queue “normalized” or “perfect HL7”. In our experience, it is best thought of as “Regenstrief HL7” The original message may be perfectly fine hl7, but, because of
peculiarities in our Hl7 ORU processor, we often have to transform it into the way that our ORU processor expects it. It is hard to push back to the sender and ask them to make changes that are peculiar to our needs.
Note: As a new interface is brought on, I think nothing about creating a custom pre-processor for it. But, we almost never change the ORU processor.
Also, in Legacy, we ran one ORU processor per institution, for scalability.
We did not care that one message would be inspected by 45 ORU processors, only one of which would act on it.
All the time is in the HL7 processing and database writing.
figure_4_inpc.pdf (44.1 KB)
···
Mark Tucker
Systems Engineer
Regenstrief Institute
(317)423-5552
Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended
solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from
making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not
sufficient for this purpose.
If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited