The CHCS FileMan input routines (^DIE and ScreenMan) recognize a kind of Data Dictionary structure not found in DHCP FileMan. This is the "Group Cross-reference". The novel Global structure characteristic of a Group Cross-Reference looks like:
^DD(Filenumber,0,"GRIX",Groupname) = Routineref
where "Groupname" is the name of a Field Group, found in the same File under
^DD(Filenumber,"GR",Groupname)
The presence of a Group Cross-reference tells FileMan/ScreenMan to invoke the "Routineref" whenever any Fields in the "Groupname" have been edited, with the old and new values stored in a temporary MUMPS local array. The code specified by "Routineref" is invoked before the data is actually filed, while the user is still editing.
Portability Effect: SERIOUS Since DHCP FileMan (Version 20) has no equivalent feature, it would be difficult to port a CHCS File containing Group Cross-references to a DHCP environment with assurance that data entry to such a File would be consistent in both systems. Certainly, some re-programming would be necessary. Probably, the programmer would have to add individual Cross-references that tried to perform the work of the Group Cross-references, but because of synchronization problems, this could be a tricky job. Fortunately, later versions of DHCP FileMan may well include an equivalent functionality. Fortunately, too, a search of the current CHCS system shows only two Files (the PATIENT File, number 2, and the PROVIDER File, number 6) that contain Group Cross-references. Since Group Cross-references must be created "by hand", rather than through use of a Utility Function, it is thus unlikely that they will be in wide use in CHCS any time soon.
In both CHCS and DHCP FileMan, there is a Global node which, if set, names a MUMPS routine to be associated with the lookup into a particular File. Generally, the ^DIC routine will transfer control to that routine, if it exists. CHCS FileMan stores the name of this routine, if it exists, preceded by the '^' character, in
^DIC(filenumber,0,"ROU")
whereas DHCP FileMan stores the equivalent routine name, without the '^' character, in
^DD(filenumber,0,"DIC")
Portability Effect: SERIOUS. If a DHCP File with a "DIC" node were transported to CHCS, the "DIC" node would be ignored, and the results would be, in general, unpredictable. The workaround is apparently simple: a programmer should just take any routine name found in
^DD(filenumber,0,"DIC")
and put it, with a prefixed '^', into
^DIC(filenumber,0,"ROU")
Unfortunately, VA FileMan allows calls to the ^DIC lookup routine to ignore such a special routine name, if the call is made in a certain way (the DIC(0) variable containing "I"). This means that any application code ported along with such a "special lookup file" would need to be vetted by a programmer for every call to ^DIC. If a call to ^DIC is found where the input parameter string contains an "I", then that call would need to be re-considered.
CHCS FileMan offers the developer a way to insure that every lookup value used by ^DIC to select an Entry from a particular File be first pre-processed. For example, such processing logic can convert all lower-case input characters to upper-case. The developer stores such "pre-lookup" code in the Global node
^DD(filenumber,0,"PRELK")
The MUMPS code stored here takes the input variable 'X', and (possibly) transforms it to a different value.
Portability Effect: Requires conversion. Fortunately, there is in DHCP FileMan a documented (but almost never used) Global node,
^DD(filenumber,.01,7.5)
to which CHCS "pre-lookup" code can be moved. A bit of re-programming is required in making this conversion, but it is straightforward.
Whereas CHCS needed a good way of pre-processing input to ^DIC, DHCP decided it need a post-processing capability for lookup. Accordingly, DHCP FileMan stores an optional string of MUMPS code in
^DD(filenumber,0,"ACT")
which, when present, acts as a kind of "post-screening" logic every time an Entry in the File is selected by the ^DIC process. CHCS has no equivalent.
Portability Effect: Reqires conversion. If a DHCP File with an "ACT" node were transported to CHCS, the "ACT" would be ignored, and the results would be, in general, unpredictable. To work around this incompatibility, a programmer could create a 'special lookup program' for the File that looks like:
DO ^DIC IF Y<0 QUIT
DO
.(Here insert the "ACT" string of code)
QUIT
DHCP FileMan allows executable MUMPS code to be inserted into the nodes
^DD(filenumber,.01,"LAYGO",ix,0)
where ix is an index. Each such node is executed to set the MUMPS $T switch before an entry in the file to be added. CHCS has no equivalent.
Portability Effect: Requires conversion. If a DHCP File with "LAYGO" nodes were transported to CHCS, these nodes would be ignored as new Entries in the File were "LAYGO"ed, and the result would be, in general, unpredictable. A possible workaround might be to create a "Special lookup" routine for such a File.
CHCS FileMan uses the existence of the node
^DD(Filenumber,0 "COPY")
to decide whether the "Transfer" option is allowed to move data from the file specified by 'Filenumber' to some other File. DHCP FileMan has no similar check.
Portability Effect: Uncertain. A straightforward, automatic addition of the "COPY" node to any File ported to CHCS is recommended. (The value of the "COPY" node could simply be set equal to the value of the File's "DD" node.) Without the security protection of this node, a File could easily be inappropriately "cloned" by a naive CHCS FileMan user.
Both CHCS FileMan and DHCP FileMan allow DATE, SET, POINTER, FREE-TEXT, VARIABLE-POINTER, NUMERIC, and MUMPS Fields to be marked as "UNEDITABLE" by the Utility Option called "UNEDITABLE DATA". For consistency, CHCS FileMan also allows Word-Processing Fields to be so marked. In the Data Dictionary structure, an 'Uneditable' Word-Processing Field will characteristically have a Specifier of "WI" or "WLI", as in
^DD(1003.01,0) = TEXT SUB-FIELD^^.01^1
.
.
^DD(1003.01,.01,0) = TEXT^WI^^0;1
Portability Effect: SERIOUS A CHCS developer may designate a Word-Processing Field as 'UNEDITABLE'. This designation would be ignored if the Field were ported to a DHCP environment, and hence the anticipated FileMan security feature of uneditability would be lost. To rectify this might require a great deal of reprogramming, such that every Input Template or ^DIE call involving the uneditable Field might need to be re-worked. Fortunately, an automatic program could easily search for Global node
^DD(n,.01,0)
that contained both "W" and "I" in it second "^"-piece. Also fortunately, there are unlikely to be many such uneditable Word-Processing Fields in a typical application.
CHCS FileMan supports a Data Dictionary structure, used as part of the data input verification process, called Consistency Checks. Any CHCS FileMan Field can have associated with it one or more such "checks", stored dependent from
^DD(Filenumber,fieldnumber,6)
Whenever data for such a Field is entered or changed, this checking logic is invoked. The logic is thus an extension, one could say, of the Field's Input Transform. Unlike the Input Transform, though, it can be written by a user in 'Computed Field' notation, rather than in MUMPS.
By way of example, here is one such Consistency Check, as it appears in the CHCS database for the ADMISSION DATE multiple date:
^DD(2.95,.01,6,1,0) = Not after discharge
^DD(2.95,.01,6,1,1) = ADMISSION DATE'>DISCHARGE DATE
^DD(2.95,.01,6,1,5,1,0) = 2.95^1.01
^DD(2.95,.01,6,1,9) = S X=1 I DIJF(1.01)]"" S X=DIJF'>DIJF(1.01)
The first of these four nodes contains the developer's English-language explanation of what the Check is requiring for valid data entry into Field .01 of (sub-)File 2.95. The second node shows how the developer wrote this Check as a Boolean-valued Computed-Field expression, using the name of the Field itself ("ADMISSION DATE") and also the name of some other field ("DISCHARGE DATE"). The third node indicates the Data Dictionary location of the other field, and the fourth and last node is the MUMPS code that FileMan generated from the developer's "ADMISSION DATE'>DISCHARGE DATE"; this MUMPS code is run at data entry time to set the MUMPS variable 'X' to either '1' or '0'. Any Consistency Check setting 'X' to '0' has the effect of prohibiting the data entry.
Remembering that a FileMan Field's general characteristics are described by a coded "Specifier", the 2nd "^"-piece of the Field's zero node, it should also be mentioned that the Specifier of a CHCS Field that has Consistency Checks includes a special "K" parameter that is not found in DHCP Field Specifiers.
Portability Effect: Requires Conversion. DHCP FileMan would ignore CHCS Consistency Checks on a Field, and therefore would allow erroneous input in a ported application. It would be a straightforward matter, however, to add code to the Input Transform of any such Field. The code would invoke some program into which the CHCS Consistency-check code (from 'node 9') had been inserted.
DHCP FileMan allows auditing on a field-by-field basis, and correspondingly includes in any audited Field:
^DD(filenumber,fieldnumber,"AUDIT")
and
^DD(filenumber,fieldnumber,"AX")
to designate the types of auditing, and executable code to determine if auditing is on or off.
CHCS FileMan allows auditing on a File-by-File basis, and correspondingly flags an audited File with
^DIC(Filenumber,0,"DIET")=12
DCHP uses the Globals ^DIA and ^DIAR(1.11) for its auditing process, whereas CHCS uses ^DIAU and ^DIET.
Portability Effect: Uncertain. The two systems are incompatible in respect to auditing, but this is not a great portability concern, since the question of what is audited is usually a site-specific system management issue, rather than something addressed by application design. However, to insure that applications do not "count on" auditing, DHCP application code ported to CHCS would have to be searched for the occurrence of references to "^DIA" or "^DIAR(1.1", while CHCS application code ported to DHCP would have to be searched for the occurrence of references to "^DIET" or "^DIAU".
DHCP FileMan allows defining a "KWIC" (Key Word In Context) cross-reference so that values cross-referenced will be 'split' by some character other than the 'space' character. Thus a value like "FRACTURE,TIBIA" could generate cross-reference values of "FRACTURE" and "TIBIA" if "parsed by comma".
Portability Effect: Nil. This small enhancement to DHCP FileMan is actually portable back to CHCS systems, since once the KWIC cross-reference code exists, it is executed at the same points in both systems. One small step might be taken to insure that CHCS FileMan properly treats a DHCP KWIC cross-reference: a programmer could replace the letters "KWIC" with the letters "MUMPS" in the node
^DD(filenumber,fieldnumber,1,ix,0)
corresponding to the 'ix'th KWIC cross-reference of a field, if that cross-reference can be seen to be parsing on a character other than the 'space' character.
DHCP FileMan allows defining a "Screen" for a SET field, as well as for a POINTER field. The Global structure of a "screened SET" Field is isomorphic to that of a "screened POINTER", and its Specifier (second "^"-piece of the zero node of the Field) similarly contains an asterisk (*).
Portability Effect: Requires conversion. A 'screened' SET field transported to a CHCS system would be seen by that system's FileMan as a regular, un-screened SET field. Users on CHCS would therefore be allowed to make illegal input to such a Field. If the 'screening logic' is really essential to the application, the only apparent fix to this incompatibility would be to change the "SET" to a "FREE-TEXT" field, with appropriate stringent Input and Output Transforms.
DHCP FileMan stores an optional 'Technical Description' of any Field dependent from node
^DD(Filenumber,fieldnumber,23)
CHCS FileMan has no equivalent word-processing field.
Portability Effect: Nil. Does not impact portability of functionality, since DHCP FileMan only uses this field for documentation (in Data Dictionary listings).
CHCS FileMan stores two optional free-text fields in nodes
^DD(Filenumber,fieldnumber,27)
and
^DD(Filenumber,fieldnumber,28)
as external documentation of the Field. DHCP FileMan has no corresponding fields.
Portability Effect: Nil. Does not impact portability of functionality, since CHCS FileMan only uses these fields for documentation.
CHCS FileMan also stores an optional SET-type field in
^DD(Filenumber,fieldnumber,29)
which flags the "archive status" of the field to the CHCS archiving system. DHCP handles archiving differently.
Portability Effect: Nil. Should not impact portability. A CHCS File ported to DHCP might include such 'archive flags', but DHCP FileMan would ignore them. This would be appropriate, since it would be expected that different archive arrangements would be made for such Files in a 'DHCP world'.
Contrary to current CHCS documentation (in the Manual designated "TC-4-0130C"), CHCS FileMan stores previous lookup values for a given user in the Global ^DIJUSV, whereas DHCP FileMan stores such values in ^DISV.
Portability Effect: Uncertain. This difference should not imply any portability problem, since the ^DISV/^DIJUSV Global is handled at run time, and its contents would not be transported. In both systems the subscripting is identical, i.e. by 'DUZ' user number, so that there is no user-interaction discrepancy between the two systems. As usual, however, a programmer may have made explicit reference, for some special purpose, to the Global. Therefore, CHCS packages ported to DHCP should have all occurrences of "^DIJUSV" replaced by "^DISV", and DHCP packages should have all occurrences of "^DISV" replaced by "^DIJUSV".
As will be explained in Section VII, below, CHCS screen-entry is based on Input Templates. There is one node in the Input Template global, ^DIE, which is used by CHCS ScreenMan. This is the so-called "check" node -- the second-level subscript "CHK".
CHCS screens are able to invoke "Check" logic at the moment between the last user input (a "YES" answer to the "OK TO FILE?" question) and the actual filing of the Template data. This "Pre-filing logic" can examine data values in the temporary local "DG" array, and can abort the filing of data by setting the local variable "Y". The programmer stores the Entryref to this MUMPS code within the Template "by hand":
^DIE(Templatenumber,"CHK",1,Filenumber) = Entryref
Thus, for example, we find in the CHCS application suite
^DIE(215,"CHK",1,101) = AYCHK^ORLAB4
This means that when a user is done entering data for Template number 215 (which edits File 101), the subroutine AYCHK^ORLAB will be invoked to "Check" that data.
Portability effect: Requires conversion. "CHK" logic is equivalent to the "Data Validation" property of a DHCP ScreenMan form, but the CHCS MUMPS code would need to be re-written if ported to DHCP. For example, instead of setting "Y", DHCP code would want to set the "DDSERROR" variable, and so on. The general problem of porting ScreenMan design from one system to the other will be treated (pessimisticly) in Section VII. below. Conversion of "CHK" code is only a tiny part of that larger problem.
1. Special lookup nodes need to be moved from
^DD(filenumber,0,"DIC")
to
^DIC(filenumber,0,"ROU")
and all application code associated with that filenumber needs to be examined for calls to ^DIC with the DIC(0) parameter containing an "I".
2. Any File containing nodes dependent from
^DD(filenumber,.01,"LAYGO")
need to be carefully examined by a programmer to devise a workaround.
3. Files should be transported 'unaudited', and application code referring to ^DIA or ^DIAR(1.11) needs to be reworked.
4. Post-Action "ACT" nodes need to be handled, possibly by building a special lookup routine.
5. "COPY" nodes need to be inserted into every ported DHCP File.
6. Screened SET fields need to be handled.
7. In application code associated with the ported Files, any occurrences of "^DISV" need to be replaced by "^DIJUSV".
1. Special lookup nodes need to be moved from
^DIC(filenumber,0,"DIC")
to
^DD(filenumber,0,"ROU")
2. "Pre-lookup" nodes need to be modified and moved from
^DD(filenumber,0,"PRELK") to
^DD(filenumber,.01,7.5)
3. For any Word-Processing Fields flagged as 'UNEDITABLE', re-programming needs to be considered.
4. For any Fields containing Consistency Checks, code needs to be inserted into the Field's Input Transform to effect the same checks.
5. Files should be transported 'unaudited', and application code referring to ^DIET or ^DIAU needs to be reworked.
6. In application code associated with the ported Files, any occurrences of "^DIJUSV" need to be replaced by "^DISV".