Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › another newbie question
- This topic has 11 replies, 6 voices, and was last updated 15 years, 4 months ago by Dennis Shirk.
-
CreatorTopic
-
May 30, 2009 at 11:01 pm #50919Dennis ShirkParticipant
I 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 #68006Robert MilfajtParticipant
At 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 #68007Dennis ShirkParticipant
Thanks 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 #68008Jim KosloskeyParticipant
Sorry 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 29+ years Cloverleaf, 59 years IT - old fart.
-
June 1, 2009 at 5:28 pm #68009Sergey SevastyanovParticipant
Dennis,
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 #68010Robert MilfajtParticipantQuote:
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 #68011Dennis ShirkParticipant
Thanks everyone who replied. I appreciate all the ideas.
-
June 3, 2009 at 4:28 pm #68012Tim FaulParticipantRobert 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 #68013Dennis ShirkParticipant
Hey 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 #68014Ron ArchambaultParticipant
Jim,
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 #68015Sergey SevastyanovParticipant
Dennis,
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 #68016Dennis ShirkParticipant
That 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.