STANDARD DATA DICTIONARY #8925.1 -- TIU DOCUMENT DEFINITION FILE 3/24/25 PAGE 1
STORED IN ^TIU(8925.1, (295 ENTRIES) SITE: WWW.BMIRWIN.COM UCI: VISTA,VISTA (VERSION 1.0)
DATA NAME GLOBAL DATA
ELEMENT TITLE LOCATION TYPE
-----------------------------------------------------------------------------------------------------------------------------------
This file stores Document Definitions, which identify and define behavior for documents stored in the TIU DOCUMENTS FILE (#8925).
For consistency with the V-file schema, it may be viewed as the "Attribute Dictionary" for the Text Integration Utilities.
It also stores Objects, which can be embedded in a Document Definition's Boilerplate Text (Overprint). Objects contain M code which
gets a piece of data and inserts it in the document's Boilerplate Text when a document is entered.
Warning: objects embedded in boilerplate text are looked up by multiple index (i.e. DIC(0) contains 'M'). Current code (see routine
CHECK^TIUFLF3) checks all present indexes to make sure object names, abbreviations and print names are not ambiguous for this
lookup. If new indexes are added, this code MUST BE UPDATED to check the new index as well.
Some entries in this file are developed Nationally and exported across the country. Others are created by local sites. Entries in
the first category are marked National Standard and are not editable by sites.
This file does NOT allow multiple entries OF THE SAME TYPE with the same name. That is, within a given Type, there are no
duplicate names. (This refers to the .01 field, the Technical name of the entry.)
This file does not allow a parent to have items with the same name, even if the items have different internal file numbers (i.e.
are different file entries). Again, this refers to the .01 Technical name of the entry.
Because of ownership considerations, the file does NOT allow an entry to be an item under more than 1 parent. If the same item is
desired under more than 1 parent, the item must be copied into a new entry. There is one exception: Document Definitions of Type
Component which have been marked Shared may have more than one parent.
The Document Definition Utility TIUF categorizes certain fields as Basic, Technical, or Upload, and displays these fields together
as a group when user edits or views a Document Definition. BASIC fields include Name, Abbreviation, Print Name, Type, Personal
Owner, Class Owner, Status, In Use, Shared, Orphan, Has Boiltxt, National Standard, OK to Distribute, and Suppress Visit Selection.
TECHNICAL fields include Entry Action, Exit Action, Edit Template, Print Method, Print Form Header, Print Form Number, Print Group,
Allow Custom Form Headers, Visit Linkage Method, Validation Method, and Object Method. UPLOAD fields include Upload Target File,
Laygo Allowed, Target Text Field Subscript, Upload Look-up Method, Upload Post-Filing Code, Upload Filing Error Code, and multiples
Upload Captioned ASCII Header and Upload Delimited ASCII Header.
The Document Definition file contains extensive, detailed field descriptions. Likewise, some protocols (File 101) used in TIU have
extensive and careful descriptions in the Protocol file. Many of these descriptions are used in TIU for online help. If it becomes
necessary for a national programmer to edit these descriptions, the programmer should check to make sure all online help is still
displayed properly.
Users are expected to use the Document Definition Utility TIUF to enter, edit, and delete file entries. In fact, the file
prohibits the deletion of entries through generic Fileman Options. It also prohibits the edit through generic Fileman of a few
critical fields: Type, Status, Shared, and National Standard. Adding and Deleting (but not editing) Items is also prohibited
through generic Fileman options. Abbreviation and Print Name of OBJECTS cannot be edited through generic Fileman Options.
This does NOT imply that it is SAFE to use generic Fileman to edit other fields. Users are cautioned that edit through generic
Fileman bypasses many safeguards built in to the Document Definition Utility and can create havoc unless the user THOROUGHLY
UNDERSTANDS the File and its uses.
If users find needs which are not met through TIUF, please communicate them to the TIU development team.
*****************
WARNING: Using generic Fileman options to edit entries can cause SERIOUS database problems.
****************
DD ACCESS: @
RD ACCESS: @
WR ACCESS: @
DEL ACCESS: @
AUDIT ACCESS: @
APPLICATION GROUP(S): GMTS
IDENTIFIED BY:
"W.04": W " ",@("$P($P($C(59)_$S($D(^DD(8925.1,.04,0)):$P(^(0),U,3),1:0)_$E("_DIC_"Y,0),0),$C(59)_$P(^(0),U,4)_"":"",2),$C
(59),1)")
"W.1501": S %I=Y,Y=$S('$D(^(15)):"",$D(^TIU(8926.1,+$P(^(15),U,1),0))#2:$P(^(0),U,1),1:"") N DIERR S:$L(Y) Y=$$EXTERNAL^DILFD(
8926.1,.01,"",Y,"DIERR") D:$L(Y) EN^DDIOL("Std Title: "_Y,"","!?6") S Y=%I K %I
POINTED TO BY: TIU PN TITLE field (#.07) of the PRF LOCAL FLAG File (#26.11)
TIU PN TITLE field (#.07) of the PRF NATIONAL FLAG File (#26.15)
NOTE TITLE field (#6.2) of the OE/RR NOTIFICATIONS File (#100.9)
TIU OBJECT field (#6.4) of the OE/RR NOTIFICATIONS File (#100.9)
NOTE TITLES field (#.01) of the NOTE TITLES sub-field (#123.0336) of the GMRC CONSULT MAPPING File (#123.033)
SELECTION ITEM field (#.01) of the SELECTION ITEM sub-field (#142.14) of the STRUCTURE sub-field (#142.01) of the
HEALTH SUMMARY TYPE File (#142)
TIU TITLE field (#29) of the MH TESTS AND SURVEYS File (#601.71)
CONSULT NOTE TITLE field (#30) of the MH TESTS AND SURVEYS File (#601.71)
DEFAULT TIU NOTE field (#.04) of the CP DEFINITION File (#702.01)
USE TIU NOTE TITLE field (#.05) of the MEDICINE FILE PARAMETERS sub-field (#703.91) of the CP CONVERSION File
(#703.9)
DEFAULT_TIU_NOTE field (#.06) of the OBS_FLOWSHEET File (#704.112)
FSOD NOTE TITLE field (#.04) of the FUNCTIONAL INDEPENDENCE MEASUREMENT PARAMETER File (#783.9)
NON FSOD NOTE TITLE field (#.05) of the FUNCTIONAL INDEPENDENCE MEASUREMENT PARAMETER File (#783.9)
CONSULT TITLE field (#.06) of the FUNCTIONAL INDEPENDENCE MEASUREMENT PARAMETER File (#783.9)
NOTE field (#1) of the NUPA SAVED NOTES File (#1927.09)
TIU NOTE FILE field (#6) of the TELEREADER ACQUISITION SERVICE File (#2006.5841)
DOCUMENT TYPE field (#.01) of the TIU DOCUMENT File (#8925)
PARENT DOCUMENT TYPE field (#.04) of the TIU DOCUMENT File (#8925)
ITEM field (#.01) of the ITEM sub-field (#8925.14) of the TIU DOCUMENT DEFINITION File (#8925.1)
DOCUMENT DEFINITION field (#.01) of the TIU DOCUMENT PARAMETERS File (#8925.95)
PARENT DOCUMENT CLASS field (#.02) of the TIU PERSONAL DOCUMENT TYPE LIST File (#8925.98)
DEFAULT TYPE field (#.03) of the TIU PERSONAL DOCUMENT TYPE LIST File (#8925.98)
TITLE field (#.01) of the PERSONAL DOCUMENT LIST sub-field (#8925.9801) of the TIU PERSONAL DOCUMENT TYPE LIST File
(#8925.98)
LINK field (#.19) of the TIU TEMPLATE File (#8927)
DOCUMENT DEFINITION field (#.01) of the USR AUTHORIZATION/SUBSCRIPTION File (#8930.1)
CROSS
REFERENCED BY: CLASS OWNER(AC), NAME(ACL), ABBREVIATION(ACL02), PRINT NAME(ACL03), STATUS(ACL07), ITEM(ACL1001), ITEM(AD),
VHA ENTERPRISE STANDARD TITLE(ALOINC), TIMESTAMP(AM), PRINT NAME(AM1), ITEM(AMM), MNEMONIC(AMM2), SEQUENCE(AMM3),
MENU TEXT(AMM4), PERSONAL OWNER(AP), POSTING INDICATOR(APOST), STATUS(AS), TYPE(AT), NAME(B), ABBREVIATION(C),
PRINT NAME(D), NAME(E)
8925.1,.01 NAME 0;1 FREE TEXT (Required)
INPUT TRANSFORM: S:$L($T(^TIULS)) X=$$UPPER^TIULS(X) K:$L(X)>60!($L(X)<3)!'(X'?1P.E) X I $D(X),+$G(DA) K:$$BADNAP^TI
UFLF1(X,+$G(DA)) X
LAST EDITED: JAN 07, 2002
HELP-PROMPT: This is the technical name, 3-60 characters, not starting with punctuation. If OBJECT, Name must
be unique among all object Names, Abbreviations, and Print Names.
DESCRIPTION: The name of a Document Definition entry (.01 field) must be between 3 and 60 characters long and
may not begin with a punctuation character. Although names can be entered in any case, they are
transformed to upper case before being stored.
It functions as the Technical Name of the entry. Some sites have put KWIC cross references on it
to get, say, all Titles from a given Service.
Name can be used when entering documents as the name of the Title being entered. Print Name and
Abbreviation will also be accepted.
Since it is the Technical, .01 Name, the Document Definition Utility (TIUF) uses this name
throughout.
The .01 name differs from the Print Name, which appears in lists of documents and functions as the
Title of the document.
It also differs from Item Menu Text (1-20 characters), which is used when selecting documents from
3-COLUMN MENUS.
The ORDER of names in TIUF options Edit Document Definitions and Create Document Definitions is by
Item Sequence under the parent. Order is alphabetic by Menu Text if an Item has no Item Sequence.
When a new entry is added to file 8925.1, the Document Definition Utility (TIUF) enters the Name as
the default Print Name. The Print Name can be edited if a different Print Name is desired.
File 8925.1 permits more than 1 entry with the same name as long as they don't have the same Type.
In that sense, NAMES are reusable. However, ENTRIES are NOT reusable (except specially marked
Components): an entry is NOT allowed to be an item under more than one parent unless it is a Shared
Component. (See Type Component.)
Name is a BASIC Field.
OBJECT Name Object Names, like any other names are 3-60 characters,
not starting with punctuation. Sites may want to namespace object names, use the object Print Name
as a more familiar name, and use object Abbreviation as a short name to embed in boilerplate text.
Unlike other Types, Object Abbreviation and Print Name as well as Name must be uppercase.
Object Name, Abbreviation, or Print Name can be embedded in boilerplate text. Since TIU must be
able to determine from this which object is intended, object Names, Abbreviations, and Print Names
must be unique. In fact, an object Name must differ not only from every other object name, but
also from every other object Abbreviation and from every other object Print Name. Same for
Abbreviations and Print Names. For example, if some object has abbreviation 'CND', then 'CND'
cannot be used for any other object Name, Abbreviation, or Print Name.
EXECUTABLE HELP: D NAME^TIUFXHLX:$G(TIUFXNOD)["Add/Create"&($G(TIUFSTMP)="T")
DELETE TEST: .01,0)= I 1
DELETE AUTHORITY:
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^B
1)= S ^TIU(8925.1,"B",$E(X,1,60),DA)=""
2)= K ^TIU(8925.1,"B",$E(X,1,60),DA)
CROSS-REFERENCE: 8925.1^E^KWIC
1)= S %1=1 F %=1:1:$L(X)+1 S I=$E(X,%) I "(,.?! '-/&:;)"[I S I=$E($E(X,%1,%-1),1,30),%1=%+1 I $L(I)
>2,^DD("KWIC")'[I S ^TIU(8925.1,"E",I,DA)=""
2)= S %1=1 F %=1:1:$L(X)+1 S I=$E(X,%) I "(,.?! '-/&:;)"[I S I=$E($E(X,%1,%-1),1,30),%1=%+1 I $L(I)
>2 K ^TIU(8925.1,"E",I,DA)
This KWIK cross-reference on document name will allow look-up based on sub-names, etc.
CROSS-REFERENCE: 8925.1^ACL^MUMPS
1)= D SACL^TIUDD1(X,.01)
2)= D KACL^TIUDD1(X,.01)
This is a complex cross-reference on the .01 (NAME) field. Its format will be as follows:
^TIU(8925.1,"ACL",Parent document class IEN, Title NAME, Title IEN)=""
The purpose of this cross-reference will be to help CPRS GUI perform faster title look-ups by
document class.
8925.1,.02 ABBREVIATION 0;2 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>4!($L(X)<2)!'(X?2.4A) X I $D(X),+$G(DA) K:($P(^TIU(8925.1,DA,
0),U,4)="O")&('(X?2.4U)!'$D(TIUFPRIV)) X I $D(X),+$G(DA) K:$$BADNAP^TIUFLF1(X,DA) X
LAST EDITED: JAN 07, 2002
HELP-PROMPT: Enter from 2 to 4 letters. If OBJECT, Abbreviation must be unique among all object Names,
Abbreviations, and Print Names, and must be uppercase.
DESCRIPTION: Abbreviation can be entered at the Title: prompt when entering a document. Since all Titles with
that abbreviation will then be listed, Abbreviation can serve to group Titles. BASIC Field. For
Objects, see NAME.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^C
1)= S ^TIU(8925.1,"C",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"C",$E(X,1,30),DA)
This cross reference will be used by the router/filer to identify a given report type.
CROSS-REFERENCE: 8925.1^ACL02^MUMPS
1)= D SACL^TIUDD1(X,.02)
2)= D KACL^TIUDD1(X,.02)
This complex cross-reference by class and name will help optimize the title look-up for the GUI.
8925.1,.03 PRINT NAME 0;3 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>60!($L(X)<3) X I $D(X),+$G(DA) K:($P(^TIU(8925.1,DA,0),U,4)="
O")&('(X?3.60UPN)!'$D(TIUFPRIV)) X I $D(X),+$G(DA) K:$$BADNAP^TIUFLF1(X,DA) X
LAST EDITED: JAN 07, 2002
HELP-PROMPT: Print Name is used in lists of documents and as document Title in the Patient Chart. 3-60
Characters. If OBJECT, Print Name must be unique among object Names/Abbreviations/PrintNames, and
uppercase.
DESCRIPTION: Print Name is the name used in lists of documents. For entries of Type Title, Print Name is used
as the document Title in the Patient Chart. BASIC field. For Objects, see NAME.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^AM1^MUMPS
1)= D REDO^TIUDD
2)= D REDO^TIUDD
This MUMPS-type cross-reference is used to update the TIMESTAMP on both the current document, and
its parents, when its PRINT NAME changes.
CROSS-REFERENCE: 8925.1^D
1)= S ^TIU(8925.1,"D",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"D",$E(X,1,30),DA)
This REGULAR FileMan cross-reference by PRINT NAME will facilitate look-up.
CROSS-REFERENCE: 8925.1^ACL03^MUMPS
1)= D SACL^TIUDD1(X,.03)
2)= D KACL^TIUDD1(X,.03)
This complex cross-reference by class and name will help optimize the title look-up for the GUI.
8925.1,.04 TYPE 0;4 SET (Required)
'CL' FOR CLASS;
'DC' FOR DOCUMENT CLASS;
'DOC' FOR TITLE;
'CO' FOR COMPONENT;
'O' FOR OBJECT;
INPUT TRANSFORM: K:'$G(TIUFPRIV) X
LAST EDITED: JAN 14, 1997
HELP-PROMPT: Types Class and Document Class group documents. Titles are used to enter documents. Components
are sections of documents. Objects are M code for use in Boilerplate Text.
DESCRIPTION: Type determines the nature of the entry and what sort of items the entry may have. There are 5
possible types:
CL CLASS: Classes group documents.
Example: "Progress Notes" is a class with many kinds of progress notes under it.
Classes may themselves be subdivided into items of Type Class or may have items of Type Document
Class if no further Class subdivisions are desired.
If a hierarchy deeper than Class-Document Class-Title is desired, Class is the place to insert
another level into the hierarchy: Class-Class-Document Class-Title.
Besides grouping documents, Classes also store behavior which is then inherited by lower level
entries.
DC DOCUMENT CLASS: Document Classes group documents. Document Class is the lowest level of class,
and has items of Type Title under it.
Example: "Day Pass Note" could be a Document Class under class Progress Note.
Document Classes also store behavior which is then inherited by lower entries.
TL TITLE: Titles are used to enter documents. They store the behavior of the documents which use
them.
Titles may have predefined boilerplate ("Overprint") text. They may have Components as items.
Boilerplate Text can have objects in it.
Examples: "Routine Day Pass Note" could be a Title under document class Day Pass Note. Another
example might be "Exceptional Circumstances Day Pass Note."
Titles store their own behavior. They also inherit behavior from higher levels of the hierarchy.
However, behavior stored in the Title itself overrides inherited behavior.
CO COMPONENT: Components are "sections" or "pieces" of documents. In the Hierarchy, Components are
hung as items from Titles.
Examples: "Reason for Pass" could be a component of Routine Day Pass Note. Subjective is a
component of a SOAP Note.
Components may have (sub)Components as items. They may have Boilerplate Text. Components may be
designated Shared (see Field Description for Shared). Shared Components are shown in Document
Definition Utility Displays as Type: 'CO S'.
There are advantages and disadvantages in splitting a document up into separate components (rather
than writing sections into the Boilerplate Text of the Title): Since Components are stored as
separate file entries, they are inherently accessable and even 'moveable'. Using Fileman, sites can
access components of documents the same way they can access documents for reports, etc.. Also, in
the future, TIU may have options to move/copy certain components from one document into another.
The disadvantage is speed: Components make the structure more complex and therefore slow down
processing.
O OBJECT: Objects are names which may be embedded in the predefined boilerplate text of Titles.
Example: 'PATIENT AGE'. Objects are typed into the boilerplate text of a Title, enclosed by '|'s.
For example, suppose a Title has boilerplate text:
Patient is a healthy |PATIENT AGE| year old male ...
Then a user who enters such a note for a patient known by the system to be 56 years old would be
presented with the text:
Patient is a healthy 56 year old male ...
The user can then add to the text and or edit the text, including the age (56) of the patient.
From this point on, the patient age (56) is regular text and is not updated in this note.
Objects must always have uppercase names, abbreviations, and print names. When embedding objects
in boilerplate text, users may embed any of these three (name, abbreviation, print name) in
boilerplate text, enclosed by '|'s. Objects must always be embedded in uppercase.
Objects are stored in the Document Definition File, but are not part of the Hierarchy. They are
accessible through the Option Create Objects. (They are also accessible through the Option Sort
Document Definitions, by selecting Sort by Type and selecting Type Object.)
TIU exports a small library of objects. Sites can also create their own.
Only an owner can edit an object and should do so only after consulting with others who use it.
The object must be inactive for editing. It should be thoroughly tested. See Object Status, under
Status.
Entries of type Object cannot be changed to any other type. Entries of type Class, Document Class,
Title, or Component cannot be changed to type Object.
Type is a BASIC field.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^AT
1)= S ^TIU(8925.1,"AT",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"AT",$E(X,1,30),DA)
3)= Please don't delete!
This regular cross reference is used for listing Document Definitions by Type.
8925.1,.05 PERSONAL OWNER 0;5 POINTER TO NEW PERSON FILE (#200)
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Enter Person who can edit entry. If owned by Class rather than Person, delete Personal Owner by
typing '@' at Personal Owner prompt, and then enter Class Owner.
DESCRIPTION: Document Definition Ownership has nothing to do with who can USE the entry to enter a document. It
determines responsibilty for the Document Definition itself.
An entry can be EDITED by its owner. (The Manager menu permits override of ownership so that
Ownership can be assigned to a clinician who can then fill in boilerplate text with the Clinician
menu, while the Manager can still edit the entry, since there are many fields the clinician does
not have access to.) Exception: the Manager menu does NOT override ownership of Objects or of
Shared Components. Only owners can edit Objects and Shared Components, regardless of menu.
If Title owner edits the boilerplate text of the Title, that person can edit the boilerplate text
of all components of the Title as well, without regard to component ownership. In order to edit
components individually, however, the user must own the component. This allows users to assign
ownership of components to different people, for example, for (future) multidisciplinary documents.
A PERSONAL OWNER is a person who uniquely owns the entry. An entry may have a Personal Owner OR a
Class Owner but not both. When entering a Personal Owner, be sure to delete any existing Class
Owner.
The Document Definition Utility TIUF uses the term 'Individual Owner'. Someone is an Individual
Owner of an entry if s/he is the personal owner OR, if the entry is CLASS Owned, if s/he belongs to
the Owner Class.
The Document Definition Utility TIUF enters the user as the Personal Owner if a user enters a new
entry without assigning ownership. This person can then reassign ownership if they choose.
If the person responsible for an entry plays a role corresponding to a User Class, e.g. Clinical
Coordinator, it may be more efficient to assign ownership to the class rather than to the person.
Owners are then automatically updated as the class is updated.
Editing privilege is affected not only by Owner but also by Status, by Shared, by In Use, and by
menu. Manager menus, for example, provide fuller editing capabilities than Clinician menus.
Personal Owner is a BASIC field.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^AP
1)= S ^TIU(8925.1,"AP",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"AP",$E(X,1,30),DA)
3)= Please don't delete!
This regular cross reference is used for listing Document Definitions by Personal Owner.
8925.1,.06 CLASS OWNER 0;6 POINTER TO USR CLASS FILE (#8930)
LAST EDITED: OCT 22, 1996
HELP-PROMPT: If owned by Class rather than by Person enter User Class whose members may edit entry. If owned by
Person, delete Class Owner by entering '@' at Class Owner prompt.
DESCRIPTION: Document Definition Ownership has nothing to do with who can USE the entry to enter a document. It
determines responsibility for the Document Definition itself.
An entry can be EDITED by its owner. (The Manager menu permits override of ownership so that
ownership can be assigned to a clinician (person with Clinician Menu) who can then fill in
boilerplate text, while the manager can still edit the entry, since there are many fields the
clinician does not have access to.) Exception: the Manager menu does NOT override ownership of
Objects or of Shared Components. These can ONLY be edited by an owner, regardless of menu.
If a Title owner edits the boilerplate text of the Title, that person can edit the boilerplate text
of all components of the title as well, without regard to component ownership. However, the user
must own the component in order to edit it individually, permitting separate ownership of
components.
A Class Owner is a User Class from the USR CLASS file whose members may edit the entry. An entry
may have a Personal OR a Class Owner (not both). The Document Definition Utility TIUF does not
prompt for Class Owner if the entry has a Personal Owner. To change to Class Owner, first delete
the Personal Owner by entering '@' at the Personal Owner prompt.
For new entries, users are prompted to enter the Class Owner Clinical Coordinator as the default.
To enter a different Class Owner, enter the appropriate class after the //'s. If there are no //'s
and the Replace...with editor is being used, enter ... to replace the whole class and then enter
the appropriate class.
Class Owner is a BASIC field.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^AC
1)= S ^TIU(8925.1,"AC",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"AC",$E(X,1,30),DA)
3)= Please don't delete!
This regular cross reference is used to list Document Definitions by Class Owner.
8925.1,.07 STATUS 0;7 POINTER TO TIU STATUS FILE (#8925.6)
INPUT TRANSFORM: K:'$G(TIUFPRIV) X Q:'$D(X) S DIC("S")="I 1 X $$STATSCRN^TIUFLF5" D ^DIC K DIC S DIC=DIE,X=+Y K:Y<0
X
LAST EDITED: OCT 16, 1997
HELP-PROMPT: Documents can be entered on ACTIVE Titles. Only the Owner can enter a document on TEST Titles.
Only INACTIVE Document Definitions can be edited.
DESCRIPTION: Status provides a way of making Document Definitions 'Offline' to documents. Document Definitions
need to be 'Offline' if they are new and not ready for use, if they are being edited, or if they
are retired from further use.
Status is limited to those Statuses in the Status File which apply to Document Definitions:
Inactive, Test, and Active. The Document Definition Utility TIUF further limits Statuses to those
appropriate for the entry Type (see below), limits the Status of entries with Inactive ancestors to
Inactive, and limits the Status of faulty entries to Inactive.
Status applies to all Document Definitions, but its meaning and possible values vary somewhat with
the Document Definition Type. Exception: Shared Components: See COMPONENT STATUS, below.
Status is a BASIC field.
TITLE STATUS
Status has its most basic meaning for Titles [Document Definitions of Type Title]:
A Title can have Status Inactive, Test, or Active. If it has Status Inactive, it cannot be used to
enter documents (EXCEPT through the Try Action, which deletes the document when done). If it has
Status Test, it can be used to enter documents only by its Owner. Titles should be tested (and
Tried) using TEST PATIENTS ONLY. If a Title has Status Active, it can be used to enter documents
by any one with access and authorization.
***************
NOTE on Availability of Titles for entering documents: Although Status affects availability for
entering documents, there are other factors which also affect availability: A Document Definition
is not available to a given user for entering documents (excepting the Document Definition Utility
Try Action) unless all of the following 3 criteria are met:
1) It is a Document Definition of Type Title.
2) It has Status Active or Test. If it has Status Test, the user entering a document must own
the Title.
3) If authorization for using the Title to enter documents is restricted by Business Rules, the
user must be a member of the authorized user class.
Unless these criteria are all met, users trying to enter documents will not SEE the Document
Definition. Therefore it is wise to warn users when taking definitions offline for edit, and/or to
do so at nonpeak hours for entering documents.
The above description applies to document entry BOTH manually through menu options AND via upload.
It does NOT apply to autoentry of documents via the TIU application interface. Adverse
Reaction/Allergy notes entered by the Allergy package are an example of such autoentry. The TIU
application interface for autoentering documents disregards Title status and Business Rules.
*******************
When being upgraded to Status Active or Test, a Title is examined for rudimentary completeness and
must be judged OK before the upgrade takes place. If desired, users can perform the same
examination themselves by selecting action TRY. For Titles, Action TRY also permits the user to
enter a document on the entry. The document is deleted immediately after the trial.
Availability for entering documents is the central meaning of Status. However, Status also
controls edit/deletion of Document Definitions: A Title can be edited ONLY if it has Status
Inactive, ensuring that no one is using it to enter a document while its behavior is changing.
Titles can be deleted only with Status Inactive.
NOTE: Although Status affects Editing ability, it is not the only factor affecting editing: If an
entry is already IN USE by documents, editing/deletion is restricted to aspects which will not harm
existing TIU documents.
Components under a Title have the same status as the Title: When a Title's status is changed, the
statuses of its descendant Components are automatically changed with it. (Shared Components are an
exception: see COMPONENT STATUS, below.)
CLASS/DOCUMENT CLASS STATUS
A Document Definition of Type Class or Document Class can have Status Inactive or Active.
Basics for a Class or Document Class cannot be edited (except for Owner and Status) unless it is
Inactive. Since Inactivating a Class/Document Class automatically inactivates its descendants,
this ensures that all Titles which inherit behavior from it are neither Active nor Test, and are
thus 'Offline' while inherited behavior is edited.
In contrast to Basics, the ability to add/edit ITEMS of a Class/Document Class depends on the
Status of the item, not the parent: it is NOT necessary to Inactivate a Class such as Progress
Notes in order to edit/add items.
Activating a Class/Document Class differs from Inactivating the Class/Document Class: When a
Class/Document Class is ACTIVATED, its descendants may have any Status which their Type permits:
they are not REQUIRED to be Active. Hence, they are not automatically Activated when the parent is
Activated.
COMPONENT STATUS
A Document Definition of Type Component has the same status as its parent: Its status can be
changed only by changing the Status of its Parent, if it has one. Components without parents are
always Inactive.
NOTE: The above implies that Test or Active Titles cannot have Inactive Components. In other
words, Inactivating a Component is NOT a way of retiring it. If a Component is no longer a useful
section of a Title, it should be edited so as to make it useful, or it should be deleted AS AN ITEM
from the Title of which it is a part. As with all retired Document Definitions, it should NOT be
deleted FROM THE FILE if it has been used by documents.
Components can be edited only if they have status Inactive. This ensures that all Titles using them
are offline while the components are being edited.
Shared Components are a special case since they can have multiple parents. They DO NOT HAVE A
STATUS. They can be edited only when all parent Titles have Status Inactive. (The Detailed Display
screen shows parents.) This ensures that all parent Titles of Shared Components are offline while
the component is being edited. Edit of Shared Components is permitted only through the Option Sort
Document Definitions.
Edit of Shared Components is severely restricted by Ownership, since they may be used multiple
times and across the site. Even an Inactive Status does not permit a manager (person with Manager
menu) to override ownership and edit a Shared Component they don't own. See Shared Components,
under Description of Type. See Description of Shared.
OBJECT STATUS
Document Definitions of Type Object have Status Inactive or Active.
Only ACTIVE objects function. That is, if a user enters a document on a Title with boilerplate
text containing an inactive object, the object doesn't do anything; the user sees the name of the
object and an error message in place of the object data.
Only ACTIVE objects should be embedded in boilerplate text. Exception: owners who are
creating/editing objects. Others should NOT embed inactive objects in boilerplate text since they
may not be ready for use and since they do not function when users enter documents against them.
Titles whose boilerplate text contains inactive objects cannot be activated. (This does NOT imply
that active titles never have inactive objects embedded in them since users can, after a warning,
inactivate objects even when they are embedded in active titles.)
Only INACTIVE objects can be edited (and only by an owner). Only an owner can activate/inactivate
an object. (Exception: if a user owns an object and edits the owner to someone else, the user is
not prevented from going on to edit the status in the same edit session since they WERE the owner a
few seconds ago.) Active objects are assumed to be ready for use in any boilerplate text.
Since the owner is essentially caretaker of the object for the entire site, the owner should
consult with all who use it before editing it. An object can be tested by embedding it in the
boilerplate text of a Title and selecting action Try for the Title. It need not have status Active
for this testing (and SHOULD not have status Active until testing is complete). Owners who
inactivate objects for editing should make SURE to reactivate them if they are being used.
Sites should either inactivate relevant Titles before editing objects or edit objects only when
users are not likely to be ENTERING documents since Inactive objects do not function.
If a site changes the name or behavior of an Object, it is up to the SITE to change the name
wherever it has already been embedded in Boilerplate Text, and to inform users of the change.
An object which is no longer wanted for future documents can be removed from the boilerplate text
of all Titles and Components and then deleted from file 8925.1. Only an owner can delete it. All
of the documents that used it have already got it in hard words so there is no need to keep it for
their sake. Old Objects should be edited so they are useful or deleted, not kept around forever as
Inactive.
SCREEN: S DIC("S")="I 1 X $$STATSCRN^TIUFLF5"
EXPLANATION: STATSCRN limits Status to Status file entries that are appropriate for Document Definitions: Active
, Inactive, and Test.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.1^AS
1)= S ^TIU(8925.1,"AS",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"AS",$E(X,1,30),DA)
3)= Please don't delete!
This regular cross reference is used to list Document Definitions by Status.
CROSS-REFERENCE: 8925.1^ACL07^MUMPS
1)= D SACL^TIUDD1(X,.07)
2)= D KACL^TIUDD1(X,.07)
This MUMPS-type cross-reference on STATUS support the identification of Active and TEST Titles
within a given class.
8925.1,.08 IN USE ; COMPUTED
MUMPS CODE: S X=$S($L($T(^TIUFLF)):$$DDEFUSED^TIUFLF(D0),1:"?")
ALGORITHM: S X=$S($L($T(^TIUFLF)):$$DDEFUSED^TIUFLF(D0),1:"?")
LAST EDITED: JUN 18, 1996
DESCRIPTION: IN USE applies to all entries except those of Type Object. It cannot be edited since it gets its
value automatically.
IN USE may have values 'Yes', 'No', or '?'.
A Document Definition of Type Title or Component is In Use (Yes) if there are entries IN THE TIU
DOCUMENT file which store it as their Document Definition. If not, it is NOT used (No).
NOTE: It is possible for Document Definitions to be used by documents in files other than the TIU
Document file and still be NOT In Use since In Use means in use by documents in the TIU Document
Definition file. See Warning, below.
A Document Definition of Type Class or Document Class is In Use (Yes) if it has children of Type
Title which are In Use. That is, it is Used by Documents (Yes) if there are entries in the TIU
Document file which inherit behavior from it. If not, it is NOT used (No).
IN USE has value '?' for a Document Definition File entry if routine TIUFLF is missing or if the
program encounters a nonexistent item and the entry is not In Use so far as the check has been able
to go.
Note: Since Shared Components can be items of more than one Title, a Shared Component may be In Use
even when a particular parent Title is NOT In Use. This simply means that it is also a Component
of another Title which IS In Use.
If IN USE has the explicit value 'No' for a particular Document Definition entry, the entry can be
deleted by the Owner without harming documents IN TIU DOCUMENT FILE 8925. Deleting it will,
however, orphan any descendant Document Definitions.
WARNING: If a site is using TIU to upload documents into a file other than the TIU Document file,
it may create Document Definition entries to store upload information. For example, it may create
an Operative Reports title containing instructions for uploading documents into the Surgery file.
These document definitions will be orphans and will be NOT In Use, since documents using them are
not stored in the TIU Document file. They must NOT be deleted from the Document Definition file.
Note: Deleting Objects will not harm existing documents, but WILL HARM future documents if the
Object is embedded in existing Document Definition Boilerplate Text.
If IN USE has value 'Yes' or '?', the Document Definition Utility TIUF does not permit the entry to
be deleted. Deleting the entry would cause documents in file 8925 not to function. This is true
even if the entry has status 'Inactive' and documents are no longer being written on the entry.
Technical Note: A Document Definition of Type Title or Component is IN USE if and only if it
appears in file 8925's 'B' Cross Reference.
In Use is a BASIC field.
8925.1,.1 SHARED 0;10 SET
SHARED COMPONENT
'1' FOR YES;
'0' FOR NO;
INPUT TRANSFORM: K:'$G(TIUFPRIV) X
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Enter Y for YES if this Component is intended for broad use across the site, i.e., it can be used
more than once, and need not be owned by the user.
DESCRIPTION: Applies to entries of Type Component only.
Document Definitions of Type Component may be designated SHARED by Owners who have the Manager
menu. This means the Component can be an item under multiple parents, and any user who owns a Title
can add it as an item.
Shared Components are the ONLY members of the Document Definition hierarchy which can appear in
more than one place in the hierarchy. (Objects can be used in multiple entries, but are not
members of the hierarchy.)
Shared Components are intended for broad use across the site. An example might be a Privacy Act
Component. Since a Shared Component may be used in many different Document Definitions, its Owner
is essentially caretaker for it, hospital wide, and must take into account all users before editing
it. Users who disagree with a proposed change can opt to create and use their own copy instead of
using the Shared Component.
Parents of a Shared Component are listed in the Detailed Display Screen.
Shared Field values are 1 for YES and 0 for NO, with a default value of 0 for NO if the field is
empty.
An entry may not be designated Shared unless it is of Type Component. Only a Manager (person with
Manager menu) and only an Owner can designate a Component as Shared. Only an OWNER can edit it.
(Normally Managers can override ownership and edit entries. Manager Options do NOT override
Ownership for editing Shared Components). Shared Components can only be edited from the Sort
Document Definitions Option.
Shared Components cannot be deleted. If they do not have multiple parents, they can, however, be
edited to NOT shared and THEN deleted, assuming they are not In Use by documents and the parent is
Inactive.
Shared Components do NOT HAVE a Status. They can be edited only if all parent Titles are Inactive.
This ensures that parent Titles are offline for entering documents while their components are being
edited. Parents are listed on the Detailed Display Screen.
If a Shared Component has subcomponents, they are automatically Shared, since they, with their
parents, can be used in more than one place in the hierarchy.
Sharing of Document Definitions other than Components is not permitted because it unduly restricts
the owner's right to edit/delete the Document Definition and adds undue complexity to the
Hierarchy.
Shared is a BASIC field.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,.11 ORPHAN ; COMPUTED
MUMPS CODE: S X=$S($L($T(^TIUFLF4)):$$ORPHAN^TIUFLF4(D0,^TIU(8925.1,D0,0)),1:"?")
ALGORITHM: S X=$S($L($T(^TIUFLF4)):$$ORPHAN^TIUFLF4(D0,^TIU(8925.1,D0,0)),1:"?")
LAST EDITED: FEB 01, 1996
DESCRIPTION: Orphan applies to Document Definitions of all Types except Objects and Shared Components.
Orphan is not editable since it gets its value automatically.
Document Definitions are Orphans if they do not belong to the Clinical Documents Hierarchy, i.e.,
they cannot trace their ancestry all the way back to the Class Clinical Documents. If an Orphan is
not In Use, it may be "dead wood" which should be deleted from the file. Orphans not In Use which
SHOULD NOT BE DELETED include those being kept for later possible use, those temporarily orphaned
in order to move them around in the hierarchy, and those used for uploading documents into files
other than the TIU Document file.
(Orphan does not apply to Objects since they don't ever belong to the hierarchy. Orphan does not
apply to Shared Components since they may have more than one line of ancestry.)
Warning: The DOCUMENT DEFINITION file may contain orphan entries which are not used by documents
in the TIU Document file but which contain upload instructions for storing documents somewhere
else. For example, if a site is uploading Operative Reports into the Surgery file, there may be an
orphan Operative Report Document Definition in the DOCUMENT DEFINITION file. These should NOT be
deleted just because they are orphans. Such entries can be identified by edit/viewing them through
the Sort Option and looking for Upload fields.
NOTE: Orphan as used in the Document Definition Utility TIUF does NOT mean having no parents. For
example, suppose Exceptional Day Pass Note has parent Day Pass Note. If Day Pass Note has no
parent, then Exceptional Day Pass Note cannot trace its ancestry back to Clinical Documents and is
an Orphan even though it has a parent.
Orphans are invisible to TIU users and cannot be used to enter documents.
When an item under a non-orphan is deleted as an item, it becomes an orphan along with all of its
descendants. TIUF, the Document Definition Utility, does not permit non-orphan Titles to become
orphaned if they are In Use. Titles already used but being retired from further use should be
Inactivated, NOT orphaned. Components are a different story; components being retired from further
use can and should be orphaned (deleted as items from the Title).
Reason: Titles inherit attributes and therefore require a complete ancestry in order to process
existing documents. Since components, on the other hand, do not inherit attributes, they do NOT
require a complete ancestry to process existing documents (although they must remain in the file.)
Since Orphans do not belong to the Hierarchy, they do NOT appear on the Edit Document Definitions
Option. They can be accessed through the Sort Document Definitions Option.
The field Orphan may have values 'Yes', 'No', or '?'. Orphan has value '?' if there are technical
errors making its value unknown.
Orphan is a BASIC field.
8925.1,.12 HAS BOILTXT ; COMPUTED
HAS BOILERPLATE TEXT
MUMPS CODE: S TIUFBTXT=$S($L($T(^TIUFLF)):$$HASBOIL^TIUFLF(D0,^TIU(8925.1,D0,0)),1:"UNKNOWN"),X=$S(TIUFBTXT:"YE
S",TIUFBTXT=0:"NO",1:TIUFBTXT) K TIUFBTXT
ALGORITHM: S TIUFBTXT=$S($L($T(^TIUFLF)):$$HASBOIL^TIUFLF(D0,^TIU(8925.1,D0,0)),1:"UNKNOWN"),X=$S(TIUFBTXT:"YE
S",TIUFBTXT=0:"NO",1:TIUFBTXT) K TIUFBTXT
LAST EDITED: JAN 18, 1996
DESCRIPTION: Applies to Types Title and Component only. Cannot be edited since value is automatic. A Document
Definition Has Boiltxt if it or its descendant Components have Boilerplate Text (Field 3). BASIC
field.
8925.1,.13 NATIONAL STANDARD 0;13 SET
'1' FOR YES;
'0' FOR NO;
INPUT TRANSFORM: K:'$G(TIUFPRIV) X
LAST EDITED: JAN 28, 1997
HELP-PROMPT: Enter YES if entry is Standard across the nation, i.e. sites mustn't edit
DESCRIPTION: Some Document Definitions, for example, CWAD's, are developed nationally and sent out as
standardized entries across the nation. TIU and other packages depend on their standard
definition, and they must not be edited by sites but only by the persons who are nationally
responsible for them.
Such entries are marked NATIONAL STANDARD (field has value 1 for YES), which generally prevents
sites from editing the entry.
In two cases, sites are permitted to edit National Standard entries. The first case concerns
Titles. Sites can edit Status and Abbreviation for National Titles. Status INACTIVE for a
National Title prevents manual and upload entry of documents for the Title, while continuing to
permit automatic entry for the Title via the TIU application interface for new notes. (Example:
Adverse Reaction/Allergy notes are automatically entered by the Allergy package.) Editing
Abbreviation gives sites a means of grouping national titles with other National and non-National
Titles as they please.
The second case where edit of National entries is permitted concerns the Item Multiple:
If a National Standard entry has Type Class or Document Class, sites can add/delete Nonnational
items as they please, and can edit ALL items AS ITEMS (e.g. Item Sequence, etc.). Sites CANNOT
add/delete National items.
If a National Standard entry has Type Title or Component, sites cannot add or delete items, but can
still edit items AS ITEMS.
Sites cannot add National Standard entries as Items to parents. There is one exception: Sites can
add National Shared Components to (nonnational) Titles if they wish. Sites can delete National
Standard Items from nonnational parents. (Unless there has been a mistake, such items will be
limited to Shared Components only.)
Field is NOT heritable. If field has no value for an entry, value is 0 by default. This means
that entries created by sites are NOT National Standard.
Technical Note:
National entries (except for Shared Components) must have National ancestors: if a National entry
has a nonNational ancestor, the Document Definition Utility TIUF does not permit it to be
activated. (Shared Components need not have National ancestors, and do not have a Status.)
National Standard is a BASIC field.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,.14 POSTING INDICATOR 0;14 SET
'C' FOR crisis note;
'W' FOR warning;
'A' FOR allergy/ADR;
'D' FOR directive;
LAST EDITED: FEB 27, 1997
HELP-PROMPT: Please choose an indicator corresponding to the Posting Type
DESCRIPTION: This field is used to help identify indicators of the Patient Posting Type to which the Document
Definition should be ascribed.
CROSS-REFERENCE: 8925.1^APOST
1)= S ^TIU(8925.1,"APOST",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"APOST",$E(X,1,30),DA)
This REGULAR FileMan Cross-reference by Posting Indicator will help to identify which Document
Classes are associated with each of the currently supported Posting Types.
8925.1,.15 PRF FLAG ; COMPUTED
ASSOCIATED PATIENT RECORD FLAG
MUMPS CODE: S X=$S($L($T(CFLDFLAG^TIUPRFL)):$$CFLDFLAG^TIUPRFL(D0),1:"?")
ALGORITHM: S X=$S($L($T(CFLDFLAG^TIUPRFL)):$$CFLDFLAG^TIUPRFL(D0),1:"?")
LAST EDITED: APR 05, 2005
DESCRIPTION: PRF FLAG applies only to PRF titles. The PRF FLAG of a PRF title is the name of the Patient Record
Flag associated with the title. (Notes cannot be written using a PRF title unless the title is
associated with a flag and that flag is assigned to the given patient.)
If the title is not associated with a flag or the associated flag cannot be found, the field has
value "?". If the Document Definition is not a title under Document Class PATIENT RECORD FLAG CAT
I or PATIENT RECORD FLAG CAT II, the field has value NA for non-applicable.
Technical Note: Flags and their associations with titles are stored in file PRF LOCAL FLAG (#26.11)
or in file PRF NATIONAL FLAG (#26.15).
PRF FLAG is a BASIC field.
8925.1,1 UPLOAD DELIMITED ASCII HEADER ITEM;0 Multiple #8925.11
LAST EDITED: JUL 29, 1996
DESCRIPTION: This multiple contains the upload record header format of the Document Definition, to be used by
the upload/router/filer when the preferred header format is Delimited string (as opposed to
captioned).
Delimited string is useful only if the site has a way of automating creation of upload record
headers. If they are being created by a human transcriber, use Captioned Record Headers instead.
IDENTIFIED BY: ITEM NAME(#.02)
8925.11,.01 HEADER PIECE 0;1 NUMBER (Multiply asked)
INPUT TRANSFORM: K:+X'=X!(X>30)!(X<1)!(X?.E1"."1N.N) X S:$D(X) DINUM=X
LAST EDITED: OCT 21, 1992
HELP-PROMPT: Enter the delimiter-piece for the next header item.
DESCRIPTION:
This is the number for this piece (item) of the header. Start with number 1 for the first piece.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.11^B
1)= S ^TIU(8925.1,DA(1),"ITEM","B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"ITEM","B",$E(X,1,30),DA)
8925.11,.02 ITEM NAME 0;2 FREE TEXT
INPUT TRANSFORM: K:$L(X)>30!($L(X)<2) X
LAST EDITED: OCT 21, 1992
HELP-PROMPT: Enter the name of the header item.
DESCRIPTION: This is the name of the item in the ASCII message header. Item Name is used in help messages for
the person dictating a document.
CROSS-REFERENCE: 8925.11^C
1)= S ^TIU(8925.1,DA(1),"ITEM","C",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"ITEM","C",$E(X,1,30),DA)
This REGULAR FileMan cross-reference on the ITEM NAME is used in the look-up and edit process.
8925.11,.03 FIELD NUMBER 0;3 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>10!($L(X)<1) X
LAST EDITED: OCT 21, 1992
HELP-PROMPT: Enter the FIELD # of the item in the target file.
DESCRIPTION:
This is the field number in the target file which corresponds to this header item.
CROSS-REFERENCE: 8925.11^D
1)= S ^TIU(8925.1,DA(1),"ITEM","D",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"ITEM","D",$E(X,1,30),DA)
This REGULAR FileMan cross-reference by field number is used by the filer/router to identify
header-pieces with field numbers in the target file.
8925.11,.04 LOOKUP LOCAL VARIABLE NAME 0;4 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>8!($L(X)<1)!'(X?1A1.7E) X
LAST EDITED: NOV 09, 1992
HELP-PROMPT: Enter the required local variable into which this piece will be set.
DESCRIPTION: This field specifies the local variable name into which this piece of the message header will be
set. The local variable is used by the Look-Up Method. For example, if this piece of the header
is the patient social security number, the Lookup Local Variable Name might be TIUSSN. The
social security number as written by the transcriptionist is first transformed by any existing
Transform Code, and then set into this variable (e.g. TIUSSN) for use in Look-Up Method code.
Lookup Local Variable Name is necessary only if the information in this piece is required in
order to look up the appropriate entry in the target file.
CROSS-REFERENCE: 8925.11^E
1)= S ^TIU(8925.1,DA(1),"ITEM","E",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"ITEM","E",$E(X,1,30),DA)
This cross-reference is used by the router/filer to determine which pieces of the header should
be set into special variables which may be required by the lookup routine.
8925.11,.05 EXAMPLE ENTRY 0;5 FREE TEXT
INPUT TRANSFORM: K:$L(X)>39!($L(X)<2) X
LAST EDITED: FEB 24, 1993
HELP-PROMPT: Answer must be 2-39 characters in length.
DESCRIPTION: This field is used to store sample data for this item in the form the transcriptionist is
expected to use when transcribing it. For example, if a patient has Social Security Number
555-12-1212, and the transcriptionist is expected to write 555-12-1212, then an Example Entry
should have the form 555-12-1212.
The Transform Code, if it exists, then transforms the transcribed Social Security Number
555-12-1212 into the appropriate format for the target file before using the Social Security
Number to look-up the appropriate target file entry and/or before entering it in the target file.
8925.11,.06 CLINICIAN MUST DICTATE 0;6 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: APR 23, 1993
HELP-PROMPT: Answer yes if this field needs to be dictated by the clinician
DESCRIPTION: States whether or not this piece of the header should be dictated by the Clinician. Will be used
by the Clinician Help routine to determine if this field should be shown as data that should be
dictated. (Some pieces can be entered by the transcriber without being dictated, such as the
transcriber identification).
8925.11,.07 REQUIRED FIELD? 0;7 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: OCT 04, 1995
HELP-PROMPT: Please indicate whether the field is required.
DESCRIPTION: This field is used to determine whether a given header piece is required by the application
(e.g., Author and Attending Physician may be required for the ongoing processing of a Discharge
Summary). Records lacking required fields WILL be entered if possible into the target file but
will generate Missing Field Error Alerts.
8925.11,1 TRANSFORM CODE 1;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: FEB 19, 1993
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This standard MUMPS code transforms the transcribed value of the header piece into a format
acceptable to FileMan (e.g., patient social security number 555-12-1212 must be transformed to
555121212 or to whatever (external) format FileMan accepts when a user edits the social security
number field in the target file).
Field values are transformed before being set into Special Lookup Variables and before being set
into Target Text File Fields.
Field is necessary only if transcribed piece is not in the format Fileman accepts for the target
file.
WRITE AUTHORITY: @
8925.1,1.01 UPLOAD TARGET FILE 1;1 POINTER TO FILE FILE (#1)
INPUT TRANSFORM: S DIC("S")="I $D(^DIC(+Y,""%"",""B"",""TIU""))" D ^DIC K DIC S DIC=DIE,X=+Y K:Y<0 X
LAST EDITED: JUL 29, 1996
HELP-PROMPT: Select the DHCP file in which the document will be stored.
DESCRIPTION: ------------- NOTE ON UPLOAD: Upload fields (Upload Target File, Laygo
Allowed, Target Text Field Subscript, Upload Look-Up Method, Upload Post-Filing Code, Upload Filing
Error Code, and multiple fields Upload Delimited ASCII Header and Upload Captioned ASCII Header)
apply to Document Definitions of Type Class, Document Class, and Title. Multiple fields Upload
Delimited ASCII Header and Upload Captioned ASCII Header are heritable AS A GROUP. Do NOT set
partial information at a lower level; if you set ANY information at a lower level, it should be
COMPLETE. For information on editing heritable fields, see Technical field: Edit Template.
TIUF, the Document Definition Utility does NOT display inherited Upload information. To see/edit
existing upload information, edit/view at the level it is set.
--------------
The UPLOAD TARGET FILE is the VA FileMan file in which fixed-field header information and
associated text will be stored. Only files which include the TIU Application Group may be
selected.
SCREEN: S DIC("S")="I $D(^DIC(+Y,""%"",""B"",""TIU""))"
EXPLANATION: Only files with the "TIU" application group may be selected.
8925.1,1.02 LAYGO ALLOWED 1;2 SET
'0' FOR NO;
'1' FOR YES;
LAST EDITED: JAN 28, 1997
HELP-PROMPT: Please indicate whether new entries may be added to the TARGET FILE.
DESCRIPTION: This field indicates whether or not a new entry can be created in the TARGET FILE for documents
defined by this Document Definition.
8925.1,1.03 TARGET TEXT FIELD SUBSCRIPT 1;3 FREE TEXT
INPUT TRANSFORM: K:$L(X)>15!($L(X)<1) X
LAST EDITED: MAR 31, 1994
HELP-PROMPT: Select the Word-processing field in the target file.
DESCRIPTION: This is the subscript of the word-processing field in the TARGET FILE, in which the body of the
narrative report will be stored.
8925.1,1.04 BOILERPLATE ON UPLOAD ENABLED 1;4 SET
'0' FOR NO;
'1' FOR YES;
LAST EDITED: OCT 16, 1995
HELP-PROMPT: Indicate whether boilerplate logic will be executed on upload
DESCRIPTION: This field determines whether the filer will attempt to execute boilerplate logic for uploaded
documents. Not used in version 1.
8925.1,2 UPLOAD CAPTIONED ASCII HEADER HEAD;0 Multiple #8925.12 (Add New Entry without Asking)
LAST EDITED: JUL 29, 1996
DESCRIPTION: This multiple contains the upload record header format of the Document Definition, to be used by
the upload/router/filer when the preferred header format is captioned (as opposed to delimited
string).
Under captioned header format, header items are distinguished from each other by captions such as
SSN which are entered by the transcriber, followed by the data.
Use the captioned header format if documents are transcribed by a human transcriber. Delimited
format is useful only if the site has some way of automatically generating upload record headers.
8925.12,.01 CAPTION 0;1 FREE TEXT (Multiply asked)
INPUT TRANSFORM: K:$L(X)>40!($L(X)<2) X
LAST EDITED: FEB 18, 1993
HELP-PROMPT: Answer must be 2-40 characters in length.
DESCRIPTION: NOTE: Users can choose between two possible kinds of Upload Record Headers: Captioned or
Delimited. Captioned headers should be used UNLESS the site has a way to generate upload headers
automatically.
CAPTION is the caption which the transcriber enters into the captioned upload record header
immediately preceeding the item data. It serves to distinguish one item of data from the next.
Example: PATIENT NAME
CROSS-REFERENCE: 8925.12^B
1)= S ^TIU(8925.1,DA(1),"HEAD","B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"HEAD","B",$E(X,1,30),DA)
8925.12,.02 ITEM NAME 0;2 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>20!($L(X)<2) X
LAST EDITED: JAN 22, 1993
HELP-PROMPT: Enter the name of the header item.
DESCRIPTION: This is the name of the item in the ASCII message header. Item Name is used in help messages for
the person dictating a document.
CROSS-REFERENCE: 8925.12^C
1)= S ^TIU(8925.1,DA(1),"HEAD","C",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"HEAD","C",$E(X,1,30),DA)
This REGULAR FileMan cross-reference on the ITEM NAME is used in the look-up and filing
processes.
8925.12,.03 FIELD NUMBER 0;3 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>10!($L(X)<1) X
LAST EDITED: JAN 22, 1993
HELP-PROMPT: Enter the FIELD # of the item in the target file.
DESCRIPTION: This is the FIELD # in the target file which corresponds to this header item and where this item
of data will be stored.
CROSS-REFERENCE: 8925.12^D
1)= S ^TIU(8925.1,DA(1),"HEAD","D",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"HEAD","D",$E(X,1,30),DA)
This REGULAR FileMan cross-reference is used by the filer router to identify header fields with
field numbers in the target file.
8925.12,.04 LOOKUP LOCAL VARIABLE NAME 0;4 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>8!($L(X)<1)!'(X?1A1.7E) X
LAST EDITED: JAN 22, 1993
HELP-PROMPT: Enter the required local variable into which this item will be set.
DESCRIPTION: This field specifies the local variable name into which this item of the upload header will be
set. The local variable is used by the Look-Up Method. For example, if this item of the header
is the patient social security number, the Lookup Local Variable Name might be TIUSSN. The
social security number as written by the transcriptionist is first transformed by any existing
Transform Code, and then set into this variable (e.g. TIUSSN) for use in Look-Up Method code.
Lookup Local Variable Name is necessary only if the information in this piece is required in
order to look up the appropriate entry in the target file.
CROSS-REFERENCE: 8925.12^E
1)= S ^TIU(8925.1,DA(1),"HEAD","E",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"HEAD","E",$E(X,1,30),DA)
This REGULAR FileMan cross-reference is used by the router/filer to determine which fields of the
header should be set into special variables which may be required by the lookup routine.
8925.12,.05 EXAMPLE ENTRY 0;5 FREE TEXT
INPUT TRANSFORM: K:$L(X)>80!($L(X)<2) X
LAST EDITED: FEB 24, 1993
HELP-PROMPT: Answer must be 2-80 characters in length.
DESCRIPTION: This field is used to store sample data for this item in the form the transcriptionist is
expected to use when transcribing it. For example, if a patient has social security number
555-12-1212, and the transcriptionist is expected to write 555-12-1212, than an Example Entry
should have the form 555-12-1212.
The Upload needs to know the exact form the transcriptionist is expected to use in case it needs
to transform it to make it acceptable to FileMan. In this case, the transcriptionist also needs
to know the exact form.
8925.12,.06 CLINICIAN MUST DICTATE 0;6 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: APR 23, 1993
HELP-PROMPT: Answer yes if this field needs to be dictated by the clinician.
DESCRIPTION: States whether or not this item should be dictated by the Clinician. Will be used by the
Clinician Help routine to determine if this field should be shown as data that should be
dictated. (Some items can be entered by the transcriber without being dictated, such as the
transcriber identification).
8925.12,.07 REQUIRED FIELD? 0;7 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: OCT 04, 1995
HELP-PROMPT: Please indicate whether field is required by application.
DESCRIPTION: This field is used to determine whether a given header item is required by the application (e.g.,
Author and Attending Physician may be required for the ongoing processing of a Discharge
Summary). Records lacking required fields WILL be entered into the target file, if possible, but
will generate Missing Field Error Alerts.
8925.12,1 TRANSFORM CODE 1;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: FEB 19, 1993
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This standard MUMPS code transforms the transcribed value of the header item into a format
acceptable to FileMan (e.g., patient social security number 555-12-1212 must be transformed to
555121212 or to whatever (external) format FileMan accepts when a user edits the social security
number field in the target file).
Field values are transformed before being set into Special Lookup Variables and before being set
into target file fields.
Field is necessary only if transcribed item is not in the format Fileman accepts for the target
file.
WRITE AUTHORITY: @
8925.1,3 BOILERPLATE TEXT DFLT;0 WORD-PROCESSING #8925.13 (NOWRAP)
LAST EDITED: APR 21, 1995
LAST EDITED: MAR 05, 1993
HELP-PROMPT: Enter default Report Format
DESCRIPTION: Applies to Titles and Components.
Site can preload the text field of a document with default text/default format/overprint data
which is presented to the user when entering the document. User can then edit and/or add to the
boilerplate text.
If document is formatted into columns, users entering documents should use replace mode rather
than insert mode (or Find/RePlace Text) to preserve the columns.
Boilerplate Text may be used as an alternative to components to split a document up into
sections, but such sections are stored together and cannot be separately accessed the way
components can. See Type Component, under Basic field Type.
Titles/Components must be inactive in order to edit boilerplate text.
Boilerplate Text is the place to embed objects which go fetch data. For example, suppose a Title
has boilerplate text:
Patient is a healthy |PATIENT AGE| year old male...
Then a user who enters such a note for a patient known by the system to be 56 years old would be
presented with the text:
Patient is a healthy 56 year old male...
The user can then add to the text and/or edit the text, including the age (56) of the patient.
From this point on, the patient age (56) is regular text and is not updated in this note.
If a user enters a document when an embedded object is Inactive, the object does not function;
the user sees the object name and an error message. Similarly, if an object has been misspelled
in the boilerplate text, or deleted from the file, or if the object name in the boilerplate text
is not unique among objects, the object does not function.
When embedding objects in boilerplate text, users should make sure the entire object name is on
one line rather than split between two lines. Split names generate "NOT found" error messages.
Users must also allow enough white space in the boilerplate text for whatever data the object
imports. Users can check boilerplate text using action TRY.
Any user who can edit boilerplate text can embed any object in it. However, except for object
owners who are testing an object, USERS SHOULD EMBED ONLY ACTIVE OBJECTS in boilerplate text. An
object can be embedded in as many different Document Definitions as desired.
A document with multiple components can have boilerplate text in the entry itself and/or in any
component. Boilerplate text in the entry itself appears first.
8925.1,3.02 OK TO DISTRIBUTE 3;2 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JAN 28, 1997
HELP-PROMPT: Enter 1 for YES if entry should be included when this file is exported with data. Enter 0 for NO
or leave blank if entry is for local use only.
DESCRIPTION: Presently applies only to National Programmers; does not appear on Manager or Clinician Menus.
If field is 1 for YES, then entry should be included for export. If field has no value or has
value 0, entry should not be included for export.
Since TIU is hierarchical, the entry's behavior depends on entries above it in the hierarchy. It
is the responsibility of the exporter to make sure all ancestors which are necessary for the proper
behavior of an exported entry are also exported with it (or are already present at sites receiving
the exported entries).
Field is NOT heritable. BASIC field.
8925.1,3.03 SUPPRESS VISIT SELECTION 3;3 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JAN 24, 1997
HELP-PROMPT: Enter 1 for YES ONLY IF this is an administrative note which creates its own historical visit. You
will NOT receive workload credit for such visits.
DESCRIPTION: Applies to entries of Type Class, Document Class, and Title.
For most documents it is very important that the user entering a document select the appropriate
visit to link the document with. However, certain administrative documents for outpatients have no
particular visit that they should be linked with. For example, a clinician could have a chance
encounter with a patient in the corridor and want to document the discussion, or a clinician could
simply want to remind him/herself of something for a given patient. Documents for such purposes
can be set to automatically create their own historical visit when they are entered, so that the
user is not asked to select a visit.
Warning: Such documents DO NOT GIVE WORKLOAD CREDIT.
Heritable. BASIC field. If field has no value and there is no value to inherit, default value is
NO. For information on editing heritable fields, see Technical Field Edit Template.
8925.1,4 UPLOAD LOOK-UP METHOD 4;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: JUL 29, 1996
HELP-PROMPT: Please enter the MUMPS code to be executed for record location.
DESCRIPTION: Sometimes when an entry is uploaded into the target file, a new entry is created for it. However,
in other cases such as for Operative Reports, or for an addendum, the file entry already exists and
must be looked-up and edited.
Look-Up Method is the MUMPS code invoked to perform such a look-up on the target file. If a
look-up is necessary and this field is blank, a regular DIC lookup is performed. If the regular
DIC lookup is not sufficient to locate the appropriate entry, this field should contain the lookup.
It should expect any look-up special variables named in the header fields as input variables, and
should return the variable Y in DIC-compatible format (i.e., IEN^EXTERNAL VALUE[^1]).
WRITE AUTHORITY: @
8925.1,4.1 COMMIT ACTION 4.1;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: NOV 26, 1997
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This M-Code is executed when the TIU document is "committed" to the database (i.e., when the
document is saved, and prior to release, verification, or signature). Heritable. TECHNICAL field.
WRITE AUTHORITY: @
8925.1,4.2 RELEASE ACTION 4.2;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: NOV 26, 1997
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION:
This M-Code is executed upon Release of the document. Heritable. TECHNICAL field.
WRITE AUTHORITY: @
8925.1,4.3 VERIFICATION ACTION 4.3;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: NOV 26, 1997
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION:
This M-Code is executed upon Verification of the document. Heritable. TECHNICAL field.
WRITE AUTHORITY: @
8925.1,4.4 DELETE ACTION 4.4;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: NOV 26, 1997
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION:
This M-Code is executed upon Deletion of the document. Heritable. TECHNICAL field.
WRITE AUTHORITY: @
8925.1,4.45 PACKAGE REASSIGNMENT ACTION 4.45;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: DEC 02, 1997
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This M-Code is executed when a document with a link to a client application is Reassigned.
Heritable. TECHNICAL field.
WRITE AUTHORITY: @
8925.1,4.5 UPLOAD POST-FILING CODE 4.5;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: JUL 29, 1996
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This field specifies code to be executed following the successful filing of an uploaded record. It
may be used to send bulletins or alerts, evaluate expected signers/cosigners, trigger events,
update statuses, or whatever the designer of the application deems appropriate.
WRITE AUTHORITY: @
8925.1,4.6 ENTRY ACTION 4.6;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 22, 1996
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This M-Code is executed during the Entry/Editing of a document, after selection of the Title, and
prior to selection of the Patient. It may be used to set up environmental variables, etc.
Heritable. TECHNICAL field.
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,4.7 EXIT ACTION 4.7;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 22, 1996
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This M-Code is executed just prior to Exit from the entry/edit process for a document. It may be
used to send alerts or bulletins, clean up temporary global variables, etc. Heritable. TECHNICAL
field.
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,4.8 UPLOAD FILING ERROR CODE 4.8;E1,245 MUMPS
UPLOAD FILING ERROR RESOLUTION CODE
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: JUL 29, 1996
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This MUMPS-type field specifies the code to be executed when the user attempts to resolve a filing
error. Filing Errors may be resolved either by responding to a Filing Error Alert or through the
option to Review Upload Events. Typically, the code will offer the user an opportunity to look up
online information necessary to resolve the error (e.g., demographic, or case-related information).
WRITE AUTHORITY: @
8925.1,4.9 POST-SIGNATURE CODE 4.9;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 01, 1997
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This M-Code is executed following Signature (or Cosignature) of a TIU document. Heritable.
TECHNICAL field.
WRITE AUTHORITY: @
8925.1,5 EDIT TEMPLATE 5;E1,245 FREE TEXT
INPUT TRANSFORM: K:$L(X)>60!($L(X)<2) X
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Enter the name of the Input Template for documents defined by this entry.
DESCRIPTION: Applies to Classes, Document Classes, Titles. This is the Input Template for Entering/Editing
documents defined by this entry. Template includes fixed field information such as Patient, etc.
Enter Edit Template in Format [TEMPLATE NAME], or as a "field-string" (e.g., .01;1;3;5).
Heritable. TECHNICAL field.
NOTE on editing heritable fields:
When editing heritable fields, the user is presented with the EFFECTIVE value of the field as the
default (e.g. NO//). This is the same as the value shown in the display and is the field's own
value if it has one, the inherited value if the field does not have its own value, or the default
for the field if the field has neither its own nor an inherited value. If the user accepts this
default by pressing return, the value is made explicit, i.e., entered into the field. If a user
does NOT want to make the value explicit, the user should enter @, which leaves a blank field
blank. If the user want to delete an explicit value, the user should enter @, which deletes the
field value, leaving TIU to use the effective value for the field.
EXECUTABLE HELP: D HELP1^TIUFXHLX(5)
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,6 PRINT METHOD 6;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Please enter the MUMPS code to be executed to print a record.
DESCRIPTION: Applies to Types Class, Document Class, Title. This M-Code is executed when a document is Printed
from the TIU List Manager screen (as opposed to a separate print option which may have its own
code.) Heritable. TECHNICAL field. For more information on editing heritable fields, see Technical
field Edit Template.
EXECUTABLE HELP: D HELP1^TIUFXHLX(6)
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,6.1 PRINT FORM HEADER 6.1;1 FREE TEXT
INPUT TRANSFORM: K:$L(X)>40!($L(X)<3) X
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Answer must be 3-40 characters in length.
DESCRIPTION: For basic information on Print Form Header see Technical field Allow Custom Form Headers.
The Print Form Header is the official medical record title of the document which has been approved
by the Medical Record Committee based on national guidelines.
Examples: Progress Notes, Physical Examination, History - Part 1, etc.
This field is heritable with lower level values overriding higher ones AS LONG AS the field is
applicable. See Allow Custom Form Headers. Print Form Header is a TECHNICAL field.
TECHNICAL DESCR: The narrative stored in this field will display as the form header of a document. If entered at a
CLASS level such as FORMS, all forms documents will display entered header as the form header of
the document. If the free text is entered at a lower level (i.e., TITLE), this form header will
override the one entered at the higher level and will be displayed on the form.
EXECUTABLE HELP: D HELP1^TIUFXHLX(6.1)
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,6.12 PRINT FORM NUMBER 6.1;2 FREE TEXT
INPUT TRANSFORM: K:$L(X)>20!($L(X)<3) X
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Answer must be 3-20 characters in length.
DESCRIPTION: For basic information on Print Form Number see Technical field Allow Custom Form Headers.
The Print Form Number is the official medical record form number of the document which has been
approved by the Medical Record Committee based on national guidelines.
Example: Progress Note - Vice SF 509, Consult - SF 513, Physicial Examination - SF 506.
Field is heritable with lower level values overriding higher ones AS LONG AS the field is
applicable. See field Allow Custom Form Headers. Print Form Header is a TECHNICAL field.
TECHNICAL DESCR: The free text stored in this field will be displayed as the form number of a document. If entered
at a CLASS level such as Forms, all Forms documents will display the entered value as the form
number of the document. If the free text is entered at a lower level (i.e., TITLE), this value
will override the one entered at the higher level and will be displayed on the form.
EXECUTABLE HELP: D HELP1^TIUFXHLX(6.12)
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,6.13 PRINT GROUP 6.1;3 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>10)!(X<1)!(X?.E1"."1N.N) X
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Type a Number between 1 and 10, 0 Decimal Digits. Enter ?? for help.
DESCRIPTION: For basic information on Print Group see Technical field Allow Custom Form Headers.
Print Group is an integer number which serves to group by print form headers/numbers related
documents that share a common print method; e.g., Progress Notes, H&P's, and other documents may
share a common print method, but have differing form headers/numbers and should each print in their
own, separate collation. Specifying a common print group for documents with the same
headers/numbers (for example, Progress Notes have Print Group 2, H&P's might have Print Group 7)
causes such documents from each print group to collate together when a mixed print is called for.
Since documents collate first by print method, then by print group, print group is not necessary
unless documents share a common print method.
Print Group is heritable with lower level values overriding higher ones AS LONG AS the field is
applicable. See Allow Custom Form Headers. Print Group is a TECHNICAL field.
EXECUTABLE HELP: D HELP1^TIUFXHLX(6.13)
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,6.14 ALLOW CUSTOM FORM HEADERS 6.1;4 SET
ALLOW CUSTOM FORM HEADERS/NUMBERS AT LOWER LEVELS
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JAN 28, 1997
HELP-PROMPT: May be set for Types CL and DC only. Enter 1 for YES if descendent Titles can have individual
(Custom) Form Headers/Numbers within their Document Class. Otherwise enter 0.
DESCRIPTION: Allow Custom Form Headers may be set for entries of Type Class or Document Class and affects
DESCENDANTS of the entry for which it is set.
Information on Form Headers, Form Numbers, Print Group, and Allow Custom Form Headers:
Some clinical documents use Forms with Form Headers and Form Numbers, for example, Progress Note
Forms have Header 'Progress Notes' and Number 'Vice SF 509.'
The Owner of a Document Definition must decide whether all documents descending from the entry will
have the SAME Header/Number, or whether to allow CUSTOM (varying) Headers/Numbers at lower levels.
Allow Custom Headers holds the decision: If the field has value 0 for NO, then ALL descendant
documents use a COMMON Header/Number (or perhaps they all use NO Header/Number); they also collate
together in printouts.
For example, Class Progress Notes does NOT Allow Custom Form Headers. This means that ALL Progress
Note Titles have the same header and the same form number. For Class Progress Notes, Field Print
Form Header holds the header 'Progress Notes', Field Print Form Number holds Form Number 'Vice SF
509', and Field Print Group holds '2'. Since Class Progress Notes does not Allow Custom Form
Headers, these field values apply for ALL Progress Note Titles. That is, all Progress Notes have
header 'Progress Notes', Form Number 'Vice SF 509', and collate together in printouts.
Field Allow Custom Field Headers also determines whether or not related Fields Print Form Header,
Print Form Number, Print Group, (and even Allow Custom Field Headers) are applicable at lower
levels. If an entry at a particular level DOES allow Custom Form Headers, then these related
fields DO APPLY to descendants at the next lower level. If an entry at a particular level DOES NOT
allow Custom Form Headers, then ALL LOWER LEVELS inherit the the prohibition, and the related
fields DO NOT APPLY at ANY lower levels.
Example: Since Class Progress Notes does NOT Allow Custom Form Headers, fields Print Form Header,
Print Form Number, Print Group, and Allow Custom Field Headers DO NOT APPLY to Document Classes or
Titles under Progress Notes. This means that Document Definitions for documents requiring
different Form Headers/Numbers must be placed under a separate line of descent in the hierarchy;
they cannot be under Progress Notes.
Example: Class Clinical Documents, the Mother of all Document Definitions, does not want to REQUIRE
all Document Definitions under it to use one common Header. So Clinical Documents DOES Allow
Custom Form Headers. Classes/Document Classes UNDER CLinical Documents can decide for themselves
whether or not to Allow Custom Headers for their own Items.
Example: Class DISCHARGE SUMMARY has only one Form Header and Number which is used by all Discharge
Summary documents. So Class Discharge Summary does NOT Allow Custom Headers.
Example: Class FORMS might contain miscellaneous documents, each using a different Form with its
own Form Header and Form Number. So Class Forms would Allow Custom Headers.
Field Allow Custom Form Headers may be set for Document Definitions of Type Class or Document Class
only, and affects the DESCENDANTS of the entry for which it is set.
If a DOCUMENT CLASS Allows Custom Form Headers, then TIUF, the Document Definition Utility, does
not permit a descendant Title to be activated unless fields Print Form Header, Print Form Number,
and Print Group have a value (of their own or inherited). If NO Header, or Number is desired,
enter 'NONE'. If NO Print Group is desired, enter '0'.
For information on editing heritable fields, see Technical field Edit Template.
EXECUTABLE HELP: D CUSTOM^TIUFXHLX
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,6.5 ON BROWSE EVENT 6.5;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: FEB 15, 2001
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This is MUMPS code which is invoked on browsing a document to fetch data from the Requesting
Package that will be included in the display.
WRITE AUTHORITY: @
8925.1,6.51 ON RETRACT EVENT 6.51;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: MAR 01, 2001
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This is MUMPS code which is invoked on retraction of a document to perform any processing task that
the Requesting Package may require.
WRITE AUTHORITY: @
8925.1,7 VISIT LINKAGE METHOD 7;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Please enter the MUMPS code to be executed to establish Visit Linkage.
DESCRIPTION: Applies to Types Class, Document Class, Title. This M-Code is executed to establish Visit Linkage,
usually displaying appropriate visits and prompting the user to select the correct one.
Heritable. TECHNICAL Field. For information on editing heritable fields, see Technical Field Edit
Template.
EXECUTABLE HELP: D HELP1^TIUFXHLX(7)
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,8 VALIDATION METHOD 8;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 22, 1996
HELP-PROMPT: Please enter the MUMPS code to be executed to validate the selection of patient and
Visit/Admission.
DESCRIPTION: Applies to Types Class, Document Class, Title. This is the M-Code to be invoked when Validating
the visit and other fixed field information on a record during entry/edit. User is asked to OK or
to correct the information.
Heritable. TECHNICAL field. For information on editing heritable fields, see Technical field Edit
Template.
EXECUTABLE HELP: D HELP1^TIUFXHLX(8)
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,9 OBJECT METHOD 9;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: OCT 22, 1996
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: Applies to Objects. This M-Code is invoked when a document is entered whose boilerplate text
contains the object. Extracted data are inserted into document text. Author then edits/adds to
text. TECHNICAL field.
WRITE AUTHORITY: @
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.1,10 ITEM 10;0 POINTER Multiple #8925.14
8925.14,.01 ITEM 0;1 POINTER TO TIU DOCUMENT DEFINITION FILE (#8925.1) (Multiply asked)
INPUT TRANSFORM: S DIC("S")="I $G(TIUFPRIV) X:$D(TIUFISCR) ""I Y=TIUFISCR""" D ^DIC K DIC S DIC=DIE,X=+Y K:Y<0 X
LAST EDITED: OCT 16, 1997
HELP-PROMPT: ITEM must be a new or pre-existing Document Definition with appropriate Type which you own, which
is not already an Item elsewhere.
DESCRIPTION: Items are themselves Document Definitions. The Type of the parent entry determines what Types of
items it has. A parent entry of type Class has items of type Class or Document Class. A
Document Class entry has items of type Title. If a Title entry has more than a single section,
it has items of type Component. Components may also be multi-section with items of type
Component. Objects do not have items.
TECHNICAL DESCR: The Item subfield of Item Field 10 in File 8925.1 is screened when using the TIUF Document
Definition Utility to add items (i.e. when variable TIUFISCR is defined.
This screen is needed in ADDTEN^TIUFLF4, which noninteractively adds an item to the Item
multiple. The screen limits the lookup to the 8925.1 IFN of the item being added to the Item
multiple. Without the screen, the lookup fails when there are multiple 8925.1 entries of the
same name.
SCREEN: S DIC("S")="I $G(TIUFPRIV) X:$D(TIUFISCR) ""I Y=TIUFISCR"""
EXPLANATION: See Technical Description.
EXECUTABLE HELP: D NAME^TIUFXHLX
DELETE TEST: .01,0)= I 1
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE: 8925.14^B
1)= S ^TIU(8925.1,DA(1),10,"B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),10,"B",$E(X,1,30),DA)
CROSS-REFERENCE: 8925.1^AD
1)= S ^TIU(8925.1,"AD",$E(X,1,30),DA(1),DA)=""
2)= K ^TIU(8925.1,"AD",$E(X,1,30),DA(1),DA)
This cross-reference facilitates traversal from child to parent, up the class hierarchy.
CROSS-REFERENCE: 8925.1^AMM^MUMPS
1)= D REDOX^TIUDD
2)= D REDOX^TIUDD
This MUMPS-type cross-reference will update the timestamp on the parent document when the ITEM,
MNEMONIC, or SEQUENCE changes.
CROSS-REFERENCE: 8925.1^ACL1001^MUMPS
1)= D SACL^TIUDD1(X,10.01)
2)= D KACL^TIUDD1(X,10.01)
This MUMPS-type cross-reference by class and name will help to identify the titles within a given
class.
8925.14,2 MNEMONIC 0;2 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>4!($L(X)<1) X
LAST EDITED: JUL 20, 1994
HELP-PROMPT: Mnemonic is a handle by which to select Classes/Document Classes from a menu. Enter the Sequence
number, or 1-4 letters, or nothing if you don't want mnemonics.
DESCRIPTION: Item Mnemonic is a handle by which to select Classes/Document Classes from a menu. 1-4 characters
long. Mnemonic is usually numeric with the same value as the Sequence. Alpha mnemonics are
permitted if preferred.
CROSS-REFERENCE: 8925.1^AMM2^MUMPS
1)= D REDOX^TIUDD
2)= D REDOX^TIUDD
This MUMPS-type cross-reference will update the TIMESTAMP on the parent document when either the
ITEM, MNEMONIC, or SEQUENCE changes.
8925.14,3 SEQUENCE 0;3 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>999)!(X<.01)!(X?.E1"."3N.N) X
LAST EDITED: OCT 21, 1996
HELP-PROMPT: Item Sequence determines display order under the parent. For alphabetic order, do not enter
sequences. Sequence is between .01 and 999, 2 Decimal Digits.
DESCRIPTION: Item Sequence, if entered, determines item's order under its parent. If items have no sequence,
item order is alphabetic by item Menu Text. Sequence must be between .01 and 999.
CROSS-REFERENCE: 8925.1^AMM3^MUMPS
1)= D REDOX^TIUDD
2)= D REDOX^TIUDD
This MUMPS-type cross-reference will update the TIMESTAMP of the parent document when the ITEM,
MNEMONIC, or SEQUENCE change.
CROSS-REFERENCE: 8925.14^AC
1)= S ^TIU(8925.1,DA(1),10,"AC",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),10,"AC",$E(X,1,30),DA)
3)= Please don't delete!
This REGULAR Fileman cross reference is used to list items by sequence number.
8925.14,4 MENU TEXT 0;4 FREE TEXT (Required)
INPUT TRANSFORM:K:X[""""!($A(X)=45)!($A(X)=32) X I $D(X) K:$L(X)>20!($L(X)<1) X I $D(X) K:$$UPPER^TIULS($E(X,1,3))=
"ALL" X
LAST EDITED: JAN 21, 1999
HELP-PROMPT: This is the short name of the entry, used in 3 column menus. 1 to 20 characters. Must not begin
with 'All', or with a space.
DESCRIPTION: Item Menu Text is the short name users will see for Classes and Document Classes when selecting
them from 3-COLUMN MENUS. Document Definitions are selected from 3-column menus when viewing
documents across many patients and when viewing many kinds of documents at the same time (e.g.
Progress Notes and Discharge Summaries).
To edit the Menu Text of a Document Definition, you must be viewing the Document Definition as an
ITEM of its PARENT. Select 'Detailed Display' for the PARENT and then 'Items'.
Menu Text has 1 - 20 characters. Menu Text must not begin with a space or with 'All'. The Document
Definition Utility TIUF automatically sets the Item Menu Text to the first 20 characters of the
Item's Name when an entry is first added as an item. (If an entry's Name begins with 'All' its Menu
Text is given 'AlX' as its first 3 characters.) The utility does NOT update Menu Text if the entry
Name is later changed, since this would overwrite what a site may have carefully set up. Menu Text
is required.
Menu Text can affect item order under a parent since order is alphabetic by menu text if items do
not have sequence numbers.
TECHNICAL DESCR:Menu Text cannot begin with 'All' because XQOR, the Unwinder Utility, misinterprets it. The result
(for titles) is that when a user selects a Document Class of titles to view from a three column
menu, and one of the titles has menu text starting with 'All,' then no documents are found for
titles AFTER the title starting with 'All', even though such documents may exist. Similar problems
occur with types other than titles.
Menu Text cannot begin with a space because such Menu Text cannot be used to select the entry from
a menu: if the space is left off, it is questioned, and if the space is left in, it is still
questioned.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
CROSS-REFERENCE:8925.1^AMM4^MUMPS
1)= D REDOX^TIUDD
2)= D REDOX^TIUDD
This MUMPS-type cross-reference updates the TIMESTAMP on the parent document when the DISPLAY NAME
changes.
CROSS-REFERENCE:8925.14^C^MUMPS
1)= S ^TIU(8925.1,DA(1),10,"C",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),10,"C",$E(X,1,30),DA)
This M cross reference could have been regular. It is used to display items with no sequence in
alpha order by Menu Text.
8925.1,11 STAT AUTO PRINT EVENT 11;0 SET Multiple #8925.111 (Add New Entry without Asking)
LAST EDITED: JUN 21, 1994
DESCRIPTION: This parameter applies only to stat documents.
This parameter determines at what stage(s) a document should be automatically printed for chart,
either singly when document is ready, or in batch mode.
Some documents will need to be printed for chart only when they are complete, ie have obtained all
expected signatures and cosignatures. Others should perhaps be printed for chart at an earlier
stage, allowing earlier chart access, and then be reprinted when complete. Documents may also need
to be reprinted AFTER completion for certain events such as amendment.
Any event which should trigger auto printing of the document should be entered as an auto print
event.
- SIGNED means firstline signature, as opposed to secondline cosignature. - COSIGNED, OPTIONAL,
INCOMPLETE means when an incomplete document obtains an optional cosignature. - COSIGNED,
OPTIONAL, COMPLETED means when a previously completed document obtains an optional cosignature,
namely, a walkup. - COMPLETED means when some event occurs that completes the document, for
example the document obtains its last expected optional cosignature.
If one event occurs to a document and corresponds to two selected print events (such as COMPLETED
and COSIGNED OPTIONAL INCOMPLETE), the document will only print once.
If parameter is not entered and Document Definition has no ancestor to inherit from, parameter
assumes default value N for NONE. If parameter is not entered and Document Definition has a parent
to inherit from, then parameter assumes value (assumed or explicit) of parent print events. If
parameter is non applicable because Document Definition does not allow stat documents, or because
Document Definition does not allow auto printing, enter N for NONE.
8925.111,.01 STAT AUTO PRINT EVENT 0;1 SET (Multiply asked)
'N' FOR NONE;
'T' FOR TRANSCRIBED;
'R' FOR RELEASED;
'V' FOR VERIFIED;
'S' FOR SIGNED;
'CSR' FOR COSIGNED, REQUIRED;
'CSOINC' FOR COSIGNED, OPTIONAL, INCOMPLETE;
'CSOCP' FOR COSIGNED, OPTIONAL, COMPLETED;
'CP' FOR COMLETED;
'AD' FOR ADDENDUM ADDED;
'AM' FOR AMENDED;
LAST EDITED: OCT 27, 1994
HELP-PROMPT: Enter every event which should trigger auto printing of document whenever the event occurs.
CROSS-REFERENCE: 8925.111^B
1)= S ^TIU(8925.1,DA(1),11,"B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),11,"B",$E(X,1,30),DA)
8925.1,12 ROUTINE AUTO PRINT EVENT 12;0 SET Multiple #8925.112 (Add New Entry without Asking)
DESCRIPTION: This parameter applies to routine (non-stat) documents only. Documents whose Document Definitions
do not allow stat documents are considered routine.
See parameter STAT AUTO PRINT EVENT for description.
8925.112,.01 ROUTINE AUTO PRINT EVENT 0;1 SET (Multiply asked)
'N' FOR NONE;
'T' FOR TRANSCRIBED;
'R' FOR RELEASED;
'V' FOR VERIFIED;
'S' FOR SIGNED;
'CSR' FOR COSIGNED, REQUIRED;
'CSOINC' FOR COSIGNED, OPTIONAL, INCOMPLETE;
'CP' FOR COMPLETED;
'CSOCP' FOR CONSIGNED, OPTIONAL, COMPLETED;
'AD' FOR ADDENDUM ADDED;
'AM' FOR AMENDED;
LAST EDITED: JUN 21, 1994
HELP-PROMPT: Enter an event which should trigger auto printing of routine documents.
CROSS-REFERENCE: 8925.112^B
1)= S ^TIU(8925.1,DA(1),12,"B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),12,"B",$E(X,1,30),DA)
8925.1,13 PROCESSING STEPS 13;0 POINTER Multiple #8925.113
DESCRIPTION: This sub-file contains the optional and required steps for processing any document, along with the
states (e.g., unverified -> unsigned) that a given step (e.g., verification) moves the document
between.
8925.113,.01 PROCESSING STEP 0;1 POINTER TO USR ACTION FILE (#8930.8) (Multiply asked)
LAST EDITED: FEB 16, 1995
HELP-PROMPT: Please indicate a step involved in processing this document.
DESCRIPTION: This is a step or action (e.g., verification) in the processing of a document that moves it from
one state (e.g., unverified) to another (e.g., unsigned).
CROSS-REFERENCE: 8925.113^B
1)= S ^TIU(8925.1,DA(1),13,"B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),13,"B",$E(X,1,30),DA)
8925.113,.02 SEQUENCE 0;2 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>999)!(X<0)!(X?.E1"."1N.N) X
LAST EDITED: FEB 16, 1995
HELP-PROMPT: Indicate the order in processing this document where this step should occur.
DESCRIPTION: This is the serial sequence in the processing of the document in which the current step should
ordinarily occur. This field is only necessary when the process in question must occur in a
particular sequence (e.g., to insure that a document is always released from draft before it is
verified).
8925.113,.03 REQUIRED? 0;3 SET
'1' FOR REQUIRED;
'0' FOR OPTIONAL;
LAST EDITED: FEB 16, 1995
HELP-PROMPT: Indicate whether the step is required or optional
DESCRIPTION: This field specifies whether the step is required or optional for completion of the document
(e.g., Dictation and transcription is the typical means by which Discharge Summaries are
acquired, but they may be entered directly by the provider, if preferred).
8925.113,.04 RESULTING STATUS 0;4 POINTER TO USR RECORD STATUS FILE (#8930.6)
LAST EDITED: FEB 16, 1995
HELP-PROMPT: Indicate the status resulting from the step being taken.
DESCRIPTION: This is the status of the document following completion of the step in question. For instance,
if a discharge summary is to be registered as unsigned following verification, this would be
indicated in the RESULTING STATUS field.
8925.113,.05 CONDITION TEXT 0;5 FREE TEXT
INPUT TRANSFORM: K:$L(X)>40!($L(X)<3) X
LAST EDITED: FEB 16, 1995
HELP-PROMPT: Condition under which the step will result in the status as indicated.
8925.1,14 DIALOG DIALOG;0 Multiple #8925.114
DESCRIPTION: This sub-file contains the data necessary to handle server-based definition for fixed-field data
capture in TIU.
8925.114,.01 PROMPT 0;1 FREE TEXT (Multiply asked)
INPUT TRANSFORM: K:$L(X)>30!($L(X)<2) X
LAST EDITED: JUN 06, 1995
HELP-PROMPT: Enter the caption with which the user will be prompted.
DESCRIPTION: This is the prompt with which the user will be presented during interactive entry of the
document.
CROSS-REFERENCE: 8925.114^B
1)= S ^TIU(8925.1,DA(1),"DIALOG","B",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"DIALOG","B",$E(X,1,30),DA)
8925.114,.02 ITEM NAME 0;2 FREE TEXT
INPUT TRANSFORM: K:$L(X)>50!($L(X)<2) X
LAST EDITED: JUN 06, 1995
HELP-PROMPT: Answer must be 2-50 characters in length.
DESCRIPTION:
This is a descriptive name for the datum which will help descibe the prompt for the user.
8925.114,.03 SEQUENCE 0;3 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>999)!(X<1)!(X?.E1"."1N.N) X
LAST EDITED: JUN 06, 1995
HELP-PROMPT: Type a Number between 1 and 999, 0 Decimal Digits
DESCRIPTION: This is the sequence of the prompt within the dialog. On the Windows Client this will correspond
with the Tab Order Property of the prompt.
CROSS-REFERENCE: 8925.114^AS
1)= S ^TIU(8925.1,DA(1),"DIALOG","AS",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,DA(1),"DIALOG","AS",$E(X,1,30),DA)
This REGULAR FileMan Cross-reference on the sequence sub-field of the Dialog Multiple will
facilitate appropriate serialization of prompts.
8925.114,.04 FIELD 0;4 FREE TEXT
INPUT TRANSFORM: K:$L(X)>10!($L(X)<1)!(+X<0) X
LAST EDITED: JAN 16, 1997
HELP-PROMPT: Enter the field in the TARGET FILE in which the response is to be stored.
DESCRIPTION:
This is the field in the target file in which the user's response will be stored.
NOTES: XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
8925.114,.05 REQUIRED 0;5 SET
'1' FOR YES;
'0' FOR NO;
LAST EDITED: JUN 07, 1995
HELP-PROMPT: Indicate whether a response is required.
DESCRIPTION:
Please indicate whether a response to this prompt is required, in order to complete the dialog.
8925.114,.06 VISIBLE 0;6 SET
'0' FOR NO;
'1' FOR YES;
LAST EDITED: JUN 07, 1995
HELP-PROMPT: Indicate wheter the prompt will be visible to the user.
DESCRIPTION: This field specifies whether a given datum will be prompted for, or "stuffed," based on execution
of the SET METHOD for a given prompt.
8925.114,1 SET METHOD 1;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: JUN 07, 1995
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This is the mumps code for determining the default value of an interactive ("visible") prompt,
and for setting the value to be non-interactively "stuffed" on invokation of an "invisible"
prompt. Regardless of the syntactic approach (e.g., subroutine or extrinsic function, the return
value of the method should be placed in the local varible X.
WRITE AUTHORITY: @
8925.114,101 WINDOWS CONTROL W;1 SET
'1' FOR LongList;
'2' FOR SimpleList;
'3' FOR Edit;
'4' FOR Memo;
LAST EDITED: SEP 07, 1995
HELP-PROMPT: Enter the Windows control appropriate for this prompt
DESCRIPTION:
Stores the type of Windows control necessary to get the data for this prompt.
8925.114,102 API NAME W;2 FREE TEXT
INPUT TRANSFORM: K:$L(X)>30!($L(X)<3) X
LAST EDITED: OCT 02, 1995
HELP-PROMPT: Answer must be 3-30 characters in length.
DESCRIPTION: This is the API that should be called by the broker when the control is used. How the API is
used varies with the control. Examples are: filling list boxes, getting boilerplate text, etc.
8925.114,103 API PARAMETER #1 W;3 FREE TEXT
INPUT TRANSFORM: K:$L(X)>30!($L(X)<1) X
LAST EDITED: SEP 07, 1995
HELP-PROMPT: Answer must be 1-30 characters in length.
DESCRIPTION:
A parameter that is used by the API may be stored here.
8925.114,113 WINDOWS CONDITION W3;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: SEP 07, 1995
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION: This is silent code which is executed when building the dialog for Windows. It identifies which
prompts should be included in the dialog. The condition should leave $T failse if the prompt
should not be asked.
WRITE AUTHORITY: @
8925.114,117 WINDOWS DEFAULT W7;E1,245 MUMPS
INPUT TRANSFORM: K:$L(X)>245 X D:$D(X) ^DIM
LAST EDITED: SEP 07, 1995
HELP-PROMPT: This is Standard MUMPS code.
DESCRIPTION:
This code should silently set the default value of a prompt when it is selected.
WRITE AUTHORITY: @
8925.1,99 TIMESTAMP 99;1 FREE TEXT
INPUT TRANSFORM: K:X[""""!($A(X)=45) X I $D(X) K:$L(X)>15!($L(X)<1) X
LAST EDITED: JUL 20, 1994
HELP-PROMPT: Answer must be 1-15 characters in length.
CROSS-REFERENCE: 8925.1^AM^MUMPS
1)= D SET^TIUDD
2)= D KILL^TIUDD
This cross-reference invokes menu compilation in ^XUTL("XQORM", DA;TIU(8925.1, when the TIMESTAMP
field is modified.
8925.1,1501 VHA ENTERPRISE STANDARD TITLE 15;1 POINTER TO TIU VHA ENTERPRISE STANDARD TITLE FILE (#8926.1)
INPUT TRANSFORM: S DIC("S")="I '$$SCREEN^XTID(8926.1,"""",Y_"","")" D ^DIC K DIC S DIC=DIE,X=+Y K:Y<0 X
LAST EDITED: MAR 21, 2007
HELP-PROMPT: Please identify the VHA Enterprise Title to which this local title should be mapped.
DESCRIPTION: This reference to the VHA ENTERPRISE STANDARD TITLE FILE provides for the mapping of local titles
to the Enterprise Standard Titles.
SCREEN: S DIC("S")="I '$$SCREEN^XTID(8926.1,"""",Y_"","")"
EXPLANATION: Only ACTIVE Enterprise Titles may be selected.
CROSS-REFERENCE: 8925.1^ALOINC
1)= S ^TIU(8925.1,"ALOINC",$E(X,1,30),DA)=""
2)= K ^TIU(8925.1,"ALOINC",$E(X,1,30),DA)
3)= ** DO NOT DELETE **
This REGULAR FileMan cross-reference will facilitate searching by VHA Enterprise Standard Titles.
8925.1,1502 MAP ATTEMPTED 15;2 DATE
INPUT TRANSFORM: S %DT="ESTX" D ^%DT S X=Y K:Y<1 X
LAST EDITED: MAR 01, 2006
HELP-PROMPT: Enter the date/time at which mapping was attempted.
DESCRIPTION:
This is the date/time at which the user attempted to map the Local Title to a VHA Enterprise Title.
8925.1,1503 MAP ATTEMPTED BY 15;3 POINTER TO NEW PERSON FILE (#200)
LAST EDITED: MAR 01, 2006
HELP-PROMPT: Specify the person who attempted to map the title.
DESCRIPTION:
This is the person who attempted to map the Local Title to a VHA Enterprise Title.
FILES POINTED TO FIELDS
FILE (#1) UPLOAD TARGET FILE (#1.01)
NEW PERSON (#200) PERSONAL OWNER (#.05)
MAP ATTEMPTED BY (#1503)
TIU DOCUMENT DEFINITION (#8925.1) ITEM:ITEM (#.01)
TIU STATUS (#8925.6) STATUS (#.07)
TIU VHA ENTERPRISE STANDARD TI
(#8926.1) VHA ENTERPRISE STANDARD TITLE (#1501)
USR ACTION (#8930.8) PROCESSING STEPS:PROCESSING STEP (#.01)
USR CLASS (#8930) CLASS OWNER (#.06)
USR RECORD STATUS (#8930.6) PROCESSING STEPS:RESULTING STATUS (#.04)
INPUT TEMPLATE(S):
TIU EDIT DOCUMENT TYPE OCT 22, 1995@10:30 USER #0
TIU UPLOAD FIELD EDIT MAR 28, 1996@15:51 USER #0
TIUF UPLOAD FIELD EDIT DEC 10, 1996@14:17 USER #0
Used by Document Definition Utility TIUF to edit upload fields.
PRINT TEMPLATE(S):
TIU HT TITLE MAPPINGS AUG 22, 2011@15:26 USER #0 ^TIUCTM HT Title Mapping Report
TIU HT TITLE PRINT AUG 22, 2011@15:28 USER #0 ^TIUCTP HT Title Verification Report
SORT TEMPLATE(S):
TIU HT STATUS-NAME AUG 22, 2011@15:29 USER #0 ^DISZ*
SORT BY: STATUS// ( STATUS not null)
WITHIN STATUS, SORT BY: NAME// ( NAME not null)
This sort template supports the TIU HT TITLES search for verifying the
install of TIU*1*258.
FORM(S)/BLOCK(S):