
Ask HN: Encryption and Security in MUMPS - tcpipcowboy
I am curious to hear from anyone working in the Healthcare Industry who programs in MUMPS how they secure and encrypt data.  Electronic Health Record applications such as Epic who use MUMPS and&#x2F;or subsets of the language may not have inherent MUMPS-based security.  How do you approach security and encryption in your MUMPS environment?<p>I did see this note in the MUMPS help and will be digging into ANSI M to see if I can get more information:<p>$TRANSLATE() provides a tool for tasks such as changing case and doing encryption.<p>For examples of case translation, refer to the ^%LCASE and ^%UCASE utility routines.
======
whitten
The first line of defense and encryption is provided by the MUMPS system
itself. Both Cache and GT.M provide encryption of the database on the disk. I
am not as familiar with Cache's methods recently, but as I recall, GT.M has
stated they are encrypting the dynamic data in memory as well. GT.M also
allows changing the encryption key for a database and re-encrypting the whole
database with a new key dynamically. (i.e. while the system is actively being
used (read and write) for financial or healthcare data.)

Other common issues in healthcare involve using ssh and TLS to encrypt TCP/IP
data being transmitted over the network, as well as use of PGP or one-way
encrypting for login passwords, such as VistA's ACCESS CODE and VERIFY CODE.

~~~
tcpipcowboy
A hypothetical example would be a routine that calls another routine and
passes information to the child process. Can one programmatically encrypt that
information to make sure it retains PHI security? This is asked understanding
that at the server level the information should technically be secured (as you
noted, including transmitted data), but with the desire to work in "paranoid
mode" and ensure extra layers of patient confidentiality at the code level.
Just in the tutorials for MUMPS and M I've reviewed so far I've not seen any
clear examples I could test out.

In reviewing $TRANSLATE()closer, it's not exactly what I'm looking for,
either, although this and $ZTRANSLATE() may be as close as I can get for my
example from what I've read thus far. Appreciate the reply!

~~~
whitten
So, calling another routine in M doesn't create a child process. Nor does
calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-
Processing" and you expresses that you can start another "JOB" that calls
another bit of code that starts in another process using the JOB command
rather than the DO subroutine call command. (I'm trying not to be pedantic,
but rather to increase knowledge about this obscure programming language)

You can pass data to this other process, but the ANSI MUMPS standard does NOT
require that the data passed by inter-process communication channels be
encrypted.

Since GT.M is open source, it is an interesting idea to encrypt this data and
decrypt it when receiving it. I'll bring it up to some friends.

Another idea worth examining might be to use the Foreign subroutine interface
both in Cache and GT.M systems. Thanks for suggesting this.

~~~
tcpipcowboy
Thanks for the terminology clarification. Still getting used to M so please
bear with me here. I'm using GT.M-amd64-Linux/V6.3-000A.

Just in the research I've done so far, I'm looking at something along the
lines of the below, but I would love to see more advanced and complete
snippets.

    
    
      ;--
      ; New, define variables
      ;--
    
      N cryptKey,derivedKey,cipher,plainText
      S cryptKey="Private Encryption Key"
      S derivedKey=$$zderiveKey(cryptKey,1,1)
      S plainText'"Hello, Crypto World!"
    
      ;--
      ; Encrypt plainText
      ;--
    
      S cipher=$$zaesenc(plainText,derivedKey)
    
      ;--
      ; Display decrypted text
      ;--
    
      W #
      W !,"Encrypted: ",cipher
      W !!,"Decrypted: ",$$zaesdec(cipher,derivedKey)
      Q
    

I'll look into the Foreign subroutine interface. Anything like Haskell's FFI?

