|
 
 |
| EDITORIAL |
|
| Year : 2019 | Volume
: 5
| Issue : 3 | Page : 96-99 |
|
Cloud computing – Securing patient data
David Charles Amos
One Vision Health Ltd, Primrose Hill, London, UK
| Date of Web Publication | 30-Dec-2019 |
Correspondence Address:
David Charles Amos
780 Melton Road, Thurmaston, Leicester, LE4 8BD
UK
 Source of Support: None, Conflict of Interest: None  | Check |
DOI: 10.4103/digm.digm_20_19
How to cite this article:
Amos DC. Cloud computing – Securing patient data. Digit Med 2019;5:96-9 |
| Impact of Cloud Technology on Medical Applications | |  |
In 2017 the NHS (UK) was found to be the biggest buyer of Fax machines in the UK, where some 9,000 machines [1] were still being used for sending patient documents to the intended recipient. Clinicians send their documents by fax because it is a known secure method of recorded delivery. In 2019 there is still a considerable fear of committing the storage of patient data to any cloud-based {cloud computing} application [2] – with good reason. Regular press reports on the theft of data from cloud-based systems [3] can result in medical leaders choosing to avoid new technology and to stick with traditional methods for document transmission. This paper considers a model for storing patient data which is inherently more secure than legacy methods and which can be adopted in the design of new cloud computing medical applications. At present, the majority of medical applications are hosted internally within the hospital's own IT environment. This hides the application from the outside world and protects the system from unauthorized external access, ensuring that only hospital roles may access patient records. With the advent of new mobile technology, there is now the opportunity to access medical data and patient information while “on the move” and more importantly, to be able to share access to that data with roles outside of the hospital environment. External roles may be approved third parties involved in patient support at home – allowing patients to be discharged as early as possible, thereby making a ward bed available for another patient. Providing external access to legacy systems is particularly difficult due to the fact they are unlikely to be compatible with mobile devices and ring-fenced behind many layers of IT security for protection. To resolve this dilemma, the application needs to be redesigned and rebuilt as a cloud computing service so that the use of the application and the data held therein may then be shared by those approved to have access. A fundamental element of the new application design is that it should provide access via a standard browser so that any mobile device may operate with the system. Here is where the need for a new model of security becomes the key.
| Access and Storage | | |
The security surrounding cloud applications falls into two main areas – service access protocols and data storage. End-user access protocols to cloud computing services are generally well implemented and include the now obligatory website certificate to encrypt site access sessions (https). However, the simple model of identifying approved users by e-mail address and a password is no longer sufficient. Increasingly a third, fourth, and even fifth layer of additional highly secure access methods should be considered:
- Randomized characters from a memorable phrase (i.e., input characters 3, 7, and 14)
- Single-shot short message service (SMS) pin verification sent to the user's personal mobile device (Be aware that this option needs to be optional for hospital roles where the GSM signal in a ward may be deficient. However, for field-based roles, this should be mandatory.)
- Option to limit user profile access to a device-specific internet protocol (IP) address.
A very secure access model may require an end user to input 3–4 different credentials to gain access. These options should be selectable according to the user profile, allowing hospital roles to choose “Device IP address” and field-based roles “SMS Pin.” Flexibility is key and requires thought during user profile configuration and system design.
Typically, “forgot password” is the most reported system access issue. Those systems which raise the access security with three additional barriers will generate a higher level of support ticket requests, and this aspect needs to be considered during the design phase. The ability for a user to “self-reset” their access credentials (change of mobile number for example) should be the key to any system access design and may involve senior user roles in the approve, confirm, and identify the process.
While the end-user security access model is crucial, this paper is primarily focused on a new model for the storage of patient medical data.
| Future Developments | | |
We are at the beginning of a new era in digital medicine and mobile enablement.
The next generation of medical applications will need to share patient records with the third party roles outside of the core locations where they are generated – General Practitioner (GP) practices and hospital wards.
These new applications need to ensure that patient data privacy is a key to their core design such that theft of a patient record is made extremely difficult or impossible – even if the hosting environment is breached in some way.
The vulnerability of existing legacy application designs revolves around their use of the ubiquitous SQL database to hold all of the data fields pertinent to the patient record or related medical procedure. The use of SQL is inherent to the model of all modern code generators. The database holds the variables being stored as named fields within the database schema. Should the security of the hosting service be breached or a rogue IT support role gain access to the file system, then by simply copying database records off the service all patient details within that record set are now available to the thief and easily processed to extract key information.
The new data storage model proposed by this paper takes the simple step of splitting the public and private patient data fields and storing these separately to each other using randomized algorithms known only to the application code. This ensures that the application code is the only mechanism by which to find and access the patient private encrypted records.
The patient public keys will be those known to anyone or are commonly known by the medical profession and not subject to any privacy requirement. These will be fields such as name and postcode, phone numbers, medical record (NI) number and date of birth, and GP or hospital ID. These fields are chosen by the service design team to ensure that the private records held within the system can be retrieved by any user after input of typical search and find strings, with partial match filters as and when required.
These public keys are the only fields held in the SQL database, and consequently, if the service is subjected to a security breach which results in one or more SQL records being stolen, nothing of consequence has been lost. The thief can see the public keys and a randomized file name which holds the private data. Located with and by direct reference to these public keys is the file name of the patient data record – which is located elsewhere within the hosted environment. Its path is hidden and known only to the application code.
The patient's medical record is held as readable structured content within a PDF [4] format file. This PDF file has a randomized file name and is encrypted.[5] The file can only be decrypted by the application code using a key which is used by the application when it stores the file. The user is never asked to input or manage the encryption key and is unaware of the background process used to store the medical records securely.
Additional security is created by storing the medical record at rest in a physically separate file store under a known pyramid tree structure, for example, by date within the location. This tree structure is chosen by the design team. The application will use the public keys to choose the storage location and thereby unless the algorithm is known, then even if the file store space can be accessed, any records found are not easily linked back to the SQL record holding the public keys. Since the file names are randomized and the file encrypted then even for a role with access to the hosting environment, it is not possible to make sense of the stored records.
The application code knows the document encryption key and the stored location of the patient record, and consequently, only an approved user of the application, who has been validated via the secure access model, is able to view that patient's medical record details.
The benefits of using this physical separation with encryption model are that theft of any of the application data files does not give easy access to the patient's private information.
When an appropriately approved user calls for the medical record, the application retrieves the PDF file, decrypts it, and sends the now open PDF, via the secure session to the device of the end user, which is displayed using an appropriate viewer. For an additional layer of security, the application should implement record access logging. For every call to access the patient record, the details of that user are recorded in an access log, each access to a patient record is tracked by date, time, and end-user profile. Subsequently, the record access log may be used to backtrack to determine which user(s) have accessed details about any particular patient. Further, by implementing simple analysis routines to regularly process the log, any unusual viewing activity may be identified and investigated before any significant misuse of patient data occurs.
The stored patient record is never updated, it remains unchanged, the application workflow always writes a new patient record to support each required transaction, thereby delivering the additional benefit of ensuring that a recorded patient history cannot be tampered with. Allowing the application to import scanned or native documents, and storing those as part of the patient history record using the same distributed methodology provides for a complete solution to patient profile needs.
| Big Data Analytics | | |
Since the data captured and held by the computing application are likely to be of high value to many other services in the medical world, a means of sharing the information is highly desirable.
To facilitate this capability, the application code can be enhanced to scrape nonpersonal information from the data record before it is stored. Using an Application Program Interface (API),[6] the data fields which are of interest to third party services may be shared without exposing any information pertaining to the original patient. This will likely be medical procedure data which can be analyzed by another application service and used for research in related fields. Data are exported one record at a time in real-time to the alternative service; this might be a data mine [7] used for management information reporting or another long-term medical archive used by researchers.
While the data are depersonalized, the profile of the patient needs to form part of the data set passed across via the API, for example, fields such as age, sex, and weight; these parameters may not form part of the medical procedure data set but should be included from the patient profile captured by the application, this allows any later analysis to put the medical data into context. The second part revolves around free text fields, while these form a key part of medical records, these fields should not be passed over via the API, simply because the HCP user may inadvertently insert the patient name or some other identifiable information (NI number) which could breach the General Data Protection Regulation or the applicable privacy rules when exported outside of the secured application.
Storing public and private records separately combined with highly secure access protocols allows cloud computing applications to be developed which will support emerging multifunctional service requirements and share the captured information with public data analytics services.
| References | | |
| 1. | |
| 2. | Griebel L, Prokosch HU, Köpcke F, Toddenroth D, Christoph J, Leb I, et al. A scoping review of cloud computing in healthcare. BMC Med Inform Decis Mak 2015;15:17. Available from: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4372226/. [Last accessed on 2019 Aug 13].  |
| 3. | |
| 4. | |
| 5. | |
| 6. | |
| 7. | |
|
Search Pubmed for