- This topic has 11 replies, 7 voices, and was last updated 19 years, 4 months ago by
.
-
Topic
-
We are a small pathology lab in western Washington, serving several hospitals, and a range of clinics. We have been negotiating with the hospitals to direct an ADT feed from their HIS to us so we can avoid having our staff manually enter patient demographics. The hospitals are balking at turning on an open ADT feed due to HIPAA regs, and we are looking at alternatives. Most have proven pretty costly. These options involve creating custom ORM messages that will add IN1 segments, and setting up a store and send interface that would hold ADT’s till an ORM arrived. Has anyone else out there found a workable solution to a problem similar to this?
-
Replies
-
-
I’m interested in seeing possible solutions for this as well. We’ve been wrestling with this from the hospital side for the radiology group that does our interpretations. Basically the same problem — the radiologists get a daily feed of transcription data from our clinical system without the demographics and coverage info that they need for their billing. We don’t send straight ADT to the radiologists because at the time of registration we don’t know in all cases if there’s going to be a rad service performed, so 1) it would overwhelm the radiologist billing system to give them everything and 2) we don’t want to send ePHI for patients the radiologists have no business knowing about.
The BEST solution for us would be when the HIS receives the charge transaction from the Clinical system to trigger an ADT message to the radiologist. Technically it’s feasible if you can have a process to manage charge errors and reversals. However because of the $$$ and the performance to date of the vendors involved, it hasn’t come off for us.
What we do have (that no one is REALLY happy with) is to wait until the bill drops and scan the claim content for radiology revenue codes and use the patient and coverage demo from the claim header and batch that up to the radiologists daily. The big flaw with this is that our billing lag days mean that the radiologist have unmatched data on their system longer than they want to.
Vince Angulo
Children’s Health System
-
I think that if you have a business agreement per HIPAA, you should be covered for an ADT feed. We are connected with a reference lab and are using CISCO VPN concentrators on both ends. I’m thinking that if you do networking in healthcare, you are eventually going to need to buy one of these beasts. $2200 from Insight…..
(Insert your favorite IS vendor here…..)
-
-
We are actually doing something similar, but equally as cumbersome. We have created an SQL database where we direct ADT and Results. The ADT sits there in the database until a matching Result comes in. A daily process looks for the ADT that has a matching result and sends both out in a file to the Business Partner. It is not the optimum solution, but it seems to work for us and we’ve yet to find anything better. -
Scott, thanks for replying, so it sounds like you are getting an ADT feed from the HIS. Are you storing them in a database of some variety? Also, how is the Cloverleaf configured for this system? Scott Lee wrote:Here is what I did for our radiologist billing interface (with Comprehensive Medical Practice Management (CMPM)) –
When I get an ADT from the HIS I store it in a file.
-
-
Mark, The ADTs are stored in files on the CL server. All of the work is done by Cloverleaf…
- 1) The ADT comes into the engine from the HIS (Affinity).
2) A01, A04, and A08 messages are routed (raw) to cmpm_hold_out.
3) A tcl proc parses the message for the admit date and sets the outbound file name to the admitdate in YYYYMMDD format. Today’s admits for example will be written to a file named 20050429.
4) The cmpm_hold_out thread appends the ADT to the file using fileset/local.
5) ORM messages come in to the engine from the HIS.
6) While they are being routed/translated to/for Radiology (Swearengen) the patient’s account number is written to the file accounts.dat. These are the patients who had rad orders placed.
7) ORU messages come into the engine from Radiology.
8) These are routed to cmpm_out.
9) cmpm_out writes them to a file stamped with today’s date. eg – CMPMORU20050429. The fileset/FTP protocol is used to send them to a Windows server for later transfer to CMPM.
10) Daily at midnight cmpm_hold_in picks up the ADT files that are dated more than 4 days ago. Today for example it picked up the file named 20050425.
11) These are routed to cmpm_out.
12) A tclproc takes these ADTs and matches them with the accounts.dat file. If they match then the ADT segments are stored in an array. If later in the file another (newer) ADT message is found for the same patient then the newer segments overwrite the older segments. This means that only one message per patient per day will be sent to CMPM and it will have the latest version of each segment.
13) cmpm_out writes them to a file stamped with today’s date. eg – CMPMADT20050429. The fileset/FTP protocol is used to send them to a Windows server for later transfer to CMPM.
14) That’s where Cloverleaf’s involvment stops.
15) A batch script runs every night on the windows server where the files now sit. It FTPs the files to CMPM via a VPN connection. Two files are sent every day – CMPMORU
and CMPMADT .
It sounds pretty complex so it helps me to think of the dated ADT files as ‘buckets’ for storing a given day’s ADTs. Once I had that concept in my head everything else fell into place.
Mark Perschbacher wrote:Scott, thanks for replying, so it sounds like you are getting an ADT feed from the HIS.
- 1) The ADT comes into the engine from the HIS (Affinity).
-
We have a similar situation with our affiliated hospital (we are a physicians practice associated with the hospital). Since the hospital is our reference lab we have decided to automate the order process. Instead of sending separate ADT/ORM messages and worrying about queueing, etc., we are sending one “super order” which has patient demographics, insurance, diagnosis and order information. The hospital registers the patient based on the ADT portion of the message and uses the order portion as it needs to create the order to send to the lab system. Hope this helps,
Bob
Robert Milfajt
Northwestern Medicine
Chicago, IL -
Scott, I would like to discuss the details of this process, give me a call 360-416-2250 or fire off an email, markper@skagitpathology.com Scott Lee wrote:Mark,
The ADTs are stored in files on the CL server.
-
Our ADT and Results interfaces each have an outbound thread that translates and then writes the messages to files on the local server. Once a day a Unix script runs that stops the threads and FTP’s the files over to the server where the database resides and those are then imported into the database by another script. Then there is an additional script that pulls out all the matching records from the database and writes them to a new file which is then placed on our Secure FTP server for pickup by our Business Partner. Mark Perschbacher wrote:George, thanks for replying.
-
We do something similar for radiologists and transcribed documents. Ours is not done through Cloverleaf, because it’s primarily driven by the transcription system, which currently doesn’t send anything through Cloverleaf. We query the transcription system (Softmed, through their Report Generator) to get the transcriptions for the previous day, run a query to get demographics for those records (in a fixed file format that the Radiology doctors group just had to learn to interpret), then we send them that file as an encrypted email attachment, and route the transcribed documents to them as encrypted PDF’s.
And that was the easiest way to do it….
🙂
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
