Language File (.85)
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.
Contents
- 1 Background for the Language File Version 2
- 2 Components of Language File Version 2
- 2.1 Patient File: Language Preference Field
- 2.2 Patient File: Language Skills Subfile
- 2.3 Changes to Options
- 2.4 Language File: New Entries
- 2.5 Language File: Code Fields
- 2.6 VW HL7 Tables File
- 2.7 Language File: Data Dictionary Overhaul
- 2.8 Distributing and Installing the Core Language File
- 2.9 Distributing and Installing the Extended Language File
- 3 Licensing
- 4 Installing the Language File Version 2
- 5 Verifying the Installation
- 6 Contributors
- 7 Future Development
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 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.
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, 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 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.
