Global: ^TIU(8925.1

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.

DELETE AUTHORITY:

1)= S ^TIU(8925.1,"B",$E(X,1,60),DA)=""

2)= K ^TIU(8925.1,"B",$E(X,1,60),DA)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This field is used to help identify indicators of the Patient Posting Type to which the Document Definition should be ascribed.

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.

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.

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.

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.

This field indicates whether or not a new entry can be created in the TARGET FILE for documents defined by this Document Definition.

This is the subscript of the word-processing field in the TARGET FILE, in which the body of the narrative report will be stored.

This field determines whether the filer will attempt to execute boilerplate logic for uploaded documents.  Not used in version 1.

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.

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.

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.

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:  @

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:  @

This M-Code is executed upon Release of the document.  Heritable.  TECHNICAL field.

WRITE AUTHORITY:  @

This M-Code is executed upon Verification of the document.  Heritable.  TECHNICAL field.

WRITE AUTHORITY:  @

This M-Code is executed upon Deletion of the document.  Heritable.  TECHNICAL field.

WRITE AUTHORITY:  @

This M-Code is executed when a document with a link to a client application is Reassigned.  Heritable.  TECHNICAL field.

WRITE AUTHORITY:  @

the designer of the application deems appropriate.

WRITE AUTHORITY:  @

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:  @

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:  @

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:  @

This M-Code is executed following Signature (or Cosignature) of a TIU document.  Heritable.  TECHNICAL field.

WRITE AUTHORITY:  @

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.

WRITE AUTHORITY:  @

field.  For more information on editing heritable fields, see Technical field Edit Template.

WRITE AUTHORITY:  @

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.

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.

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.

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.

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.

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.

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:  @

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:  @

Heritable.  TECHNICAL Field.  For information on editing heritable fields, see Technical Field Edit Template.

WRITE AUTHORITY:  @

information.

Heritable.  TECHNICAL field.  For information on editing heritable fields, see Technical field Edit Template.

WRITE AUTHORITY:  @

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.

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.

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.

See parameter STAT AUTO PRINT EVENT for 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.

This sub-file contains the data necessary to handle server-based definition for fixed-field data capture in TIU.

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.

This reference to the VHA ENTERPRISE STANDARD TITLE FILE provides for the mapping of local titles to the Enterprise Standard Titles.

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.

This is the date/time at which the user attempted to map the Local Title to a VHA Enterprise Title.

This is the person who attempted to map the Local Title to a VHA Enterprise Title.