The Remedy platform draws on the insights, optimization strategies, and best practices our team learned while developing and managing one of the Top 10 paid iPhone apps in 2008. On the iPhone, Remedy has been optimized to make extensive use of data caching and baked in business logic, avoiding excessive transactions with the backend servers that would be associated with “thin” applications. In addition, the protocols used for communications have been optimized to be as light-weight as possible. This allows us to avoid excessive bandwidth and server resources.
The iPhone client application communicates with the Remedy Systems servers via a lightweight RPC (Remote Procedure Call) interface. In addition to direct method execution via remote procedure calls, the iPhone also uses a subsystem called the Remote Object Manager to cache specific objects that will be frequently accessed or manipulated during the course of the programs use. These objects are not persistently stored, but any modifications are recorded as changes in a central journal, which is used as the basis for synchronization with the Remedy Systems servers.
Remedy Systems was optimized for speed and the efficient transfer of data. We believe a main barrier to physician adoption is the slow processing speeds found on other mobile devices. Persistent data on the iPhone is stored in one of two SQLite databases, in accordance with its place as Apple's sanctioned storage engine.
The drug database is used by the Remedy application to support the display and search of generic and brand name drugs. It also contains the minimum data necessary to make initial form, route, and strength determinations during the prescription entry process. By doing this, we’re able to minimize the amount of data that is actually transferred back and forth between the server and the device - which helps keep the application running fast.
The second database maintained by the application is secured using AES-256 bit encryption. The initial database is created at the first log-on for a given practice, and the encryption key used is transmitted as part of the initial authorization processes. It is never stored persistently on the device, and only remains in RAM while the application is in use. The secure database houses the patient index, as well as the change journal.
The patient index that is persistently maintained on the device contains a minimal "Header" for each patient within the practice. This includes all the information necessary to search for, and display the patient in a reference manner. Currently that includes the patients first, last, and middle names, their primary contact number, gender, date of birth, and file number. Full patient records are checked out through the Object Manager on an as needed basis, and are not persistently cached on the device.
Any “thing” within the system is an object. A patient, a prescription, an alert, a practice, and a pharmacy are all objects within the system that can be displayed and in some cases edited.
The editing of objects, such as patients, occurs through the use of a set of data type editors. This editor system allows the user interface to by dynamic and adaptable to the use of alternate backing stores, such as accessing patients through an external PHR/EMR with different capabilities.
Once an API is in place, it is through this process that Remedy seamlessly connects with partner EMRs and practice management systems. If a partner does not have an API, Remedy can collaborate to build a joint API that takes advantage of Remedy's light weight mobile drug database and secure JSON based communication and data synchronization engines.