Home   Package List   Routine Alphabetical List   Global Alphabetical List   FileMan Files List   FileMan Sub-Files List   Package Component Lists   Package-Namespace Mapping  
Info |  Desc |  Directly Accessed By Routines |  Accessed By FileMan Db Calls |  Pointed To By FileMan Files |  Pointer To FileMan Files |  Fields |  All
Print Page as PDF
Global: ^TIU(8925.1

Package: Text Integration Utility

Global: ^TIU(8925.1


Information

FileMan FileNo FileMan Filename Package
8925.1 TIU DOCUMENT DEFINITION Text Integration Utility

Description

Directly Accessed By Routines, Total: 219

Package Total Routines
Text Integration Utility 176 TIU182D1    TIU189    TIU199    TIU212B    TIUADD    TIUASRPT    TIUBR    TIUBRWS
TIUCHECK    TIUCHLP    TIUCNFIX    TIUCNSLT    TIUCP    TIUCPFIX    TIUDAEN    TIUDD
TIUDD1    TIUDD61    TIUDD98    TIUDPEDT    TIUE1008    TIUE1012    TIUE246    TIUEC112
TIUEDI1    TIUEDI2    TIUEDI4    TIUEN137    TIUEN165    TIUEN169    TIUEN182    TIUEPRNT
TIUFA    TIUFA1    TIUFC    TIUFC1    TIUFD    TIUFD1    TIUFD2    TIUFD3
TIUFD4    TIUFH1    TIUFHA    TIUFHA1    TIUFHA2    TIUFHA3    TIUFHA4    TIUFHA5
TIUFHA6    TIUFHA7    TIUFHA8    TIUFHLP1    TIUFIX1    TIUFIX2    TIUFLA    TIUFLA1
TIUFLD    TIUFLD1    TIUFLF    TIUFLF1    TIUFLF2    TIUFLF3    TIUFLF4    TIUFLF5
TIUFLF6    TIUFLF7    TIUFLF8    TIUFLJ    TIUFLJ1    TIUFLP1    TIUFLT    TIUFLX
TIUFT    TIUFT1    TIUFX    TIUFZZ43    TIUFZZ60    TIUFZZ8    TIUHL7U1    TIUHL7U2
TIUHSL    TIUHSOBJ    TIUHSOLM    TIUHSV    TIULA    TIULA1    TIULA2    TIULA3
TIULA4    TIULC1    TIULE    TIULF    TIULG    TIULP    TIULQ    TIULX
TIUMAP    TIUMAP1    TIUMAP2    TIUMLIST    TIUP1008    TIUP1012    TIUP113    TIUP134P
TIUP146P    TIUP149P    TIUP171P    TIUP188P    TIUP242    TIUP246    TIUPEFIX    TIUPEVN1
TIUPFFIX    TIUPI260    TIUPLST    TIUPNAPI    TIUPNCV3    TIUPNFIX    TIUPOST    TIUPP3
TIUPR222    TIUPR230    TIUPREL    TIUPRF    TIUPRF2    TIUPRFL    TIUPS109    TIUPS112
TIUPS115    TIUPS130    TIUPS137    TIUPS14    TIUPS163    TIUPS165    TIUPS169    TIUPS17
TIUPS184    TIUPS209    TIUPS225    TIUPS76    TIUPS79    TIUPUTA    TIUPUTC    TIUPUTC1
TIUPUTD    TIUQRYL    TIUR    TIURA    TIURB    TIURB1    TIURB2    TIURB3
TIURC    TIURC1    TIURD1    TIURENDX    TIUSROI    TIUSROI1    TIUSRV    TIUSRVD
TIUSRVG    TIUSRVL    TIUSRVL1    TIUSRVLI    TIUSRVLO    TIUSRVR1    TIUSRVT    TIUSRVT1
TIUSTA    TIUSTS    TIUSTT    TIUT    TIUTHLP    TIUTPBN    TIUUPEDT    TIUWRII1
IHS Mods To Text Integration Utilities 17 BTIUDDL    BTIUFD    BTIUODL    BTIUP1    BTIUP13    BTIUP2    BTIUP3    BTIUP4
BTIUP6    BTIUPOS    BTIUPOS3    BTIURPT1    BTIURPT2    BTIURPT3    BTIURPT4    BTIUSRVT
BTIUVSIT    
IHS Electronic Health Record 5 BEHODC    BEHODC7    BEHODCH    BEHOTIU    BEHOTIUI    
Authorization Subscription 2 USRAEDT    USRLA    
Clinical Reminders 2 PXRMGECK    PXRMTIU    
Health Summary 2 GMTSADH5    GMTSPOST    
Order Entry Results Reporting 2 ORRHCT    ORWTPN    
Outpatient Pharmacy 1 PSOTALK2    
Tracking Procedure Workflow 1 BTPWEVNT    
VueCentric Components 1 CIAOQN    
iCare 1 BQITIULS    

Accessed By FileMan Db Calls, Total: 68

Package Total Routines
Text Integration Utility 47 TIU169D    TIU182D1    TIU199    TIUEC112    TIUFA1    TIUFC1    TIUFD4    TIUFHA1
TIUFHA2    TIUFHA5    TIUFHA7    TIUFHLP    TIUFL    TIUFLD    TIUFLF4    TIUFT
TIUFT1    TIUFXHLX    TIUFZZ60    TIUHL7P2    TIUHSOBJ    TIUMAP    TIUP1008    TIUP1012
TIUP171P    TIUP242    TIUP246    TIUPI260    TIUPNCV6    TIUPR225    TIUPR230    TIUPS109
TIUPS112    TIUPS115    TIUPS137    TIUPS14    TIUPS148    TIUPS163    TIUPS165    TIUPS169
TIUPS17    TIUPS209    TIUPS225    TIUSROI1    TIUTPBN    TIUUPEDT    TIUWRII1    
IHS Mods To Text Integration Utilities 11 BTIUDDL    BTIUDOC    BTIUDSC    BTIUICL    BTIUODL    BTIUP1    BTIUP2    BTIUPOS
BTIUPOS3    BTIUPRE    BTIURPT    
Health Summary 6 GMTSCW    GMTSDS    GMTSDSB    GMTSPN    GMTSPNB    GMTSPNSL    
Authorization Subscription 1 USRP1001    
Consult Request Tracking 1 GMRCTIUE    
IHS Electronic Health Record 1 BEHOTIUI    
Registration 1 DG53P554    

Pointed To By FileMan Files, Total: 12

Package Total FileMan Files
Text Integration Utility 6 TIU DOCUMENT(#8925)[.01.04]    TIU DOCUMENT DEFINITION(#8925.1)[#8925.14(.01)]    TIU DIVISION PRINT PARAMETERS(#8925.94)[#8925.949999911(.01)]    TIU DOCUMENT PARAMETERS(#8925.95)[.01]    TIU PERSONAL DOCUMENT TYPE LIST(#8925.98)[.02.03#8925.9801(.01)]
TIU TEMPLATE(#8927)[.19]    
Registration 2 PRF LOCAL FLAG(#26.11)[.07]    PRF NATIONAL FLAG(#26.15)[.07]    
Authorization Subscription 1 USR AUTHORIZATION/SUBSCRIPTION(#8930.1)[.01]    
Health Summary 1 VA HEALTH SUMMARY TYPE(#142)[#142.14(.01)]    
IHS Changes To Scheduling 1 CHART DEFICIENCY(#9009016.4)[99]    
Patient Care Component 1 PCC MAN REPORTS VISIT SORT(#9001003.7)[999919]    

Pointer To FileMan Files, Total: 8

Package Total FileMan Files
Authorization Subscription 3 USR CLASS(#8930)[.06]    USR RECORD STATUS(#8930.6)[#8925.113(.04)]    USR ACTION(#8930.8)[#8925.113(.01)]    
Text Integration Utility 3 TIU DOCUMENT DEFINITION(#8925.1)[#8925.14(.01)]    TIU STATUS(#8925.6)[.07]    TIU VHA ENTERPRISE STANDARD TITLE(#8926.1)[1501]    
Kernel 1 NEW PERSON(#200)[.051503]    
VA Fileman 1 FILE(#1)[1.01]    

Fields, Total: 55

Field # Name Loc Type Details
.01 NAME 0;1 FREE TEXT
************************REQUIRED FIELD************************

  • 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^TIUFLF1(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 complex cross-reference by class and name will help optimize the title look-up for the GUI.
.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.
.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.
.04 TYPE 0;4 SET
************************REQUIRED FIELD************************
  • '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.
.05 PERSONAL OWNER 0;5 POINTER TO NEW PERSON FILE (#200) NEW PERSON(#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.
.06 CLASS OWNER 0;6 POINTER TO USR CLASS FILE (#8930) USR CLASS(#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.
.07 STATUS 0;7 POINTER TO TIU STATUS FILE (#8925.6) TIU STATUS(#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.
.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.
.1 SHARED 0;10 SET
  • '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
.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.
.12 HAS BOILTXT COMPUTED

  • MUMPS CODE:  S TIUFBTXT=$S($L($T(^TIUFLF)):$$HASBOIL^TIUFLF(D0,^TIU(8925.1,D0,0)),1:"UNKNOWN"),X=$S(TIUFBTXT:"YES",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:"YES",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.
.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
.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.
.15 PRF FLAG COMPUTED

  • 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.
1 UPLOAD DELIMITED ASCII HEADER ITEM;0 Multiple #8925.11 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)
1.01 UPLOAD TARGET FILE 1;1 POINTER TO FILE FILE (#1) 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.
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.
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.
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.
2 UPLOAD CAPTIONED ASCII HEADER HEAD;0 Multiple #8925.12 8925.12

  • 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.
3 BOILERPLATE TEXT DFLT;0 WORD-PROCESSING #8925.13

  • LAST EDITED:  APR 21, 1995
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.
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.
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:  @
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:  @
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:  @
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:  @
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:  @
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:  @
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:  @
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
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
4.8 UPLOAD FILING ERROR CODE 4.8;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 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:  @
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:  @
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
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
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
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
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
6.14 ALLOW CUSTOM FORM HEADERS 6.1;4 SET
  • '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
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:  @
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:  @
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
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
9 OBJECT METHOD 9;E1,245 MUMPS

  • INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
  • LAST EDITED:  MAR 10, 2004
  • 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.
  • TECHNICAL DESCR:  
    IHS/ITSC/LJF 9/4/2003: Removed write access set to @.  Since so many IHS sites do not have a programmer readily available, application coordinators need to update patient object code.
  • NOTES:  XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER
10 ITEM 10;0 POINTER Multiple #8925.14 8925.14
11 STAT AUTO PRINT EVENT 11;0 SET Multiple #8925.111 8925.111

  • 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.
12 ROUTINE AUTO PRINT EVENT 12;0 SET Multiple #8925.112 8925.112

  • 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.
13 PROCESSING STEPS 13;0 POINTER Multiple #8925.113 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.
14 DIALOG DIALOG;0 Multiple #8925.114 8925.114

  • DESCRIPTION:  
    This sub-file contains the data necessary to handle server-based definition for fixed-field data capture in TIU.
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.
1501 VHA ENTERPRISE STANDARD TITLE 15;1 POINTER TO TIU VHA ENTERPRISE STANDARD TITLE FILE (#8926.1) TIU VHA ENTERPRISE STANDARD TITLE(#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.
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.
1503 MAP ATTEMPTED BY 15;3 POINTER TO NEW PERSON FILE (#200) NEW PERSON(#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.
9003130.1 DESCRIPTION 9003130.1;0 WORD-PROCESSING #8925.90031301
Info |  Desc |  Directly Accessed By Routines |  Accessed By FileMan Db Calls |  Pointed To By FileMan Files |  Pointer To FileMan Files |  Fields |  All