GB2558548A

GB2558548A - A computer data encoding system

Info

Publication number: GB2558548A
Application number: GB1621493.4A
Authority: GB
Inventors: Michael Gaffney Philip
Original assignee: L2s2 Ltd
Current assignee: L2s2 Ltd
Priority date: 2016-12-16
Filing date: 2016-12-16
Publication date: 2018-07-18
Also published as: GB201621493D0

Abstract

A computer data encoding system (100, fig 1) includes an intermediate computer system 103 that is configured to: receive an encrypted data string from an electronic device 107; substitute a unique encoded string for the encrypted data string; send the encoded string to a data storage computer system 104; send the encoded string to the electronic device 107; and store a map (which may be encrypted) of the encoded string assigned to the encrypted string substituted for the encrypted data string. An electronic device for use in a computer data encoding system obtains and decodes an encoded and encrypted data string by obtaining an encoded string from a data storage computer system; interrogating a map of the encoded string to an encrypted data string to find an encrypted data string that is mapped to the encoded string; and decrypting the encrypted data string. The map maybe encrypted using a key stored at an encryption key storage computer system that has no access to the data storage computer system. System allows fields of personally identifiable information PII to be protected by tagging or marking the fields to indicate to the intermediate processing device that these fields should be encoded.

Description

(54) Title of the Invention: A computer data encoding system

Abstract Title: Mapping encoded string to encrypted strings in a data encoding system (57) A computer data encoding system (100, fig 1) includes an intermediate computer system 103 that is configured to: receive an encrypted data string from an electronic device 107; substitute a unique encoded string for the encrypted data string; send the encoded string to a data storage computer system 104; send the encoded string to the electronic device 107; and store a map (which may be encrypted) of the encoded string assigned to the encrypted string substituted for the encrypted data string. An electronic device for use in a computer data encoding system obtains and decodes an encoded and encrypted data string by obtaining an encoded string from a data storage computer system; interrogating a map of the encoded string to an encrypted data string to find an encrypted data string that is mapped to the encoded string; and decrypting the encrypted data string. The map maybe encrypted using a key stored at an encryption key storage computer system that has no access to the data storage computer system. System allows fields of personally identifiable information PH to be protected by tagging or marking the fields to indicate to the intermediate processing device that these fields should be encoded.

USER DEVICE PROXYSERVER DATASTORE TRUSTED KEY SERVER | ^k--107 1^103 1^104 1^--102

SEND DATA WITH SUBSTITUTIONS

1/9

FIGURE 1

USERDEVICE PROXYSERVER DATASTORE TRUSTED KEY SERVER

1^107 1^103 1^104 I 102

SEND DATA WITH SUBSTITUTIONS

FIGURE 2

3/9

USER DEVICE

PROXY SERVER

DATA STORE

107

103

104

TRUSTED KEY SERVER I 102

FIGURE 3

USER DEVICE | ^-108

REQUEST CONTENT 114

PROXY SERVER -103

DATA STORE . <_·

104

TRUSTED KEY SERVER

I <-102

DISPLAY CONTENT ·<

FIGURE 4

5/9

John Smith X CatDogl23

O <-l

100 101 FIGURE 5

6/9

7/9

701

Start Encoding

Tagged field (John Smith)

◄·

707-x +

Append coding to string

E.g.

human tea catdogl23· green rain iron tree music now now@music

E.g.

human tea Jane Doe !► catdog!23 John Smith

706-x

John Smith (catdog!23)

Send to untrusted store when all tagged fields processed

708

Substitute into copy of record

709—x

-J-►

Send to device that created the record in trusted zone

FIGURE 7

8/9

to device or browser through proxy

FIGURE 8

9/9 σ>

A COMPUTER DATA ENCODING SYSTEM

FIELD OF THE INVENTION

The present invention relates to a computer data encoding system.

BACKGROUND OF THE INVENTION

Organisations that use electronic records systems to store and process personally identifiable information (PII) or other sensitive information and release it inappropriately are subject to severe penalties. PI I, sometimes called sensitive personal information (SPI) or Personal Identifiable Data (PID) is information that can identify an individual person either directly or in the context of other data.

It is usually necessary for multi-disciplinary teams who use an electronic records system, for example in healthcare, education and government, to have access to an individual’s complete record including PI I. However, other staff in the organisations often require access to part of the record but do not require the PI I. This is usually achieved through the use of a permission structure that grants access to appropriate data.

In 2016, most hospitals and schools and other organisations world-wide operate large databases that include PH, but only a small proportion of the data or information in these databases including PI I is encrypted; the data is “open” or “data in the clear”. The use of “open” data is intrinsically unsafe and exposes the organisations to heavy fines. Data is often “open” because current encryption systems lack usability and use of encryption systems may detrimentally impact the usability of a system on which data is encrypted and can make sharing data between systems difficult. This has hindered the deployment of encryption systems in these circumstances.

There is an increasing awareness of the value of data mining and big data in many areas of research and management, but concerns over privacy and safety make the procurement of many databases difficult. For example, it can take months or years to negotiate access to medical records including PH and typically significant work must be performed to anonymise the data before it can be exported from an organisation. This is costly, time consuming and carries risk.

Organisations may wish to store and process data overseas for reasons of cost or expertise but it is usually difficult or illegal to transfer PH across borders.

In circumstances where expert teams need to work across borders in potentially hostile environments, for example in disaster medicine, it is undesirable to send more people into harm’s way than is absolutely necessary.

Providing health records to commercial organisations for the purpose of data mining to research disease and treatments is useful but contentious and causes public concern due to worries regarding data security and potential misuse.

Users of applications or apps on mobile computer devices, such as smart phones or tablet 10 computers, can use manufacturers’ encryption systems to protect data on their devices.

However, for this to work successfully reliance is placed on the vendors’ trustworthiness and procedures.

Organisations and individuals that collect data are responsible for its safe keeping and appropriate use. They have to go to significant lengths to justify export and storage of data with third parties and have to put in place data sharing agreements, consents and compliance with standards, all of which result in costs and delay.

SUMMARY OF THE INVENTION

Examples of the present invention provide a low cost and highly practical solution to 20 improving the safety of data use, particularly data including PH, allowing those that require access to protected parts of the records to work unencumbered, whilst guaranteeing that all others see anonymised records. Example arrangements described remove the need to specially process data to allow it to be exported for data mining and analysis. The example arrangements described enable data to be stored and processed overseas as external parties will not be able to access protected data.

Embodiments of the present invention allow open data to be used by specialist teams in the host country to work with support teams in another country who can provide services such as medical coding and expert advice but who will not know the identity of a patient. This greatly reduces costs and minimises exposure of personnel to potential harm.

Embodiments of the present invention allow data to be released at low cost for analysis without PI I but still allow validation and verification of outcomes to be performed by the data source organisation’s qualified clinicians.

The invention in its various aspects is defined in the independent claims below to which reference should now be made. Advantageous features are set forth in the dependent claims.

Broadly, the inventors of the arrangement described herein have appreciated that these technical advantages arise from a computerised encoding system as follows. Data including PI I is created on a user’s computer terminal such as a laptop computer, desktop computer, tablet computer or phone. Selected fields, typically PH, are marked or tagged so that they can be identified for processing before storage or export. The data in these fields is encoded to sequences of human identifiable, easily describable or pronounceable words and or numbers that uniquely identify the PH. This mapping may be performed on the user’s terminal or on an intermediate computer, or server or proxy located between the terminal and the storage system. This data mapping may be encrypted against a trusted key or keys and may be stored on trusted servers or on an external storage system. The trusted key or keys used to encrypt mapped data are hosted by either the organisation itself or by a trusted host in the country in which the data is collected, such as at a lawyer’s office.

The data is therefore intrinsically safe as the PI I is always non-reversibly encoded and may be safely exported or stored overseas or placed in a third party Cloud system (remote computer). The storage partner is not given access to the map secure keys or map data and therefore does not have access to the encoded PI I. Thus, data may be safely exported to third parties for analysis without the usual processing and checking required to prevent PI I leakage.

On data retrieval, authorised users’ equipment may use the trusted keys and map data to resolve the PI I in the clear. The encoded mapped strings may be displayed on an authorised user’s terminal alongside the data in the clear to allow the user to discuss the record unambiguously with a third party, without revealing the Pll. The third party user will be able to search the database for the encoded strings and thus retrieve the appropriate encrypted records.

In summary, arrangements are described in more detail below and take the form of a computer data encoding system comprising an intermediate computer system or software. The intermediate computer system is configured to: receive data from an electronic device or user interface; identify tagged or otherwise marked data fields to be protected; assign a unique encoded string to each identified instance of data fields to be protected; maintain an encrypted or unencrypted map of assigned encoded strings to identified field data and substitute the encoded string data for the identified field data before transferring to a storage system.

Arrangements described below describe a computer data encoding system comprising an intermediate computer system. The intermediate computer system is configured to: receive an encrypted data string from an electronic device; substitute a unique encoded string for the encrypted data string; send the encoded string to a data storage computer system; send the unique identifier to the electronic device; and store an encrypted map of the unique encoded string assigned to the encrypted string substituted for the encrypted data string, wherein the encrypted map is encrypted using a key stored at an encryption key storage computer system that has no access to the data storage computer system.

A string is a set of characters.

Encoding is defined as the process of mapping a sequence of characters to replace a character set in a way that may only be reversed or decoded if the mapping is available. It is impossible to recover the original data without access to the mapping. In encoding, the content is replaced.

Encryption is a process of putting a set of characters, content, a string or strings into a particular format so that only an authorized entity or entities may access it. Content is encrypted using a key to generate ciphertext that can only be read if decrypted with a key. An authorized entity can decrypt the ciphertext with the key, but an unauthorized entity who does not have the key cannot decrypt the ciphertext. In encryption, in contrast to encoding, data is concealed.

The system may decode protected fields as the data is displayed or consumed, by retrieving the data with included protected fields from the data storage computer system, file server or storage system; identifying fields that are encoded by tags or patterns; retrieving appropriate encrypted or unencrypted mapping tables; if necessary, decrypting the mapping tables with keys from a secure key storage computer system or trusted key repository under the control of the data owners for the purpose of decoding the protected fields into data in the clear and substituting data in the clear with its associated encoded string into the dataset before display to the user. The display of data in the clear may additionally be controlled by the user’s access permissions.

Users of the data without decoding equipment or software see human readable, easily described or pronounceable encoded strings substituted into all Pll fields. These strings are searchable to allow records to be unambiguously retrieved.

Authorised users may need to be able to perform inexact searches on some Pll, for example, a name field with incorrect spelling. For offline systems, this is achieved by the intermediate apparatus, computer system or software creating an “in the clear” local dataset of all selected field data for a given user and encrypting this against a trusted or personal key or keys before transfer to the electronic device, where inexact searches can then be performed.

For online use, the intermediate apparatus, computer system or software would retrieve the protected field data mapped to each encoded string to allow inexact searching and use the found encoded strings to retrieve data from external storage and substitute data in the clear into the page on the fly. A typical intermediate apparatus or computer system that could perform this task is a reverse proxy server that would intercept browser queries; match search queries to assigned encoded strings; build appropriate queries; forward these to the storage server; retrieve responses; decode protected fields and return data in the clear to the querying browser. The key or keys used to secure the data map would be obtained from a trusted key server and these would not be made available to third parties.

Authorised users browsing through this intermediate apparatus or reverse proxy see data in the clear.

Secure retrieval of map encryption keys from a key server, encryption key storage computer system or trusted key repository hosted by a trusted third party in the country of origin of the data that has no access to the protected data, may be achieved by a computer program or device authenticating with the trusted key server, passing a private certificate, key or identifier and retrieving a unique encryption key when the electronic device is turned on. Alternatively, a security device token generator, for example a smart card writer, may hold encrypted keys for use with devices that are used without a network connection to the trusted key server or servers.

Easy collaboration between users authorised to see PH and external users may be achieved by encoding the selected data using only easily described characters, for example dictionary words, numbers, upper or lower case letters, simple punctuation or other human readable characters, such that users of protected datasets can unambiguously identify and discuss records without needing to reveal the data in the clear.

When using combinations of dictionary words, it is important to avoid creating strings that are profane or could otherwise cause offense. By using combinations of words or joined words from the same parts of speech or word class, for example, “verb verb”, “noun noun” or “adverb adverb”, the risk of creating compound offensive phrases and profanity can be reduced or minimised thus reducing or minimising the risk of profanity, offense or insult.

Additionally, the computer system processing the dictionary words to remove homophones, profane words, religious words, sexual words and racial words before a final human screening will result in a list of words that can be used individually or in combination to create unique strings that can be used to encode the data in the protected fields.

Each protected data field may also be mapped to similarly processed dictionaries in alternative languages to make the encoding simple to use with collaborators using any language. These additional encodings may be translations of the composite language strings or selected at random or pseudo-randomly. The language used may be selected by the users or by the machines locale and the alternative encoding displayed alongside the protected fields.

Both the substituted encoded strings associated with the protected fields and the protected data in the clear may be displayed together to allow a legitimate user of the full record to discuss a record anonymously with an external collaborator who is not allowed to see the data in the clear. An example would be for a patient’s doctor to discuss the patient’s condition with an expert situated overseas. For the ease of the collaborator, the record may be communicated unambiguously by copying and pasting the encoding in the collaborator’s language.

Protected data may be utilised on legacy equipment that has no encryption capabilities; PI I data will be secured.

Electronic devices or software may be used when disconnected from a network by encrypting selected fields using encrypted cached copies of the organisation’s key or keys.

These encrypted fields are subsequently substituted with encoded strings as described above when connectivity becomes available and the record is transferred through the intermediate computer system. By substituting encoded strings for encrypted strings, significantly, the amount of data required for storage can be reduced; the data storage requirement is low.

Authorised web browsers may display selectively encoded fields as data in the clear by transferring the web page through a trusted reverse proxy server or software that maintains a locally encrypted map of all encoded strings to the encrypted strings. This method includes identifying the protected fields by tags or other means, decrypting the encoded strings to data in the clear text strings and dynamically substituting these into the browsed page so that the requesting user sees the protected data fields shown in the clear, with or without the encoded string. Subject to access permissions this allows users in an organisation, for example a hospital, to view data in the clear on any existing web browser without modification, whilst guaranteeing that users external to the organisation would see encoded data.

Examples of the present invention make it safe for an organisation to store its data in a third party data storage computer system, such as a Cloud hosting or Internet-based hosting arrangement anywhere in the world by ensuring that all the identifiable and sensitive data is substituted with encoded strings that represent PI I held by trusted parties in the country of data origin. It will be impossible for an external organisation to access these fields from the stored data.

A separate encryption key storage computer system enables an organisation to outsource key holding to trusted organisations such as legal firms without putting protected data at risk, as without the data map and data, the trusted key holder will have no ability to compromise confidentiality.

Examples of the present invention enable identifiable or otherwise sensitive information, such as PH, to be always protected other than at the moment of use without impinging on the efficiency of authorised users who will see data in the clear. This protects against careless or unlawful export and ensures that data is always protected and harmless if accidentally released.

Examples of the present invention provide a low cost solution requiring minimal investment for distribution and storage of safe data using the public Internet. The arrangements described make it economical and less complicated to export anonymous datasets to third parties for data mining and statistical processing, particularly for exploiting medical data.

Examples of the present invention may be used with any type of encryption and the datasets with selected protected fields may be further encrypted in transfer and storage.

Examples of the present invention make it possible to search for records even though every replaced field is unique with no reversible mapping to the original fields. With suitable software or computer equipment, users need not be aware they are searching encoded data.

Applying examples of the present invention will significantly improve data safety without causing inefficiency. Examples of the present invention provide a highly secure data handling mechanism that can be used on the public Internet without revealing the protected data. The security is due to several factors some of which are preferred features of examples of the present invention such as: selected field encoding secured with the organisation’s trusted keys results in the data being stored and transferred with complete safety, it being impossible to gain access to the PI I from the stored data irrespective of processing power; reduction in stored data size as encoded strings can be much shorter than encrypted strings on short fields; only users with software or equipment authorised to see data in the clear will be able to decode the data; selected fields are protected with keys in the sole control of the data owners; no third party including external storage or key holders can gain access to protected fields; external parties including IT staff do not have to be trusted to secure the data; any encryption technique may be employed; the protected fields can be further encrypted by system security along with the unprotected record content.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram illustrating a computer data encoding system embodying an aspect of the present invention;

Figure 2 is a schematic diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which tagged protected fields are replaced with encoded strings that are easily described to users not entitled to see in the fields in clear text;

Figure 3 is a schematic diagram illustrating the method carried out by the computer data encoding system of Figure 1 for retrieving encoded data and decoding data to display in the clear following the method illustrated in Figure 2;

Figure 4 is a schematic diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which encoded data is replaced with clear text for web users who browse through a secure intermediate proxy server;

Figure 5 is a schematic diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which data requests in the clear entered in a trusted website retrieve records from the anonymised data store;

Figure 6 is a flow diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which dictionary words in any language are combined and filtered to avoid profanity and avoid causing offense;

Figure 7 is a flow diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which tagged fields in a data record are substituted with easily communicated, pronounceable strings;

Figure 8 is a flow diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which encoded data is decoded and displayed as clear text; and

Figure 9 is a flow diagram illustrating a method, implemented on the computer data encoding system of Figure 1, by which an inexact search on PI I may be conducted via an approved device.

DETAILED DESCRIPTION OF THE INVENTION

An example computer data encoding system and method that provides selective protection of data fields will now be described with reference to Figures 1 to 9.

Figure 1 illustrates a typical network configuration of the computer data encoding system. The computer data encoding system of Figure 1 includes two sections namely an organisation’s trusted section 100 and an external, separate untrusted section 101 in which data is stored. The vertical bold line 118 that divides Figure 1 into two sections represents a conceptual or physical boundary between the organisation’s secure trusted software, hardware and services on the left 100 and the external (separate) data storage facility on the right 101. Typically, the trusted components are in the organisation’s country of operation and the storage facility may be either in the organisation’s facility or in an externally hosted system, for example, Cloud storage, either in the operating country or overseas.

Broadly, the computer data encoding system 100 includes an intermediate apparatus, processing device or software 103 that processes data sent to and retrieved from the data storage computer system or external storage system 104. Terminal devices, for example mobile devices 107, fixed equipment 108 or sensors are used to collect ‘data in the clear’ in all fields. The devices may encrypt this data using digital keys obtained from a trusted key server 102 using communications pathway 111. Fields to be protected are tagged or otherwise marked at design or at run time to indicate to the intermediate processing device or software 103 that these fields should be encoded. Data is communicated with the intermediate apparatus by a network connection 113, 114. The intermediate device or software 103 substitutes encoded strings comprised of combinations of easily described words with or without numeric qualifiers for the strings in the tagged fields and stores a map of the substitutions. The intermediate device or software may secure the mapping tables with a key or keys obtained from the trusted key server 102 via communications link

112. The intermediate device or software passes the data with the field substitutions through to the storage system 104. The data in storage is therefore intrinsically safe.

When data is requested from the external storage system 104 by devices connected through the intermediate apparatus 103 the encoded data is decoded and data in the clear is substituted into the retrieved data 113, 114. The encoded strings may also be passed to the devices to be displayed associated with the data in the clear. This allows unambiguous identification of records with co-workers not entitled to see the data in the clear. Devices 109 accessing the external data store directly 116 rather than through the intermediate apparatus will only see encoded data. Similarly, devices 106 in the untrusted zone will only be able to see encoded data. The data mapping may be performed on the devices rather than on the intermediate device or software if a means of synchronising the mapping tables between devices is provided.

Data stored on the external storage system may be separately or additionally encrypted by system keys 105. An intermediate computer system 103 in the form of a proxy server forms part of the computer data encoding system. The proxy server is in communication connection with the encryption key storage computer system 102 via communication connection 112 and the data storage computer system 104 via communication connection 115 as well as a users’ electronic devices 107,108 via communication connections 113, 114. The proxy server is configured to store unique encoded strings mapped to tagged strings (that may be encrypted) transferred from users’ electronic devices; and substitute these strings into the data record before sending to the data storage system 104. In this example, the user’s electronic device 107 is a tablet computer and the user’s electronic device 108 is a desktop computer with a web browsing capability, but the electronic devices may comprise any computer such as a laptop computer, desktop computer, tablet computer, smartphone or the like. The users’ electronic devices 107 can: store an encrypted map between at least one of the unique encoded strings and encrypted data stored in the data storage computer system; have permission to access a trusted encryption key from the encryption key storage computer system; and can access and decrypt encrypted data identified by the at least one of the unique encoded strings in the data storage system. Electronic device 108 of Figure 1, in this example a desktop computer with a web browser, connects to the intermediate apparatus, in this case a reverse proxy server 103, through communications connection 114, receives pages with data in the clear substituted into protected fields by the reverse proxy server 103 that uses a map store (encrypted or otherwise, such as not encrypted) between at least one of the unique encoded strings and data in the clear or encrypted strings, and a key from the trusted key server to decode the data as it passes through the reverse proxy server. Electronic device 109 of Figure 1, in this example a tablet computer, does not store a map (encrypted or otherwise, such as not encrypted) between at least one of the unique encoded strings and tagged strings and does not have permission to access a trusted encryption key from the encryption key storage computer system and so can only access the unprotected data and the encoded strings. Users who access the data store directly 106 in the untrusted zone 101 will see only unprotected data and encoded data substitutions.

The method carried out on the computer data encoding system may be implemented in software as a computer program. A non-transitory computer readable medium or media, such as one or more hard disk drive, solid state memory, CD-ROM or DVD-ROM may be provided that comprises instructions for carrying out the computer data encoding method.

CREATING AND STORING DATA

With reference to Figures 1 and 2, content is created through trusted client devices such as a tablet computer 107 that has appropriate software installed on it or through an authorised web browser of a local client device 108 that communicates through the reverse proxy server or intermediate server 103. The content is, for example, patient records including confidential data or PH in data fields such as name, address, date of birth and hospital number. The fields of the content to be selected for encoding may be identified or tagged (step 201, Figure 2) either when the document is designed or dynamically chosen at the time the data in the document field is entered. Fields of the created content may also include unencrypted or open fields, such as open text (non-PII).

In the case of a device 107 that may be used on or off line (that is, connected to the internet or other network or not), the data entered into selected fields is encrypted against local trusted keys (step 202 of Figure 2). That is to say, keys stored on or accessed directly by the device before the data is locally stored on the device (that is to say, stored on the device in a device store, such as a hard disk drive or solid state storage). These keys may be retrieved from the external trusted key server 102 through the communication connection 111 between the device and the key server or from the secure token 110 dynamically for each encryption or cached when the device is started. If cached, these keys may be encrypted by a further system encryption key to protect the data and keys if the device is compromised.

In other words, selected data fields are encrypted as they are entered or created against organization managed keys at a user device 107, such that records are stored such that protected fields can only be decrypted on computer equipment or electronic devices 107, 103 on which appropriate software is installed that has access to the organization’s keys.

In order to do this, fields to be protected are nominated, appropriate keys are assigned and an encryption algorithm is applied to the selected fields using the keys. The resulting dataset can be used safely for any purposes that do not require open access to the protected fields on devices such as 109, 106.

When the device 107 next has network connectivity to form a communication connection (203 Figure 2) with the intermediate server 103 it passes the record data including the data to be protected to the intermediate server 103. The proxy server allocates a unique encoded string to each tagged string or field to be protected (step 204 of Figure 2). The intermediate server passes the allocated encoded string to the device 107 by communications network 113 to allow the encoded string to be displayed alongside the data in the clear on the device to allow unambiguous identification with users not entitled to see the clear text. The intermediate server substitutes the tagged string with the unique encoded string into the data record to be passed to the external storage system 104 over communication connection 115 between the intermediate server 103 and the external storage system 104 (step 206 of Figure 2).

The encoded string may be comprised of an easily communicated word or words with or without additional characters, numbers or symbols to ensure that the string is system unique. The unique encoded string may be human-readable and, in particular, an electronic representation of human-readable or pronounceable words or characters or symbols or numbers or combinations of the aforesaid.

In the case of a device 108 on which the user enters data via a web page, the substitution with encoded strings is performed by the intermediate server 103 as the data passes through to the storage system 104. The intermediate server may optionally encrypt fields to be protected (step 202 of Figure 2) using a private key or keys obtained from the external trusted key server or key repository 102.

The proxy server 103 has a store, in this example a hard disk drive or solid state disk that creates and holds or stores a map of the tagged strings with their substituted encoded strings. This store could be located anywhere in the trusted zone 100. This map is encrypted against locally trusted keys obtained from the external trusted key server or key repository 102 through communication connection 112 between the intermediate server and the key server (step 205 of Figure 2).

The intermediate server 103 transfers the records containing open fields, such as open or unencrypted text, and the selected protected fields containing the unique encoded strings to the external storage 104 that may be separately encrypted by the external system storage keys 105.

For off line use, the proxy server or intermediate server 103 synchronises a tagged string to encoded string map with each user device 107 to allow use when connectivity is unavailable. In other words, the intermediate server sends or updates a copy of the map though a communication connection between the intermediate server and the user device 107. The map may be a selected sub-set of the full map, based on the records that are known to exist in the user’s device’s local storage. This allows the user device to display records in the clear and is explained in more detail further below.

The records stored in the external storage system 104 will be anonymous but searchable by easily entered natural or human readable words.

In the event the system security keys are compromised, the devices 107 may be forced to work off-line while the keys used by the intermediate server 103 are changed and the record store 104 is rekeyed. This process may take many hours if the amount of stored data is large. Once the rekeying is complete, the external devices are reconnected through the intermediate server. The intermediate server replaces data encrypted against compromised keys with data encrypted against new keys before transferring the data to the external store 104. This allows the system to be used in critical applications in which extended downtime would be unacceptable.

Personnel and systems may be assigned different keys to protect different parts of the same dataset and used to reveal information appropriately.

RETRIEVING DATA IN THE CLEAR BY SYNCHRONISATION WITH A DEVICE

With reference to Figures 1 and 3, the computer data encryption system 100 described provides for the automatic secure decoding of protected fields against an organisation’s private keys. In this example, the intermediate device 103 collects or receives data records to be synchronised with a mobile device 107. This content may be, for example, medical records assigned to the authenticated user of the device. On receipt of the user’s targeted content (step 301, Figure 3): the intermediate server identifies tagged protected fields; requests map data from the trusted store (step 302, Figure 3); requests a map key from the trusted key store 102 via communications pathway 112; decrypts the encoding map using this key (step 303, Figure 3); requests a data key from the trusted key store and decrypts the field data if encoded (step 304, Figure 3); substitutes the decoded strings into the data record (step 305, Figure 3); adds the encoded strings to the clear text in the record so that the data can be communicated without ambiguity to someone who is not permitted to see the data in the clear (step 306, Figure 3); if required the record may be encrypted against another key (step 307, Figure 3) before final transfer to an authorised device by communications pathway 113. The device 107 then uses its authorised user or device key to decrypt the content on-the-fly as it is displayed or stores the decrypted data in a local database to enable clear text search.

When the protected fields were encrypted before encoding, the same overall effect may be achieved by: on receipt of the user’s targeted content: the intermediate server 103 identifies protected fields; requests the map data of encoded strings to encrypted strings from a local or trusted store (step 302, Figure 3); appends the encoded strings for reference to their associated encrypted strings; substitutes these compound strings for the associated encoded strings into the content; encrypts the content with the user’s or device’s trusted key; sends the content to the authorised device 107; the device 107 requests a key from the trusted key store 102 via communications connection 111; decrypts the encrypted part of the compound strings; and inserts the cleartext and associated encoded string references into the device display on-the-fly or stores the decrypted data in a local database to enable clear text search.

Referring to Figure 1, broadly, the user device 107 may retrieve data from the external storage 104 via the intermediate server 103 over communication connection 113 between the intermediate server 103 and the user device. If the user device 107 holds or stores the synchronised map or if the intermediate server 103 performs this function on the fly as data passes through and if the device 107 can access the trusted key or keys from the trusted repository 102 or the secure token 110 (the key on the token is written by the key server 102 and the token 110 is then available to the device by for example a card reader), it will be able to display selected protected data fields in the clear.

RETRIEVING DATA IN THE CLEAR THROUGH A WEB BROWSER

With reference to Figures 1, 4 and 5, the computer data encoding system 100 described provides for the retrieval of data in the clear in response to a clear text search. Retrieving data in the clear in response to a clear text search by an authorised user requires additional processing by the intermediate server 103. The intermediate server 103 must be located in a secure trusted location and must maintain a local or trusted database of mappings of data in the clear strings to encoded strings. If the mapping table is encrypted, it must be decrypted (step 402 Figure 4) each time a request from a device 108 is received.

To retrieve a single record, the user will need to enter as many data fields as necessary to achieve an unambiguous match. An example is first name, last name, address, and date of birth. When a user enters a clear text search string or strings (108, Figure 4) the intermediate server will search the database that contains the mapping of clear text strings to encoded strings. On successful unique match, the intermediate server 103 will retrieve the record from the storage system 104 (Figure 1) by requesting the record (115, Figure 4) by the looked-up encoded strings. As the data is passed back to the client device 108, the clear text with its associated encoded strings are inserted into the page for reference to allow easy and safe communication with users not entitled to see PH.

In the example shown in Figure 5, the words “John Smith” are entered into a search field in an Internet browser or application. The browser or application passes a request 502 to a web site or web service on the intermediate server (504, Figure 5). The intermediate server 103 looks up “John Smith” in its map database 503 which may be encrypted and builds a request query with the encoded string “CatDog123” found for “John Smith” and passes this request 505 to a web server 507 attached to the untrusted data store (104, Figure 1). The record for user “CatDog123” is retrieved from the external untrusted store and passed in the web response 506 to the intermediate server 504. In this example, the intermediate server inserts the clear text (“John Smith (CatDog123)”) into the record and passes the result through the web response 512 to the authorised requesting website or application. The result in response to the query “John Smith” will be the correct record showing “John Smith (CatDog123”). The encoded string may be shown associated with the text in the clear string in any way that makes the association clear.

If the search string “CatDog123” is passed to a collaborator or other user not entitled to see PH they will be able to retrieve the same record by navigating to the URL of the untrusted server (507, Figure 5) and entering “CatDog123” into any web browser or web connected device search field. This will cause a web request or other retrieval method to be requested 508 from the web server 507. In the same way as the server 507 responds to a trusted request 505, the server will respond with the record matching the search key. The response 509 will return the record without Pll 511 which will only show the entered search key. In normal use, the page also contains non-PII identification information that allows unambiguous confirmation that the correct record has been retrieved.

An example of using this sequence is for a physician retrieving the record of a patient John Smith and wanting an opinion from an expert located overseas. The physician communicates with the expert and asks him or her to retrieve the record for the patient on their screen. The phrase “CatDog123” may be communicated by email or telephone or any other communication mechanism. The expert then enters the string “CatDog123” and retrieves the same patient’s record. The expert would confirm some information from the displayed screen to the physician to ensure that both are looking at the same patient.

In another example, in a disaster event anywhere in the world, clinicians in a field hospital may be entering patient data into an electronic records system with PH. The disaster team need to be able to see text in the clear. There are several advantages to a mirrored system being available in the medical team’s host country by way of example remote medical coding, provision of specialist advice and providing information for reporting and control. The mechanism described allows the PH to be removed before data leaves the disaster zone permitting transfer across international borders. The home team has no need to be able to identify patients but it is essential that as processed records are returned to the field in the disaster zone that they can be coupled unambiguously to the correct patients. This collaborative safe working allows the cost of rescue missions to be reduced and allows some of the team to be kept out of harm’s way.

RETRIEVING ENCODED DATA THROUGH A WEB BROWSER

A user not authorised to view PI I may still access records by searching for encoded strings. A device 109, 106 may retrieve data from the external storage device 104 even if it does not have access to a copy of the map or trusted keys, the trusted repository 101 or the secure token 110. In this case, the device will display encoded data in the selected protected fields.

In this example, a user is asked to find a record by searching for an encoded string. The web servers or web services or file servers of the external storage 104 operate rules that ensure data is only provided from a search of the data if enough key words are entered to guarantee an unambiguous unique match. If, as an example, it is desired to retrieve a patient’s record in a foreign country using only encoded data it is necessary to enter only a few natural or human readable words or data fields. To protect a patient’s identity, it is usually considered necessary to anonymise their first name, last name, date of birth, address and health system identifier. To retrieve this patient’s record from potentially millions of encrypted records, it is only necessary to enter less than ten common words. If the health system number is guaranteed to be unique it would only be necessary to enter a single word and qualifier, for example, a house number, no other processing, software or equipment is required.

Referring to Figures 6, an example is presented of a method that produces a list of unique easily described encoding strings. It is usual but not essential to choose a language 600 spoken by all parties that wish to collaborate. A reference dictionary 601 is used that identifies the part of speech for each word or word class for example adjective, adverb, noun and verb. The dictionary is pre-processed 603 to remove undesirable artefacts for example hyphens, underscores, single character words and apostrophes. The list may be further restricted to words shorter than a pre-set limit, for example, six characters. The outcome of this pre-processing is to produce several tables of words 607 from which the final string is assembled.

A separate dictionary of common words (known by most people) 602 is also stripped of undesirable artefacts 604 and is used to create a list of Data Words 608. The Data Word list 608 is used to gate the tables of words (step 611) to produce a filtered Word Source Table 612.

A Bad Word list 610 is created by applying exclusion rules that may include homophones, slang, medical words, religious words, offensive words, profane words, sexual words etc. followed by final human inspection 609. The Bad Word table or list is used to filter or gate the Word Source Table 612 (step 613) to provide a list of words that can be combined to produce unique strings for use in encoding that should not cause offense. The filtered words are assembled into compound strings 614 such that only words of the same part of speech or word class are combined for example adverb adverb, verb verb, noun noun etc. Final acceptability inspection is then carried out (step 615). Finally, a numeric or symbolic qualifier may be added to the processed words if required to extend the number of unique combinations (step 616).

Figure 7 shows an example of the encoding process or method in more detail. A record containing a tagged field (in this case “John Smith”) is received by the encoding logic 701. The next available pre-prepared composite encoding string in table 702 (in this case “catdog123”) is assigned to the string “John Smith” and stored in step 703 to the secure mapping database 704. The encoded string “catdog123” is substituted into the record 705 for “John Smith” and is sent to the external untrusted store 104 (of Figure 1) by communications pathway 706. Finally, the encoded string “catdog123” is added 707 to the clear text string “John Smith” for example as “John Smith (catdog123)” and returned to the source device 107 by communications pathway 709. The authorised user is now able to communicate the encoded string to an unauthorised user so that the same record may be discussed without ambiguity without revealing the protected data.

Figure 8 shows a simplified example of a method for decoding protected strings by looking up a clear text Pll string from the trusted secure data map to allow substitution into a retrieved record. In this example a set of records have been retrieved based on a set of search criteria. The records are complete but show substituted encoded text that needs to be replaced with the original Pll. Only devices or software that have access to the encoding map will be able to resolve the Pll.

The intermediate server (Figure 1, 103) or a device with a local synchronised mapping table would start decoding tagged field look up 800, which in the example shown is “catdog123”, by searching each substituted encoded string in this example “catdog123” (step 801). The trusted mapping database 802 may be optionally encrypted: it is only accessible by authorised users and processes in the trusted zone. The result of the search in the example is the Pll or in the clear string “John Smith” (step 803). The original encoded string “catdog123” is appended to the retrieved Pll string in step 805 to create the compound string “John Smith (catdog123)”. The Pll and encoded string may be combined in any way that makes the association clear. This compound string is then substituted into the record for the original search string i.e. “catdog123” becomes “John Smith (catdog123)”. Communications pathway 807 returns the data to the authorised user’s browser or device.

An example would be a list of patients that meet a particular set of medical conditions. Authorised users in the trusted zone would retrieve a list of identifiable patients whereas unauthorised users would retrieve the same list without Pll.

Figure 9 shows a simplified example of the process or method needed to enable retrieval of records with inexact searches. In the example shown, “Jon Smith” is entered into a search field to retrieve a record 901. In this example, this is misspelt as the record required is for “John Smith” with an “h” in “John”. Standard search mechanisms are used to retrieve any records that might be indicated by the search string from the mapping database 902. At step 903 a series of records are requested from the external untrusted data store 906 by the keys “dark tin”, “water radio”, “catdog123” and “fish house” found as a result of the inexact search 901. At step 904, the retrieved records are processed as shown in Figure 8

i.e. the Pll and associated encoded strings are inserted into the records and displayed to the user. The additional information in the record in this medical example the address, age and sex of the patient returned in the record is displayed together with the Pll to allow the chosen record to be identified unambiguously: in this example, the third entry “John Smith”. At step 905, the full record of the correct patient is returned to the user performing the search with “John Smith (catdog123)“ substituted into the record.

The simplified workflow in this example is: a physician enters the name of the patient for whom they wish to retrieve their medical record into a web browser or device 901. They type the name incorrectly making an exact search impossible. Simple and well known search algorithms are used to retrieve a list of patients who closely match the entered search name 903. These records are retrieved by the encoded keys found by looking up the possible patients by their Pll information in the mapping table. The system displays a list of possible matches 904 showing both the Pll and other field data to allow the use to select the correct record. The final step 905 shows the record chosen by the user displaying both the Pll and its associated encoding to allow discussion with colleagues not authorised to view Pll or for other purposes of validation.

A typical method is to consider records that meet Distance Criteria (how many changes required to obtain a match). The intermediate server or computer system (103, Figure 1) requests records with the found encoded strings from the external server 906. The possible match strings are shown to the user 904 to allow selection of the desired record in this case “John Smith”. The intermediate server or computer system then presents the record for “John Smith” with the name in the clear associated with the encoded string; in this case as “John Smith (catdog123)”.

Embodiments of the present invention have been described. It will be appreciated that variations and modifications may be made to the described embodiments within the scope of the present invention.

Claims

1. A computer data encoding system comprising: an intermediate computer system configured to:

receive an encrypted data string from an electronic device;

5 assign a unique encoded string to the encrypted data string;

substitute the encrypted data string with the encoded data string; send the encoded data string to a data storage computer system; send the encoded data string to the electronic device; and store a map of the assignment of the encrypted data string to the

10 encoded string.

2. A computer data encoding system according to claim 1, wherein the map is unencrypted.

3. A computer data encoding system according to claim 1, wherein the map is 15 encrypted using a key.

4. A computer data encoding system according to claim 3, wherein the key is stored at an encryption key storage computer system that has no access to the data storage computer system.

5. A computer data encoding system according to claim 4, wherein the key stored in 20 the encryption key storage computer system is accessible only by the data owner or a trusted third party and/or is located at a trusted location.

6. A computer data encoding system according to any preceding claim, wherein the data string includes personally identifiable information.

7. A computer data encoding system according to any preceding claim, wherein an 25 electronic device retrieving data from the data storage computer system without access to the map and/or without access to the key retrieves the data string without personally identifiable information.

8. A computer data encoding system according to any preceding claim, wherein the encoded string is human readable.

9. A computer data encoding system according to claim 8, wherein the encoded string comprises 20 or less characters, such as a common word, dictionary word or words with or without a numeric or symbol qualifier.

10. A computer data encoding system according to any of claims 8 or 9, wherein the encoded string comprises at least two dictionary words.

11. A computer data encoding method according to claim 10, wherein the at least two dictionary words comprise words of the same word class such as verbs, nouns or adverbs.

12. A computer data encoding system according to any preceding claim, wherein the data string includes open information.

13. A computer data encoding system according to any preceding claim, wherein the intermediate computer system comprises a proxy server and/or the electronic device comprises a computer such as a laptop computer, desktop computer, tablet computer, smartphone or the like.

14. An electronic device for use in a computer data encoding system, the electronic device being configured to obtain and decode an encoded and encrypted data string by:

obtaining an encoded string from a data storage computer system; interrogating a map of the encoded string to an encrypted data string to find an encrypted data string that is mapped to the encoded string; and decrypting the encrypted data string.

15. An electronic device according to claim 14, wherein the map is unencrypted.

16. An electronic device according to claim 14, wherein the map is encrypted using a key to form an encrypted map.

17. An electronic device according to claim 16, further comprising, before decrypting the encrypted data string:

obtaining a key from an encryption key storage computer system, wherein the key enables decryption of the encrypted map of the encoded string to the encrypted data string; and decrypting the encrypted map using the key.

18. An electronic device according to claim 16 or claim 17, wherein the electronic device is configured to obtain only selected encoded data strings if it cannot obtain the key and/or the encrypted map.

19. An electronic device according to claim 18, wherein the encoded data strings 5 comprise non-confidential or anonymised data.

20. An electronic device according to any of claims 14 to 19, wherein the encoded string is human readable.

21. An electronic device according to claim 20, wherein the encoded string comprises 20 or less characters, such as a common word, dictionary word or words with or without a

10 numeric or symbol qualifier.

22. An electronic device according to any of claims 20 or 21, wherein the encoded string comprises at least two dictionary words.

23. An electronic device according to claim 22, wherein the at least two dictionary words comprise words of the same word class such as verbs, nouns or adverbs.

15

24. An electronic device according to any of claims 14 to 23, wherein the electronic device further comprises a store and the encrypted map is stored in the store.

25. An electronic device according to claim 24, wherein the electronic device is configured to synchronise the encrypted map stored in the store with the encrypted map stored in an intermediate computer system.

20

26. An electronic device according to any of claims 14 to 25, wherein the electronic device is configured to retrieve encoded strings that match in the clear search strings to enable records to be retrieved from a data storage computer system.

27. An electronic device according to claim 26, wherein the electronic device is configured to search the encoded strings mapped to encrypted data strings using at least

25 one matched keyword.

28. An electronic device according to any of claims 14 to 27, wherein the electronic device comprises a computer such as a laptop computer, desktop computer, tablet computer, smartphone or the like.

29. A computer data encoding method comprising:

5 an electronic device: creating a data string; encrypting the data string to form an encrypted data string; and transferring the encrypted data string to an intermediate computer system;

the intermediate computer system: receiving the encrypted data string; assigning a unique encoded string to the encrypted data string; substituting the encrypted data string

10 with the encoded string; sending the encoded string to a data storage computer system;

sending the encoded string to the electronic device; and storing a map of the assignment of the encrypted data string to the encoded string.

30. A computer data encoding method according to claim 29, wherein the map is

15 unencrypted.

31. A computer data encoding method according to claim 29, wherein the map is encrypted using a key.

32. A computer data encoding method according to claim 31, further comprising: an encryption key storage computer system storing the key, wherein the encryption key

20 storage computer system has no access to the data storage computer system and the map.

33. A computer data encoding method according to claim 32, wherein the key stored in the encryption key storage computer system is accessible only by a trusted third party.

34. A computer data encoding method according to any of claims 29 to 33, wherein the

25 encoded string is human readable.

35. A computer data encoding method according to any of claims 29 to 34, wherein the data string includes personally identifiable information.

36. A computer data encoding method according to any of claims 29 to 35, further comprising an electronic device retrieving data from the data storage device without access to the map and without access to the key retrieves the data string without personally identifiable information.

37. A computer data encoding method according to any of claims 29 to 36, further comprising, if the data string comprises a small number of characters, such as 100 or less

5 characters, reversibly adding a unique padding string to the data string before encrypting the data string to form an encrypted data string.

38. A computer data encoding method according to any of claims 29 to 37, wherein the encoded string comprises a human readable string.

39. A computer data encoding method according to any of claims 29 to 38, wherein the 10 encoded string comprises 20 or less characters, such as a dictionary word or common dictionary word.

40. A computer data encoding method according to any of claims 29 to 39, wherein the encoded string comprises at least two dictionary words.

41. A computer data encoding method according to claim 40, wherein the at least two 15 dictionary words comprise words of the same word class such as verbs, nouns or adverbs.

42. A computer data encoding method according to any of claims 29 to 41, wherein the data string includes open information.

43. A computer program for carrying out the computer data encoding method of any of claims 29 to 42.

20

44. A non-transitory computer readable medium comprising instructions for carrying out the computer data encoding method of any of claims 29 to 43.

45. A computer data encoding system as substantially herein described with reference to, and as illustrated by, the accompanying drawings.

46. An electronic device for use in a computer data encoding system as substantially 25 herein described with reference to, and as illustrated by, the accompanying drawings.

47. A computer data encoding method as substantially herein described with reference to, and as illustrated by, the accompanying drawings.

48. A computer program for carrying out the computer data encoding method as substantially herein described with reference to, and as illustrated by, the accompanying drawings.

49. A non-transitory computer readable medium comprising instructions for carrying out 5 the computer data encoding method as substantially herein described with reference to, and as illustrated by, the accompanying drawings.

ytAjg/ZW»1

Intellectual

Property

Office

Application No: Claims searched: