Difference between revisions of "Language File (.85)"
(→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
Contents
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.
