Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › another newbie question
- This topic has 11 replies, 6 voices, and was last updated 14 years, 6 months ago by
Dennis Shirk.
-
CreatorTopic
-
May 30, 2009 at 11:01 pm #50919
Dennis Shirk
ParticipantI have a text file that has three messages for each patient in it. The fist message is the ADT the next is the ORM and the third is the ORU. I need to take to take the PID, PV1, PV2 and possibly the NK1 from the ADT and -
CreatorTopic
-
AuthorReplies
-
-
June 1, 2009 at 3:08 pm #68006
Robert Milfajt
ParticipantAt some point, you need to lose the tag newbie! 😆
What you ask is pretty complicated stuff. Cloverleaf is a message by message processing machine, and to have it remember data from one message for another one coming down the chain, is not in its nature. I sure hope that the source system will always have ADT-ORM-ORU, or you could be in some trouble with your solution.
Anyway, I asked myself how I would go about this task, and something came to mind. You could create two routes for your file messages.
1. ADT messages down one route, which create a file in some directory with some unique patient idenficaton, e.g., MRN, in the file name. This gets your ADT information for the ORU route to use.
2. ORU messages down another route, where a TCL proc could open/read the ADT file, get the data you need, and set it into the ORU message, and destroy the file when it is done.
The TCL would be quite complicated, and it is not something I have handy to post, but you would use the open, read and close commands to get the data from the file, the exec command to run OS command to delete the file, and various other commands to move the data from the file to the ORU message.
I would like to hear what others think!
Good luck,
Bob
Robert Milfajt
Northwestern Medicine
Chicago, IL -
June 1, 2009 at 3:24 pm #68007
Dennis Shirk
ParticipantThanks for responding. I would also like to hear what others think. The more ideas I get the better 🙂
-
June 1, 2009 at 3:49 pm #68008
Jim Kosloskey
ParticipantSorry I have to be brief.
What I would do is to see exactly what the receiving system needs.
I would then see what the sending sysgtem provides in the ORU. Many systems provide a fair amount of Patient demographics in their Result messages.
If the two match up (the sending system is sending what the receiving system needs in the ORU) then you are finished.
I suspect the reason to get the ADT info is because the receiving system does not support ADT and needs the patient to be ‘registered’ in order to post a result.
Perhaps you can create a dummy ORU from the ADT (Xlate ADT to ORU)that will ‘seed’ the receiving system so that the patient exists. Then the real ORU will post the result.
The GnuDB might be useful here as well.
There is always Sql-Lite (I think that is the tool) but it does not come with Cloverleaf(R).
email: jim.kosloskey@jim-kosloskey.com
-
June 1, 2009 at 5:28 pm #68009
Sergey Sevastyanov
ParticipantDennis,
I agree with Jim, first check what you are missing in ORU that is required by receiving system. As far as I know Memorial Hospital in York, PA is on McKesson Paragon (and so are we). Paragon does include PID, PV1 and PV2 in their ORU messages. So if you are sending Paragon messages then only NK1 is missing (and it sounds like it’s optional).
If you are sending to Paragon then it’s likely that Paragon needs just minimum information, so you could build a database and store necessary information per patient/per visit (or whatever other criteria you need) and pull it while translating the messages.
Of course that would require some Tcl programming along with database access routines.
Thanks
-
June 1, 2009 at 7:42 pm #68010
Robert Milfajt
ParticipantQuote:Perhaps you can create a dummy ORU from the ADT (Xlate ADT to ORU)that will ‘seed’ the receiving system so that the patient exists.
Then the real ORU will post the result.
I like Jim’s idea here. This is your best bet because it pushes the responsibility of storing the data and processing down to the receiving system, where it belongs. The less Cloverleaf has to do, the easier you job of support becomes.
Bob
Robert Milfajt
Northwestern Medicine
Chicago, IL -
June 1, 2009 at 8:26 pm #68011
Dennis Shirk
ParticipantThanks everyone who replied. I appreciate all the ideas.
-
June 3, 2009 at 4:28 pm #68012
Tim Faul
ParticipantRobert Milfajt wrote:Quote:Perhaps you can create a dummy ORU from the ADT (Xlate ADT to ORU)that will ‘seed’ the receiving system so that the patient exists.
Then the real ORU will post the result.
I like Jim’s idea here.
-
June 10, 2009 at 2:49 pm #68013
Dennis Shirk
ParticipantHey guys,
I had one of my coworker write up a script in C and he now has all of the data that I need in one ORU message. What we are going to do is have a sql script dump all of the messages to a file with the three different types of messages. Then this C script will run and and pull out the different information that we need and put it all into one ORU message.Then I can have Cloverleaf send the ORU message to a company called MEDent. The C script will run on the hour and overwrite the text file from before. My question then is how can set the inbound thread to restart every hour to pick up the new data?
-
June 10, 2009 at 3:14 pm #68014
Ron Archambault
ParticipantJim,
SQLite is available in 5.7 as a package lib in tcl. I have not used it yet but we’re planning on taking advantage of it in some new project once we complete our upgrade.
Ron
-
June 10, 2009 at 3:19 pm #68015
Sergey Sevastyanov
ParticipantDennis,
If I understood you correctly, you want your thread occasionally (every hour) to check for a file.
You can do it using ftp-fileset protocol (or ftp-local if the file is created on your cloverleaf server). You can specify how often to check for your files, or you can use advance scheduling (I never used that one).
Thanks
-
June 10, 2009 at 4:00 pm #68016
Dennis Shirk
ParticipantThat is what I am looking to do . I will check out both options then. Thanks Sergey
-
-
AuthorReplies
- The forum ‘Cloverleaf’ is closed to new topics and replies.