Forum Replies Created
-
AuthorReplies
-
Okay, I’m flummoxed. I wonder if the SQLite in cl 5.7 was compiled without fts3? It’s a config switch to the compiler, and it’s not automatic. fts3 has been there since SQLite 3.5, but I don’t know when it started being the default in Cloverleaf.
Max or Charlie?
Ah. So you are logged in as a cloverleaf user on a unix-like system. In that case, you should NOT use sqlite3.
When you logged in with all of the setup associated with being a
Cloverleaf user, you usesqlite to access Cloverleaf related SQLite stuff. If you wanted to access your system’s sqlite shell, you’d probably usesqlite3 (or an absolute path.)### ‘which’ shows the difference: I’m logged in as a Cloverleaf user ###$ which sqlite
/opt/cloverleaf/cis6.0/integrator/tcl/bin/sqlite
$ which sqlite3
/usr/bin/sqlite3
If you’re on RedHat, it’s very likely that the Cloverleaf SQLite is ahead of your system SQLite, possibly by as much as a version number!
I don’t think he had it wrong, Charlie.
Mike,
Set up your globals when the process starts and access them during the run phase. I don’t have any code left anymore, but I used to do this in 5.3 with a small list. It was essentially a very short list of provider ids I needed to screen out of a thread, but I couldn’t justify loading it every time the proc was run, small or not.
How big a chunk of memory are you talking about? If you are screening ADT based on duplication, Epic can be set to kill duplicates that are sent in a short time span.
😈
I bet this “lock” would go away with a cleanup. You won’t see the pid accessing a smat file if there isn’t actually any access going on. Just sayin’…
It would be best if your thread was set to accept the encoding Epic is sending. This might take some experimentation to figure out. The most likely guess is Latin-1, I think, even if all of the settings say it’s ASCII. You know it isn’t really ASCII, because you see the circumflex. I’m assuming you’re seeing the
No, you definitely don’t want to change it from ASCII, but you
do want it to come into the thread and change itto ASCII. Since you can’t see it in ASCII but can see it in another encoding, you can fix this in the engine by accepting the encoding, and then substituting the component escape for the circumflex. You have to make sure you are not getting any other encoded characters from Epic, or you will be doing a translation for each of them. When the output is “clean” you can send it, as ASCII, to the downstream systems.Cloverleaf has
hcihexdump for dumping a file from the command line. Programming editors usually have a way to view files as hex.And, not to harp on it, but
Epic should be fixing this. The Bridges TS and the Beaker TS need to have a little talk and get this working as ASCII encoded HL7.Scott —
You can also push a little higher into the Epic interface technical support. A lot of newer interface TS’s don’t really get it, and their programming experience is limited to what is essentially a MUMPS networked database.
The higher level understands that an engine doesn’t automatically save messages for future use. They aren’t astonished by it, and usually have some experience with other solutions.
Epic is sending UTF8, which for most purposes is ASCII.
Probably the font in use in the client is missing a glyph for the circumflex codepoint, which is why you see a box.Try looking at a hex-dump of the message if you want to get the real details.
Can the AIP be tweaked to send the escape for the component separator? Fixing this might take an SLG, if you haven’t opened one.
Otherwise, you might try doing a map to the escape in the engine.
If neither of those is an option, can Beaker send the measurement unit in some other format? Maybe 1E3 would be acceptable.
Tyler —
We haven’t run into this problem with Epic. Is there a profile variable for the character encoding in that results AIP? Try checking your ASCII_CHARS_TRASLATION_TABLE setting — your table may be messed up.
You should talk to your TS about this. You shouldn’t getting Unicode (probably Unicode, anyway) out of Epic unless you’re getting results as a formatted report, not HL7.
Jeff W Dinsmore wrote:
For dynamic access to SMAT messages, we have an indexing function that takes indexing info from the idx files, extracts a few data elements of interest from each message (message trigger/type,MRN,encounter, etc) and drops it into an SQLite DB.Do you have a scheduled job that does an
hcimsiutil -Z to your threads?Carl Duff wrote:Got it working (kinda) and for what it’s worth….
set xlateOutVals [lindex [lindex $xlateInVals 0] 2]
would access the 3rd element of the list.
Additional comments/suggestions welcomed.
-Carl
The xlateInVals list is a list in a list, but the “{ … }” that surrounds it isn’t visible.
Mike Strout wrote:After a little more research, it seems that one needs to assign the result of lreplace to a variable for it to be saved.
Not correct
lreplace $segments 6 6 “”
Correct
set segments [ lreplace $segments 6 6 “” ]
The quickest way to tell what kind of command you’ve got is to see if the syntax expects a variable, or the contents of a variable. If it says
Code:cmd $foo ; # to save this you want % set foo [cmd $foo]
it will require a set to save the results, if it says
Code:cmd foo
it is directly manipulating the contents of the variable.
Getting the interpreters right in the testing tool is an amazing feat, and the tool has just been getting better over time. But I wouldn’t use “what works in the testing tool” as a guide to syntax, yet.
-
AuthorReplies