Difference between revisions of "Documentation for CPRS Text Integration Utility (TIU)"
(→Overview of Integrating Transcription with VistA) |
(Added glossary link to Record~) |
||
Line 33: | Line 33: | ||
3. The file is then uploaded from the desktop PC, where it was created, into VistA in one of two ways. Either it is uploaded with the "Kermit" transfer protocol (supported by many terminal emulator programs), or the file is transfered by some other protocol (i.e. scp etc) to the host file system. From there VistA can get the file locally. | 3. The file is then uploaded from the desktop PC, where it was created, into VistA in one of two ways. Either it is uploaded with the "Kermit" transfer protocol (supported by many terminal emulator programs), or the file is transfered by some other protocol (i.e. scp etc) to the host file system. From there VistA can get the file locally. | ||
− | 4. The file containing all the notes is then processed one note at a time. First the type of note is used to decide how to handle the fields that follow. The data from the fields is stored in temporary variables and a "filer" program is called. This filer program will take the information and create a database record for the note. I.e. it stores it in the database. If the filer can't handle the information, or if something is missing, or the specified patient can't be found etc., then it returns a failure code. | + | 4. The file containing all the notes is then processed one note at a time. First the type of note is used to decide how to handle the fields that follow. The data from the fields is stored in temporary variables and a "filer" program is called. This filer program will take the information and create a database [[record~|Record]] for the note. I.e. it stores it in the database. If the filer can't handle the information, or if something is missing, or the specified patient can't be found etc., then it returns a failure code. |
5. For each note that has failed the upload process, an "alert" is created in VistA. This is kind of like an e-mail with the failed note attached. The transcriptionist is given opportunity to edit the note from inside VistA to fix the problem and then retry the filing process. | 5. For each note that has failed the upload process, an "alert" is created in VistA. This is kind of like an e-mail with the failed note attached. The transcriptionist is given opportunity to edit the note from inside VistA to fix the problem and then retry the filing process. |
Revision as of 21:39, 10 March 2012
Overview of Integrating Transcription with VistA
Let me outline the steps needed to get transcription into VistA. This is not a hack — VistA has a full transcription package.
1. In VistA, one must set up document types, such as "progress note", "history and physician", "telephone note" etc. I suppose everything could be called a "note", but it's not as helpful when looking back over a list of notes for a patient in CPRS. For each document type, one defines upload fields such as "patient name", "date of birth", "sex", "social security number". Each of the fields can be specified as required (or if not specified then they are optional).
2. The transcriptionist will enter data for these fields. VistA will display a help screen for the expected format for a given note. Below is a printout from my "Phone Note" type document. The fields shown are all the possible fields. They are not all required:
==================================================== [NewDict]: PHONE NOTE Alias: Jones,Abe ChartNumber: 123456789 Date of Birth: 01/01/1972 Date of Encounter: 04/21/2003 Patient Name: Jones,Adam B Provider: Houser,Doug Social Sec. Number: 123 45 6789 Sex: MALE Visit Location: Main_Office Transcriptionist: Fingers,Speedy Name: Jones,Adam B [TEXT] PHONE NOTE Text [END] *** File should be ASCII with width no greater than 80 columns. *** Use "///" for "BLANKS" (word or phrase in dictation that isn't understood). ====================================================
All the dictation for a given provider (or even multiple providers) can be put into one big file, split up by headers for each type of note.
See the section "Text Formatting" below for a discussion on the document text requirements.
3. The file is then uploaded from the desktop PC, where it was created, into VistA in one of two ways. Either it is uploaded with the "Kermit" transfer protocol (supported by many terminal emulator programs), or the file is transfered by some other protocol (i.e. scp etc) to the host file system. From there VistA can get the file locally.
4. The file containing all the notes is then processed one note at a time. First the type of note is used to decide how to handle the fields that follow. The data from the fields is stored in temporary variables and a "filer" program is called. This filer program will take the information and create a database Record for the note. I.e. it stores it in the database. If the filer can't handle the information, or if something is missing, or the specified patient can't be found etc., then it returns a failure code.
5. For each note that has failed the upload process, an "alert" is created in VistA. This is kind of like an e-mail with the failed note attached. The transcriptionist is given opportunity to edit the note from inside VistA to fix the problem and then retry the filing process.
Text Formatting
Now some more info about the text formatting of the file containing all the notes. It has to be ASCII only (i.e. not in MS Word or WordPerfect format). This means that formatting commands such as bold or underlining or italics etc are not allowed.
Each line should be 80 characters or less in length. In practice this means that the transcriptionist has to hit <ENTER> at the end of each line (i.e. don't use word wrapping), or use a word processor that can change all the word wrapping into clipped lines for you. Microsoft Word has such a formatter. In older versions (e.g. Microsoft Word 95), this done by setting "MSDOS text with layout" as the save type when saving. In newer versions (e.g. Microsoft Word 2003), this is done by setting "Plain Text" as the save type when saving, and turning on "Insert line breaks" in the subsequent dialog.
Kevin Toppenberg
5-10-05