|
|
|
Table of Contents
Table of Figures
Main Menu
Start Background Extracts XVI,
XV, VIII & XXI
Talons Extract Checklist
PowerPoint Presentation
Running Extracts
PowerPoint Presentation
Recreate XVI Extracts
Y.T.D. Summary &
VII
Paris Extract
Process Third Party
Files
Process ORMIS Extract
(draft)
Process
Excelcare Extract
Emergency Feeder Products
List Unix Subdirectory
Print Spooler Access
Talons Spooler Access
PowerPoint Presentation
Purge Files &
Lists
Talons Purging PowerPoint
Presentation
List Files on NT FTP
Server
Mapping & Setup
Menu
Talons Mapping
PowerPoint Presentation
Department Codes Entry
Departments not
required
Date Variable
Mapping
Create &
Check Units & Wards
Flag Episode
for XV Extract
FTP System
parameters
FTP Password
Extract Tables
for XV
EDIS Discharge
codes setup
Check Saved XV Fields for changes
Saved XV data start date
View Job Status Menu
Extract XVI
Running status
Principles of operation
Processing
Extract XVI, what happens & Why
These links should be used with care, the latest Versions are listed at Other Documents
Episode
Bundling Episode Matching & Bundling
PowerPoint Presentation
Inpatient
Unlinked
QH Feeders Episode Parameters
APP Clinic Excludes
2003-2004
Changes
Electives System Linking (electives Interface Business Rules)
Extract Checklist Talons Extract Checklist PowerPoint Presentation
2003-2003 Talons Changes & V3.0 Notes
Figure 1 Main Menu
Figure 2 Date Entry Screen,
CSH.PERIOD
Figure 3 Launch Options
Figure 4 Prerequisite Data loading
& processing
Figure 5 List of process subroutines
to be run.
Figure 6 Time for Bed?
Figure 7 EX.XV.IP.UNIX.zzz Options
Figure 8 Print output Spooler
Figure 9 Mapping & Set-up Menu
Figure 10 Department Codes Entry
Screen
Figure 11 Date Variable Mapping
Entry Screen
Figure 12 Listing of unmapped wards
& Units
Figure 13 Flagging an Episode for
inclusion in XV
Figure 14 FTP parameters extract
Figure 15 Job Status Menu
Figure 16 Extract XVI running status
Figure 17 Phantom job
Status
Table 1 Paris Layout
Table 2 Ormis Layout
Back to CSH Homepage Back to Table of Contents
Talons is the suite of programs that draws data from "feeder" systems on a number of systems based on the HBCIS platform, as well as other systems. It collates the data, brings it to a common format, then produces various extracts of this data for use in Transition II®
Feeder systems include A.T.D., P.M.I., Medical records, Emergency, Theatre, Outpatient Appointment, Pathology, Radiology, Allied Health, Nurse dependency, Elective Admissions as well as other local specialist software.
In drawing the data in, in some instances, products are "created" from date time data or combinations of other data fields, in others, well-defined products are already in use and are just extracted.
The major function of Talons is to link these products to a specific admission episode, emergency attendance or outpatient event. In systems where no outpatient appointment feeder is used, unlinked pseudo episodes are created.
As data is exported into files suitable for import into Transition II for Unix, Talons is able to Map local department codes both real and implied, into Standard Department codes as defined by the implementation.
Talons Software is installed on the C.S.C. Unix platform as an account in the Reality Database. Output from Talons is exported to a Unix sub-directory in flat Unix ASCII file format. Files may be subsequently compressed using Unix compression utilities. Files may then be FTP’d onto another system.
To access talons, use the normal method for accessing the HBCIS modules using the local Unix login. The Account name will vary but will most probably be "TALONS-ZZZ" where ZZZ represents your Facility TLA (three letter acronym).Some sites may have another level of security and will require you to enter a user id and password. (Commonly called SEC2 security contact your system administrator to get SEC2 access to TALONS-zzz)
If using Reallink for Windows telnet client program, there should be no problems with emulation. If using Super TCP VT320, Microsoft Telnet or other vt220 compatible emulation, after you log in you get "IztA" or similar, hit enter at least five times till they stop, then, if the screen comes up all over, type VT, this will correct it and refresh the screen. If "SEC2" CSC security is in use, you may type "TERM" at the menu prompt to set-up your terminal type to VT. Your System administrator will assist you with this set-up as well as with Port parameters settings.
The following main menu will appear, (please note the frame and window menu items on the screen dumps will vary according to the telnet client in use)
Figure 1 Main Menu
There may be more, less, or different numbered lines, the function of the line is defined by the description, not by its number. In all cases, where the description includes the word "Menu", another page of menu options will be displayed.
In the following pages, The manual will describe the various programs and tasks that are activated by the menu options. There will be no reference to menu numbers, only to the parent menu name where appropriate. You may choose to add your menu numbers to the index.
This is the major processing option and allows all normal monthly extracts to be created. Extracts started in this way will run as what is known as TIPH jobs, (Terminal Independent Process handler). Some may know of them as Phantom Jobs. After the Job is launched, your screen will return to the menu. You may log off or disconnect, or be disconnected, and the Job will still complete. The date entry Screen will display
Figure 2 Date Entry Screen, CSH.PERIOD
This allows the entry of financial year and calendar period, the combination of terms is used to ensure that no confusion exists in the mind as to what is being asked for. Enter the first year date e.g. for 1996-1997 enter 1996, then <enter>, then the calendar month as a number then <enter> (e.g. 7 is July), then confirm with a Y <enter>. If you do not confirm, you will be re-prompted, if you press <esc> then <enter> you will return to the menu.
A list of periods processed and the dates they were processed are shown. (Note this screen is compliant with Y2K issues)
Another screen will follow if satellite / supplementary sites are to be process listing the Accounts and TLA of the additional sites.
Following this screen you will be prompted for the tasks you wish to start, EX.XVI.UNIX & EX.XV.IP.UNIX. You may start one or both. In the future there may be more processes that can be started in this screen, and the process names (as here) may vary.
Figure 3 Launch Options
Both processes may be started together.
The following screens pertain to EX.XVI.UNIX, which creates utilisation extracts.
The first screen will tell you if the pre-requisite data from third party systems has not been loaded. This only indicates that the loading process has been done, and the number of records loaded.
Figure 4 Prerequisite Data loading & processing
You may choose to exit at this point to run the appropriate prerequisite, if all are in order, you will not be prompted.
The next screen allows you to choose which of the several subroutines you may choose to reselect the data file for and then process.
<<<Unless you know what you are doing always say "Y" for yes>>>>
Figure 5 List of process subroutines to be run.
Processes will be run regardless for modules if the period has not been run before for that module.
Re-Selection only relates to the data file as it exists on the HBCIS system or a pre-loaded Talons third party file, it does not relate to re-importing or re-loading the Third party file from the FTP server.
You will be prompted with the following
This option will RE-select data from main data file rather than use a previously saved list of data (Almost always use 'Y')
THIS OPTION DOES NOT DISABLE A FEEDER
When extracts are fun for any period, a list of the "Selection" from the data file is saved,
If you choose to "NOT" reselect from the data file when repeating a run, The existing list will be used,
If you then choose not to re-process the extract data, the Output products will be exactly the same as the last time the extract was run for that period.
You will be prompted with this as a reminder
RE-PROCESSING will re-crunch the data and will always occur if the data is RE-selected (Almost Always use 'Y')
THIS OPTION DOES NOT DISABLE A FEEDER
If you choose to re-process while not re-selecting, the data may change very slightly if the source data file existing records have been altered or updated in any way,
If you choose to reselect, then re-processing will automatically occur, and any new records will be added to the extract, and any changes to existing records will reflect in the output.
In general, always re-select and re-process Y & Y unless you are confident you know what you are doing, why you are doing it, or have been asked to do it by CSH or Allegiance staff.
A prompt for the time and date to sleep until processing will commence will then appear. The Phantom will launch now, but will go dormant before actually processing any data until the next occurrence of the time specified on the date specified. Your IMSU will advise you of when they would prefer you to run extracts, taking into consideration processing demands on your system. The process will run even if you log off your terminal, only a reboot of the CSC Reality database or action by Systems staff to kill the job will prevent it from running.
Figure 6 Time for Bed?
Enter the time in 24hour clock, press space <enter> to run now.
The following screens relate to running the demographic and medical records extract XV.
Figure 7 EX.XV.IPz.zz.UNIX Options
You may choose to force a reselect of the file (normally choose "Y"). You may also choose to monitor for changed admissions in the current and last financial periods. This should be done at least once a month, but use the option in the codes setup menu in general.
The Cut-off Date for old data will cause only data after and including this date to be extracted. This date can be changed backwards and forwards. Data being held for extract due to changed Admissions information with discharge dates prior to this date will be held
In addition you will be prompted for the time and date to start this extract unless you have just set off an XVI extract, in which case the XV will automatically be set to follow the data gathering of the XVI to ensure all XV data sourced from running and XVI is included.
The TIPH extracts will run, printed reports will be output to the spooler options set as system default and extract files created and placed in the appropriate locations.
All tasks will be run in the order required and under normal circumstances no other action will be required. You may choose to run your EX.XV.IP.UNIX.ZZZ as often as you wish, weekly would be normal. The EX.XVI.UNIX extract (utilisation) must be run Monthly about 14 days after the end of the month after all other required data has been loaded and processed. The VIII and XXI files are produced in this extract as well.
This option is more or less identical to the "Start Background extracts" options except that it will recreate only XVI extracts, without re-selecting or processing. It is used solely to re-create the Unix output file if modifications have been made to the Department code mapping table. Please note, if you have changed date information for wards as well as mappings this option will still produce correct output and totals for extract X.
Talons maintains year to date information for a period of 10 years, this information can be used to produce a extract VIII. A version of the standard date screen CSH.PERIOD will prompt only for the financial year. The extract will be processed and the reports run to the spooler. (An option to copy a Hold file from the spooler to the Unix extract file for use in importing to excel or access exists on the UTILS menu and is documented in that section)
<<<< Please note. >>>>
Where department code mappings are varied or entered incorrectly then changed or other similar circumstances, YTD data may well be lost or incorrect in one or more periods.
This option allow a PARIS extract file to be processed, the file must be placed in the TALONS Unix directory as defined at your site, with full read & write access permissions for all users. Please ensure the file is named consistent with the convention parisYYMM. Any file name may be used but the default option makes life simpler.
| Start | Length | Format | Description |
| 1 | 9 | Left | Unit record number |
| 16 | 10 | Left | Location code (Patient PMI location) |
| 26 | 10 | dd-mm-ccyy | Date of Service |
| 36 | 5 | hh:mm | Time of service |
| 41 | 10 | Left | Product code |
| 51 | 10 | Left | Department performing service |
This option allow a third party file extract file to be processed, the file must be placed in the TALONS Unix directory as defined at your site, with full read & write access permissions for all users. Please ensure the file is named consistent with the convention (feeder)YYMM. Any file name may be used but the default option makes life simpler.
The data layout for this extract is fixed as follows in the table, each record is on one line and no delimiters are used.
| Start | Length | Format | Description |
| 1 | 10 | Left | Unit record number |
| 16 | 10 | Left | Location code (Patient PMI location) |
| 26 | 8 | dd/mm/yy | Date of Service |
| 34 | 5 | hh:mm | Time of service |
| 39 | 10 | Left | Product code |
| 49 | 10 | Left | Department performing service |
| 59 | 10 | Left | Quantity provided |
Process ORMIS extract (draft)
The ORMIS extract option allows an ORMIS file extract file to be processed, the file must be placed in the Network directory as defined at your site, with full read & write access permissions for all users. Please ensure the file is named consistent with the convention THTRYYMM.CSV. Any file name may be used but the default option makes life simpler. YYMM 9707 = July 1997.
The Xlcare extract is performed on files produced by the XLCare Patient dependency Module at RCH (Herston)
The current file format usage is as follows
Data |
Col |
Length |
Notes |
URNO |
6 |
7 |
Alphanumeric |
LOCATION |
27 |
2 |
Alphanumeric |
| Date of dependency | 51 |
6 |
YYMMDD |
| Time | 76 |
4 |
HHMM |
| Dept | 29 |
4 |
Alphanumeric |
| Product | 33 |
3 |
Alphanumeric |
| Quantity | 35 |
5 |
Numeric |
The process option will load the data into the holding files for extract with other data. It is possible to load more than one file at a time.
Filenames The DOS files from Xlcare should be placed in the designated location on the FTP server. The filenames should be as follows XL 98011.TXTWhere 9801 represents the calendar month i.e. January 1998,the 1 represents the file number.XL and .TXT are fixed |
If only one file is sent then it is Number 1.
If the filename is incorrect, either by style or by Case, it will not be collected
Running the process
TMS & EDIS
These extracts are functionally
equivalent. EDIS Data must be pre-loaded from the Menu option before running
extracts
|
Feeder |
Product |
Qty |
Description |
|
TMS |
MINUTES-n |
Mins |
The
number of minutes between time seen and discharge at triage level n |
|
TMS |
TR-<n> |
1 |
A
counter of patients at triage level n |
|
TMS |
UDG-<n> |
1 |
A
counter of patients at UDG level n |
|
TMS |
<procedure> |
1 |
A
counter for each procedure identified |
|
|
|
|
|
|
EDIS |
TRMIN.<n> |
Mins |
The
number of minutes between time seen and discharge at triage level n |
|
EDIS |
TRCTR.<n> |
1 |
A counter
of patients at triage level n |
|
EDIS |
UDGMIN.<n> |
Mins |
The
number of minutes between time seen and discharge at UDG level n |
|
EDIS |
UDGCTR.<n> |
1 |
A counter
of patients at UDG level n |
|
EDIS |
P.<prodeure> |
1 |
A counter
for each procedure identified |
Record
Selection And periodising
Selection is based on
Arrival date
UDG, meaning
and where it comes from
UDG is based on the
work of Richard Ashby at RBH, and is a combination of disposal and triage code.
The codes mean
as follows
|
UDG |
Description |
|
1 |
Died In Dept |
|
2 |
Triage level 1
and admitted into Hospital |
|
3 |
Triage level 2
and admitted into Hospital |
|
4 |
Triage level 3
and admitted into Hospital |
|
5 |
Triage level 4
and admitted into Hospital |
|
6 |
Triage level 5
and admitted into Hospital |
|
7 |
Triage level 1
and sent home |
|
8 |
Triage level 2 and sent home |
|
9 |
Triage level 3 and sent home |
|
10 |
Triage level 4 and sent home |
|
11 |
Triage level 5 and sent home |
|
12 |
Did not wait |
|
DOA |
Dead on arrival
(for Certification) |
|
nn.xx |
Other
combination of Triage and disposal code no matched above |
The last two
codes are not strictly UDG's but allow complete characterisation of all
remaining patients.
This data is
derived purely from the Discharge codes and the sense they have, and the numeric
triage Urgency codes.
This option lists the Unix Subdirectory, showing the size and ownership of all files.
This provides access to a spool job control program supplied as part of Talons. Please remember to clear spool jobs periodically.
Figure 8 Print output Spooler
There are two prompts, one for the job number, the other for the action. No action will be taken on Open or Printing jobs. Use <esc> to exit.
Job No:
Action:
 | E for Edit, allows the viewing of the contents of print jobs, and also printing and deleting. While editing a Job, use EX to exit from the "." Prompt, P to page, T for Top, B for Bottom and L/fred will find the first occurrence of fred, successive A’s with repeat again, or use L999/fred to see all occurrences in 999 lines of fred(case is important here). SP will start printing the job from the current location of the cursor in the file back to the top of the current page. |
|
| P to print, this option will send the Job to the queue specified. |
|
| D to delete, deletes select Job(s). |
|
| Q to switch queues, this will change a job to another queue. |
|
| C to copy a Job to the Unix directory as a TXT file for import into Excel or similar. This file may also be copied to the FTP server used by TALONS for third party file access, the filename will be JOBnnn.TXT |
|
| A will switch to an alternate account. |
If there are more than 15 Jobs enter at the job number will page through them.
Selecting this option will prompt with the standard date entry screen, You will then be prompted whether to clear the Unix subdirectory as well. Some text on the screen will remind you of the actions and need to take them.
Purging Files
The Talons Purge option allows the selective purging of Pick data files in the Realityâ Database, Item Lists in the Realityâ system pointer-file, and Unix extract files located on the HBCIS Sun Box. These will be discussed in detail below.
When to Purge
Once a period has been fast loaded and it is not expected that the period needs to be re-processed, it can be purged.
Consequences of purging to reprocessing
If a period is purged, all third party files for that period, such as ORMIS, AUSLAB, PARIS, TRENDCARE, or EDIS, anything that is imported from outside the HBCIS system at all, must be re-loaded.
What Does Purging Do in detail
As noted, purging removes period data files from the major data files within TALONS, the major data files store each period as a separate "Data Level", purging deletes that data level, allowing the space to be returned to the unused pool of Realityâ free space. Data levels are created as required and identified to each period. Frequent Purging will minimise the space taken by TALONS in the Realityâ database.
Realityâ stores selection "queries" as a List of item ID's in a System file called the Pointer file. Purging Deletes these lists that are no longer required. Some lists are not deleted, these keep track of changes for certain functions, the Purge function handles this automatically.
TALONS as part of its function creates Unix data files, these are stored as compressed ".Z" files in the TALONS Unix files directory, some of the files in this directory are imported files. The Purge function will delete all files starting with the Sites three letter Campus code and for the specified period. Imported files will not be purged by this function.
Not all imported files from the NT FTP box are saved, gradually all Import processes are being modified to delete files after import and processing. Files directly FTP'd to the Unix directory must be managed by the user. Copies of all third party files should be left on the FTP server for as long as it is conceivably possible they may be required, then archived off to some other secure storage location
.Purging at a Multi Account site
Sites such as Mater and Redcliffe/Caboolture require that Purging be carried out in each account, as a security feature of Realityâ only allows deletion of Data levels from within the actual account. This is handled by providing a Phantom process launcher to purge files by launching a phantom process in each account to do the task. The Purging is only one of several processes that can be started by this Phantom process starter.
This option allows the listing of the TRANSITION Unix host import directory. Remember these files are on a remote system, not this one, check details such as date time and size to verify correct completion of extracts. Use backpage on your terminal emulation to see previous pages
List Files on IBM Host
List files on Auslab Server
These options allow the paged output of remote system file listings
Figure 9 Mapping & Set-up Menu
This menu contains the screens to undertake tasks associated with setting up mapping table from local codes to Standard department codes and to Mark a specific inpatient episode for re-transmission.
Department codes are entered on the Dept code screen off the Mapping & Set-up menu. This allows mapping of local codes and descriptors to the Standard Casemix department codes specified for the Queensland implementation of transition two. As codes may exist in several feeders, the feeder system and code are joined with a colon ":" to define each as a unique ID. A description (free text), feeder system (optional) may be entered, the Transition department code must be entered, and will consist of 4 alphabetical uppercase characters followed by two numeric characters.
The Talons system will automatically assign codes to new departments, these codes will be in the range XXAA01 to XXZZ99. They must be re-mapped in Both TALONS and in transition PRIOR to POSTING, or remapped in Talons, and the period re-extracted using the MENU option to Recreate output file.
Map non-required departments to a nominal value, suggestion is to use ZZZZ01. Do not leave them at the assigned XX value or they will always list in error lists. A matching Mapping on Transition should not be set up.
The screen is similar to the illustration below, note fields may have been added for site specific purposes.
Figure 10 Department Codes Entry Screen
Data Entry notes.
For "Ward Departments" that change location, ward code and ward type , a date based mapping table can be used to allocate a geographic location code to different departments and ward types. It is important to note that this date based table defines the departments that occupied the location on the dates specified, not which location a department occupied on specified dates. In compiling the preparation for this table it will be helpful to think primarily about the location first. e.g. CC5 location was CCU Ward from 1/9/96 to 31/12/97, then was General Medical 3 from 1/1/98 to 3/2/98 etc. Do not think of it like CCU was in CC5 from 1/9/96 till 31/12/97 then in CC6 from 1/1/98 till 4/7/98 then …. or we will all be confused. If when a ward was re-located, it tooks its ward code with it, then no change is required. This function is only applied when the same Geographical Ward Code has housed several different departments using that Geographical Ward code for each one.
Some additional data entry techniques exist for this table, the table will only appear for "WARD" feeder codes such as WARD or PDS2. In addition xxxWD for sites with Multi campii accounts where xxx is the Campus Identifier, this applies to RED/CAB. If no data is entered, the value used will be the value in the master screen. If the date of the service is outside the ranges specified, the master screen value will be used. Enter or modify the data then move the cursor to the bottom-most line where no department is specified, then hit spacebar then enter.
Figure 11 Date Variable Mapping Entry Screen
The table will sort data, removing nonsensical sequencing and blank lines, and ensuring lines are in date order, and that one day follows another. If a product occurs on a date not within the ranges specified, it will be mapped to the value in field 4 of the main screen.
Create & Check Units and wards
This option collates the Wards & Units files and creates any non-previously defined departments. It will then produce an output to the screen or Printer showing those departments, their descriptions, and the code assigned to them.
Figure 12 Listing of unmapped wards & Units
Only non assigned codes appear in this list (starting with XX…..), running this option prior to running an extract will facilitate identification of new wards and units that have been set up since last mapping was completed.
Figure 13 Flagging an Episode for inclusion in XV
This screen allows an episode to be flagged for sending in the next extract. Only use this screen if you understand why you want to send an episode up to Transition again, and what that will mean. Enter the episode number as per urno-sequence e.g. B123456-11, then file the record. Exit the screen with the <esc> key or END (F1) key.
Added 2004-2005
There have been changes to this screen to allow Non existent (DELETED) to be flagged, and to alow the setting of a FORCE SEND status, which will push an episode through any Cutoff dates that have been set. Enter the Episode in Field one, Fields 2,3,4 are for information only, indicating the date and time, and process that placed a record here, Field 5 is set to either Y or N depending on your requirment to force the record through. THIS may upset closed periods, be warned.
Figure 14 FTP parameters extract
This screen allows the set-up of the FTP protocol parameters for transfer of the
extract data files from the Talons system to the transition system.
It is imperative that data in this screen is correct, that user id’s are entered in the
correct case and that path and directory names are correct. Note that above
/home/fred is incorrect, it should be /home/fred/, with the following slash.
Slashes depend on the system data is drawn from, these can be PARIS, ORMIS, EDIS, AUSLAB,
as well as MARY.ROSE which is where data is sent to. Delete entries no longer in use.
Filename and action fields are not used at this time. The password is no longer stored on
this screen, (see below) Line 05 is now blank on the above screen
A separate screen for changing passwords is accessed from the menu, this allows the Password for any system (usually MARY.ROSE) to be changed. The system name must be entered, default is MARY.ROSE and hitting enter will accept the default. Then enter the password then enter, then again then enter. Do not store a null password, if you have stuffed up, go back from the menu to do it again.
THIS ONLY CHANGES THE PASSWORD STORED ON YOUR SYSTEM DETAILS SCREEN- YOU MUST CHANGE THE PASSWORD ON THE ACTUAL HOST BY OTHER MEANS
To
Facilitate entry of HAS discharge codes a screen
on the Setup and codes menu has been added. This is only relevant to EDIS Sites.
The
fields are self explanatory and a Prompt message accompanies each Field. A Zero
or one is expected.
For Each
Discharge code in EDIS we are trying to ascertain the following.
The
combinations of these data elements allow the determination of the UDG.
Type
F to file each record after editing or creating.
This option creates a series of small reference tables for loading into T2. Refer extract guide 2-23 patient code tables.
Check Saved XV Fields for changes
This screen will run the CHECK SAVED INFORMATION process, see below. It should be run about once every couple of months. You can change the date here (see below). This process can also be optionally run with the XV extract, however it should be run here for preference.
This screen allows the start date for monitoring a number of set fields for changes.
The fields include changes to any one of the following data elements.
| Data Element | File details |
| Admit date |
Admissions File |
| Disch Date | Admissions File |
| DRG | MED-REC file |
| Account class | Admissions file, Account class at admission. |
| LOS - Leave | Admissions file, detects changes in leave status |
| Principle Diagnosis | MED-REC file |
| Discharge Code | Admissions file |
| Principle Procedure | MED-REC file |
|
Days On List |
EAM.ELECTIVES |
|
Wait
List Category |
EAM.ELECTIVES |
|
NMDS
Specialty |
EAM.ELECTIVES
10 , EAM.UNITS |
|
Contract
Role |
ADMISSIONS |
|
Contract
Type |
ADMISSIONS |
|
Admission
Type |
ADMISSIONS |
|
SNAP
Group |
SNAP
data as extracted |
|
Care
type |
From
Admissions File |
|
SNAP
Days |
SNAP
Data as extracted |
| Patient Date of Death | Patients File - Added 2003 |
Figure 15 Job Status Menu
This screen allows the status of currently and previously run Phantom (TIPH) jobs. The options interrogate a log file record for the current or last run job and display selected information.
Figure 16 Extract XVI running status
The screen is similar to the above but has less detail
In both screens, the top line indicates the options the process was started with and the
current time. The screens are refreshed every 3 seconds.Total bytes for XV VIII and XXI
are shown
Use the <esc> key to return to the menu.
Figure 17 Phantom job Status
This option lists the current status of phantom jobs, jobs with a status of "A" are active, "T" have completed normally, "K" are a problem. In this event print the Job number listed in the next column under "outfl#" or copy it to unix and fax/email it to Support.
The TALONS extract process uses modules of program code to perform extracts from various PICK data files and combine them into files that can be exported as extracts. Different modes of operation exist for different extracts, the most complex extracts are without doubt the Utilisation extracts Extract XVI. (I apologise for the complex nature of these descriptions, but the matter at hand is not simple)
Processing Extract XVI, what Happens & why.
The basis of existence of extract XVI is to collect and identify "Products" utilised by a patient, match them to an appropriate episode, and add them to various totals. This is effected programmatically by identifying episodes, identifying products, linking products to episodes, and then counting them all, finally producing an extract of the data they hold in the format we desire.
The major Episode identifying systems in a hospital are the Inpatient ATD system, the emergency department attendance system, and the outpatient appointments and attendance recording systems. These systems having quite different functions, store episode data in different ways, the first part of the extract process is to collect these episodes, create a common format pseudo episode identifier. The data is then stored in a consistent and easily retrievable manner keyed on the Patient medical record number.
To identify products, we must first select all data in our major data file that exists on the CSC system or third party file, then one record at a time. We derive the products from the data, check to see if the Medical record number has been changed, then match the date and medical record number to our episodes files. Finally the data is written into a common format file that accumulates the product quantities and is then later used for export.
As the process of Summarising can be most efficiently undertaken in conjunction with the exporting process, they are carried out together. The Accumulator file is selected, each record is then totalled to produce Extract X utilisation totals, and blocks of data are appended to our master Extract output file. At the end of processing, the Totals data is output as an extract as well. The Unix files may be finally compressed to save space.
Extract XV episode identification
As utilisation is identified, the episodes that it links to are also identified, and the period of that episode as well as the period of the utilisation is also identified, this may or may not be the same period. Inpatient episodes can pass from one month to another, and outpatient tests can link to an outpatient appointment in another period. As they are identified, they are included in lists of episodes to be sent in extract XV - demographic and episode based data. Inpatient Episodes are easy to identify from selections of the admissions file to produce a list of episode numbers of patients treated in the period. For outpatient episodes, there is no single means of identifying the episodes as accurately as identifying them as the utilisation is identified, as well as the period of the utilisation, for this reason, no Extract XV for outpatient episodes can be processed until an extract XVI has been processed. The system will handle this Automatically, processes are run in the correct sequence at all times.
There are more precise and detailed descriptions of the Bundling in the following training AID. This description is very general.
See Episode Matching & Bundling
As patient funding systems move toward separate case payments for patients, it becomes necessary to link utilisation to appropriate episodes. Few feeder systems can reliably indicate the source clinic or patient type for outpatient data, the dynamics of inpatient episodes change with merging and splitting of episodes with statistical discharges. Historically this information was of secondary importance to the feeder systems users. In an Ideal world, all feeders would contain links not only to the patient medical records number, but also the number and type of episode that it belonged too.
Talons uses Business rules to link to episodes, the rules run in the order listed below, the first rule with compliance matches the utilisation to that episode.
See Episode Matching & Bundling
Any product used on any day when a patient was an inpatient, from the midnight immediately preceding date of admission to the midnight immediately following is linked to the Inpatient Episode number. (except products from emergency department feeder systems). While it would be appropriate to distinguish products ordered by emergency departments and link that to the emergency episode, the shortcomings of data preclude this. It must be noted that the major studies of Emergency department have almost always produced models based on this proviso, and that the status of such "products" is difficult to define. The transition (no pun) from Emergency patient to Inpatient is also a grey area, some institutions treat admission as starting from time of commencement of treatment in the emergency, others from the time of "discharge" from emergency to "ward".
See Episode Matching & Bundling
If a patient is not an inpatient, the list of emergency & outpatient episodes for the MRN in question is evaluated, the closest episode both Emergency and/or Outpatient is identified. If the date of service of the product is on the same day as the start of the emergency episode or less than or equal to 1 days after it, it is matched to the product, otherwise if the closest Outpatient episode is within ± 30 days then it is matched. In the event that requesting clinic in a form that is useable is identified in the data, the system will link to that clinic in preference to another with less date difference, but this has not been found at sites to date.
See Episode Matching & Bundling
Products (utilisation) that does not link, is given a pseudo episode composed of the UR, a "UL" or other identifier, and an internal representation of the date. These episodes represent data for patients not falling into the standard categories of Hospital patients, inter-hospital referrals, referrals from local LMO clinics, etc.
Electives System Linking (Electives Interface Business Rules EAS)
To be revised, linking is now based on the presence of a link in the HBCIS files.
The URNO, Admission Date and discharge date, are passed to a routine
that searches all the waiting list entries listed for that URNO, from most recent to
first, in that order, it checks to find status of 2 or 3 in each records list of statuses.
If the date of that status is within
either side of 2 days of admission, it is a hit.
If the date of that status is within
admission and discharge dates, it is a hit.
If the date of that status is within 4
days either side of discharge date, it is a hit
If the Elective record has an episode
number in it that matches the current episode, it is a hi
The Status, the Days between the date on list and admission date and
the URGENCY code in the elective record are then passed back to the extract.
Note that the Admission status of "Elective" is recorded in the Admissions file and is totally independent of the elective system, data may or may not correlate.
Linked Emergency and Admission Episode
Where an emergency episode terminates on a day of admission, the Triage of the Emergency attendance will be passed to the Inpatient XVI extract record.
While it is possible to run XV extracts for inpatients without running a corresponding XVI period, please note, that Theatre (Surgeon, Surgery flag and pre-op and post-op days) and Emergency linkages (Triage) are dependant on data collected during running of the XVI. When scheduling both extracts to run for normal monthly processing, assign a time for the XV to start after the XVI has completed, several hours should be sufficient, but check your normal times. This flexibility is allowed for convenience as often XV extracts will be run several times a month for the current month to collect weekly data. Later, once an XVI has been run, always schedule an XV to run as well to collect this data.
An XV started at the same time as an XVI will always be paused until the XVI completes it's data gathering phase.
Talons Extract Checklist PowerPoint Presentation
