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

From VistApedia
Jump to: navigation, search
m (Contributors: add Ben Mehling)
m (Version 2 Language file)
Line 592: Line 592:
 
  David Whitten
 
  David Whitten
 
  Kevin Toppenberg
 
  Kevin Toppenberg
Ben Mehling
+
Ben Mehling
 
  Rick Marshall
 
  Rick Marshall
  

Revision as of 23:10, 22 January 2012

The Language File Version 2 project added upgrades to File Manager's Language file (.85) and related software to help WorldVistA EHR 2.0 meet the EHR certification standards required by meaningful use stage one.

Background for 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 1994 release 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 early 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 packages 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.

The work to convert File Manager to the Dialog framework was done partly by VA's 1990s File Manager development team (named above), but especially by George Timson in his subsequent MSC Fileman work. The work to convert Mail Manager to the Dialog framework was done single-handedly by Gary Beuschel.

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, 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 meaningful use stage one 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 understand, speak, read, and write 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 four sets of skills for all languages a patient can speak is essential to maximizing the chances of communication, which is the spirit of this meaningful use stage one 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 meaningful use stage one goal.

To meet meaningful use stage one, all these problems had to be solved.

Components of Language File Version 2

The following seven changes make up this project:

1) Added Language Preference field (256000) to Patient file (2).

2) Added Language Skills subfile (256001/2.0256001) to Patient file (2).

3) Tertiary modifications to the primary options that edit and display patient demographic information.

4) Hundreds of new entries added to the Language file (.85).

5) New code fields added to the Language file (.85).

6) New VW HL7 Tables file (260).

7) Overhaul of data dictionary of the Language file (.85)

Patient File: Language Preference Field

This is the new field added to the Patient file (2) to support the letter of the preferred-language requirement of meaningful use stage one:

STANDARD DATA DICTIONARY #2 -- PATIENT FILE        DEC 27,2011@19:09:49  PAGE 1
STORED IN ^DPT(  (58806 ENTRIES)   SITE: Oroville Hospital Development   UCI: DEV,VISTA
                                                       (VERSION 5.3)   

DATA          NAME                  GLOBAL        DATA
ELEMENT       TITLE                 LOCATION      TYPE
-------------------------------------------------------------------------------

2,256000      LANGUAGE PREFERENCE    256000;1 POINTER TO LANGUAGE FILE (#.85)

             LAST EDITED:      JUN 22, 2011 
             DESCRIPTION:      This field is to define the language preference
                               of the patient.  

    FILES POINTED TO                      FIELDS

LANGUAGE (#.85)                   LANGUAGE PREFERENCE (#256000)
                                  LANGUAGE SKILLS:LANGUAGE SKILLS (#.01)

This field was created by Chris Richardson.

Patient File: Language Skills Subfile

On 20 December 2010, Nancy Anthracite pointed the team to appendix A of the HL7 tables, which includes standards for language ability and language proficiency:

Language Ability
	
1 Read
2 Write
3 Speak
4 Understand
5 Sign
Language Proficiency
	
1 Excellent
2 Good
3 Fair
4 Poor
5 Some(level unknown)

In designing the subfile for the Patient file, Chris Richardson approximated these two standards but modified them. He changed the order of the abilities and omitted signing. He also changed the order of the proficiencies, replaced them with more specific and intuitive names where possible, followed the VISTA convention of eschewing numeric codes in favor of more user-friendly alphabetic ones, and omitted "some (level unknown)". Here is the resulting data dictionary for the new subfile:

STANDARD DATA DICTIONARY #2 -- PATIENT FILE        DEC 27,2011@19:09:49  PAGE 1
STORED IN ^DPT(  (58806 ENTRIES)   SITE: Oroville Hospital Development   UCI: DEV,VISTA
                                                       (VERSION 5.3)   

DATA          NAME                  GLOBAL        DATA
ELEMENT       TITLE                 LOCATION      TYPE
-------------------------------------------------------------------------------

2,256001      LANGUAGE SKILLS        256001;0 POINTER Multiple #2.0256001

             DESCRIPTION:      The languages listed here are associated with a
                               series of qualifiers for UNDERSTANDING,
                               SPEAKING, READING, and/or WRITTEN skill levels
                               of each langua language specified for this
                               patient.  

2.0256001,.01   LANGUAGE SKILLS        0;1 POINTER TO LANGUAGE FILE (#.85)
                                  (Multiply asked)

               LAST EDITED:      MAY 24, 2011 
               DESCRIPTION:      This multiple is to help catalog the language
                                 skills of the patient.  It may be the case
                                 that a patient may be called upon to
                                 communicate with other patients that the
                                 staff is unable to communicate with
                                 otherwise.  

               CROSS-REFERENCE:  2.0256001^B 
                                 1)= S ^DPT(DA(1),256001,"B",$E(X,1,30),DA)=""
                                 2)= K ^DPT(DA(1),256001,"B",$E(X,1,30),DA)

2.0256001,1     UNDERSTANDING SKILL LEVEL 0;2 SET

                                 'P' FOR poor to none; 
                                 'I' FOR intermediate; 
                                 'N' FOR native skills; 
                                 'M' FOR mastery of the Language; 
               LAST EDITED:      MAY 24, 2011 

2.0256001,2     SPEAKING SKILL LEVEL   0;3 SET

                                 'P' FOR poor to none; 
                                 'I' FOR intermediate; 
                                 'N' FOR native skills; 
                                 'M' FOR mastery of the Language; 
               LAST EDITED:      MAY 24, 2011 

2.0256001,3     READING SKILL LEVEL    0;4 SET

                                 'P' FOR poor to none; 
                                 'I' FOR intermediate; 
                                 'N' FOR native skills; 
                                 'M' FOR mastery of the Language; 
               LAST EDITED:      MAY 24, 2011 

2.0256001,4     WRITTEN SKILL LEVEL    0;5 SET

                                 'P' FOR poor to none; 
                                 'I' FOR intermediate; 
                                 'N' FOR native skills; 
                                 'M' FOR mastery of the Language; 
               LAST EDITED:      MAY 24, 2011 
 
    FILES POINTED TO                      FIELDS

LANGUAGE (#.85)     LANGUAGE SKILLS:LANGUAGE SKILLS (#.01)

This subfile was created by Chris Richardson. Greg Woodhouse and Nancy Anthracite helped brainstorm the actual representation with him.

Why the Interpreter Language subfile (19906/2.019906) Was Not Used

WorldVistA EHR 1.0 included a subfile that was not used for this project. Here is its complete data dictionary:

STANDARD DATA DICTIONARY #2.019906 -- INTERPRETER LANGUAGE SUB-FILE   
                                                  DEC 27,2011@18:16:57  PAGE 1
STORED IN ^DPT(D0,19901,   SITE: Oroville Hospital Development   UCI: DEV,VISTA

DATA          NAME                  GLOBAL        DATA
ELEMENT       TITLE                 LOCATION      TYPE
-------------------------------------------------------------------------------
CROSS REFERENCED BY: INTERPRETER LANGUAGE(B)

2.019906,.01  INTERPRETER LANGUAGE   0;1 POINTER TO LANGUAGE FILE (#.85)
                                (Multiply asked)

             OUTPUT TRANSFORM: S Y=$$GET1^DIQ(.85,Y,1,"")
             LAST EDITED:      MAY 09, 2005 
             HELP-PROMPT:      English is the default Language if no other 
                               Language is entered.  If others are entered and
                               the patient speaks English as well, ENGLISH 
                               must be included in this field. 
             CROSS-REFERENCE:  2.019906^B 
                               1)= S ^DPT(DA(1),19901,"B",$E(X,1,30),DA)=""
                               2)= K ^DPT(DA(1),19901,"B",$E(X,1,30),DA)

     FILES POINTED TO                      FIELDS

LANGUAGE (#.85)                   INTERPRETER LANGUAGE (#.01)

This field, along with the other 19900-numberspaced fields, was created by Brian Lord at Daou Systems in 2005 as part of the Centers for Medicare and Medicaid Services's (CMS's) VistA-Office EHR (VOE) project. This was a project to modify VA's FOIA VISTA to create a dialect of VISTA preconfigured for small clinics and doctor's offices. It was inspired by studies showing the high rate of medical error in the United States and the promise of EHRs to drive down those errors; EHR uptake was especially low in small clinics and doctor's offices, so CMS wanted to create a free EHR they could adopt. The project was crushed when EHR vendors got wind of it, which interrupted the plans for this subfile along with everything else. Since this work predates meaningful use, it was originally added not to comply with MU stage one but to meet CMS's design requirements for the VOE project.

Note the use of the field's output transform to overcome the difficulty with pointers to the existing Language file resolving to language number rather than name. Also note the better-than-average help prompt. Although unfinished, this subfile was a good start on solving the problem.

When Chris Richardson set out to solve the problem of adding a preferred language field to the Patient file for meaningful use stage one, he decided against using the Interpreter Language field partly because of its unclear history at the time and partly because of its unfinished state. As part of the bundling of this work for distribution as part of WorldVistA EHR 2.0, Rick Marshall will delete this promising but unfinished and orphaned subfile from the Patient file.

At some point, the remaining 19900-numberspaced fields need to be analyzed as well for whether they are in use and whether they should be finished or removed.

Changes to Options

Language File: New Entries

Language File: Code Fields

VW HL7 Tables File

Language File: Data Dictionary Overhaul

Distributing and Installing the Core Language File

Distributing and Installing the Extended Language File

Licensing

Installing the Language File Version 2

System Requirements

Infrastructure Dependencies

VISTA Package Dependencies

Downloading the Software

Installation and Configuration

Verifying the Installation

Contributors

Version 2 Language file

George Timson
Chris Richardson
Nancy Anthracite
John McCormack
Brian Lord
Greg Woodhouse
David Whitten
Kevin Toppenberg
Ben Mehling
Rick Marshall

Version 1 Language file

Marcus Werners
Maureen Hoye
Tami Winn
Danila Manapsal
Michael Ogi
Don Creaven
David LaLiberte
Rick Marshall

Future Development

Later in 2012, revisit the Language file to upgrade it to include the latest versions of the language standards - ISO 639-3 & 5, which include a lot more languages, dialects, and language families - and redo this process. There's no rush on that since the current generation of the data is sufficient for our current needs.

Thereafter in 2012, work with John McCormack to capture the coding systems themselves in his new coding-system file and to work out the proper distribution of entries in that file - which package should they belong to, etc. - and then distribute those coding systems with pointers back to the Language file. John's design separates the true entity we are trying to represent (the actual human language in the Language file) from the coding system that tries to represent it, and it can be updated over generations of standards (the coding system in John's coding-system file) and then link them by having the coding system point to its referent. It standardizes a pattern in the VISTA database that had been accumulating in an ad hoc and tangled way into a new, clean, extensible architecture for managing coding systems and weaving them into the VISTA architecture. We will support his architecture by making the language coding systems a guinea pig.

Immediate To Do List for the Language File Version 2

This temporary section will track the work left to be done to polish and release version 2 of the Language file. As items are completed, they will be checked off. When all items are complete, this section will be removed.

1. Finish writing this Wikipedia article.

2. Confirm its accuracy with the principals who did the initial work.

3. Consider adding Signing to the Language Skills subfile of the Patient file, to better match the HL7 standard.

4. Improve the help and technical help for all the DD elements introduced or revised as part of this project.

5. Delete the Interpreter Language subfile from the Patient file.

6. Investigate whether to delete the other Daou-added fields in the 19900 numberspace from the Patient file.

7. Modify the DINIT routines in WorldVistA EHR 2.0 to correct the DD of the Language file and its small set of core entries so they match.

8. Create the DILAINIT routines to generate the full Language file 2.0.

9. Apply those inits to a WV EHR environment to prove they work.

10. Send them to Skip Ormsby with simple instructions for how to weave them into his next WV EHR KIDS distribution's pre-install routine. This should give WV EHR everything it needs to proceed for the current version.

11. Reapply these same changes on top of an MSC Fileman environment to "rebundle" them as MSC File Manager changes.

12. Send them to George Timson for inclusion in a new MSC Fileman release, so those who install MSC Fileman over WV EHR don't undo WV EHR's shiny new Language file.