C

Clynica

Clynica is a simple alternative to pen and paper for doctors to manage their patients and prescriptions in one place.

C

Clynica

Clynica is a simple alternative to pen and paper for doctors to manage their patients and prescriptions in one place.

The problem Clynica solves

Many doctors and their patients worldwide are dependant on handwritten paper prescription and records which has a few issues:

(1) Accessibility: The documents must be physically available to access. This may cause issues when old records (including drug prescriptions) are lost, unavailable or the ink has faded.

(2) Security: The documents are usually not stored in secure locations which means there is a risk of compromise of personally-identifiable medical information.

Clynica solves these issues by providing doctors the flexibility to quicky register new patients, write down prescriptions (using a pen on a tablet), access patient's old records, view the patient's history and instantly generate printed prescriptions that will ensure clarity when purchasing drugs from a pharmacy. Moreover, the records are stored securely on Clynica's servers which can only be accessed by an authorized doctor. This allows quick, secure and hassle-free access to medical records so that the doctor can focus on the treatment better.

Challenges we ran into

The biggest hurdle we faced while implementing this project was the integration and usage of MyScript's Interactive Ink API. Our requirement was to have multiple text fields in a single 'UIViewController', but MyScript provided for only a single 'document' per 'UIViewController'. The documentation did not help much either. We had to look around their developer forums, try different implementations that would allow us to include two or more drawable text fields in a single controller. We partially achieved this following these steps:

  • Set up a global ink capture view, and send the pointer events to each field depending on their location.
  • Store the data for each field in a dedicated content part.
  • Have an editor pool and use setPart() to assign an editor when a field receives input and detach the editor when the field becomes inactive to avoid the need for one editor per field.
  • The different editors can share the same render target (i.e. rendering view), but you have to make sure that invalidate() calls for concerning one field will only affect the area of the view corresponding to this field.

Technologies used

Discussion