GB2514997A

GB2514997A - Data handling system

Info

Publication number: GB2514997A
Application number: GB1306875.4A
Authority: GB
Inventors: Victor Robert Leonard; Nigel Duncan Kelly; Paul Howarth Skye; Paul Andrew Buckley
Original assignee: Individual
Current assignee: Individual
Priority date: 2013-04-16
Filing date: 2013-04-16
Publication date: 2014-12-17
Also published as: GB201306875D0

Abstract

In a health care system a user is provided with a health care user personal health data storage device 1 having coupling means 3 operable to couple the device to a plurality of health care service provider entity 17, 21, 22, 23, 25 for transferring data between the device and the entities. The device is operable to receive data relating to health care provided to the user and to store this data so that the device holds a record 7 of health care services provided by the plurality of health care service provider entities. A primary health care service provider entity. such as a general practitioner or personal physician, may store data corresponding to the data on the card in a master data record 19. A further embodiment users cloud storage rather than a card.

Description

Data Handling System

TECHNICAL FIELD

The present invention relates to an arrangement for an entity for storing and transferring data and to a system in which such an arrangement is used.

BACKGROUND TO THE INVENTION

In many systems, such as current health care systems, data (documents and information) may be generated by a multiplicity of different service (e.g. health care) providers, such as general practitioners (GAs) or other personal physicians, hospitals, pharmacists, midwives, ambulance services, dentist, etc. Often the data that are generated by one service provider is not made available elsewhere, meaning that the data are not available to other service providers -which can be inconvenient and even dangerous if the data may affect how the patient should be treated. In a health care system, some data are provided to the general practitioner in an attempt to provide a centralised data store for each health care user. However, these documents are generally sent in paper form by post, which is rather bureaucratic and prone to delays and error.

Attempts have been made to integrate the computer systems of various health care service providers at great cost. However, these have generally not been successful.

A further feature of known health care arrangements is that the health care user can feel excluded from the health care process, and may feel that the health care services providers have much data relating to the user which the user is not able to access.

Charges for health care services are also more widespread now and the need to track what an individual is spending plus what health care providers are charging is becoming increasingly important.

I

Similar challenges arise in relation to services provided to animals (e.g. veterinary services) and also to services/process applied to animals after slaughter (e.g. tracking movement and processing of meat).

Embodiments of the present invention seek to overcome some of these drawbacks of conventional arrangements.

SUMMARY OF THE INVENTION

In one aspect the present invention provides a data storage arrangement for an entity, having coupling means operable to couple the storage arrangement to a plurality of service providers for transferring data between the storage arrangement and the service providers, the storage arrangement being such that it is operable to receive data relating to services provided to the entity and to store this data so that the arrangement holds a record of services provided by the plurality of service providers.

The storage arrangement may be in the form of cloud based storage whereby the data stored is accessible through the Internet via a custom built application hosted by a suitable device, such as a PC, tablet or smart phone.

The coupling means may enable a secure Internet connection for uploading the data onto the cloud based storage.

The storage arrangement may be a device in the form of a card which is conveniently transportable by the user -for example, credit card sized. The device may be a health care data card. The device may be an NFC (Near Field Communication) enabled Smartphone, SmartCard or similar device, The coupling means for the card may be a USB connector or any other form of connector that allows the transmission of data by mechanical coupling or wire es sly.

The storage arrangement may hold data relating to animals or people. The storage arrangement may be used to hold all medical documentation and key medical history across the full range of health care services used by the entity. It may hold the information in document and summary form as if the reader were "viewing the case notes of the entity. This means that the storage arrangement does not need a complex means of data integration with a wide variety of health record databases and systems but simply integrates the output from these systems into a readable format and presents them S through a document reader which may be all contained as a secure application on the card (if applicable) or a mobile application.

The storage arrangement may hold data relating to the medical treatment of an animal (veterinary data). The system may allow veterinary professionals and animal owners to access the data. The system may continue to store data relating to animals after slaughter, so that the processing of the animals after slaughter can be monitored and the provenance of meat products can be traced back to the animal that was the source of the products.

The present invention does not need a complex means of data integration with a wide variety of health record databases and systems but may integrate the output from these systems into a readable format and present them through a document reader which may be all contained as a secure application on the card (if applicable) or within a mobile application.

The data may comprise information and documents. The documents may be stored in a predetermined form. The documents can be accepted onto the storage arrangement in any electronic format and then presented back through the viewer application as an image. Advantageously, the documents are stored in a form which is common standard, such as PDF. In this way, the storage arrangement does not require the capability to handle documents in a multiplicity of formats.

An advantageous aspect of the storage arrangement (e.g. card or cloud storage) is that it will hold and maintain all documentation relating to all the health services used by the cardholder. The instant availability and transportability of this key information across all these service providers will bring about the convergence of personal and key medical data about the card holder across currently disparate systems.

The storage arrangement may include means operable to store user identification information. The user identification information may include a password, PIN, a photograph, biometric data and the like. The storage arrangement may include authentication means that controls access to the data on the storage arrangement. The authentication means may compare the stored user identification information with input information to perform authentication. For example, the user may enter their password (and/or other personal data, such as their NHS number) in order to access the storage to arrangement. The entered password is input to the device and compared with a password previously stored on the device. In this way, it can be verified that the person accessing the data is the user that has provided the password previously.

In another arrangement, a different type of authentication may be performed.

The authentication means allows a photograph of the user from the user identification information to be displayed so that this can be compared with the user holding the card or accessing the cloud storage, in order to allow a third party to confirm that the holder of the card is the user to which the data relates. This can be particularly useful if the user is incapacitated (for example, by injury), as this enables emergency personnel to verify that the data on the card or the cloud storage belongs to the user. The user may be given the option to allow their summary details (or possibly all the details) to be visible to others in case of an emergency. This removes the need to have a complex and possibly unworkable security system that enables emergency services to over-ride' the normal security. If the user decides to keep their data safe for only their access then it would not be available to others in an emergency.

In another aspect, the present invention provides a system which includes the storage arrangement as defined above, and which further includes the plurality of service provider entities defined above, and wherein the service providers include a primary service provider operable to store data corresponding to the data stored by the arrangement.

S

The storage arrangement may be operable to transmit the data between the storage arrangement and the primary service provider via the coupling means. The transmission of data may be a mechanical coupling of the S storage arrangement to the primary health care service provider entity or the data may be transmitted via a network, such as the Internet or a cellular telecommunications network.

Such a primary service provider may be a general practitioner (GP) or other personal physician. If such a primary health care service provider entity stores data corresponding to the data on the card or cloud storage, this provides a back-up of that data so that the data are not lost should the storage arrangement be lost or damaged. For those users choosing to use this invention on mobile devices, such as mobile phones, tablets or any such devices, (wireless/network coupling) they may choose to store their data on the cloud based storage so that it will be accessible wherever they can access the Internet, Those users only wanting to use the USB card device (mechanical coupling) may have their device backedup' with their GP's system to ensure the data can be recovered in the event of a lost, stolen or damaged card.

The embodiment to be described includes means for providing a single point of access to a variety of documentation and services that are used either routinely or in exceptional circumstances by the entity.

The card or cloud storage may also contain basic personal data about the entity that will facilitate securing the documents on the card or cloud storage and also in identifying that the stored data does in fact belong to the individual entity. n

The health care data card or cloud storage may centralise all health records into one location and it allows health professionals to access all health records (in contrast to previous arrangements). The card may also be used as a charge card for paying for these services. The storage arrangement may log the cost of each service to provide a full audit trail of health care costs for the individual card entity and the health care services in generaL The card itself may be a very simple design based on proven, highly portable technology that is easy to use and will be familiar to anyone who uses a PC or laptop with a USB connector.

The unit cost of the basic card may be very small. The cost of implementing the solution may be very low if the run time version of the software is loaded onto the card This makes it a viable proposition to the general public and to the health service providers alike.

The cloud storage solution may be provided as a web service linked to any PC or mobile device via a secure login. The means of access may be controlled by a custom web service application. Cloud storage will be secure Internet storage dedicated to this service.

The solution may provide a fully auditable set of documentation with an audit trail of who made changes and when collected on the storage arrangement and synchronised with the master data records from each health service provider.

The storage arrangement concept can be broken down into two components based on the type of use expected of the card. These are: Everyday" health care data card carried by a user, and hospital records/treatment card for emergencies and one-off cases.

Documentation can be synchronised onto a person's storage arrangement, in the same way as their current doctor's records would be today after a hospital visit. The hospital records card could be used standalone for the duration of the person's stay in hospital and only used "locally" to record treatment, medication and surgery information. In this instance the documentation used by the hospital can be stored as templates on the storage arrangement and then used to build up the medical file during the person's stay The storage arrangement may also hold the same information as a European Health Insurance Card (EHIC), and so may be used for the same purpose as a EHIC. )

The storage arrangement may also hold the wishes of the cardholder in respect of Organ Donation and so may be used as an Organ Donor Card.

In another aspect the present invention provides a health care service user personal health data storage device having coupling means operable to couple the device to a plurality of health care service provider entities for transferring data between the device and the entities, the arrangement being such that the device is operable to receive data relating to health care provided to the user and to store this data so that the device holds a record of health care services provided by the plurality of health care service provider entities.

The device may be in the form of a card which is conveniently transportable by the user -for example, credit card sized. The device may be a health care data card. The coupling means may be a USB connector or any other form of connector that allows the transmission of data by mechanical coupling or wirelessly.

The device health care data (e.g. card) may be used to hold all medical documentation and key medical history across the full range of health care services used by the cardholder. It may hold the information in document and summary form as if the reader were viewing" the case notes of the cardholder, This means that the card does not need a complex means of data integration with a wide variety of health record databases and systems but simply integrates the output from these systems into a readable format and presents them through a document reader which may be all contained as a secure application on the card or a mobile application.

The present invention does not need a complex means of data integration with a wide variety of health record databases and systems but may integrate the output from these systems into a readable format and present them through a document reader which may be all contained as a secure application on the card or within a mobile application.

The data may comprise information and documents. The documents may be stored in a predetermined form. Advantageously, the documents are stored in a form which is common standard, such as PDF. In this way, the device does not require the capability to handle documents in a multiplicity of formats.

An advantageous aspect of the device (e.g. card) is that it will hold and maintain all documentation relating to all the health services used by the cardholder. The instant availability and transportability of this key information across all these service providers will bring about the convergence of personal and key medical data about the card holder across currently disparate systems.

The device may include means operable to store user identification information. The user identification information may include a password, PIN, a photograph, biometric data and the like. The device may include authentication means that controls access to the data on the card, The authentication means may compare the stored user identification information with input information to perform authentication. For example, the user may enter their password in order to access the data. The entered password is input to the device and compared with a password previously stored on the device. In this way, it can be verified that the person accessing the data is the user that has provided the password previously.

In another arrangement, a different type of authentication may be performed.

The authentication means allows a photograph of the user from the user identification information to be displayed so that this can be compared with the user holding the card, in order to allow a third party to confirm that the holder of the card is the user to which the data relates. This can be particularly useful if the user is incapacitated (for example, by injury), as this enables emergency personnel to verify that the data on the card belongs to the user. The user may be given the option to allow their summary details (or possibly all the details) to be visible to others in case of an emergency. This removes the need to have a complex and possibly unworkable security system that enables emergency services to over-ride' the normal card security. If the user decides to keep their data safe for only their access then it would not be available to others in an emergency.

In another aspect, the present invention provides a health care system which includes the health care service user personal health data storage device as defined above, and which further includes the plurality of health care service provider entities defined above, and wherein the health care service provider entities include a primary health care service provider entity operable to store data corresponding to the data on the card.

The device may be operable to transmit the data between the device and the primary health care service provider entity via the coupling means. The transmission of data may be a mechanical coupling of the device to the primary health care service provider entity or the data may be transmitted via a network, such as the Internet or a cellular telecommunications network.

Such a primary health care service provider entity may be a general practitioner (GP) or other personal physician. If such a primary health care service provider entity stores data corresponding to the data on the card, this provides a back-up of that data so that the data are not lost should the device be lost or damaged. For those users choosing to use this invention on mobile devices, such as mobile phones, tablets or any such devices, (wireless/network coupling) they may choose to store their data on a cloud based storage service so that it will be accessible wherever they can access the Internet. This also provides a backup of their data. Those users only wanting to use the USB card device (mechanical coupling) may have their device backed-up' with their GP's system to ensure the data can be recovered in the event of a lost, stolen or damaged card.

The embodiment to be described includes means for providing a single point of access to a variety of documentation and services that are used either routinely or in exceptional circumstances by the healthcare data card holder.

The card may also contain basic personal data about the cardholder that will facilitate securing the documents on the card and also in identifying that the card does in fact belong to the individual cardholder.

The health care data card may centralise all health records into one location and it allows health professionals to access all health records (in contrast to previous arrangements). It may also be used as a charge card for paying for these services and logging the cost of each service to provide a full audit trail of health care costs for the individual card holder and the health care services in general.

The card itself may be a very simple design based on proven, highly portable technology that is easy to use and will be familiar to anyone who uses a PC or laptop with a USB connector.

The unit cost of the basic card may be very small. The cost of implementing the solution may be very low if the run time version of the software is loaded onto the card. This makes it a viable proposition to the general public and to the health service providers alike.

The solution may provide a fully auditable set of documentation with an audit trail of who made changes and when collected on the card and synchronised with the master data records from each health service provider, The card concept can be broken down into two components based on the type of use expected of the card. These are: Everyday" health care data card carried by a user, and hospital records/treatment card for emergencies and one-off cases.

Documentation can be synchronised onto a person's health care data card, in the same way as their current doctors records would be today after a hospital visit. The hospital records card could be used standalone for the duration of the person's stay in hospital and only used "locally" to record treatment, medication and surgery information. In this instance the documentation used by the hospital can be stored as templates on the device and then used to build up the medical file during the person's stay.

The card may also hold the same information as a European Health Insurance Card (EHIC), and so may be used for the same purpose as a EHIC.

The card may also hold the wishes of the cardholder in respect of Organ Donation and so may be used as an Organ Donor Card.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention an embodiment will now be described by way of example, with reference to the accompanying drawings, in which: Figure 1 shows the core system architecture of a first embodiment to the invention; Figure 2 shows a modified core system architecture to that of Figure 1; Figures 3 to 6 show a graphical user interface of the system when accessed by a user's smart phone; Fig 7 shows a scenario for Healthcare Professionals, HCPs, carrying out their regular (e.g. daily/weekly) rounds in accordance with an embodiment of the invention; Fig 8 shows the concept of Mymedi Medical History Timeline in accordance with an embodiment of the invention; Figure 9 shows the concept of using a Smartcard containing an NFC (Near Field Communication) chip or tag that stores secure encrypted patient data; Figure 10 shows a schematic view of the health care system in accordance with an embodiment of the invention; Figure 11 shows a schematic view of a health care user data storage device coupled to a personal data processing apparatus in accordance with an embodiment of the invention; 1 0 Figure 12 shows the steps taken to synchronise data on the health care user data storage device with that of a physician in accordance with a first procedure; Figure 13 shows the steps performed to transfer data between a health care user data storage device and a physician in accordance with a second procedure; and Figure 14 shows schematically the elements involved in the exchange of data between a health care user data storage device and a hospital system.

In the drawings like elements are generally designated with the same reference signs.

DETAILED DESCRIPTION OF EMBODIMENT OF THE INVENTION

Figure 1 shows the core system architecture of a first embodiment of the invention. The solution is a means of capturing documents that relate to an event. An event could be a visit to a person's GP or Dentist or a hospital that generates a document or update that gets added to the person's overall health record. The event is created in the solution by categorising the event using pre-set event names and then attaching the relevant document to that event. The event is linked to the person by their NHS number. The numbered steps in Figure 1 can be summarised as follows: 1. Data Input/Migration/Transfer a. The customised web service can be run from a PC or other Internet connected device that is used by the health service provider to capture and maintain the medical information and records about the patient.

b. It is accessed by the health service provider logging on to the administration version of the web service via a secure login.

Authentication will consist of a user id (generated at registration) and a password plus a One Time Password -online generated secure access code (from Vasco component)..

c. Note: It is envisaged that the document upload facility will eventually be integrated into the health service providers application through an agreed API such that the upload can be achieved by a single click of an Upload' button.

d. Until the above API is implemented the health service provider will be required to export an electronic copy of the patients records from their system onto a local storage area. They can choose which records to export. The format of the export is not critical to the service.

e. Once logged onto the web service the health service provider selects the Document Upload' option.

f. The health service provider then enters the NI-IS number for the patient for whom they are uploading the data.

g. They then select the relevant category of health service provider (eg GP, Dentist....) and locate the file to be uploaded.

h. They then press Save and the document is uploaded to the cloud storage service and is immediately available for viewing.

Alternatively they can connect the physical card storage device via a USB connection and transfer the records directly to the card.

I. If the health service provider can only generate a paper copy of the health records then these can be converted to an electronic image through scanning or by taking a photo on a mobile device and then uploading that image into the device via the web service administration tools described above.

2. Web Service a. The web service transfers the electronic copy of the document and stores it on a dedicated cloud service.

3. Data Centre S a. The cloud service uses a commercial data centre for storing the documentation.

b. This data centre can be secured to the level stipulated by the NHS IT Security Policy.

c. The data centre provides the core storage and a secure backup service.

4. Admin Console System Administrator a. An end user is provided with an administration facility that allows them to control their access process and to help setup specific user groups relevant to their needs.

b. Each user can choose which documents andIor meta data fields are to be made visible to health care providers. They can choose all or none or select specific data items.

c. Family access can be set up for parents to be able to administer and view their children's health records.

d. Field group access can be set up to create a working group of health care providers who need to have coordinated access to a patient's records (eg GP, Care Home, Social Services may form a specific group for a particular patient).

e. The end user can enter and maintain their personal data (the meta data) through the administration function.

5. Actor View a. The documents stored on the device Card or Cloud) are viewed through a custom application that can be run on any mobile device (Smart Phone, Tablet, Laptop, PC etc) connected to the Internet.

The viewer application can view any document type (PDF, MS Office, Image etc).

b. The end user accesses their records through the application using a secure login process.

c. They can then view documents that can be filtered by event types and date/time.

d. They can see their personal data and access settings.

e. For those who have set up group/family access then they have an extra filter based on the categories with that group (eg family

members or field group titles).

6. FieldGroupView

a. The field group view is a specific filter for a group of health care providers that need access to the latest set of medical / health records for a patient.

b. When the group is set up each member of the group is identified by their service registration number. They then use this to gain access to the group view through the standard login process.

Figure 2 shows a modified core system architecture which shows the input of various patient events such as GP appointment, hospital appointment, hospital operation and dentist check-up. The elements 1 to 6 of Figure 2 are similar to the like-numbered elements ito 6 of Figure 1.

Figures 3 to 6 show a user interface that will be available to a user if the system when accessing the system using a smart phone.

Figure 3 shows a log-in page.

Figure 4 shows a homepage, which may be displayed after log-in, which allows the user to select either "appointments", "health services', "medical" or "emergency".

Figure 5 shows the content made available if the "appointments" option is selected. A menu of appointments is displayed, and the user may then select a particular appointment to obtain further information about that appointment.

Figure 6A shows the information displayed when the option "medical" is selected. A list of medical options is displayed. The user may then select one of these options, such as "GP". More detail relating to the option is then displayed, such as various OP records. An individual record may then be selected in order to view that record in detail.

Figure 6B, 60 and 6D show what is displayed when the emergency option is selected. The first screen displayed is a menu of data that might be relevant in an emergency, such a personal information, immunisation status, blood type, current problems, past history, allergies, donor details and EHIC details.

The content displayed when each of these options is selected is shown, by way of example, in Figure6D.

Healthcare Professional Daily Rounds: Figure 7 shows a scenario for Healthcare Professionals, HCPs, (e.g. Doctor, specialist consultant, surgeon, care worker, social worker) carrying out their regular (e.g. daily/weekly) rounds on a ward, department, care home, household or other facility. The system enables a HOP performing daily rounds to assess, consult and record wellbeing, progress and health of patients.

The HOP View provides information to assist the HCP with their tasks, such as daily schedule and patient location. This also provides a link to individual patient medical records, notes and event information.

The system provides an easy method for an authorised HOP to add/view/edit patient records, notes and information, either by data entry or by voice recognition. This makes it possible for a HCP to make notes by dictating into a tablet or mobile device. This feature is very useful in busy environments, such as a Hospital Ward Doctor on their daily rounds visiting many patients.

They will have records, notes and information on each patient at the touch of a button. All records, notes and events are accessible in one place, even if a patient is moved to a different ward, room, building or hospital.

When a HOP adds a record, note or event to a patient record, this is added to the patient mymedi account and appears under the correct category on the patient timeline. For example a Hospital Ward Doctor adds an entry for a Hospital visit. The entry will appear on the patient mymedi account under Hospital category. This information wilt be available to all HCPs who have been granted access by the patient.

Mymedi Medical History Timeline: Figure 8 shows the concept of Mymedi Medical History Timeline. The concept is based around securely storing all records, notes and information in one place over an individual's lifetime. From birth to present day, the concept allows every record, note, appointment, operation or other event to be recorded on a Patient timeline. This provides a to full medical history to all Healthcare professionals a Patient may come into contact with over their lifetime.

The following system modules may be provided that provide the functionality discussed below, for example.

SYSTEM MODULES

Mymedi Patient Records * Synchronised Electronic Medical Records in one place * Filtered by ascending or descending chronological order, time period, record type, medical category Mymedi Appointments * Manage a Patient's appointments from one location * Reminders for all appointments * Check availability for appointments * Set up appointments when a Patient is to be referred to a specialist Mymedi Emergency * Patient's Emergency details and information accessible by authorised user Mymedi Symptom Diary (Recording Symptoms over a specified Period) * Patients often find it difficult to provide an accurate account of how they have been feeling or symptoms experienced.

* The Symptom Diary is a Mymedi function to be used by a Patient and accessible to authorised Healthcare Professionals.

* A Patient has the ability to keep a record of their own medical symptoms, notes or information over a period of time.

* The Symptom can be saved as a text note, a voice recording or a photograph.

* Symptoms can be filtered by a specific medical problem! concern, to type, time, Healthcare Professional or other variables * The aim is to build up an accurate record of a Patient's symptoms and feelings * This is to assist a patient, in describing symptoms experienced over a specified period of time, to a Healthcare Professional.

Mymedi Care Plan * The Mymedi Care Plan is a Mymedi function to be used by Patients and HCPs * The Mymedi Care Plan is a real time source of information * It can be a chronological list of care plan information for a Patient * It provides a care plan for a Patient that is accessible to all authorised Healthcare Providers (HCP) * It provides guidance, advice and information for a Patients care at any point during their lifetime.

* It provides guidance, advice and information before, during and after care for a Patient * It provides critical care information for a Patient before, during and after an operation * It provides critical care information for a Patient with an ongoing medical condition or other type of problem * It provides a detailed dosage guidance and information for Patients taking medication * It provides critical information in an emergency It provides a source to share important care plan information between Patient and HCPs, especially working in different departments and locations.

Mymedi Medication Manager * A Mymedi function to track a Patient's medication usage * Provides cost tracking information to HCPs * It provides a detailed dosage guidance and information for Patients taking medication * It provides critical information in an emergency * It shares a Patient's medication information with authorised HCPs Mymedi Communication Channels * Electronic communication channels between Patients and HCPs 15. Improve real time communication between groups to improve care * A communication channel is set up and users/groups are invited to join * A group can have any number or authorised members * Specialist groups can be set up to advise on specialist areas * Automate letters for appointments and referral to specialists * Automate HCPs can communicate with Patients, HCPs related to the patient and next of kin etc Mymedi Comments Box * Report Abuse by a GP, HCP, Hospital or other body electronically and confidentially * Make suggestions, recommendations or commendations electronically Mymedi Reward Scheme * Loyalty reward scheme and vouchers for Mymedi Members * Electronic vouchers for discounts on goods and services (i.e. free coffee or fruit in Hospital in Cafe) * Patients have access to Mymedi vouchers whilst staying or visiting a hospital * Promotion of products and services Mymecli Find A HCP * Find any type of HOP in your area Mymedi Support Groups * Online forum for people with the same problem or condition * Provide targeted support, help and advice for individuals * More focused than using an internet search engine * By HOP referral only * Authorised HOPs act as mentors Mymedi Workflow * Provide mechanism to set up electronic workflow between HCPs and Patient * Oommunication mechanism between HOPs when a patient is sent to a specialist by referral Mymedi Parking Manager * Parking is a stressful time in any hospital car park * Pay your hospital parking at a discounted rate through your mymedi account * Pay parking at the click of a button through a smartphone * Integrate with existing system, pay machines already in use inside Hospitals Mymedi Patient Cost Tracker * Ability to track a Patient through the Healthcare system and record and analyse associated costs * Useful in identifying abuse to system and geographic and demographic behavioural patterns.

Mymedi NFC Smartcard: Figure 9 shows the concept of using a Smartcard or device containing an NFC (Near Field Oommunication) chip or tag that stores secure encrypted patient data. The data will include categories such as 2] emergency information, mymedi account details, mymedi access settings.

The chip or tag communicates with a trusted NFC enabled smartphone or similar device to enable a Healthcare Professionals (HCP) to access critical emergency information on the patient. This may be in an emergency situation (such as at the scene of an accident) or in a situation where the Patient is incapacitated or unable to communicate with the HCP (such as in A&E).

Figure 10 shows a health care system in accordance with a further embodiment of the invention. 1 0

A health care user is provided with a personal health data storage device 1 (hereinafter referred to as a healthcare data card). The healthcare data card 1 includes a USB connector 3 to facilitate transfer of data between the health care data card 1 and other equipment. It should be understood that the USB connector 3 is one example of a means for data transfer. Other data transfer means fall within the scope of the invention, such as cellular radio, other mechanical data transfer arrangements or wireless data transfer arrangements such as cellular radio, Bluetooth orWi-Fi.

The health care data card includes a personal data store 5 and a medical data store 7. The total data storage capacity of the health care data card 1 may be any suitable amount, for example 16GB. The health care data card 1 further includes a data processing application 9. The data processing application 9 may be implemented using any suitable hardware or software.

The data processing application 9 may be implemented using HTML5, and may be configured to read documents in a suitable format such as PDF format. Therefore the application 9 may will run on any device to enable portability and future proofing as the data may need to exist for the lifetime of the user. By using industry standard software for the application 9 this will also simplify any future developments and enhancements.

The data processing application 9 may include various security features, For example, it may include data decryption means so that the data in the personal data store 5 may be encrypted.

The user may interact with the data held on the health care data card 1 using a suitable personal data processing device 11, such as a personal computer, laptop or a tablet" type device, or any other suitable device, that preferably includes a visual display 13, means for sending data to and receiving data from the USB connector 3 (or other data transfer means) of the health care data card 1. The personal data processing device 11 further includes suitable software for handling data, such as browser software 15.

The system further comprises a plurality of health care service provider entities. A special class of care service provider entity (a primary care service provider entity) may be a general practitioner, OP, (or other personal physician) entity 17, which supervises user data held on a master data record (MDR) 19 for each user. A GP interacts with the GP entity 17 using a suitable GA data processing device 20.

Other entities in the system include health care service providers HSP1 21, HSP2 22 and HSP3 23. Each of the healthcare service providers has associated with it a respective data store 21A, 22A and 23k The system may further include a hospital 25 with an associated data store 25A and hospital data processing device 26.

The personal data processing device 11 and OP entity 17, may be connected together for data exchange by the internet 27. A cloud-based document exchange service 29 may store a copy of some or all of the data in the MOR 19 in a mirrored MDR 19A. The document exchange provider may be a known type such as DropBox, Google Docs or iCloud.

The healthcare data card 1 is initiated and personalised for a particular user by the user connecting the healthcare data card 1 to their personal data processing device 11 using the USB connector 3 (Figure 11). This coupling causes the run-time data processing application 9 to automatically start up and to interact with the personal data processing device 11 and the browser thereof to display a data entry form on the visual display 13 used to capture and hold the personal information. The form may be a HTML form.

Suitable personal data may be captured by the user entering the data via a user interface of the personal data processing device 11. The data are then S transferred to the personal data store 5 of the healthcare data card 1, Personal data may include: -Photograph/Biometric data -Name address, telephone numbers, email address -National Insurance Number -A password that will meet security standards for holding data on a mobile device -Date of birth -Employment contact information -Contact information for emergencies, legal guardian and GP -Organ Donor information The user may also enter certain summary medical information, which will be stored on the medical data store 7, such as: Blood type Medical allergies Medical conditions Prescription information Surgical procedures and dates Implant or prostheses type, make and serials(s) Immunisation records The personal data entered facilitates authentication of healthcare data card 1 and the user thereof by authentication means comprised in the application 9.

The user may authenticate himself/herself by providing a password (e.g. by entering this via the user interface of the personal data processing apparatus 11). The application 9 may compare this with the stored password to perform authentication. Advantageously, the data facilitates authentication of the card and user in an emergency when communication with the user may not be possible due to illness or injury. Such authentication data may include a photograph of the user and/or biometric data such as finger prints, DNA data and the like. The application 9 may allow the display of this authentication data so that it can be compared with the user to verify that the card is that of the user. The application 9 may prevent access to the data in medical data store 7 until authentication is complete.

The access control is preferably kept simple. The user may have the option to opt into an open' policy whereby data on their card can be easily unlocked by the emergency services without the need for them to provide a password etc. If the user opts out then only the user can open up the card for accessing the data. The user could select to allow "open" access to all or only some of their data.

The user can update this personal data at any time by using the same data entry form. An audit trail of changes will be kept on the card 1.

As mentioned above, the GA entity 17 supervises the master data record 19 of the healthcare data card 1 user. Data may be exchanged between the master data record 19 and medical data store 7 of the healthcare data card 1 in the following manner.

The user of the healthcare data card 1 visits their GP entity 17 (Figure 12).

For interaction with the GP entity 17 the healthcare data card 1 is coupled to the GA data processing device 20 by the USB connector 3. The user may be authenticated by a suitable process. For example, GP data processing device may access data from the personal data store 5 to access photographic or biometric data. The appearance/biometric data of the user presenting the healthcare data card 1 may be compared with this stored photographic/biometric data in order to authenticate the user.

Under the control of a GP, the GP entity 17 may make available selected data from the master data record 19 to the user by transferring data from the master data record 19 to the medical data store 7 on the healthcare data card 1.

The entire content of the medical data store 7 may be stored on the master data record 19 in order to backup that data, so that the medical data on the store 7 of the healthcare data card 1 can be recreated on a replacement healthcare data card in the event that the healthcare data card 1 is lost or damaged.

In a similar way, the entire content of the medical data record 19 may be transferred to the medical data store 7 so that the master data record 19 and the medical data store 7 are synchronised. However, some data of the medical data record may be retained on the master data record 19 only. For example, the GP may have control over which data are transferred from the master data record 19, in order to prevent sensitive data being transferred onto the medical data store 7.

The manner of data transfer between the medical data store 7 and the master data record 19 described above requires the physical attendance of the healthcare data card 1 (and the user) at the GP's premises so that the healthcare data card 1 can be manually coupled to the GP data processing device 20.

As an alternative, the document exchange provider 29 may provide the storage area 19A that mirrors the entire (or selected) content of the master data record 19. The GP may control which (if any) data from the master data record 19 are allowed to be stored on the mirrored master data record 1 9A.

The user of the healthcare data card 1 may access data from the mirrored master data record 19A by coupling the healthcare data card 1 to their personal data processing device 11 via the USB connector 3 (Figure 13). Via a connection to the internet 27, the data processing application 9 on the healthcare data card 1 locates the storage area of document exchange provider 29 where the mirrored master data record 19A is stored, The location of the mirrored master data record 19A may be provided as part of the medical data stored in the medical data store 7 and transferred by the GP 17, or may be established when the card 1 is initiated.

The data processing application 9 may then download data from the mirrored master data record 19A. The entire content of the mirrored master data record 19A may be downloaded. Alternatively, only selected data may be downloaded. Further alternatively, the data processing application 9 may identify where data in the medical data store 7 is superseded by data on the master data record 19A, and may selectively download the new data to replace the superseded data on the medical data store 7.

By the internet 27 connection between the personal data processing device 11 and the mirrored master data record 19A, data may also be transferred from the medical data store 7 of the healthcare data card 1 to the mirrored master data record 19A. The internet 27 connection between the GP entity 17 and the document exchange provider 29 allows data to be transferred between the mirrored master data record 19A and the master data record 19 of the GP system. Updated data from the medical data store 7 provided to the mirrored master data record 19A may then be transferred to the master data record 19 so that this holds the most up to date medical data for the user.

The system may be configured to automatically synchronise data on the medical data store 7, and the MDR 19 and/or mirrored MDR 19k The system further includes various healthcare service providers 21, 22, 23 as discussed above. The health care service providers may provide respective services such as ambulance, paramedic, dentistry, optician, pharmacy, care home, physiotherapy, chiropractic, osteopathy, surgical care, midwifery. The records held by these healthcare service providers may include (but are not limited to): Ambulance Service / Paramedics records Dentist records and dental history (including x-rays) Opticians records / eye prescription Pharmacy records (in chemists or hospitals) Hospital records (including x-rays) -NHS and Private Care Home records S Physiotherapist / Chiropractor / Osteopath records Home care worker records Social Care Service Midwife Service Each of these healthcare services providers 21, 22, 23 may hold data relevant to the user, and this is stored on the associated healthcare service provider database 21A, 22A, 23A. Data may be transferred between any of these healthcare service providers 21, 22, 23 and the healthcare data card 1 via the USB connector 3. This allows medical data from the medical data store 7 to be accessed by the healthcare service provider to ensure that appropriate healthcare service is provided (in accordance with medical requirements of the user). Also, details of healthcare services provided by the relevant healthcare service provider can be stored on the medical data store 7 so that the user of the healthcare data card 1 has possession of this information, which can be subsequently transferred to the master data record 19 of the GP system 17 by the methods described above.

Before any such data exchange is allowed, authentication of the user of the healthcare data card 1 may be performed using the personal data stored in the personal data store 5, for example by verifying photographic data, DNA data or any other data capable of authenticating the user.

In this way, the healthcare data card I holds the full range of healthcare service data on the medical data store 7 relevant to the user. The data may comprise information (e.g. in free text format) or documents (such as PDF documents that include text and/or images/photographs). The data are held in document and summary form as if the data processing application 9 were viewing" the case nodes of the user. This means that the healthcare data card 1 does not require a complex means of data integration with a wide variety of health record databases and systems but simply integrates the output of these systems into a readable format and presents the output through the data processing application 9 (e.g. document reader).

3 The healthcare data card 1 holds and maintains all information and documentation relating to all the health services used by the user. The medical data store 7 of the card 1 provides instant availability of this information to all the service providers and provide conversion of personal and medical data for the user across currently disparate systems. The healthcare data card 1 centralises all health records for the user in one location and allows all health professionals to access all the health records.

The data processing application 9 of the healthcare data card 1 and/or the GP systems 17 may record who makes changes to the medical data on the medical data store 7 and/or master data record 19, when those changes were made, and when data were synchronised with the data of the mirrored master data record 19A. In this way an audit trail of who made changes and when the changes were may be provided.

One specific example of a health service provider is the hospital 25. When a patient is admitted to hospital, their medical records may be conveniently obtained from their healthcare data card 1 by connecting it, via the USB connector 3, to the hospital data processing apparatus 26. Data may be transferred from the medical data store 7 after authentication, if required. In this way, the hospital is provided with appropriate medical records for the user so that the correct treatment may be given. The medical data may, optionally, be transferred to a wrist band 30 which includes a medical data store 32 and a USB connector 34 (Figure 14). Data from the medical data store 7 of the healthcare data card 1 may be transferred to the hospital data processing device 26, and from there to the wrist band 30 for storage on the data store 32, via the USB connector 34. The wrist band 30 can then be fitted around the patient's wrist (or ankle). In this way, the medical data will always be present with the patient during procedures at the hospital. This allows medical professionals to consult the medical data in the store 34 when appropriate.

Also, as treatment is given (e.g. administration of drugs or surgery is performed), details of this can be added to the data store 34 by uploading the data to the data store 32 via the connector 34.

At the end of the hospital admission, data from the store 32 of the wrist band may be transferred to the hospital data processing apparatus 26, and from there to the user's healthcare data card 1. By coupling the healthcare data card 1 to the hospital data processing device 26, details of medical treatment provided can be stored in the medical data store 7 of the healthcare data card 1.

Data documents and information can be uploaded directly onto the card 1 by connecting it to a data processing device belonging to the health service provider or by picking up documents placed in document exchange provider 29. A function within the data processing application may guide the user through options for uploading documents and then will then pick up and store documents onto the card 1.

The master data record 19 may then be updated when the user presents a healthcare data card to the GP processing apparatus 21, or alternatively, the data be transferred by the user coupling the healthcare data card 1 to their personal data processing device 11 and transmitting the data via the internet 27 to the GP entity 17, from where it is stored in the master data record 19.

This is highly convenient, compared with conventional arrangements where paper records from the hospital 25 would have to pass from the hospital to the GP entity 17 or designated data entry centre.

In some circumstances, the user may be admitted to hospital in an emergency. In such a situation the healthcare data card 1 may be particularly advantageous. During transportation of the user to the hospital (e.g. in an ambulance), the user's healthcare data card 1 may be coupled to an appropriate ambulance data processing device and data from the card 1 may be accessed by the ambulance personnel and/or transmitted wirelessly to the hospital. In this way, the ambulance personnel and/or hospital can access the patient's medical history without delay so that appropriate treatment can be provided in a timely manner.

Comments may be added to documents stored in the master data record 19 or medical data store 7. However, the documents are "read only" documents and their contents cannot be changed. However, annotations/comments can be made for each document of each user and then viewed by healthcare professionals and entered onto the systems of the healthcare service providers as appropriate.

The healthcare data card 1 may further be used to control access to prescription medication. When a GP issues a prescription to the user of healthcare data card 1, electronic details of the prescription may be transferred from the OP data processing device 21 to the healthcare data card 1 via the USB connector 3 (or via the internet 27). The user may then subsequently present the healthcare data card 1 to an appropriate data processing apparatus of a pharmacist. After authentication (e.g. using photographic data from the personal data store 5, DNA or the like, for example), the pharmacist downloads the prescription data from the medical data store 7 to their data processing device, and then dispenses the appropriate medication. That the medication has been dispensed may also be recorded on the medical data store 7 of the healthcare data card 1, which data may be subsequently stored on the master data record 19 by an appropriate data communication of one of the two types described above with reference to Figures 12 and 13.

The documents stored on the medical data store 7 and masters data record 19 may include x-rays, MRI scans and other image data, in addition to text data.

Benefits of the healthcare data card 1 and the system of the embodiments include: Patients feel they are involved and have ownership and controt of their records Records available 24/7 anywhere in the world Records can be viewed on any device that can read and display the contents of a USB stick Increases efficiency Reduces overall costs of delivering the health services o Staff costs o Operational costs U) 0 Treatment costs Will help save lives Improves patients experience Could be used for electronic prescriptions Could produce annual statement of services provided and costs.

IS Helps reduce mistakes The documents stored in the medical data store 7 and the master data record 19 may be separated into categories based on health service provider, each category having a separate directory or folder". For example, all records relating to a particular hospital admission may be stored in a first folder, documents relating to GP visits may be stored in a second folder, documents related to dental work may be a stored in a third folder, etc. The data processing application 9 on the healthcare data card 1 may allow the user to explore each folder and view the relevant documentation and data in a convenient manner. Further categorisation is possible to allow a finer level of sub-division of the data if required In the embodiment described above the health care data card I is implemented as stand-alone card, (for example of credit card size) that has a USB connector 3 connecting to other data processing apparatus to allow the transfer of data between the data processing apparatus and the health care data card 1. As indicated above, the data processing apparatus may comprise a PC, laptop or tablet device. Alternatively, the data processing apparatus could be a cellular telephone, or apparatus including cellular communication capability. Further, the health care data card 1 itself may include cellular telecommunication ability so that data may be transferred between the card 1 and other entities, such as master data record 19 and mirrored master data record 19A using the cellular communications network.

S Such a cellular communications network may be a 3G or 4G cellular communications network, for example.

Claims

CLAIMS1 A data storage arrangement for an entity, having coupling means operable to couple the storage arrangement to a plurality of service S providers for transferring data between the storage arrangement and the service providers, the storage arrangement being such that it is operable to receive data relating to services provided to the entity and to store this data so that the storage arrangement holds a record of services provided by the plurality of service providers.
2. The arrangement of claim 1, wherein the data comprises information and documents.
3. The arrangement of claim 2, wherein the documents are stored in a predetermined format.
4. The arrangement of any one of claims 1 to 3, including means operable to store entity identification information.
5. The arrangement of claim 4, including authentication means for controlling access to the data on the arrangement.
6. The arrangement of claim 5, wherein the authentication means is operable to compare the stored entity identification information with input information in order to perform authentication.
7. A system including the storage arrangement of any one of claims 1 to 6, and further including the plurality of service providers, wherein the service providers include a primary service provider entity operable to store data corresponding to the data stored by the arrangement.
8. The system of claim 7, wherein the arrangement is operable to transmit the data between the arrangement and the primary service provider via the coupling means.
9. The system of claim 8, wherein the transmission of data is performed by mechanical coupling of the arrangement to the primary service provider.

3
10. The system of claim 8, wherein the transmission of data is by a network, such as the Internet.
11. An arrangement substantially as hereinbefore described with reference to and/or substantially illustrated in any one of or any combination of accompanying drawings.
12. A system substantially as hereinbefore described with reference to and/or substantially illustrated in any one of or any combination of accompanying drawings.
13. A health care service provider persona! health data storage device having coupling means operable to couple the device to a plurality of health care service provider entities for transferring data between the device and the entities, the arrangement being such that the device is operable to receive data relating to health care provided to the user and to store this data so that the device holds a record of health care services provided by the plurality of health care service provider entities.
14. The device of claim 13, wherein the data comprises information and documents.
15. The device of claim 14, wherein the documents are stored in a predetermined format. n
16. The device of any one of claims 13 to 15, including means operable to store user identification information.
17. The device of claim 16, including authentication means for controlling access to the data on the card.
18. The device of claim 17, wherein the authentication means is operable to compare the stored user identification information with input information in order to perform authentication.
19. A health care system including the health care service personal health data storage device of any one of claims 17 to 18, and further including the plurality of health care service provide entities, wherein the health care service provider entities include a primary health care service provider entity operable to store data corresponding to the data on the card.
20. The system of claim 19, wherein the device is operable to transmit the data between the device and the primary health care service provider entity via the coupling means.
21. The system of claim 20, wherein the transmission of data is performed by mechanical coupling of the device to the primary health care service provider entity.
22. The system of claim 20, wherein the transmission of data is by a network, such as the Internet.
23. A health care service provider user personal health data storage device substantially as hereinbefore described with reference to and/or substantially illustrated in any one of or any combination of accompanying drawings.
24. A health care system substantially as hereinbefore described with reference to and/or substantially illustrated in any one of or any combination of accompanying drawings.