GB2466022A

GB2466022A - Selecting service providers and secure information exchange for medical appointments.

Info

Publication number: GB2466022A
Application number: GB0822334A
Authority: GB
Inventors: Mark Wilson
Original assignee: SELF REFER Ltd
Current assignee: SELF REFER Ltd
Priority date: 2008-12-08
Filing date: 2008-12-08
Publication date: 2010-06-09
Also published as: GB0822334D0

Abstract

A data management system for providing secure access to information relevant to an interaction between a user and a service provider. A user identifier for the user and authentication arrangements are used so that an appointment can be scheduled with one of a selection of hospitals, specialists or firms selected from a database. The patient selects a service provider, place, date and time for an interaction and the method includes providing an interface enabling the customer and service provider to assist in managing the treatment. In particular, the user is provided with an interface enabling the user to grant access selectively using authorization to registered service providers for their health records. The scheduling assistant also provides a way to pay for the appointments, and for the doctor, dentist or health, legal or other professional to update the patient history.

Description

Data Management and Access System and Method The system relates to the field of secure data management and data access. In particular embodiments, the system relates to the booking of appointments and the management of and access to data relating to those appointments.

Traditionally, appointments with service providers are made directly by contacting individual service providers, for example by telephone, and booking the appointment at a mutually convenient time. A number of internet-based appointment systems exist for arranging appointments and bookings. Information relevant to the appointment can be discussed by telephone or sent by email or secure transmission channel to the service provider before the appointment.

In one example, a patient may telephone a doctor's surgery to make an appointment at a mutually convenient time. If the patient is registered with the doctor, the doctor may already have the patient's history. If not, for example if the patient is seeking a second opinion, any previous medical history is usually imparted to the doctor during the appointment and the doctor may make a note of this for his records, adding any further notes arising from the consultation. A copy of these additional notes may also be provided to the patient. In the case of a referral or private consultation, the patient then usually pays for the appointment, if necessary, at the surgery or various procedures are implemented for the doctor to obtain reimbursement.

The problem is long-standing and has proved very difficult to solve. The UK government has invested very large sums of money in a booking system for state funded healthcare with the aim of making it easier for patients to select a health service provider but a number of problems exist concerning data security and transfer of patient records and the system cannot be extended to encompass the complications of private consultations.

Problems arise with other systems for arranging private consultations since the patient may not turn up for the appointment so the doctor may not be paid and, following the consultation, the doctor has no control over the notes he wrote and no way to add to his notes with further advice or comments. Such systems also cause difficulties for the patient as it is difficult to compare different doctors or find convenient appointment times, as the patient must contact each surgery. Also, the patient becomes responsible for keeping all of their medical notes from different doctors and specialists that are visited and providing this information each time they visit a doctor.

Concerns over data security are growing and the existing systems all have a number of drawbacks.

It is clear that similar problems arise in other situations where users wish to obtain services from service providers, for example lawyers & their clients, maintenance engineers and their customers and other medical professionals, such as dentists, physiotherapists and nurses and their clients.

According to one aspect, there is provided a computer implemented method for providing secure access to information relevant to an interaction between a user and a service provider: obtaining a user identifier for the user; receiving first data provided by the user at a user interface; storing the first data in association with the user identifier in a database of a plurality of users as a user record; storing a database comprising a plurality of registered service providers; receiving information from the user indicating that the user has selected a service provider from the plurality of registered service providers for an interaction; providing an interface enabling the user and service provider to assist in managing the interaction; providing the user with an interface enabling the user to grant access selectively to registered service providers; receiving a request from the selected service provider for at least a portion of the first data for the user; validating that the request from the selected service provider is authorised by the user; providing the requested information, if authorised, for display to the service provider; receiving second data for the user from the service provider; storing the second data in association with the user identifier in the database, the first data and second data together providing an amended user record; and wherein access rights to the first and second data are independently controllable.

The access rights may be independently controllable by the user, may be preconfigured in the system or may be managed by a system administrator.

Preferably, the method further includes subsequently restricting access to the first data by the service provider in response to an expiry condition but allowing the registered service provider read access to the second data.

The method enables a user and a service provider to set up and manage an interaction between themselves and to exchange information relating to the user and to the interaction in a controlled way. This increases the control that the user and the service provider have to set up the interaction, for example an appointment in an appointment booking system, and provides an efficient mechanism to ensure that both the user and the service provider have access to the necessary data for the interaction. Control over some of the data is passed to the user, who can grant and deny access to the data by the service provider. However, the service provider cannot be denied read access to data he has added himself.

An embodiment further comprises allowing the registered service provider to enter an amendment to the second data on request under amendment conditions. Hence the second data can only be amended under controlled conditions.

Preferably, the amendment conditions comprise preventing deletion or amendment of the second data by the service provider, but receiving further input from the service provider and adding the further input to the second data. That is, a service provider can always read data he has written and add to that data, but cannot necessarily delete or amend data he has added.

In one embodiment, the amendment conditions comprise allowing amendment only in response to authorisation by the user or by a moderating user. Therefore a service provider may amend or delete data he has added only if the user, or a moderator permits him to do so. This may be useful to correct errors in the data entered by the service provider.

Similarly, a user may request amendment of data in their record by a moderating user.

However, a user will not usually be permitted to amend data added by service providers with the service provider's consent.

In a preferred embodiment, the expiry condition comprises at least one of: expiry of a specified period after the interaction; receipt of a request from the user to change an access password provided to the service provider; and receipt of a request from the user to revoke an access password for the selected service provider.

Preferably, receiving input from the user to grant access selectively to the first data comprises receiving a request from the user for an interaction with the service provider.

Therefore, a service provider may automatically be granted access to the user data when the user initiates an interaction between them.

When an interaction is set up between the user and a second service provider, the second service provider may add further, third, data to the user record. The second data already added to the user record by the first service provider may then be treated in the same way as the first data. That is, the user can grant access for the second service provider to read both the first and second data. In one embodiment, access rights to the first and second data can be granted by the user independently so that the user can control separately whether the second service provider can access the first and second data.

In a preferred embodiment, granting access to the first data by a service provider comprises supplying a password to the service provider, the password enabling access to the first data.

The password may be supplied by the user, via the system, to the service provider.

Alternatively, the system itself may generate a password and supply the password to the service provider when the user requests an interaction with the service provider. In this embodiment, the user may confirm, for example by selecting a tick box, that access to the user record can be provided to the service provider.

In a preferred embodiment, the method further comprises providing the user with a first password to control the user's access to the first and second data and at least one second password additional to the user's password to provide to a service provider. The first password can be used by the user to access, read and modify the first data in the user record. The second password may be disposable, time limited and easily changed by the user. A plurality of second passwords may be provided so that the user can control access separately for a plurality of service providers.

Preferably, validating that the request from the selected service provider is authorised by the user comprises receiving and verifying a password supplied by the selected service provider. A received password may be verified against all live issued passwords for the user's account.

Preferably, the interaction comprises the provision of a service to the user by a service provider.

Preferably, providing the interface for managing the interaction comprises: receiving a service offer from a service provider; outputting the service offer for display to the user via the interface; and receiving input from the user via the interface to reserve the service offer.

Preferably the interface displays a plurality of service offers from a plurality of service providers to the user.

Preferably, providing the interface for managing the interaction comprises: providing a calendar for scheduling the interaction; providing for display to the user a price for the interaction; accepting a reservation from the user for the interaction; confirming the reservation with the user; and providing contact details for the service provider to the user.

Preferably, the method further comprises hosting an audio and/or video session between the user and the service provider.

In one embodiment, accepting a reservation from the user for the interaction comprises receiving an indication of interest from a user with respect to the service offer and making a provisional reservation. Preferably, confirming the reservation with the user comprises receiving further input from the user, the further input comprising payment details.

In one embodiment, receiving first data entered by the user comprises receiving from the user an indication of a category for the data. Preferably, granting access to the first data comprises supplying a password to the service provider for the category of data. Therefore, different service providers may be granted access to different subsets of the first data.

In a preferred embodiment, the method further comprises: receiving a request from the user to transfer data relating to the interaction to the selected service provider; receiving the data from the user; storing the data in a temporary data store; and transferring the data to the selected service provider with the user identifier for the user. This feature of the system enables a user to send data to the service provider, particularly in advance of the interaction.

Preferably the data is transferred to the service provider by email. For example, a user may send medical test results, such as scan images, to the service provider. Transferring the data through the system means that the service provider does not have to release email contact details directly to the user, while the user can control which providers can access the data.

Further, transferring the data through the system to the service provider using only a temporary data store enables the information to be provided to the service provider without requiring large permanent storage resources.

Preferably, the data is deleted from the temporary data store when the data has been received by the service provider.

Alternatively, the data is stored in the temporary data store for a predetermined time period or for a predetermined time following completion of the interaction between the user and the service provider. For example, the data may be deleted automatically six months after an appointment has taken place.

In one embodiment, the data is transferred to the service provider by storing the data in the user record and enabling access to the data in the user record by the service provider.

In one embodiment, the method further comprises transferring data from the service provider to the user using a method according to any of the immediately preceding claims.

That is, rather than the data being supplied from the user to the service provider, the same method could be used to provide data, for example scan images, from the service provider to the user. This could be useful after the interaction to provide the outcome of tests to the user.

In a preferred embodiment, the method further comprises implementing an interaction closure procedure between the user and the service provider, the interaction closure procedure comprising: checking for fulfilment of an interaction completion condition and, following fulfilment of the interaction completion condition, transmitting payment for the interaction to the service provider.

In one embodiment, the interaction closure procedure comprises verifying receipt of the second data from the service provider, wherein the second data comprises at least an indication from the service provider that the interaction is complete; checking for receipt of negative feedback relating to the interaction from the user; and in the presence of second data and the absence of negative feedback, transmitting payment for the interaction to the service provider.

Preferably the closure procedure further comprises triggering the expiry condition to restrict access to the first data by the service provider.

When the interaction comprises a scheduled appointment, the closure procedure is preferably triggered automatically after the scheduled appointment time.

Preferably, the interaction completion condition comprises at least one of: the absence of a negative indication relating to the interaction from the user or the service provider over a predetermined period of time; the receipt of confirmation from the service provider that the interaction took place; and the receipt of data from the service provider to add to the user record.

The second data may include notes relating to the interaction, for example medical notes, or may simply be an indication, for example a tick in a tick-box, from the service provider that the interaction took place and/or was satisfactory.

Checking for receipt of negative feedback from the user may include giving the user a limited time in which he can indicate that the interaction was not satisfactory, for example because the service provider did not turn up. It may also include a more positive step of awaiting a positive confirmation from the user, for example a tick in a tick-box, that the interaction is complete and satisfactory.

According to a further aspect, there is provided a computer implemented method for managing an interaction between a user, having an associated user record, and a service provider selected by the user from a plurality of service providers, the method comprising: providing an interface to schedule the interaction between the user and the selected service provider; receiving payment details from the user to enable payment for the interaction; enabling access for the selected service provider to the user record for the user; following the scheduled interaction, checking for fulfilment of an interaction completion condition; following fulfilment of the interaction completion condition, transferring payment to the service provider for the interaction.

In one embodiment, the interaction closure procedure may further comprise: requesting feedback from the service provider, the feedback including at least a confirmation that the scheduled interaction occurred and data from the service provider to add to the user record; checking for negative feedback from the user; following receipt of the feedback from the service provider: adding the data from the service provider to the user record.

In this embodiment, in order for the service provider to obtain payment for the service, he must complete the process at least by confirming the interaction took place, for example that the user turned up. Preferably, the service provider also provides data to add to the user record, for example medical notes.

Preferably, the method further comprises, prior to the scheduled interaction, obtaining payment from the user and retaining the payment for transfer to the service provider following receipt of the feedback. Since the payment is held by the central, third party system the service provider can be sure that he will be paid if he takes part in the interaction, for example by attending an appointment, and the user can be sure that although he has paid in advance, he will receive his money back if there is a problem with the interaction.

Preferably, checking for negative feedback from the user comprises waiting for a predetermined time after the scheduled interaction for receipt of negative feedback from the user. For example, the user may have 24 hours in which to raise a complaint about the interaction, e.g. if the service provider does not turn up. After this time, it is assumed that the user is happy for payment to be transferred to the service provider. Checking for negative feedback also encompasses the more positive step of awaiting a positive confirmation from the user, for example a tick in a tick-box, that the interaction is complete and satisfactory.

Preferably the method further comprises, on receipt of negative feedback from the user, referring the interaction to an adjudication process to determine whether all or a portion of the payment should be transferred to the service provider. For example, if the user complains that the service provider was late for the scheduled appointment, the adjudicator can determine whether any discount should be provided to the user's payment.

Preferably, the method further comprises receiving an outcome of the adjudication process and taking at least one of the steps of: transferring payment to the service provider; transferring partial payment to the service provider; and refunding payment to the user.

Apparatus aspects corresponding to each of the method aspects described above are also provided and the preferred method features may also be implemented in the apparatus. In particular, a server or cluster of servers may be used to implement the methods set out above, or the methods may be implemented in a plurality of processors over a network, for example the internet. Database(s) are also implemented in the servers or in separate database servers to store the data and images described. User terminals are also provided that enable a user to interface and interact with the described methods and to view the images and results described. The invention also provides computer program, computer program product and computer readable medium aspects corresponding to the method aspects described.

Embodiments are set out below in more detail with reference to the accompanying drawings in which: Fig. 1 is a schematic diagram of an appointment booking system according to one embodiment; Fig. 2 is a schematic diagram of a notes management system according to one embodiment; Fig. 3 is a schematic overview of an appointment booking and notes management system according to one embodiment; Fig. 4 is a schematic diagram of a system that may be used to implement embodiments of the methods described herein.

To illustrate one embodiment of the data management and access system and method, the system will be described below with reference to an appointment system for patients to book appointments with doctors and to share their notes with those doctors. It will be clear to one skilled in the art, however, that the system may be used to arrange appointments and/or share information with other professionals and service providers in an analogous way, as described briefly below.

Medical System A registration and approval system is provided that is governed by a central control system and operator. Some of the registration process can be implemented automatically in the central control system, but operator intervention is also used to ensure that the necessary information is provided and is correct. The registration process is described with reference to Fig. 3.

The registration of a potential patient is first described 310. The patient creates a usemame, password and registers their email address in a standard fashion. No checks are made on this data. The patient can then supply further data 312, including further account details and account options (e.g. address, upload a picture, indicate the types of services in which they are interested etc) to their account. In addition to these settings, the user can upload data to their account, for example medical notes including their medical history, previous service provider details, details of any operations or tests they have had and associated images and results and details of any medication they are taking.

The registration of a doctor 314 who wishes to offer services to the patients is now described. The doctor creates a usemame, password and registers their email address in a standard fashion. No checks are made in this component of the process. The doctor then supplies information to build their profile 318. This includes: their registration number (in the UK this is the General Medical Council (GMC) number) and current place of work as well as optional details such as their area of speciality or interest. The system includes access to a, preferably external, database of locations at which doctors practice, both privately and within any public healthcare system, e.g. National Health Service (NHS) institutions. The profile information for the doctor is then verified 316. For example, the registration number can be checked in a remote database controlled by the GMC and the doctor can be contacted at his indicated place of work, for example by telephone. Speaking directly with the doctor in a location where an imposter is unlikely to have access, for example his place of work, ensures he is registering and it is not a fraudulent attempt to represent him. In addition checks are done with the GMC or other medical body to confirm registration and specialty interest. The doctor is then approved and his profile appears to the public 320 on searching and he can generate appointments 110. A disclaimer is also presented at the user interface to explain that fraudulent use of the site by an unqualified professional cannot be excluded.

The appointment booking system and process will now be described in more detail with particular reference to Fig. 1. The novel system enables two users, in this embodiment a doctor and a patient, to have read and write access to a database to enable one to create a "product" (an appointment) and another to book it. Appointments can be cancelled by the doctor if not booked.

The doctor creates an appointment 110, including setting: the date, time, duration and cost.

The doctor can set the cost to whatever amount he wishes and in whatever currency he wishes. Once made, this appointment is on display and bookable by registered patients in the service. If no one books it, the doctor can cancel it at any time with no cost. The doctor can also create recurring appointment slots, for example, he may know that he is available every Tuesday afternoon and can make appointments available every Tuesday afternoon on a recurring basis. The doctor may also indicate preferences with respect to the appointments, for example the doctor may indicate that he is available for appointments in person if they occur before 5pm, but only for remote, e.g. Internet-telephone based, appointments later in the evening. The doctor can also indicate remote communication service providers with whom he is compatible and that can be used for appointments, for example Skype, Google chat, MSN messenger, ichat etc. Patients can then view the appointments offered by the doctors. The patient can search for appointments of a particular type, for example for doctors having a particular specialism or sub-specialism e.g. trigeminal neuralgia specialists within neurosurgery, and can search by other relevant parameters such as date, time and hourly rate. In some embodiments, all patients can view at least some details of the appointments available, in particular, the specialisms on offer and the timing and cost of the appointments offered. However, in some embodiments, the identity of the doctor offering the appointment is not displayed to unregistered users. In some embodiments, unregistered users can view all details relating to appointments and service providers, but cannot book appointments until they are registered.

In other embodiments, a user must be registered before they are able to view any details of the available appointments.

Having found an appointment that meets their needs, a registered patient can then book an available appointment. In the present embodiment, this falls into two stages. The first stage is provisional booking 112 where they select and fill in details and preferences, for example how they wish to carry out the appointment (e.g. by telephone! or over the internet), their contact details (e.g. internet telephony ID!phone number), their emergency contact details and their medical notes password if they wish, as described in more detail below. This data is associated with that specific appointment, however it can be overwritten by another patient up to the moment the appointment has actually been paid for, as described below.

Further, a patient who has provisionally booked an appointment can cancel it without charge at any point (although since it is not officially booked, this is not necessary).

The second stage of booking an appointment is the payment stage in which the patient puts a deposit on the appointment 114. In the present embodiment, payment is handled by a third party payment system, but this could be implemented as part of the system. Once the payment has been made, or payment details have been provided, an event marked by a payment code is added to the appointment database by the payment processing system. This confirms the patient's appointment and ensures that no other patient can book that appointment, unless the appointment is first cancelled by the original patient. Once the deposit has been provided by the patient, the appointment is booked 116 and other patients cannot overwrite the booking. The patient can still cancel the appointment at this stage, but they are charged a cancellation fee. Similarly, the doctor can cancel the appointment, but also has to pay a cancellation penalty, some of which may go to the patient who booked the appointment.

Payment may be taken in a number of ways, for example using a credit card system, such as Google checkout, or other payment processing systems, such as paypal. A bank transfer or direct debit system may also be used to transfer funds directly from a user's account.

Preferably, payment is requested and taken when a patient provisionally books an appointment but, in one embodiment, a user may buy "credits" in the system in advance that can then be applied to selected appointments.

In the present embodiment, a credit card processing service, such as Google checkout, takes the necessary payment for an appointment as a deposit. The credit card is charged only after the appointment has taken place. In this way, the appointment booking system provides protection to both parties, the patient and the doctor, in case either does not meet at the appointment time or there is another complicating factor. In such a case the deposit can either subsequently be declined and no charge made to the credit card or it can be charged at a percentage. The patient is notified in advance of the charge made for a missed appointment, which may be a fixed fee, a percentage of the advertised appointment cost or an amount suitable as decided by an independent decision panel (e.g. 50% when the patient changes their mind regarding the appointment or does not attend). The charge for cancellation or amendment of an appointment may vary depending on how far in advance of the appointment the cancellation or change is made.

The appointment itself then takes place. The appointment may take place in person, for example in the doctor's surgery or the patient's home or the appointment may take place over the telephone, by email or over the internet, for example using an online teleconferencing system that enables video and/or voice over IP.

After the appointment is finished, the doctor confirms that the patient attended the appointment and the patient has a limited time to advise of any problems or indicate that they did not attend. If there were any problems, the system initiates a dispute procedure 120 and the patient may be charged if he was at fault or not if it was the doctor at fault. The system monitors disputes and may restrict the ability of patients who are frequently at fault to book appointments, or charge higher penalties for cancelled or missed appointments.

Similarly, doctors may gain credits, for example a higher recommendation rating in the system, if they attend appointments as arranged and incur penalties, for example lose credits or money if they miss or cancel appointments.

The system preferably requires the doctor to add some notes to the patient record in order to close the appointment and receive payment.

If the appointment was successful, the deposit taken by the credit card processing service is then realised as a payment by charging the credit card 118 and the monies received are passed on to the doctor. The monies due to the doctor may be transmitted directly into his previously-registered bank account or onto a credit card. Alternatively, the monies may be entered as a credit into the doctor's account on the system and paid to him at regular, for example monthly, intervals.

The booking and notes management system described also takes a percentage of the appointment fee for its service and additionally or alternatively, may receive payment from advertising or sponsorship.

In the present embodiment, an inbuilt real-time or delayed messaging system allows prospective patients to send brief messages to doctors (e.g. requesting an appointment if none is available). It also allows doctors to send replies to the patients. This system is not for clinical advice, but simply provides a convenient means for doctors and patients to communicate via the system.

A second aspect of the invention is the data management system, in this context a medical records system, which is illustrated schematically in Fig. 2. It will be appreciated that medical notes require particular handling as they need to be maintained confidentially for the patient. This feature is shared in common with some other types of data held for a user, such as notes relating to legal proceedings in which a user is involved, dental records, educational or criminal records. As noted above, this aspect may be implemented independently of the appointment bookings system.

The medical records system described gives patients control without taking away the necessity for doctors who have given an opinion or advice to document what they have said within the patient's notes, and to enable them to see their documentation in future, even if they can no longer access the rest of the notes.

The patient creates their medical notes and sets their medical notes access password 210.

The patient medical notes 212 contain core data such as the patient's past medical history, current medication, allergies and current complaints. The notes 212 also include any notes made by professionals whose opinion has been sought through the present appointment system and results of any tests, such as scans or blood tests, as described below. A patient can edit these notes and/or change their password at anytime, however, a patient cannot change their recorded name or date of birth. Additional notes made by professionals following consultations can be read by the patient but not altered 214. If a mistake is made in these notes, they can be altered by an administration team for a charge to the patient or doctor.

A registered patient can use the system to book an appointment or request a service 216 as described above. As part of the booking process, or during the appointment itself, the patient may give the doctor or other service provider permission, via a password or other indication such as a tick-box, 218 to enable the doctor to access the patient's notes. In the case of a tick-box, the user simply indicates that the doctor is permitted to access the notes and the system records this indication and grants access accordingly. Permission can be rescinded by a user by unticking the box (or providing some other relevant indication) wherein the system prevents the doctor from accessing the notes. An alternative embodiment of the system is described below in which passwords are provided to the service providers to enable the service providers to access the nodes. These may be managed by a user in a similar way to the tick-boxes to grant or deny access permission to the service provider.

With reference to Figs. 2 and 3, if a doctor has had his services requested (i.e. an appointment has been booked with him) and he is provided with a current password 220 at the time of appointment booking or during the consultation, he has full read access to the notes (the patients self written notes and notes written by other professionals) and can add his own notes 324, but cannot edit notes he has previously written. If no password is provided 222 he cannot read any notes, but is able to add his own notes and documentation to the patient's record 324. He will also always have the ability to re-read his own notes and continue to add to them if required. However, he will not be able to edit notes that he has previously submitted. It is important for medico-legal reasons that if a doctor sees a patient, he records this in the notes. It is also important in case of future disagreements, that the doctor has access to what he has documented.

The password provided to the doctor may be time-limited and may be different to the master password used by the patient. In addition, a patient can change their access password at any time 322. When the password changes or the time elapses, the doctor is restricted to read and write (but not edit) access of their own notes only 326. Doctors whose services have not been requested 224 have no access to notes.

This system can also be applied to radiology'images/pathology results/other data, therefore results of hospital tests can be uploaded into the system for review by a doctor who the patient books and appointment with. A patient can have control over who can and cannot see images by controlling password access. This additional information or images can be uploaded into a secure folder and a password can be provided by the patient to the doctor to enable access to these images. This system may be provided separately from the notes system described above, since the doctor will not need to add notes to this part of the system, only to the patient's notes. However, preferably, the systems are integrated so that the images can be reviewed alongside the patient's notes as part of the same system.

Data may be divided into separate sections or categories to enable a user to see selected parts of the notes. For example, data relating to a mental health issue may be stored in a separate category to data relating to physical problems. Different access permissions (via passwords or tick-boxes) may be applied to the different categories of data so that, if a patient books an appointment with a doctor in relation to the mental health issue, the doctor can be permitted to access the notes relating to mental health, but not the notes relating to the patient's physical problems.

In general, one party can set an access password and inform a second party of this if they wish. This grants access to that person's information so long as that password remains active. The lay party can alter the password at any point. The second party can still see notes/data they have made, however, they cannot access other notes/data on that lay person.

Image Transfer The system may further provide a method to enable additional data that is not part of the user record to be transferred between users and service providers. For example, prior to an appointment, a patient may wish to send to a doctor test results for review before the consultation. These test results may include large files, such as image files. The system could also be used to upload or transfer GP referral letters to the service provider. The system described herein may include an interface via which the user can transmit these files directly to a doctor. The user selects an option on the interface, for example via a "transmit data to doctor" icon. This brings up a window in which the user can browse for and select a particular file to transmit, for example a scan image from an MRI scan or an X-ray. The system also provides a list of doctors (for example as a drop-down list or in a second page) with whom the patient has booked an appointment. The user can select the doctor to whom they wish to transfer the image or data. The user then presses a "send" button to transmit the data to a doctor. The data is transmitted to a stored email address for the doctor without the patient seeing the contact address for the doctor, hence maintaining the doctor's confidentiality.

The image is preferably transmitted via the system, but is not stored within the system, hence reducing the storage capacity necessary in the system. However, in some embodiment, the image may be stored in a temporary storage means in a database. The data may be stored until the data has been successfully transmitted to the doctor's email address.

If the initial transmission fails, this allows the user to resend the data without reuploading it to the system. In a further embodiment, the data may be stored until after the scheduled appointment time and then automatically deleted shortly afterwards. In this embodiment, the doctor may simply be sent a notification with a link to access the data on the system. In a further embodiment, users may pay a subscription to enable them to keep a predetermined amount of data on the system. This may be useful for users who often need to transmit the same data to doctors or who wish to keep a central repository of data.

Other Service Providers While the system has been described in the context of a doctor-patient appointment booking system, it is clear that the system may be extended to other types of services. Clearly, other medical or pseudo-medical services may be implemented in a similar way to that for the medical system described. For example, dentists, physiotherapists, psychiatrists, chiropodists, midwives and nurses and other health professionals may provide services through a similar system to that described above for doctors. These health professionals may potentially also have access to at least some of the patient's medical notes if such access is granted by a user.

Totally separate systems may also be implemented for different types of service providers.

For example, a similar system may be implemented for professionals in other fields such as accountants or members of the legal profession, for example solicitors, barristers and patent and trade mark attorneys. In this case, a user's notes may contain information relating to legal proceedings, a new invention that the user wishes to patent, or financial information relating to a user's company. As described above, different categories of data may be stored separately and assigned different passwords and access rights. For example, a user may grant his accountant permission to view his financial details, but prevent access by the accountant to his legal or medical notes.

Appointments may be made with the professionals and fees negotiated for the appointments as described above. Similarly, payments may be processed and disputes resolved via a third party system. The notes system described herein means that all conversations between the user and the service provider can be documented and stored independently. These can then be used as evidence by an independent dispute procedure. For some types of work, instead of offering appointments for a specific length of time, professionals may offer a fixed service. For example, an accountant may offer a fixed fee for preparing a set of accounts or a solicitor may offer a fixed fee for performing a conveyancing for a property transaction.

In another embodiment, the system may be used by workmen to offer their services. For example plumbers and electricians may make appointments available to fix problems within the home. In this context, the fact that the user has control over the data that is entered into the system may deter unscrupulous workmen from recommending unnecessary or ineffective courses of action or entering excessive quotes for proposed work. A feedback and recommendation function built into the system may also enable good workmen to receive further work by word of mouth recommendations and provide users with some assurances before booking the relevant appointments.

The system may also be applied in other fields, such as education. Teachers and private tutors could offer appointments for online or in-person teaching sessions. The notes could provide information about the user's teaching needs and the levels achieved as well as feedback from the teachers and tutors employed. During or after a teaching session, the notes system could also be used for the user to submit homework and for the tutor to provide feedback on the homework submitted.

Therefore, it is clear that the system described has a number of uses and is not limited by the embodiments described above.

A particular embodiment of a terminal 700 via which a user can access the system can be implemented using a processing system, an example of which is shown in Fig. 4. In

I

particular, the processing system 710 generally includes at least one processor 720, or processing unit or plurality of processors, memory 712, at least one input device 714 and at least one output device 716, coupled together via a bus or group of buses (not shown). In certain embodiments, input device 714 and output device 716 could be the same device. An interface 718 can also be provided for coupling the processing system 710 to one or more peripheral devices, for example interface 718 could be a PCI card or PC card. The interface 718 may also comprise a modem or network adaptor, for example an Ethernet card. The memory 712 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The processor 720 could include more than one distinct processing device, for example to handle different functions within the processing system 710.

Input device 714 receives input data from a user and can include, for example, a keyboard, a pointer device such as a pen-like device or a mouse, audio receiving device for voice controlled activation and internet telephony such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, video receiving device such as a web camera etc. Input data could come from different sources, for example keyboard instructions in conjunction with data received via a network. Output device 716 produces or generates output data and can include, for example, a display device or monitor in which case output data is visual, a printer in which case output data is printed, a port, for example a USB port, a peripheral component adaptor, a video and/or audio output device, a data transmitter or antenna such as a modem or network adaptor, etc. A user could view data output, or an interpretation of the data output, on, for example, a monitor or using a printer.

In use, the processing system 710 is adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, the local memory 712 or remote databases via a network to implement the methods described herein. The interface 718 may allow wired and/or wireless communication between the processing unit 710 and peripheral components that may serve a specialised purpose. The processor 710 receives instructions as input data via input device 714 and can display processed results or other output to a user by utilising output device 716. More than one input device 714 and/or output device 716 can be provided. Input data may be received from and output data may

I

be sent to a remote server 724 or a cluster of servers via a network 722 which may include the Internet, connected to the interface 718. It should be appreciated that the processing system 710 may be any form of terminal, server, specialised hardware, or the like and is not limited to the embodiment shown.

Processing system 710 is adapted to communicate with other terminals or with one or more servers 724, for example a database server which is connected to a plurality of databases 726a, 726b, by sending and receiving data via a network 722, thereby facilitating communication of data. The remote server 724 may comprise a single server or a cluster of servers, which may be geographically remote from each other, for example being implemented as a "cloud". The server(s) 724 may be standalone devices implementing the system described herein or the described system may be implemented on a portion of the server(s) 724, which may also provide other functionality, for example by serving other web-based applications. For resiliency and redundancy, the servers 724 are preferably separated geographically and topographically.

The server(s) 724 are connected to at least one database and preferably a plurality of databases 726a, 726b. The databases 726a, 726b may also be provided in cluster or "cloud" arrangement and are preferably also geographically and topographically separated over the network 722.

It will be clear to one skilled in the art that the systems and methods described herein may also be implemented using other types of physical equipment and the description above is not intended to be limiting. For example, the user terminal 700 may be replaced by a hand-held unit, such as a laptop, PDA or mobile telephone, providing similar functionality.

Elements of the system may be implemented independently, for example the appointments booking system may be implemented without the notes management system and vice versa.

Features of one aspect of the system may be implemented within another aspect.

Claims

Claims 1. A computer implemented method for providing secure access to information relevant to an interaction between a user and a service provider: obtaining a user identifier for the user; receiving first data provided by the user at a user interface; storing the first data in association with the user identifier in a database of a plurality of users as a user record; storing a database comprising a plurality of registered service providers; receiving information from the user indicating that the user has selected a service provider from the plurality of registered service providers for an interaction; providing an interface enabling the user and service provider to assist in managing the interaction; providing the user with an interface enabling the user to grant access selectively to registered service providers; receiving a request from the selected service provider for at least a portion of the first data for the user; validating that the request from the selected service provider is authorised by the user; providing the requested information, if authorised, for display to the service provider; receiving second data for the user from the service provider; storing the second data in association with the user identifier in the database, the first data and second data together providing an amended user record; and wherein access rights to the first and second data are independently controllable.
2. A method according to Claim 1 further comprising, in response to an expiry condition, subsequently restricting access to the first data by the service provider but allowing the registered service provider read access to the second data.
3. A method according to Claim 1 or 2 further comprising allowing the registered service provider to enter an amendment to the second data on request under amendment conditions.I
4. A method according to Claim 3 wherein the amendment conditions comprise preventing deletion or amendment of the second data by the service provider, but receiving further input from the service provider and adding the further input to the second data.
5. A method according to Claim 3 wherein the amendment conditions comprise allowing amendment only in response to authorisation by the user or by a moderating user.
6. A method according to any preceding claim wherein the expiry condition comprises at least one of: expiry of a specified period after the interaction; receipt of a request from the user to change an access password provided to the service provider; and receipt of a request from the user to revoke an access password for the selected service provider; receipt of a request from the user to rescind an access permission granted using a selection box.
7. A method according to any preceding claim wherein receiving input from the user to grant access selectively to the first data comprises at least one of: receiving a request from the user for an interaction with the service provider; receiving an indication in a selection box that a service provider should be granted access to the first data.
8. A method according to any preceding claim wherein granting access to the first data by a service provider comprises supplying a password to the service provider, the password enabling access to the first data.
9. A method according to any preceding claim further comprising providing the user with a first password to control the user's access to the first and second data and at least one second password additional to the user's password to provide to a service provider.
10. A method according to any preceding claim wherein validating that the request from the selected service provider is authorised by the user comprises receiving and verifying a password supplied by the selected service provider.
11. A method according to any preceding claim wherein the interaction comprises the provision of a service to the user by a service provider.
12. A method according to any preceding claim wherein providing the interface for managing the interaction comprises: receiving a service offer from a service provider; outputting the service offer for display to the user via the interface; and receiving input from the user via the interface to reserve the service offer.
13. A method according to any preceding claim wherein providing the interface for managing the interaction comprises: providing a date selection interface for scheduling the interaction; providing for display to the user a price for the interaction; accepting a reservation from the user for the interaction; confirming the reservation with the user; and providing contact details for the user to the service provider.
14. A method according to Claim 13 further comprising hosting an audio and/or video session between the user and the service provider.
15. A method according to Claim 13 wherein accepting a reservation from the user for the interaction comprises receiving an indication of interest from a user with respect to the service offer and making a provisional reservation.
16. A method according to Claim 13 wherein confirming the reservation with the user comprises receiving further input from the user, the further input comprising payment details.I
17. A method according to any preceding claim wherein receiving first data entered by the user comprises receiving from the user an indication of a category for the data.
18. A method according to Claim 17 wherein granting access to the first data comprises receiving an indication from the user to grant permission for the service provider to access the category of data.
19. A method according to any preceding claim further comprising receiving a request from the user to transfer data relating to the interaction to the selected service provider; receiving the data from the user; storing the data in a temporary data store; and transferring the data to the selected service provider with the user identifier for the user.
20. A method according to Claim 19 wherein the data is deleted from the temporary data store when the data has been received by the service provider.
21. A method according to Claim 19 wherein the data is stored in the temporary data store for a predetermined time period or for a predetermined time following completion of the interaction between the user and the service provider.
22. A method according to Claim 19 wherein the data is transferred to the service provider by storing the data in the user record and enabling access to the data in the user record by the service provider.
23. A method according to any preceding claim further comprising transferring data from the service provider to the user using a method according to any of Claims 19 to 22.
24. A method according to any preceding claim further comprising implementing an interaction closure procedure between the user and the service provider, the interaction closure procedure comprising: checking for fulfilment of an interaction completion condition;Ifollowing fulfilment of the interaction completion condition, transmitting payment for the interaction to the service provider.
25. A method according to Claim 24 further comprising triggering the expiry condition to restrict access to the first data by the service provider.
26. A method according to Claim 24 or 25 wherein the interaction comprises a scheduled appointment and wherein the interaction closure procedure is triggered automatically after the scheduled appointment time.
27. A method according to any of Claims 24 to 26 wherein the interaction completion condition comprises at least one of: the absence of a negative indication relating to the interaction from the user or the service provider over a predetermined period of time; the receipt of confirmation from the service provider that the interaction took place; and the receipt of data from the service provider to add to the user record.
28. A computer implemented method for managing an interaction between a user, having an associated user record, and a service provider selected by the user from a plurality of service providers, the method comprising: providing an interface to schedule the interaction between the user and the selected service provider; receiving payment details from the user to enable payment for the interaction; enabling access for the selected service provider to the user record for the user; following the scheduled interaction, checking for fulfilment of an interaction completion condition; following fulfilment of the interaction completion condition, transferring payment to the service provider for the interaction.
29. A method according to Claim 28 wherein the interaction completion condition comprises at least one of:Ithe absence of a negative indication relating to the interaction from the user or the service provider over a predetermined period of time; the receipt of confirmation from the service provider that the interaction took place; and the receipt of data from the service provider to add to the user record.
30. A method according to Claim 28 or 29 further comprising, prior to the scheduled interaction, obtaining payment from the user and retaining the payment for transfer to the service provider following receipt of the feedback.
31. A method according to Claim 29 or 30 further comprising, on receipt of a negative indication from the user or the service provider, referring the interaction to an adjudication process to determine whether all or a portion of the payment should be transferred to the service provider.
32. A method according to Claim 31 further comprising receiving an outcome of the adjudication process and taking at least one of the steps of: transferring payment to the service provider; transferring partial payment to the service provider; and reftinding payment to the user.
33. Apparatus for providing secure access to information relevant to an interaction between a user and a service provider: means for obtaining a user identifier for the user; means for receiving first data provided by the user at a user interface; means for storing the first data in association with the user identifier in a database of a plurality of users as a user record; means for storing a database comprising a plurality of registered service providers; means for receiving information from the user indicating that the user has selected a service provider from the plurality of registered service providers for an interaction; means for providing an interface enabling the user and service provider to assist in managing the interaction;Imeans for providing the user with an interface enabling the user to grant access selectively to registered service providers; means for receiving a request from the selected service provider for at least a portion of the first data for the user; means for validating that the request from the selected service provider is authorised by the user; means for providing the requested information, if authorised, for display to the service provider; means for receiving second data for the user from the service provider; means for storing the second data in association with the user identifier in the database, the first data and second data together providing an amended user record; and means for independently controlling the access rights to the first and second data.
34. Apparatus according to Claim 33 further comprising means for subsequently restricting access to the first data by the service provider in response to an expiry condition but allowing the registered service provider read access to the second data.
35. A network device for providing secure access to information relevant to an interaction between a user and a service provider: an input interface for obtaining a user identifier for the user; an input interface for receiving data from the user and the service provider, including receiving first data provided by the user at a user interface; memory for storing in a first database data relating to a plurality of users, the database storing the first data in association with the user identifier as a user record; memory for storing in a second database data relating to a plurality of registered service providers; the input interface further receiving information from the user indicating that the user has selected a service provider from the second database of registered service providers for an interaction; an interface for enabling the user and service provider to assist in managing the interaction; the interface enabling the user to grant access selectively to registered service providers;Ithe interface further receiving a request from the selected service provider for at least a portion of the first data for the user; a processor operable for validating that the request from the selected service provider is authorised by the user; an output interface for providing the requested information, if authorised, for display to the service provider; the interface further receiving second data for the user from the service provider; memory for storing the second data in association with the user identifier in the first database, the first data and second data together providing an amended user record; and an interface for enabling independent control of the access rights to the first and second data.
36. A network device according to Claim 35 further comprising a processor operable for subsequently restricting access to the first data by the service provider in response to an expiry condition but allowing the registered service provider read access to the second data.
37. Apparatus for managing an interaction between a user, having an associated user record, and a service provider selected by the user from a plurality of service providers, the apparatus comprising: means for providing an interface to schedule the interaction between the user and the selected service provider; means for receiving payment details from the user to enable payment for the interaction; means for enabling access for the selected service provider to the user record for the user; means for checking for fulfilment of an interaction completion condition, following the scheduled interaction; means for transferring payment to the service provider for the interaction following fulfilment of the interaction completion condition.
38. A network device for managing an interaction between a user, having an associated user record, and a service provider selected by the user from a plurality of service providers, the device comprising: an interface for scheduling the interaction between the user and the selected service provider; an interface for receiving payment details from the user to enable payment for the interaction; an interface for enabling access for the selected service provider to the user record for the user; a processor operable for checking for fulfilment of an interaction completion condition; the processor further operable to transfer payment to the service provider for the interaction following completion of the interaction fulfilment condition.
39. A computer program, computer program product or computer readable medium for implementing a method according to any of Claims ito 32.
40. Apparatus substantially as any one described herein with reference to Fig. 4.
41. A method substantially as any one described herein with reference to any of Figs. 1 to 3.