Difference between revisions of "Mobile Application Considerations"

Latest revision as of 18:59, 25 January 2016

We are trying to build a mobile app (for Android and iOS). What should we consider?

Well, one issue I think you will need to consider is that any mobile app must assume that you have only sporadic internet connectivity.

Sometimes, you will have great connectivity, but you never know when it will change. Perhaps you will go from a home wireless network that is well connected to a telephone connectivity that is one or two packets a second at best or vice versa. Many applications depend on a connectivity module that doesn't match reality.

Another thing to think about is what kind of connectivity abstraction you want to have. It is nice to connect on the abstraction of Files, Entries, and Fields. This is a higher level than at the level of Global nodes and cross-references, and will probably let you offload a lot of the database handling onto the VistA database manager (FileMan). You should think of your data updates as a single atomic action, since that will allow the maximum throughput with the most efficient use of your slowest action (network connectivity).

Another important communication avenue for VistA applications will be the RPC Broker. This allows subroutines to be processed remotely from your mobile device where they may have access to more information than your application does. Careful unit tests of the REMOTE PROCEDURE CALLs that you depend upon will be very important, so you know you get the information you expect. A time-till-invalidated analysis on your data should also be done, as you will be connecting to a multi-process system where more than your application will be updating/changing/removing data.

A careful analysis of client data (on the mobile device) versus server data (on the VistA server) will be necessary. If the data is only valid for one institution (on the VistA server), it will be best that it be retrieved from the server. Assumptions about what is on the server, (even to the point of field names in a particular language) makes your application less flexible, but does make it faster as the data can be complied into local device data structures. Perhaps a strategy involving local data which can be overridden by communicated data from the server will be an optimal blend for your application.

Most Mobile apps don't depend on disk access on-device, so you don't need to think of speeding up that access through caching, but should consider caching for the data you access over the network. And of course, purging, replacing data with more up-to-date copies, and writing data back to the server should be part of this strategy as well. A round-robin LRU algorithm may turn out to be the best method, but you should test various strategies for your application data/program mix.

It will be necessary to have some kind of true encryption on the contents of the connection between your mobile devices and the back-end server. This should be a strong encryption rather than simple obfuscation. VistA applications are generally medical, and as such, will have personally identifiable information (PPI) commonly transmitted and received, as well as personal Health information (PHI). It is critical that you assume your data will be transmitted on non-secure connections, and require such measures.

It is important that you realize that your application will have private information of a non-patient specific variety, such as physician's names, authority to write prescriptions, clinic hours, private phone numbers, etc.

Think carefully about the information you store in your mobile app, as you don't know when it will be saved to permanent storage, backed up, retrieved by applications other than yours, etc. You don't control when the device powers down, or memory becomes memory mapped files. Due precautions regarding at-rest encryption should thus be taken.