The Master Data Model for Veteran Care

Developer Documentation » VDM » Tiu_Document_Definition-8925_1

TIU Document Definition (8925.1)

This file stores Document Definitions, which identify and define behavior for documents stored in the TIU DOCUMENTS FILE (#8925). For consistency with the V-file schema, it may be viewed as the “Attribute Dictionary” for the Text Integration Utilities. It also stores Objects, which can be embedded in a Document Definition’s Boilerplate Text (Overprint). Objects contain M code which gets a piece of data and inserts it in the document’s Boilerplate Text when a document is entered. Warning: objects embedded in boilerplate text are looked up by multiple index (i.e. DIC(0) contains ‘M’). Current code (see routine CHECK^TIUFLF3) checks all present indexes to make sure object names, abbreviations and print names are not ambiguous for this lookup. If new indexes are added, this code MUST BE UPDATED to check the new index as well. Some entries in this file are developed Nationally and exported across the country. Others are created by local sites. Entries in the first category are marked National Standard and are not editable by sites. This file does NOT allow multiple entries OF THE SAME TYPE with the same name. That is, within a given Type, there are no duplicate names. (This refers to the .01 field, the Technical name of the entry.) This file does not allow a parent to have items with the same name, even if the items have different internal file numbers (i.e. are different file entries). Again, this refers to the .01 Technical name of the entry. Because of ownership considerations, the file does NOT allow an entry to be an item under more than 1 parent. If the same item is desired under more than 1 parent, the item must be copied into a new entry. There is one exception: Document Definitions of Type Component which have been marked Shared may have more than one parent. The Document Definition Utility TIUF categorizes certain fields as Basic, Technical, or Upload, and displays these fields together as a group when user edits or views a Document Definition. BASIC fields include Name, Abbreviation, Print Name, Type, Personal Owner, Class Owner, Status, In Use, Shared, Orphan, Has Boiltxt, National Standard, OK to Distribute, and Suppress Visit Selection. TECHNICAL fields include Entry Action, Exit Action, Edit Template, Print Method, Print Form Header, Print Form Number, Print Group, Allow Custom Form Headers, Visit Linkage Method, Validation Method, and Object Method. UPLOAD fields include Upload Target File, Laygo Allowed, Target Text Field Subscript, Upload Look-up Method, Upload Post-Filing Code, Upload Filing Error Code, and multiples Upload Captioned ASCII Header and Upload Delimited ASCII Header. The Document Definition file contains extensive, detailed field descriptions. Likewise, some protocols (File 101) used in TIU have extensive and careful descriptions in the Protocol file. Many of these descriptions are used in TIU for online help. If it becomes necessary for a national programmer to edit these descriptions, the programmer should check to make sure all online help is still displayed properly. Users are expected to use the Document Definition Utility TIUF to enter, edit, and delete file entries. In fact, the file prohibits the deletion of entries through generic Fileman Options. It also prohibits the edit through generic Fileman of a few critical fields: Type, Status, Shared, and National Standard. Adding and Deleting (but not editing) Items is also prohibited through generic Fileman options. Abbreviation and Print Name of OBJECTS cannot be edited through generic Fileman Options. This does NOT imply that it is SAFE to use generic Fileman to edit other fields. Users are cautioned that edit through generic Fileman bypasses many safeguards built in to the Document Definition Utility and can create havoc unless the user THOROUGHLY UNDERSTANDS the File and its uses. If users find needs which are not met through TIUF, please communicate them to the TIU development team. ******* WARNING: Using generic Fileman options to edit entries can cause SERIOUS database problems. ******

Global: ^TIU(8925.1,

Domain: Non-Clinical

Properties

Label/Field Name Field # Description Datatype Attributes Range
Name
  name
.01 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.
STRING INDEXED
REQUIRED
 
Abbreviation
  abbreviation
.02 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.
STRING INDEXED  
Print Name
  print_name
.03 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.
STRING INDEXED  
Type
  type-_04
.04 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.
ENUMERATION INDEXED
REQUIRED
DOCUMENT CLASS: DC
OBJECT: O
COMPONENT: CO
CLASS: CL
TITLE: DOC
Personal Owner
  personal_owner
.05 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.
POINTER INDEXED New_Person-200
Class Owner
  class_owner
.06 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.
POINTER INDEXED Usr_Class-8930
Status
  status
.07 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.
POINTER INDEXED TIU_Status-8925_6
Shared
  shared
.1 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.
BOOLEAN   false: 0
true: 1
National Standard
  national_standard
.13 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.
BOOLEAN   false: 0
true: 1
Posting Indicator
  posting_indicator
.14 This field is used to help identify indicators of the Patient Posting Type
to which the Document Definition should be ascribed.
ENUMERATION INDEXED crisis note: C
warning: W
allergy/ADR: A
directive: D
Upload Delimited Ascii Header
  upload_delimited_ascii_header
1 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.
OBJECT   Upload_Delimited_Ascii_Header-8925_11
Upload Target File
  upload_target_file
1.01 ————-
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.
POINTER   File-1
Laygo Allowed
  laygo_allowed
1.02 This field indicates whether or not a new entry can be created in
the TARGET FILE for documents defined by this Document Definition.
BOOLEAN   false: 1
true: 0
Target Text Field Subscript
  target_text_field_subscript
1.03 This is the subscript of the word-processing field in the TARGET FILE, in
which the body of the narrative report will be stored.
STRING    
Boilerplate On Upload Enabled
  boilerplate_on_upload_enabled
1.04 This field determines whether the filer will attempt to execute
boilerplate logic for uploaded documents. Not used in version 1.
BOOLEAN   false: 1
true: 0
Upload Captioned Ascii Header
  upload_captioned_ascii_header
2 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.
OBJECT   Upload_Captioned_Ascii_Header-8925_12
Boilerplate Text
  boilerplate_text
3   STRING    
Ok To Distribute
  ok_to_distribute
3.02 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.
BOOLEAN   false: 0
true: 1
Suppress Visit Selection
  suppress_visit_selection
3.03 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.
BOOLEAN   false: 0
true: 1
Upload Look-up Method
  upload_lookup_method
4 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]).
STRING    
Commit Action
  commit_action
4.1 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.
STRING    
Release Action
  release_action
4.2 This M-Code is executed upon Release of the document. Heritable.
TECHNICAL field.
STRING    
Verification Action
  verification_action
4.3 This M-Code is executed upon Verification of the document. Heritable.
TECHNICAL field.
STRING    
Delete Action
  delete_action
4.4 This M-Code is executed upon Deletion of the document. Heritable.
TECHNICAL field.
STRING    
Package Reassignment Action
  package_reassignment_action
4.45 This M-Code is executed when a document with a link to a client
application is Reassigned. Heritable. TECHNICAL field.
STRING    
Upload Post-filing Code
  upload_postfiling_code
4.5 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.
STRING    
Entry Action
  entry_action
4.6 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.
STRING    
Exit Action
  exit_action
4.7 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.
STRING    
Upload Filing Error Code
  upload_filing_error_code
4.8 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).
STRING    
Post-signature Code
  postsignature_code
4.9 This M-Code is executed following Signature (or Cosignature) of a TIU
document. Heritable. TECHNICAL field.
STRING    
Edit Template
  edit_template
5 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.
STRING    
Print Method
  print_method
6 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.
STRING    
Print Form Header
  print_form_header
6.1 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.
STRING    
Print Form Number
  print_form_number
6.12 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.
STRING    
Print Group
  print_group
6.13 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.
NUMERIC    
Allow Custom Form Headers
  allow_custom_form_headers
6.14 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.
BOOLEAN   false: 0
true: 1
On Browse Event
  on_browse_event
6.5 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.
STRING    
On Retract Event
  on_retract_event
6.51 This is MUMPS code which is invoked on retraction of a document to perform
any processing task that the Requesting Package may require.
STRING    
Visit Linkage Method
  visit_linkage_method
7 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.
STRING    
Validation Method
  validation_method
8 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.
STRING    
Object Method
  object_method
9 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.
STRING    
Item
  item
10   OBJECT   Item-8925_14
Stat Auto Print Event
  stat_auto_print_event
11 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.
ENUMERATION   NONE: N
VERIFIED: V
AMENDED: AM
COSIGNED, REQUIRED: CSR
COSIGNED, OPTIONAL, INCOMPLETE: CSOINC
SIGNED: S
RELEASED: R
TRANSCRIBED: T
ADDENDUM ADDED: AD
COMLETED: CP
COSIGNED, OPTIONAL, COMPLETED: CSOCP
Routine Auto Print Event
  routine_auto_print_event
12 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.
ENUMERATION   NONE: N
VERIFIED: V
AMENDED: AM
COMPLETED: CP
COSIGNED, REQUIRED: CSR
COSIGNED, OPTIONAL, INCOMPLETE: CSOINC
CONSIGNED, OPTIONAL, COMPLETED: CSOCP
SIGNED: S
RELEASED: R
TRANSCRIBED: T
ADDENDUM ADDED: AD
Processing Steps
  processing_steps
13 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.
OBJECT   Processing_Steps-8925_113
Dialog
  dialog
14 This sub-file contains the data necessary to handle server-based definition
for fixed-field data capture in TIU.
OBJECT   Dialog-8925_114
Timestamp
  timestamp
99   STRING    
Vha Enterprise Standard Title
  vha_enterprise_standard_title
1501 This reference to the VHA ENTERPRISE STANDARD TITLE FILE provides for the
mapping of local titles to the Enterprise Standard Titles.
POINTER INDEXED TIU_Vha_Enterprise_Standard_Title-8926_1
Map Attempted
  map_attempted
1502 This is the date/time at which the user attempted to map the Local Title
to a VHA Enterprise Title.
DATE-TIME    
Map Attempted By
  map_attempted_by
1503 This is the person who attempted to map the Local Title to a VHA
Enterprise Title.
POINTER   New_Person-200

↑ Return to top

Sub-Files

Upload Delimited Ascii Header (8925.11)

ID
Upload_Delimited_Ascii_Header-8925_11

Properties

Label/Field Name Field # Description Datatype Attributes Range
Header Piece
  header_piece
.01 This is the number for this piece (item) of the header. Start with
number 1 for the first piece.
NUMERIC INDEXED
REQUIRED
 
Item Name
  item_name
.02 This is the name of the item in the ASCII message header. Item Name is
used in help messages for the person dictating a document.
STRING INDEXED  
Field Number
  field_number
.03 This is the field number in the target file which corresponds to this
header item.
STRING INDEXED  
Lookup Local Variable Name
  lookup_local_variable_name
.04 This field specifies the local variable name into which this piece of the
message header will be set. The local variable is used by the Look-Up
Method. For example, if this piece of the header is the patient social
security number, the Lookup Local Variable Name might be TIUSSN. The
social security number as written by the transcriptionist is first
transformed by any existing Transform Code, and then set into this
variable (e.g. TIUSSN) for use in Look-Up Method code.

Lookup Local Variable Name is necessary only if the information in this
piece is required in order to look up the appropriate entry in the target
file.
STRING INDEXED  
Example Entry
  example_entry
.05 This field is used to store sample data for this item in the form the
transcriptionist is expected to use when transcribing it. For example, if
a patient has Social Security Number 555-12-1212, and the transcriptionist
is expected to write 555-12-1212, then an Example Entry should have the
form 555-12-1212.

The Transform Code, if it exists, then transforms the transcribed Social
Security Number 555-12-1212 into the appropriate format for the target
file before using the Social Security Number to look-up the appropriate
target file entry and/or before entering it in the target file.
STRING    
Clinician Must Dictate
  clinician_must_dictate
.06 States whether or not this piece of the header should be dictated by the
Clinician. Will be used by the Clinician Help routine to determine if
this field should be shown as data that should be dictated. (Some pieces
can be entered by the transcriber without being dictated, such as the
transcriber identification).
BOOLEAN   false: 0
true: 1
Required Field?
  required_field
.07 This field is used to determine whether a given header piece is required
by the application (e.g., Author and Attending Physician may be required
for the ongoing processing of a Discharge Summary). Records lacking
required fields WILL be entered if possible into the target file but will
generate Missing Field Error Alerts.
BOOLEAN   false: 0
true: 1
Transform Code
  transform_code
1 This standard MUMPS code transforms the transcribed value of the header
piece into a format acceptable to FileMan (e.g., patient social security
number 555-12-1212 must be transformed to 555121212 or to whatever
(external) format FileMan accepts when a user edits the social security
number field in the target file).

Field values are transformed before being set into Special Lookup
Variables and before being set into Target Text File Fields.

Field is necessary only if transcribed piece is not in the format Fileman
accepts for the target file.
STRING    

↑ Return to top

Upload Captioned Ascii Header (8925.12)

ID
Upload_Captioned_Ascii_Header-8925_12

Properties

Label/Field Name Field # Description Datatype Attributes Range
Caption
  caption
.01 NOTE: Users can choose between two possible kinds of Upload Record
Headers: Captioned or Delimited. Captioned headers should be used UNLESS
the site has a way to generate upload headers automatically.

CAPTION is the caption which the transcriber enters into the captioned
upload record header immediately preceeding the item data. It serves to
distinguish one item of data from the next. Example: PATIENT NAME
STRING INDEXED
REQUIRED
 
Item Name
  item_name
.02 This is the name of the item in the ASCII message header. Item Name is
used in help messages for the person dictating a document.
STRING INDEXED  
Field Number
  field_number
.03 This is the FIELD # in the target file which corresponds to this header
item and where this item of data will be stored.
STRING INDEXED  
Lookup Local Variable Name
  lookup_local_variable_name
.04 This field specifies the local variable name into which this item of the
upload header will be set. The local variable is used by the Look-Up
Method. For example, if this item of the header is the patient social
security number, the Lookup Local Variable Name might be TIUSSN. The
social security number as written by the transcriptionist is first
transformed by any existing Transform Code, and then set into this
variable (e.g. TIUSSN) for use in Look-Up Method code.

Lookup Local Variable Name is necessary only if the information in this
piece is required in order to look up the appropriate entry in the target
file.
STRING INDEXED  
Example Entry
  example_entry
.05 This field is used to store sample data for this item in the form the
transcriptionist is expected to use when transcribing it. For example, if
a patient has social security number 555-12-1212, and the transcriptionist
is expected to write 555-12-1212, than an Example Entry should have the
form 555-12-1212.

The Upload needs to know the exact form the transcriptionist is expected
to use in case it needs to transform it to make it acceptable to FileMan.
In this case, the transcriptionist also needs to know the exact form.
STRING    
Clinician Must Dictate
  clinician_must_dictate
.06 States whether or not this item should be dictated by the Clinician. Will
be used by the Clinician Help routine to determine if this field should be
shown as data that should be dictated. (Some items can be entered by the
transcriber without being dictated, such as the transcriber
identification).
BOOLEAN   false: 0
true: 1
Required Field?
  required_field
.07 This field is used to determine whether a given header item is required
by the application (e.g., Author and Attending Physician may be required
for the ongoing processing of a Discharge Summary). Records lacking
required fields WILL be entered into the target file, if possible, but
will generate Missing Field Error Alerts.
BOOLEAN   false: 0
true: 1
Transform Code
  transform_code
1 This standard MUMPS code transforms the transcribed value of the header
item into a format acceptable to FileMan (e.g., patient social security
number 555-12-1212 must be transformed to 555121212 or to whatever
(external) format FileMan accepts when a user edits the social security
number field in the target file).

Field values are transformed before being set into Special Lookup
Variables and before being set into target file fields.

Field is necessary only if transcribed item is not in the format Fileman
accepts for the target file.
STRING    

↑ Return to top

Item (8925.14)

ID
Item-8925_14

Properties

Label/Field Name Field # Description Datatype Attributes Range
Item
  item
.01 Items are themselves Document Definitions. The Type of the parent entry
determines what Types of items it has. A parent entry of type Class has
items of type Class or Document Class. A Document Class entry has items
of type Title. If a Title entry has more than a single section, it has
items of type Component. Components may also be multi-section with items
of type Component. Objects do not have items.
POINTER INDEXED
REQUIRED
Tiu_Document_Definition-8925_1
Mnemonic
  mnemonic
2 Item Mnemonic is a handle by which to select Classes/Document Classes from
a menu. 1-4 characters long. Mnemonic is usually numeric with the same
value as the Sequence. Alpha mnemonics are permitted if preferred.
STRING    
Sequence
  sequence
3 Item Sequence, if entered, determines item’s order under its parent. If
items have no sequence, item order is alphabetic by item Menu Text.
Sequence must be between .01 and 999.
NUMERIC INDEXED  
Menu Text
  menu_text
4 Item Menu Text is the short name users will see for Classes and Document
Classes when selecting them from 3-COLUMN MENUS. Document Definitions are
selected from 3-column menus when viewing documents across many patients
and when viewing many kinds of documents at the same time (e.g. Progress
Notes and Discharge Summaries).

To edit the Menu Text of a Document Definition, you must be viewing the
Document Definition as an ITEM of its PARENT. Select ‘Detailed Display’
for the PARENT and then ‘Items’.

Menu Text has 1 - 20 characters. Menu Text must not begin with a space or
with ‘All’. The Document Definition Utility TIUF automatically sets the
Item Menu Text to the first 20 characters of the Item’s Name when an entry
is first added as an item. (If an entry’s Name begins with ‘All’ its Menu
Text is given ‘AlX’ as its first 3 characters.) The utility does NOT
update Menu Text if the entry Name is later changed, since this would
overwrite what a site may have carefully set up. Menu Text is required.

Menu Text can affect item order under a parent since order is alphabetic
by menu text if items do not have sequence numbers.
STRING REQUIRED  

↑ Return to top

Processing Steps (8925.113)

ID
Processing_Steps-8925_113

Properties

Label/Field Name Field # Description Datatype Attributes Range
Processing Step
  processing_step
.01 This is a step or action (e.g., verification) in the processing of a document
that moves it from one state (e.g., unverified) to another (e.g., unsigned).
POINTER INDEXED
REQUIRED
Usr_Action-8930_8
Sequence
  sequence
.02 This is the serial sequence in the processing of the document in which the
current step should ordinarily occur. This field is only necessary when the
process in question must occur in a particular sequence (e.g., to insure
that a document is always released from draft before it is verified).
NUMERIC    
Required?
  required
.03 This field specifies whether the step is required or optional for completion
of the document (e.g., Dictation and transcription is the typical means by
which Discharge Summaries are acquired, but they may be entered directly by
the provider, if preferred).
ENUMERATION   REQUIRED: 1
OPTIONAL: 0
Resulting Status
  resulting_status
.04 This is the status of the document following completion of the step in
question. For instance, if a discharge summary is to be registered as
unsigned following verification, this would be indicated in the RESULTING
STATUS field.
POINTER   Usr_Record_Status-8930_6
Condition Text
  condition_text
.05   STRING    

↑ Return to top

Dialog (8925.114)

ID
Dialog-8925_114

Properties

Label/Field Name Field # Description Datatype Attributes Range
Prompt
  prompt
.01 This is the prompt with which the user will be presented during interactive
entry of the document.
STRING INDEXED
REQUIRED
 
Item Name
  item_name
.02 This is a descriptive name for the datum which will help descibe the prompt
for the user.
STRING    
Sequence
  sequence
.03 This is the sequence of the prompt within the dialog. On the Windows Client
this will correspond with the Tab Order Property of the prompt.
NUMERIC INDEXED  
Field
  field
.04 This is the field in the target file in which the user’s response will be
stored.
STRING    
Required
  required
.05 Please indicate whether a response to this prompt is required, in order to
complete the dialog.
BOOLEAN   false: 0
true: 1
Visible
  visible
.06 This field specifies whether a given datum will be prompted for, or
“stuffed,” based on execution of the SET METHOD for a given prompt.
BOOLEAN   false: 1
true: 0
Set Method
  set_method
1 This is the mumps code for determining the default value of an interactive
(“visible”) prompt, and for setting the value to be non-interactively
“stuffed” on invokation of an “invisible” prompt. Regardless of the
syntactic approach (e.g., subroutine or extrinsic function, the return
value of the method should be placed in the local varible X.
STRING    
Windows Control
  windows_control
101 Stores the type of Windows control necessary to get the data for this
prompt.
ENUMERATION   SimpleList: 2
Edit: 3
Memo: 4
LongList: 1
Api Name
  api_name
102 This is the API that should be called by the broker when the control is
used. How the API is used varies with the control. Examples are:
filling list boxes, getting boilerplate text, etc.
STRING    
Api Parameter #1
  api_parameter_number1
103 A parameter that is used by the API may be stored here. STRING    
Windows Condition
  windows_condition
113 This is silent code which is executed when building the dialog for
Windows. It identifies which prompts should be included in the dialog.
The condition should leave $T failse if the prompt should not be asked.
STRING    
Windows Default
  windows_default
117 This code should silently set the default value of a prompt when it is
selected.
STRING    

↑ Return to top


Document generated on August 31st 2017, 2:55:41 pm