Difference between revisions of "Language File (.85)"

From VistApedia
Jump to: navigation, search
(Improvements in Medsphere Fileman)
(Problems with Existing Architecture)
Line 355: Line 355:
  
 
=== Problems with Existing Architecture ===
 
=== Problems with Existing Architecture ===
 +
 +
The problems with the architecture before WorldVistA EHR 2.0 were these:
 +
 +
1) First, the Patient file needs to point to the Language file, but it did not.
 +
 +
2) Second, Chris Richardson rightly concluded that although phase one meaningful use only requires a single field to record preferred language, to be truly useful it should also include a multiple that records all the languages the patient knows, separately including how well they read, write, and speak the language. Communicating with non-English-speaking people can often require round-about methods; after all, what if no one in the hospital speaks a patient's preferred language? If someone happens to speak an additional language they speak, you can still communicate with them. Likewise, some speakers of different dialects of Chinese cannot communicate through speech but can understand each other perfectly in writing. Tracking all three sets of skills for all languages a patient can speak is essential to maximizing the chances of communication, which is the spirit of this phase one meaningful use goal. The existing file also lacked such a subfile.
 +
 +
3) The main options used to edit and report patient demographics did not include these new fields.
 +
 +
4) The Language file itself contained only eleven languages. It needed its contents to be massively upgraded.
 +
 +
5) Although users refer to language by name, software prefers to refer to language by unique codes. Although such coding systems exist for languages, the existing data dictionary included no such coding fields.
 +
 +
6) Coding systems change over time. Tying a permanent hub file like Language to a specific generation of codes makes it impossible to keep track of changes to those codes over time. Some other file would be needed to keep track of the language codes themselves
 +
 +
7) The biggest problem with the existing file dates back to the decision to include Arabic. To make it easy to make Arabic language #10, the team made the key of the file be the record's internal entry number. When VA broke up the File Manager team, it de facto converted this temporary expediency into the permanent condition of the file, with the file's scaffolding released into production. The result is that pointers to the Language file from other files do not resolve as the name of the language but as its number, making it nearly useless to end users and meeting neither the spirit nor the letter of the phase one meaningful use goal.
  
 
=== Solutions in Language File Version 2 ===
 
=== Solutions in Language File Version 2 ===

Revision as of 23:46, 27 December 2011

What is the Language File Version 2?

back: VistA_Meaningful_Use_Enhancements

Meaningful-use Requirement

Stage one of meaningful use include a core objective that users be able to record demographic information, including preferred language, gender, race, ethnicity, date of birth, and date and preliminary cause of death in the event of mortality in the eligible hospital. Stage one includes a corresponding core measure that more than 50% of all unique patients seen by the eligible professional (EP) or admitted to the eligible hospital (EH) have demographics as recorded structured data.

Here is the precise wording about these core objectives from the Federal Register, Vol. 75, No. 8, Wednesday, January 13, 2010, Rules and Regulations:

"C. Standards, Implementation Specifications, and Certification Criteria Processes Before and After the HITECH Act . . .

"2. HITECH Act Requirements for the Adoption of Standards, Implementation Specifications, and Certification Criteria . . .

"Once the National Coordinator accepts a recommendation for the priority order of standards, implementation specifications, and certification criteria, such priorities will be communicated to the HIT Standards Committee to guide its work. The HIT Policy Committee is charged with making recommendations in at least the following eight areas as specified in section 3002(b)(2)(B) of the PHSA: . . .

"(7) The use of electronic systems to ensure the comprehensive collection of patient demographic data, including, at a minimum, race, ethnicity, primary language, and gender information;

". . .

"TABLE 1—CERTIFICATION CRITERIA . . .

"Proposed meaningful use Stage 1 objectives: Record demographics [4] [5]

"Certification criteria to support the achievement of meaningful use Stage 1 by eligible professionals: Enable a user to electronically record, modify, and retrieve patient demographic data in- cluding preferred language, insurance type, gender, race, ethnicity, and date of birth.

"Certification criteria to support the achievement of meaningful use Stage 1 by eligible hospital: Enable a user to electronically record, modify, and retrieve patient demographic data in- cluding preferred language, insurance type, gender, race, ethnicity, date of birth, and date and cause of death in the event of mortality.'

"[4] For eligible professionals the full proposed meaningful use Stage 1 objective is: 'record demographics: preferred language, insurance type, gender, race, ethnicity, date of birth.'

"[5] For eligible hospitals the full proposed meaningful use Stage 1 objective is: 'record demographics: preferred language, insurance type, gender, race, ethnicity, date of birth, date and cause of death in the event of mortality.'

". . .

"§ 170.304	Specific certification criteria for Complete EHRs or EHR Modules designed for an ambulatory setting.

"The Secretary adopts the following certification criteria for Complete EHRs or EHR Modules designed to be used in an ambulatory setting. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically and in accordance with all applicable standards and implementation specifications adopted in this part: . . .

"(c) Record demographics. Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, insurance type, gender, race, ethnicity, and date of birth.

". . .

"§ 170.306	Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.

"The Secretary adopts the following certification criteria for Complete EHRs or EHR Modules designed to be used in an inpatient setting. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically and in accordance with all applicable standards and implementation specifications adopted in this part: . . .

"(b) Record demographics. Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, insurance type, gender, race, ethnicity, date of birth, and date and cause of death in the event of mortality."

Prior to WorldVistA EHR 2.0, VISTA did not include anything like a preferred language field attached to patients, nor did it include the necessary options to set or modify it. This part of the project was about resolving this deficiency to help WorldVistA EHR 2.0 become a certified EHR hospitals could use to meet meaningful use stage one.

Architectural Base

VISTA has included a Language file (#.85) since the release in the mid 1990s of version 21 of the File Manager (aka Fileman) package. Fileman 21 included numerous features designed to introduce true multi-lingual capabilities into VISTA. The Fileman team at the time intended to follow this up with further enhancements in the subsequent versions of Fileman and to assist the primary-development teams responsible for all other VISTA packages in shifting to this new internationalization framework. Unfortunately, their work was interrupted when the U.S. Department of Veterans Affairs (VA) chose to break up the File Manager development team, leaving VISTA database development at a crawl for the subsequent fifteen years. As a result, there was a Language file to build from for this WorldVistA EHR 2.0 project, but it was far more rudimentary than it was intended to be by its designers.

The first version of the Language file was created by Marcus Werners, who at the time was the technical lead for the VISTA implementation at the German Heart Institute of Berlin. He was motivated by the problem of having to repeatedly translate new versions of VISTA packages into German. He spent his multi-week annual vacation one year in the mid-1990s working side by side with the File Manager team in San Francisco to develop File Manager's internationalization framework, including the design of this file. The other members of the team were Maureen Hoye, Tami Winn, Danila Manapsal, Michael Ogi, Don Creaven, David LaLiberte, and Rick Marshall, all of whom were involved in the brainstorming sessions with Mr. Werners, though the principal design work was his.

Existing File's Data Dictionary

Here is the data dictionary of the existing Language file presented three ways: first, a global map that shows where the data is stored in MUMPS; second, a condensed listing that summarizes the fields; and finally a standard listing that includes all the details about the file definition:

GLOBAL MAP DATA DICTIONARY #.85 -- LANGUAGE FILE             12/27/11    PAGE 1
STORED IN ^DI(.85,  (11 ENTRIES)   SITE: VISTA Forum   UCI: LIVE,FORUM (VERSION 22.0)   
-------------------------------------------------------------------------------
The LANGUAGE file is used both to officially identify a language, and to store
MUMPS code needed to do language-specific conversions of data such as dates and
numbers.  VA FileMan currently distributes only the English language entry for
this file (entry number 1).  This code is currently available for use only
within VA FileMan.  A pointer to this file from the TRANSLATION multiple on the
DIALOG file also allows non-English text to be returned via FileMan calls.  

CROSS REFERENCED BY: ID NUMBER(B), NAME(C)

^DI(.85,D0,0)= (#.01) ID NUMBER [1N] ^ (#1) NAME [2F] ^ 
^DI(.85,D0,20.2)= (#20.2) DATE INPUT [E1,245K] ^ 
^DI(.85,D0,CRD)= (#10.3) CARDINAL NUMBER FORMAT [E1,245K] ^ 
^DI(.85,D0,DD)= (#10.2) DATE/TIME FORMAT [E1,245K] ^ 
^DI(.85,D0,FMTE)= (#10.21) DATE/TIME FORMAT (FMTE) [E1,245K] ^ 
^DI(.85,D0,LC)= (#10.5) LOWERCASE CONVERSION [E1,245K] ^ 
^DI(.85,D0,MSCISO)= (#21400) CODE [1F] ^ 
^DI(.85,D0,ORD)= (#10.1) ORDINAL NUMBER FORMAT [E1,245K] ^ 
^DI(.85,D0,TIME)= (#10.22) TIME [E1,245K] ^ 
^DI(.85,D0,UC)= (#10.4) UPPERCASE CONVERSION [E1,245K] ^ 
CONDENSED DATA DICTIONARY---LANGUAGE FILE (#.85)UCI: LIVE,FORUM   VERSION: 22.0
STORED IN: ^DI(.85,                                       DEC 27,2011 PAGE 1
--------------------------------------------------------------------------------
                                                 FILE SECURITY
                                  DD SECURITY    : ^     DELETE SECURITY: ^
                                  READ SECURITY  :       LAYGO SECURITY : ^
                                  WRITE SECURITY : ^
CROSS REFERENCED BY:
      ID NUMBER(B)  NAME(C) 

                                FILE STRUCTURE
FIELD     FIELD
NUMBER    NAME

.01       ID NUMBER (RNJ10,0X), [0;1]
1         NAME (RF), [0;2]
10.1      ORDINAL NUMBER FORMAT (K), [ORD;E1,245]
10.2      DATE/TIME FORMAT (K), [DD;E1,245]
10.21     DATE/TIME FORMAT (FMTE) (K), [FMTE;E1,245]
10.22     TIME (K), [TIME;E1,245]
10.3      CARDINAL NUMBER FORMAT (K), [CRD;E1,245]
10.4      UPPERCASE CONVERSION (K), [UC;E1,245]
10.5      LOWERCASE CONVERSION (K), [LC;E1,245]
20.2      DATE INPUT (K), [20.2;E1,245]
STANDARD DATA DICTIONARY #.85 -- LANGUAGE FILE               12/27/11    PAGE 1
STORED IN ^DI(.85,  (11 ENTRIES)   SITE: VISTA Forum   UCI: LIVE,FORUM (VERSION 22.0)   

DATA          NAME                  GLOBAL        DATA
ELEMENT       TITLE                 LOCATION      TYPE
-------------------------------------------------------------------------------
IDENTIFIED BY: NAME (#1)[R]

POINTED TO BY:
              LANGUAGE field (#.01) of the TRANSLATION sub-field (#.847) of 
                  the DIALOG File (#.84) 
              LANGUAGE field (#200.07) of the NEW PERSON File (#200) 
              DEFAULT LANGUAGE field (#207) of the KERNEL SYSTEM PARAMETERS 
                  File (#8989.3) 

CROSS REFERENCED BY: ID NUMBER(B), NAME(C)

.85,.01       ID NUMBER              0;1 NUMBER (Required)

             Language-ID-Number        
             INPUT TRANSFORM:  K:+X'=X!(X>9999999999)!(X<1)!(X?.E1"."1N.N) X S
                               :$G(X) DINUM=X
             LAST EDITED:      MAY 24,1994 
             HELP-PROMPT:      Type a Number between 1 and 9999999999, 0 
                               Decimal Digits 
             DESCRIPTION:      A number that is used to uniquely identify a
                               language.  This number corresponds to the
                               FileMan system variable DUZ("LANG"), which is
                               set during Kernel signon to signify which
                               language FileMan should use.  

             NOTES:            XXXX--CAN'T BE ALTERED EXCEPT BY PROGRAMMER

             CROSS-REFERENCE:  .85^B 
                               1)= S ^DI(.85,"B",$E(X,1,30),DA)=""
                               2)= K ^DI(.85,"B",$E(X,1,30),DA)

.85,1         NAME                   0;2 FREE TEXT (Required)

             Language-Name             
             INPUT TRANSFORM:  K:$L(X)>30!($L(X)<1) X
             LAST EDITED:      MAY 24,1994 
             HELP-PROMPT:      Answer must be 1-30 characters in length. 
                               (e.g., ENGLISH, GERMAN, FRENCH) 
             DESCRIPTION:      The descriptive name of the language
                               corresponding to this entry (i.e., German,
                               Spanish).  

             TECHNICAL DESCR:  Descriptive name of this language (e.g.,
                               ENGLISH, GERMAN).  

             CROSS-REFERENCE:  .85^C 
                               1)= S ^DI(.85,"C",$E(X,1,30),DA)=""
                               2)= K ^DI(.85,"C",$E(X,1,30),DA)

.85,10.1      ORDINAL NUMBER FORMAT  ORD;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      MAR 7,1994 
             HELP-PROMPT:      This is Standard MUMPS code. 
             DESCRIPTION:      MUMPS code used to transfer a number in Y to
                               its ordinal equivalent in this language. The
                               code should set Y to the ordinal equivalent
                               without altering any other variables in the
                               environment.  Ex. in English: 
                                      Y=1     becomes         Y=1ST 
                                      Y=2     becomes         Y=2ND 
                                      Y=3     becomes         Y=3RD  etc.  

.85,10.2      DATE/TIME FORMAT       DD;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      MAR 7,1994 
             HELP-PROMPT:      This is Standard MUMPS code. 
             DESCRIPTION:      MUMPS code used to transfer a date or date/time
                               in Y from FileMan internal format, to printable
                               format equivalent to English MMM
                               DD,YYYY@HH.MM.SS.  The code should set Y to the
                               output, without altering any other variables in
                               the environment.  Ex. in English: 
                                
                                      Y=2940612.031245        becomes        
                               Y=JUN 12,1994@03:12:45 

.85,10.21     DATE/TIME FORMAT (FMTE) FMTE;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      JUN 24,1994 
             HELP-PROMPT:      This is Standard MUMPS code. 
             DESCRIPTION:      MUMPS code used to transfer a date or date/time
                               in Y from FileMan internal format, to printable
                               format based on the various outputs from
                               routine FMTE^DILIBF.  This is an extrinsic
                               function.  Coming in to this MUMPS code, in
                               addition to the internal date in Y, a third
                               parameter will be defined to contain flags
                               equivalent to the flag passed as the second
                               input parameter to FMTE^DILIBF. The code should
                               set Y to the output, without altering any other
                               variables in the environment.  The output
                               should be formatted based on these flags: 
                                
                                1    MMM DD, YYYY@HH:MM:SS 
                                2    MM/DD/YY@HH:MM:SS     no leading zeroes
                               on month,day 
                                3    DD/MM/YY@HH:MM:SS     no leading zeroes
                               on month,day 
                                4    YY/MM/DD@HH:MM:SS 
                                5    MMM DD,YYYY@HH:MM:SS  no space before
                               year,no leading zero on day 
                                6    MM-DD-YYYY @ HH:MM:SS spaces separate
                               time 
                                7    MM-DD-YYYY@HH:MM:SS   no leading zeroes
                               on month,day 
                                
                               letters in the flag 
                                S    return always seconds 
                                U    return uppercase month names 
                                P    return time as am,pm 
                                D    return only date part 

.85,10.22     TIME                   TIME;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      MAR 18,1996 
             HELP-PROMPT:      This is Standard MUMPS code for the output of 
                               time only. 
             DESCRIPTION:      The code stored here will be used to get
                               formatted output of the time part belonging to
                               a FileMan Date/Time value.  

.85,10.3      CARDINAL NUMBER FORMAT CRD;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      MAR 8,1994 
             HELP-PROMPT:      This is Standard MUMPS code. 
             DESCRIPTION:      MUMPS code used to transfer a number in Y to
                               its cardinal equivalent in this language. The
                               code should set Y to the cardinal equivalent
                               without altering any other variables in the
                               environment.  Ex. in English: 
                                      Y=2000     becomes         Y=2,000 
                                      Y=1234567  becomes         Y=1,234,567 

.85,10.4      UPPERCASE CONVERSION   UC;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      MAR 8,1994 
             HELP-PROMPT:      This is Standard MUMPS code. 
             DESCRIPTION:      MUMPS code used to convert text in Y to its
                               upper-case equivalent in this language. The
                               code should set Y to the external format
                               without altering any other variables in the
                               environment.  In English, changes 
                                  abCdeF      to: ABCDEF 

.85,10.5      LOWERCASE CONVERSION   LC;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      MAR 8,1994 
             HELP-PROMPT:      This is Standard MUMPS code. 
             DESCRIPTION:      MUMPS code used to convert text in Y to its
                               lower-case equivalent in  this language. The
                               code should set Y to the external format
                               without altering any other variables in the
                               environment.  In English, changes: 
                                   ABcdEFgHij         to:  abcdefghij 

.85,20.2      DATE INPUT             20.2;E1,245 MUMPS

             INPUT TRANSFORM:  K:$L(X)>245 X D:$D(X) ^DIM
             LAST EDITED:      JUL 14,1994 
             HELP-PROMPT:      This is Standard MUMPS code.

Existing File's Data

In the beginning, entries were created only for the language of the different nations where the team was aware File Manager was being used at the time. Most of the entries were left as placeholders to be filled in by expert VISTA adopters from those nations, but the team felt comfortable filling in English and German in detail, given their makeup.

Record number 10 was assigned to Arabic in gratitude for and recognition of the Arab scholars who introduced the concept of the number 0 to Europe (along with the rest of the Arabic numbering system). This assignment is important to the discussion that follows because it is the sole reason why this file has an ID Number field. As shown in the file's data dictionary above, the ID Number field (.001) is the internal record number exposed as a user-visible field. Usually this is done only when the record number is meaningful to an end user. In this case it is not; it has no significance at all, except that by adding it the team was able to ensure that Arabic was made language #10.

The entries for Russian, Greek, and Hebrew were added later.

LANGUAGE List                                         DEC 27,2011@14:10   PAGE 1
--------------------------------------------------------------------------------
ID NUMBER: 1                            NAME: ENGLISH
  CARDINAL NUMBER FORMAT: I Y S Y=$FN(Y,",")
  DATE/TIME FOR: S:Y Y=$S($E(Y,4,5):$P("JAN^FEB^MAR^APR^MAY^JUN^JUL^AUG^SEP^OCT^
NOV^DEC","^",+$E(Y,4,5))_" ",1:"")_$S($E(Y,6,7):+$E(Y,6,7)_",",1:"")_($E(Y,1,3)+
1700)_$P("@"_$E(Y_0,9,10)_":"_$E(Y_"000",11,12)_$S($E(Y,13,14):":"_$E(Y_0,13,14)
,1:""),"^",Y[".")
  DATE/TIME FORMAT (FMTE): N RTN,%T S %T="."_$E($P(Y,".",2)_"000000",1,7),%F=$G(
%F),RTN="F"_$S(%F<1:1,%F>7:1,1:+%F\1)_"^DILIBF" D @RTN S Y=%R
  LOWERCASE CONVERSION: S Y=$TR(Y,"ABCDEFGHIJKLMNOPQRSTUVWXYZ","abcdefghijklmnop
qrstuvwxyz")
  ORDINAL NUMBER FORMAT: I $G(Y) S Y=Y_$S(Y#10=1&(Y#100-11):"ST",Y#10=2&(Y#100-1
2):"ND",Y#10=3&(Y#100-13):"RD",1:"TH")
  TIME: S Y=$S($L($G(Y),".")>1:$E(Y_0,9,10)_":"_$E(Y_"000",11,12)_$S($E(Y,13,14)
:":"_$E(Y_0,13,14),1:""),1:"")
  UPPERCASE CONVERSION: S Y=$TR(Y,"abcdefghijklmnopqrstuvwxyz","ABCDEFGHIJKLMNOP
QRSTUVWXYZ")
ID NUMBER: 2                            NAME: GERMAN
  CARDINAL NUMBER FORMAT: S:$G(Y) Y=$TR($FN(Y,","),",",".")
  DATE/TIME FORMAT: S:Y Y=$S($E(Y,6,7):$E(Y,6,7)_".",1:"")_$S($E(Y,4,5):$E(Y,4,5
)_".",1:"")_($E(Y,1,3)+1700)_$P(" "_$E(Y_0,9,10)_":"_$E(Y_"000",11,12)_$S($E(Y,1
3,14):":"_$E(Y_0,13,14),1:""),"^",Y[".")
  LOWERCASE CONVERSION: S Y=$TR(Y,"ABCDEFGHIJKLMNOPQRSTUVWXYZ[]\","abcdefghijklm
nopqrstuvwxyz{}|")                      ORDINAL NUMBER FORMAT: S:$G(Y) Y=Y_"."
  TIME: S Y=$S($L($G(Y),".")>1:$E(Y_0,9,10)_":"_$E(Y_"000",11,12)_$S($E(Y,13,14)
:":"_$E(Y_0,13,14),1:""),1:"")
  UPPERCASE CONVERSION: S Y=$TR(Y,"abcdefghijklmnopqrstuvwxyz{}|","ABCDEFGHIJKLM
NOPQRSTUVWXYZ[]\")
ID NUMBER: 3                            NAME: SPANISH
ID NUMBER: 4                            NAME: FRENCH
ID NUMBER: 5                            NAME: FINNISH
  DATE/TIME FORMAT: X:$G(Y) ^DD("DD")   ORDINAL NUMBER FORMAT: I $G(Y) S Y=Y_"."
ID NUMBER: 6                            NAME: ITALIAN
ID NUMBER: 7                            NAME: PORTUGUESE
ID NUMBER: 10                           NAME: ARABIC
ID NUMBER: 11                           NAME: RUSSIAN
ID NUMBER: 12                           NAME: GREEK
ID NUMBER: 18                           NAME: HEBREW

Design Intentions

This version of the file was intended mainly to be used to assist in the process of translating all of VISTA's hard-coded text (such as in user prompts, help, and so on) into other languages so it could be used by non-English-speaking users. The only database pointers to the Language file are from (1) the Dialog file (#.84), which contains the canned text to be translated along with any translations, (2) the Kernel System Parameters file (8989.3), to allow the default language of the VISTA system to be set, and (3) the New Person file (200), to allow individual users to be set to a different language than the overall system.

In addition, the Kernel package during user sign-on would set the local variable DUZ("LANG") to the user's language, so that File Manager would offer dialog in that language wherever available. The intent was for package's to replace their hard-coded MUMPS write commands with calls to an API that would fetch the correct piece of dialog from the Dialog file, automatically translating it whenever DUZ("LANG") told it to. Because of the chaos in VISTA strategy and coordination over the past fifteen years, only two VISTA packages, File Manager and Mail Manager, have been converted so far to the use of this new internationalization framework. It remains a high priority for any future VISTA work to follow their example, not just to support multilingual use of VISTA but also because the same calls that support this also support separating the business logic from the user interface (UI), a necessary step in making it possible to convert VISTA applications to next-generation UIs like browsers and mobile devices.

Improvements in Medsphere Fileman

George Timson, the original author of File Manager, made significant enhancements to File Manager after the U.S. Department of Veterans Affairs released version 22 (the last version of Fileman officially released so far). This work was done for and paid by various clients but especially by Medsphere Corporation. Included in this work were significant improvements to Fileman's internationalization framework, which gave Mr. Timson the ability to convert many of File Manager's unique elements of dialog (such as file and field names, word-processing values, and so on) over to the enhanced internationalization framework so they could be translated as well. Many files (including Fileman's own data dictionary, file #0) were pointed to the Language file, and a new Code field was added. In a more recent upgrade, Mr. Timson added separate fields for two-letter and three-letter codes, to be used to record the ISO 639 codes for languages.

Unfortunately, to date neither VA nor Indian Health Service (IHS) has adopted these extensions to File Manager. Therefore, they are not part of the VA's Freedom of Information Act (FOIA) release, and consequently neither are they the basis for WorldVistA EHR. Therefore, upgrading WorldVistA EHR to version 2.0 so it could be certified and so its adopters could attest to meaningful use had to be done independently of Mr. Timson's work.

For the brief present, Mr. Timson's work represents a fork, an alternative (and in most ways superior) dialect of File Manager. As described below, the full plans for this project include eventually synchronizing Mr. Timson's MSC Fileman solution to the language file with WorldVistA EHR 2.0's solution, to make it possible to later resolve the fork by adopting Mr. Timson's work into the WorldVistA EHR codebase. For now, for the next couple of months, their Language files will remain out of sync, making it problematic for the adopter of either to install the other.

Later in this project, as it moves toward the synchronization phase, this page will be expanded to compare MSC File Manager to WorldVistA EHR 2.0 File Manager in enough detail to guide the reunification.

Problems with Existing Architecture

The problems with the architecture before WorldVistA EHR 2.0 were these:

1) First, the Patient file needs to point to the Language file, but it did not.

2) Second, Chris Richardson rightly concluded that although phase one meaningful use only requires a single field to record preferred language, to be truly useful it should also include a multiple that records all the languages the patient knows, separately including how well they read, write, and speak the language. Communicating with non-English-speaking people can often require round-about methods; after all, what if no one in the hospital speaks a patient's preferred language? If someone happens to speak an additional language they speak, you can still communicate with them. Likewise, some speakers of different dialects of Chinese cannot communicate through speech but can understand each other perfectly in writing. Tracking all three sets of skills for all languages a patient can speak is essential to maximizing the chances of communication, which is the spirit of this phase one meaningful use goal. The existing file also lacked such a subfile.

3) The main options used to edit and report patient demographics did not include these new fields.

4) The Language file itself contained only eleven languages. It needed its contents to be massively upgraded.

5) Although users refer to language by name, software prefers to refer to language by unique codes. Although such coding systems exist for languages, the existing data dictionary included no such coding fields.

6) Coding systems change over time. Tying a permanent hub file like Language to a specific generation of codes makes it impossible to keep track of changes to those codes over time. Some other file would be needed to keep track of the language codes themselves

7) The biggest problem with the existing file dates back to the decision to include Arabic. To make it easy to make Arabic language #10, the team made the key of the file be the record's internal entry number. When VA broke up the File Manager team, it de facto converted this temporary expediency into the permanent condition of the file, with the file's scaffolding released into production. The result is that pointers to the Language file from other files do not resolve as the name of the language but as its number, making it nearly useless to end users and meeting neither the spirit nor the letter of the phase one meaningful use goal.

Solutions in Language File Version 2

Licensing

Installing the Language File Version 2

System Requirements

Infrastructure Dependencies

VISTA Package Dependencies

Downloading the Software

Installation and Configuration

Verifying the Installation

Contributors

Future Development