System and method for management of medical records

[0001] The present invention relates to maintenance of electronic health records (EHR) used to manage medical conditions, and more particularly to improvements in sharing and collaboration among users of EHR systems.

[0002] The advent of global data communications networks, and in particular the Internet, has facilitated improved efficiency and collaboration in many fields of endeavour. However, to date the full potential of information technology has not been realised in the healthcare industry. This may seem surprising, since great benefits can be realised through effective information sharing in order to improve patient care by bringing together the efforts of general practitioners (GPs), medical specialists, allied health professionals and hospitals into a cohesive, streamlined flow of activity and information capture.

[0003] However, reluctance of healthcare providers to adopt new e-health solutions has been influenced by past failures of such systems. There are no perceived or demonstrated advantages for healthcare providers to adopt poorly conceived solutions that do not deliver benefits to patients or doctors.

[0004] Security and control of patient records has been one factor in the failure of new e-health solutions. Past approaches which relied on the patient to be the custodian and curator of their own medical information created barriers to effective treatment, rather than benefits, because patients are not qualified to decide what should and should not be included within their medical records. In Australia, there are 125 million consultations performed by GPs each year, with 83 per cent of Australians consulting a GP at least once a year. Across 7,100 general practices, 95 per cent of GPs are using computer-based systems, and 56 per cent make full use of a computerised health records system, according to data from the Australian Bureau of Statistics. Allied health professionals are increasingly involved in team-care arrangements for chronic complex disease management, and linking these professionals with GPs and institutions of care has, as yet, not been effectively undertaken.

[0005] The most common systems currently in use in Australia, for example, are known as Medical Director (MD) and Best Practice (BP). However these, and other existing systems, lack the connectivity to enable seamless information sharing.

[0006] As the primary healthcare provider, the GP is the logical person to act as custodian and curator of patient medical records. Computerised health records systems, deployed within general practices, could be an effective platform for enabling GPs to take on this role. However, it is recognised that GPs have limited time available, and therefore any successful medical record management system which places the GP in the role of curator must make the process as simple and efficient as possible.

[0007] It is, accordingly, an objective of the present invention to provide improved systems and methods for management of electronic health records (EHR) which provide for collaboration and sharing of patient medical information in a manner which is both sufficiently secure, and sufficiently simple and efficient to use, to facilitate its widespread acceptance and adoption by patients, doctors and other healthcare professionals.

[0008] In one aspect, the invention provides a computer-implemented method of sharing patient healthcare information among providers of health services to a patient, comprising:

providing a database configured to contain records comprising at least:

an electronic health record (EHR) of the patient which is associated with one or more EHR subrecords;

a plurality of health service provider records; and

at least one health service network associated with the patient EHR, which comprises one or more health service providers corresponding with said health service provider records,

wherein each EHR subrecord is associated with an access control structure defining access permissions granted to health service providers in the health service network,

receiving a request for access to an EHR subrecord of the patient;

identifying a health service provider record corresponding with a source of the request for access;

interrogating the access control structure associated with the EHR subrecord to determine an access permission of the health service provider associated with the identified health service provider record; and

providing access to the requested EHR subrecord in the event that a required access permission is granted.

[0009] Advantageously, embodiments of the invention are able to provide a centralised platform for storage and sharing of patient medical records and associated information, while enforcing requisite security and access control. The EHR subrecords of each patient may be generated, owned and controlled by different practitioners involved in care and treatment of the patient, and may contain a variety of different information and documentation, such as prescriptions, patient history records, patient progress notes, pathology records, immunisation records, medical imaging records, patient allergy information, and so forth. An associated health network may comprise all medical and allied healthcare practitioners associated with treatment of the patient, and facilitate communication and sharing of information among members of the network.

Patients may also be provided with access to their own medical records, while a primary healthcare provider, such as a patient’s GP, is able to maintain an overview of all of the patient’s healthcare records.

[0010] In embodiments of the invention, the access control structures define access permissions at least corresponding with individual health service provider records and with health service networks, whereby the access permission of the health service provider is determined according to the combined access permissions of the individual health service provider record and any health service networks including the health service provider.

[0011 ] Furthermore, the access permissions defined by the access control structures may include:

permissions to access information about the EHR subrecords;

permissions to retrieve content of the EHR subrecords; and permissions to update content of the EHR subrecords.

[0012] In some embodiments, the database is a distributed database comprising a central repository and one or more local repositories, and wherein the method further comprises:

identifying a storage location of the requested EHR subrecord; and retrieving the requested EHR subrecord from the identified storage location.

[0013] The central repository may be synchronised with the local repositories in accordance with synchronisation rules associated with individual subrecords within the database.

[0014] The method may further comprise receiving an instruction from an owner of an EHR subrecord of the patient to grant access to the EHR subrecord to one or more health service providers in the health service network; and updating the access control structure associated with the EHR subrecord to permit access by the said one or more health service providers in the health service network. The instruction to grant access may comprise information defining a limited access time-period. The method may then further comprise:

updating the access control structure associated with the EHR subrecord to permit access by the said one or more health service providers in the health service network only during the limited access time-period; and updating the access control structure associated with the EHR subrecord to revoke access by the said one or more health service providers in the health service network upon expiry of the limited access time-period.

[0015] In embodiments of the invention, health service providers are able to request the grant of access to specific patient information. This may include:

receiving a request from a requesting health service provider in the health service network for grant of access to an EHR subrecord of the patient having an owner other than the requesting health service provider;

generating a notification to the owner of the EHR subrecord of the request for grant of access;

receiving a response from the owner of the EHR subrecord to the request for grant of access; and

in the event that the response is an instruction from the owner of the EHR subrecord to grant access to the requesting health service provider, updating the access control structure associated with the EHR subrecord to permit access by the requesting health service provider.

[0016] In another aspect, the invention provides a computer-implemented system for sharing patient healthcare information among providers of health services to a patient, comprising:

at least one processor;

at least one non-volatile storage device accessible to the processor which includes a database configured to contain records comprising at least:

an electronic health record (EHR) of the patient which is associated with one or more EHR subrecords;

a plurality of health service provider records; and

at least one health service network associated with the patient EHR, which comprises one or more health service providers corresponding with said health service provider records,

wherein each EHR subrecord is associated with an access control structure defining access permissions granted to health service providers in the health service network,

at least one computer-readable memory device operatively associated with the processor,

wherein the memory device contains computer-executable instruction code configured such that, when executed by the processor, the system implements a method comprising:

receiving a request for access to an EHR subrecord of the patient;

identifying a health service provider record corresponding with a source of the request for access;

interrogating the access control structure associated with the EHR subrecord to determine an access permission of the health service provider associated with the identified health service provider record;

and

providing access to the requested EHR subrecord in the event that a required access permission is granted.

[0017] In a further aspect, the invention provides a computer-implemented client-side method of sharing patient healthcare information among providers of health services to a patient within a system having a database configured to contain records comprising at least:

an electronic health record (EHR) of the patient which is associated with one or more EHR subrecords;

a plurality of health service provider records; and

at least one health service network associated with the patient EHR,which comprises one or more health service providers corresponding with said health service provider records,

wherein each EHR subrecord is associated with an access control structure defining access permissions granted to health service providers in the health service network, and

wherein the method comprises:

receiving, from a user, a request for access to an EHR subrecord of the patient;

identifying, within the database, a health service provider record corresponding with a source of the request for access, and obtaining access permission information of the health service provider associated with the identified health service provider record, stored in the access control structure associated with the EHR subrecord;

providing, to the user, access to the requested EHR subrecord in the event that a required access permission is granted.

[0018] In this aspect, the invention may be embodied in executing software configured to present a user interface on a client device of the user, wherein the request for access to the EHR subrecord of the patient is received via the user interface. Alternatively, or additionally, software embodying the invention may be configured to interact with a third-party software application, such as a healthcare practice management software application, executing on the client device of the user. Such embodiments may monitor activities of the user in the third-party software application, wherein the request for access to the EHR subrecord of the patient is received via user interaction with the third-party software application

[0019] Further features and benefits of the invention will be apparent from the following description of embodiments, which is provided by way of example only and should not be taken to limit the scope of the invention as it is defined in any of the preceding statements, or in the claims appended hereto.

[0020] Embodiments of the invention will now be described with reference to the accompanying drawings, in which like references numerals refer to like features, and wherein:

Figure 1 is a block diagram illustrating a networked system embodying the invention;

Figures 2a and 2b are block diagrams illustrating details of a client terminal and a server, respectively, in the system of Figure 1 ;

Figure 3a is a block diagram illustrating schematically the conceptual architecture of the system of Figure 1 ;

Figure 3b is a schematic diagram of a software architecture of a homogeneous embodiment of the invention;

Figure 3c is a block diagram of a software architecture of a heterogeneous embodiment of the invention;

Figure 4 is a schematic diagram of a medical network embodying the invention;

Figure 5 is a block diagram of an exemplary data model;

Figure 6a is a schematic diagram of conceptual structure of an exemplary distributed database embodying the invention;

Figure 6b is a flowchart illustrating a method of sharing patient healthcare information among providers of health services embodying the invention;

Figure 7a is a flowchart illustrating an exemplary use case of an embodiment of the invention;

Figure 7b is a flowchart illustrating an exemplary process at first signof a medical practitioner;

Figure 7c is a flowchart illustrating an exemplary process of new patient entry;

Figure 7d is a flowchart illustrating an exemplary process for sharing patient data;

Figure 7℮ is a flowchart illustrating an exemplary process for requesting patient data;

Figure 8 is an exemplary screen display illustrating a patient record interface embodying the invention;

Figure 9 is an exemplary screen display illustrating a history record creation interface embodying the invention;

Figure 10 is an exemplary screen display illustrating an interface to medical imaging records associated with a patient record embodying the invention;

Figure 11 is an exemplary screen display illustrating an interface to letters associated with a patient record embodying the invention; and

Figure 12 is an exemplary screen display illustrating a letter creation interface embodying the invention.

[0021 ] Figure 1 is a block diagram illustrating a system 100 within which embodiments of the present invention may be implemented.

[0022] The system 100 employs a communications network 102, such as the Internet, for transfer of information and instructions between different components of the system, each of which generally comprises one or more computing devices.

[0023] The system 100 includes a central database 104 which is managed by, and accessible via, a server 106.

[0024] A number of client terminals, e.g. 108, are also connected to the system 100, and are associated with their own local databases, e.g. 110. The client terminals 108 are generally desktop personal computers (PCs) within medical practices, and may be operated by GPs, medical specialists, other health professionals, and/or associated administrative staff. At some sites, e.g. 112, a number of client terminals, e.g. 114, may share one or more local databases, e.g. 116.

[0025] It is also envisaged that other users may have access to the system 100 as clients, and in particular that patients may be provided with access to review and update their own medical records. Accordingly, the system 100 also includes client terminals, e.g. 118, which are able to access information stored in the central and local databases 104, 110, 116 using online facilities provided by the server 106, or by another associated server. It is particularly envisaged that patient access to medical records may be provided via a web-based interface, enabling patients to access the system 100 via any convenient terminal 118 having conventional web browser software installed.

[0026] Additionally, patient and other user access may be provided via a mobile web-based interface and/or a dedicated app executing on a mobile device such as a smartphone 120, which is provided with access to the system 100 via a wireless access point 122.

[0027] Figure 2a is a block diagram showing further details of a client terminal device 108, such as may be implemented within a medical practice.

[0028] The terminal device 108 may typically comprise a conventional desktop computer, which has installed software embodying aspects of the present invention.

[0029] The client terminal 108 includes at least one microprocessor 202, which is interfaced to, or otherwise operably associated with, a non-volatile memory/storage device 204. The non-volatile storage 204 may be a hard disk drive, and/or may include a solid state non-volatile memory, such as read-only memory (ROM), flash memory, or the like. The microprocessor 202 is also interfaced to volatile storage 206, such as random access memory (RAM), which contains program instructions and transient data relating to the operation of the terminal 108. In a conventional configuration, the storage device 204 maintains known program and data content relevant to the normal operation of a computer system, for example the storage device 204 may contain operating system programs and data, as well as other executable application software necessary to the normal functioning of the terminal 108. In the embodiment shown, the storage device 204 also contains program instructions which, when executed by the processor 202 enable the terminal 108 to implement functions and features of a patient EHR management system embodying the invention. In operation, instructions and data held on the storage device 204 are transferred to volatile memory 206 for execution on demand.

[0030] The microprocessor 202 is also operably associated with a network interface 208 in a conventional manner. The network interface 208 facilitates access to the data communications network 102.

[0031 ] In use, the volatile storage 206 includes a corresponding body 210 of program instructions configured to perform processing and operations embodying features of the present invention, the general and specific nature of which will be understood from the further description below with reference to Figures 3 to 12.

Additionally, the terminal 108 is interfaced to user input and output devices, such as a display, keyboard, mouse, and so forth (212) to facilitate user interaction with the programs 210 executing on the terminal 108.

[0032] Figure 2b is a block diagram showing further details of a central server 106 embodying the invention.

[0033] The server 106 may generally comprise one or more computers, each of which includes at least one microprocessor 222. The number of computers and processors 222 generally depends upon the required processing capacity of the system, which in turn depends upon the number of client systems, e.g. 108, requiring access to the server 106. In some embodiments, a third-party cloud computing platform (e.g. Amazon Web Service, Google Cloud Platform or Microsoft Azure) may be employed for implementation of the server 106, thereby enabling the physical hardware resources to be allocated dynamically in response to client demand. With this being appreciated, for simplicity in the remainder of the description it is assumed that the exemplary EFIR management system server 106 includes a single computer with a single microprocessor 222.

[0034] The microprocessor 222 is interfaced to, or otherwise operably associated with, a non-volatile memory/storage device 224. The microprocessor 222 is also interfaced to volatile storage 226. In a conventional configuration, the storage device 224 includes operating system program and data content, along with programs and data associated with other applications executed by the server 106. Furthermore, the storage device 224 contains program instructions which, when executed by the processor 222, enable the server 106 to perform operations relating to implementation of an EHR management system embodying the invention. In operation, instructions and data held on the storage device 224 are transferred to volatile memory 226 for execution on demand.

[0035] The microprocessor 222 is also operably associated with a network interface 228 in a conventional manner. The network interface 228 facilitates access to the data communications network 102, enabling the exchange of information and instructions with client terminal devices, e.g. 108, 114, 118, 120.

[0036] The central database 104 may be maintained within the storage 224, within additional storage operably associated with the microprocessor 222, and/or network-accessible storage connected to a local network and accessible, for example, via the network interface 228.

[0037] In use, the volatile storage 226 includes a corresponding body 230 of program instructions configured to perform processing and operations embodying features of the present invention, as will be better appreciated from the following discussion with reference to Figures 3 to 12.

[0038] Additional applications executed by the server 106 may include a web server application, for providing access to patient medical records via client terminals, e.g. 118, using conventional web browser software. Additionally, the server 106 may be provided with application programs and data implementing access to patient medical records via an app executing on mobile devices, such as the smartphone 120. In some embodiments, the program instructions 230 may include instructions implementing an Application Programming Interface (API). The API may be used by application software executing on any networkconnected device (e.g. client terminal 108 and/or smartphone 120) to access patient medical records, and other services provided by the server 106.

[0039] Figure 3 shows a block diagram which illustrates schematically the conceptual architecture 300 of the system 100 shown in Figure 1. Client terminals, e.g. 108, 114, 118, are represented at the top of the diagram, while the central database 104, and local databases, e.g. 110,116, are represented at the bottom of the diagram. As shown in Figure 1, in some cases the client terminals and local databases may be geographically co-located. Flowever, conceptually it is useful to think of these as separate components of the overall system 300, without regard to physical location.

[0040] The client terminals use the system’s communications infrastructure 302 to exchange information and instructions, e.g. requests, with the system platform 306. While the communications infrastructure 302 includes the network 102, shown in Figure 1, it will be understood that within the conceptual architecture of the system 300 the communications infrastructure 302 encompasses all communications channels between components of the system, including those internal to individual devices, such as user client PCs 108 and the server 106.

[0041] Similarly, the platform 306 is not a single entity, but rather represents all of the distributed software components of the system, including client application software 210 and server application software 230. The overall system platform 306 provides users of the client terminals 108, 114, 118 with access to patient medical records and other information stored within the databases, e.g.

104, 110, 116, which in this sense may be regarded as a single distributed database.

[0042] In some embodiments the body of program instructions 210 executing on client terminals, e.g. 108, may comprise a standalone application facilitating communications with the local database 110, as well as with the server 106.

Such a standalone application may also provide additional practice management functions, such as managing appointments, maintaining correspondence templates, and so forth. In other embodiments, the program instructions 210 may comprise client side code, executing within a web browser or similar controlled environment, such as a virtual machine environment. Such client side code may be written in Java, JavaScript, or other suitable language, and may be downloaded from the server 106 on demand, and/or accessed from local storage, e.g. cache storage, maintained on the local storage device 204.

[0043] In still further embodiments, the program instructions 210 may comprise executable code configured to work cooperatively with a third-party practice management software application, such as MedicalDirector products (available from Health Communication Network Limited of St Leonards, Australia) or Best Practice products (available from Best Practice Software Pty Ltd of Bundaberg, Australia). In such embodiments, the program instructions 210 may be integrated with, or executed in parallel with, the third-party practice management software. The executable code may monitor operations of the practice management software and/or access the practice management database using a standard query language such as SQL, or other interface supported by the database. The executable instructions 210 may implement a user interface that runs as a plugin, sidebar, or similar configuration. This interface may provide the user with access to patient health records, and other information and functionality available in accordance with embodiments of the invention, such as will be described below in greater detail, with reference to Figures 4 to 12.

[0044] Whatever configuration is implemented via the program instructions 210, it will be understood that this is encompassed by the terms ‘client application software’, ‘client software’, ‘local application’, and similar terminology, throughout the remainder of the present specification. Client application software may be implemented in a variety of different ways, depending upon system and user requirements, without departing from the principles of the present invention.

Where it is required to make a distinction, the term ‘homogeneous’ is used to refer to embodiments in which all functionality is provided within a single environment, without interaction with third-party application software such as practice management applications, whereas the term ‘heterogeneous’ is used to refer to embodiments in which patient healthcare information sharing is provided via a platform embodying the invention, with practice management and/or other healthcare support functionality being provided via interaction or cooperation with third-party software applications. Homogeneous embodiments may include those in which the client side services are provided by standalone executable software applications, as well as those in which client side software executes within a web browser or similar environment.

[0045] Arrows in the architecture diagram 300 indicate possible transactions which may take place within the system 100. For example, a user of client terminal 108 may request access to a record as indicated by the arrow 308. In this instance, the requested record is held in the local database 110, and is therefore immediately retrieved, e.g. by the locally executing application 210, without any requirement for further transactions within the system 100.

[0046] In an alternative example illustrated in Figure 3a, a patient client terminal 118 requests a record from the server 106, as represented by the arrow 310. In this case, a requested record (or at least a current version of the requested record) is not held within the central database 104, but is identified by the platform 306 as being available in the local database 116. Accordingly, a request 312 is made in order to retrieve the record from the database 316, which is then returned to the server, as indicated by the arrow 314. At this point, a copy of the record may be stored in the central database 104 for future reference, depending upon synchronisation settings for the record in question. In any event, the requested record is then transmitted 316 back to the requesting client terminal 118.

[0047] All transactions, operations and changes which take place within the system 300 are recorded in one or more logs 318 stored within the central database 104. This enables the platform 306 to track all operations taking place within the system, thus maintaining an audit trail. Naturally, all users of the system 100 are required to sign in, and the user responsible for each transaction is therefore known, and user identities are stored within the logs 318.

Additionally, the access rights to particular records within the system, whether stored within the central database 104, or the local databases 110, 116, are able to be controlled on the basis of each individual user identity. In particular, the platform 306 will deny a user access to any records for which permission has not been expressly granted. Access rights may be based on individual user identities and/or upon membership of relevant medical networks, as discussed in greater detail below, particularly with reference to Figures 4 to 6.

[0048] Figure 3b is a block diagram 320 illustrating a software architecture of a homogeneous embodiment of the invention. The architecture 320 comprises the underlying network infrastructure 302, and the distributed platform layer 306.

Access is provided, by the platform 306, to a distributed database comprising local 110 and centralised 104 database storage. Executable instructions 230 implemented on the server 106 may comprise one or more web server processes, facilitating access to server functionality by software executing on client terminals, e.g. conventional web browser software, using protocols such as FITTPS/FITTP. Server side functionality, such as service of static and/or dynamic web pages, delivery of client side code for execution on client terminals, and so forth, is provided by application layer processes 324.

[0049] Software executing on client terminals, e.g. 108, may comprise database access modules 326, facilitating access to local and remote database storage, either directly or via functionality implemented on the server side. A client side user interface process, 328, facilitates interaction between the user and functionality provided by the server 106, along with information stored within the various database repositories, e.g. 110, 104.

[0050] Figure 3c is a block diagram 330 illustrating schematically a software architecture of a heterogeneous embodiment of the invention, which integrates with a third-party practice management system. Again, the architecture 330 comprises the underlying network infrastructure 302, and the platform layer 306 providing information transport between the various distributed elements of the system. On the server 106 there is again provided a web services layer 322 and a server side application layer 324.

[0051] Within the heterogeneous architecture 330 the database access component 326 and client side user interface component 336 execute alongside and/or in cooperation with a third-party practice management application which may comprise its own database access components 332 along with its own user interface 334. Accordingly, the user interface component 336 differ from the equivalent components 328 of the homogeneous architecture 320 in that the user interface is now complementary to that of the third-party practice management software. For example, the user interface component 336 need only provide information, such as details of patient health records held within the central database 104, and access to additional functionality provided by the server 106 that is not already available via the third-party application user interface 334. By monitoring activity of the third-party application, the user interface component 336 may be responsive to events occurring within the practice management application, such as the opening of a new patient record.

[0052] The local database 110 may be, wholly or partially, a database maintained by the third-party application software, and may be accessed directly by the database access component 326 embodying the invention, e.g. via SQL or other standardised interface, and/or may be accessed via the third-party database access components 332. As will be appreciated, all such variations are dependent upon system and user requirements, and may be accommodated within the scope and embodiments of the invention.

[0053] Furthermore, in some embodiments a local database (not shown) may be maintained by the database access component 336 to maintain copies of records held within the central database 104 that are created and/or accessed by local users via the user interface component 336. In this case, the database access component 336 and/or components of the platform layer 306 are responsible for maintaining synchronisation of records between the local database and the central database 104.

[0054] Figure 4 is a schematic diagram illustrating a medical network 400, according to an embodiment of the invention. At one level, the medical network 400 is a healthcare-specific professional network, which includes individual healthcare professionals, departments, organisations and institutions participating in the provision of services to a patient in respect of a particular medical condition. However, in accordance with embodiments of the invention, a medical network 400 also corresponds with specific records and data structures held within the databases of the system 100.

[0055] At the conceptual ‘centre’ of the network is the GP 402, who is the primary healthcare provider of a patient 404. In managing a medical condition of the patient 404, the GP 402 may need to refer the patient to a variety of other service providers. For example, the patient may require pathology services 404, hospital services 406, counselling 408, and other specialist services 410. The GP 402 acts as the primary custodian and curator of the medical records of the patient 404. As such, the GP 402 is primarily responsible for the formation of the network 400 relating to the medical condition of the patient 404. In accordance with access permissions which may be granted by the creator of information stored within the system 100, with the consent of the patient 404, members of the network 400 are able to share information directly with one another, via the system platform 306.

[0056] As shown in Figure 4 in particular, the GP 402 shares information, for example regarding the patient’s medical history, with the various other medical service providers. These network members are also able to share information, such as pathology results, with the GP, and with other members of the network, such as the hospital 406. All of these records may be stored locally, e.g. in local databases 110, and/or may be synchronised to the central database 104.

Synchronisation settings may be configured by the individual creators of new patient information and other records stored within the system 100.

[0057] Figure 5 is a block diagram illustrating an exemplary data model 500 embodying the invention. It will be appreciated that the model 500 is not intended to be exhaustive, and may be extended to include additional classes of data, as may be required. Furthermore, the exemplary data model 500 is just one of many models which might be developed in various embodiments of the invention.

[0058] A ‘doctor’ data class 502 is used to store information about particular medical practitioners, including a unique practitioner code, registration numbers, and other authorisation numbers as may be required or provided in accordance with various regulations. For example, a practitioner’s registered prescriber or authority numbers may be stored within the ‘doctor’ records 502, to enable the platform to generate prescriptions electronically.

[0059] A ‘patient’ data class 504 contains patient details such as insurance numbers and information which may be relevant to medical history or condition, such as occupation, marital status, and so forth.

[0060] Some elements of ‘doctor’ and ‘patient’ data classes may be similar or common, such as name, gender, date of birth, contact numbers, home and/or work addresses and so forth.

[0061] An ’organisation’ data class 506 is used to hold details of organisations, such as hospitals, clinics and so forth, with which doctors and other healthcare practitioners are associated, e.g. byway of employment, consultancy, or other relationship.

[0062] It should be noted that person records have a one-to-one relationship with doctor records and patient records, i.e. a doctor or a patient is a unique person. Flowever, there may be multiple location records associated with any individual person, and furthermore location records may be associated with other types of record, such as those relating to hospitals or other organisations (not shown in the data model 500).

[0063] A variety of further data classes are associated with other information that may be generated and/or stored within the system 100. Many of these data classes correspond with records which will be associated with particular patient records. A number of examples of such data classes are illustrated in the data model 500, however it will be appreciated that these are not intended as an exhaustive list. The additional data classes shown are: prescriptions 510; patient history 512; patient progress notes 514; documents 516; pathology records 518;

immunisation records 520; medical imaging records 522; patient allergy information 524; and general custom field records 528.

[0064] The specific information associated with each data class will depend upon system, regulatory and user requirements. For example, the patient history data class 512 may define records comprising information such as the date of the relevant condition or event, details of the condition or event, treating practitioner’s comments, and so forth.

[0065] As a further example, the prescription data class 510 may define records which themselves include fields of other data types defined within the data model 500. As shown in Figure 5, a data class 530 is provided to define particular medicines, which may be prescribed, and medicines may themselves be associated with records of the ‘interaction’ data type 532, which indicate any potential adverse interactions which may occur between different medications, when simultaneously prescribed. Certain medicines, such as those known to be potentially addictive and/or to be abused by some patients, may be flagged as ‘drugs of concern’. The prescription of such medicines may then be flagged or highlighted by the user interface component 328, 336 when displaying patient records to ensure that a practitioner is aware of such prescriptions. This may assist in identifying potential abuse of drugs of concern, and help to address the problem of ‘prescription shopping’ among members of healthcare networks.

[0066] As yet another example, the ‘document’ data class 516 defines records which are uniquely associated with a specific document template, also having its own data class 534 within the data model 500. The provision of document template records enables document structures to be predefined, for example practitioner letterhead, within which various template fields may be defined, in accordance with the data class 536. Fields may include information such as, for example, document dates, addresses, and document text content.

[0067] Figure 6a is a schematic diagram illustrating the conceptual structure 600 of one possible implementation of a distributed database embodying the invention. It will be appreciated that the actual structure of the database in a particular embodiment need not follow the conceptual structure 600 precisely.

Many implementations are possible, and the conceptual structure 600 is provided principally to illustrate important relationships between records within a database embodying the invention.

[0068] The database contains entries for various medical service providers, patients, and other relevant organisations and individuals who may be involved in the management and treatment of a patient’s medical conditions. The conceptual structure 600 illustrates one GP record 602, which is just one of many provider records within the database. Also shown is one exemplary patient record 604.

[0069] A patient EFIR record 606 collects all information about the patient 604 which is stored in the system. Associated with the patient EHR 606 are:

• any number of progress note records 608, according to the corresponding data class 514;

• any number of patient history records 610, in accordance with the history data class 512;

• any number of immunisation records 612, according to the corresponding data class 520;

• any number of prescription records 614, in accordance with the corresponding data class 510;

• any number of patient letter records 616, in accordance with the document data class 516;

• any number of medical imaging records, such as x-ray records 618, in accordance with the corresponding data class 522;

• any number of pathology records 620, in accordance with the corresponding data class 518; and

• any number of correspondence records 622, in accordance with the document data class 516.

[0070] As will be appreciated, the set of records, and record types, associated with a patient EHR 606, as listed above, is not intended to be exhaustive. Other records associated with the patient EHR record 606 may include allergy records, in accordance with the corresponding data class 524, any number of custom records, which may contain information of any supported data type in accordance with the custom field data class 528, and other types of records, for example according to additional data classes which might be developed as the system evolves.

[0071] There is also associated, at least conceptually, with the patient record 604 one or more condition-dependent networks 624. Generally speaking, a condition-dependent network 624 is a network of medical professionals, and other relevant service providers, involved in the treatment, monitoring and/or management of a particular condition experienced by the patient. This network is created when the GP initially identifies a requirement to refer the patient to additional service providers, such as pathology providers, medical imaging providers, and so forth. The network is extended as the GP and/or other providers refer the patient for further services and/or share information about the patient with other providers, whereby a network such as that illustrated schematically in Figure 4 is formed.

[0072] As will therefore be appreciated, there are significant benefits for service providers to participate in the use of the system embodying the invention.

By installing the client software, establishing a local database, and registering with the platform, providers gain access not only to shared data and information about patients, but also gain access to networks of other service providers, each of which may be a source of referrals, or of services to their own patients. As has been well-established through the success of various social media networks, a ‘network effect’ significantly expands the utility of a platform, enabling vastly more rapid and effective information sharing, improving efficiencies, and creating new opportunities which may simply not exist when individual practitioners operate using isolated, unconnected systems.

[0073] As shown in the conceptual structure 600, the condition-dependent network 624 comprises any number of additional service providers, e.g. 626, 628, which have been linked to the network by sharing of patient information. The network 624 also includes, either explicitly or implicitly, the GP 602 and the patient 604. As the primary healthcare provider, it is clearly beneficial for the GP to have access to patient information generated by other providers within the network 624. It is also beneficial for the patient to have access to their own medical records, so that they can make this information available to other providers, for example if it is necessary for them to see a different GP on one or more occasions. Additionally, the patient may be permitted to add certain types of information to their own patient EHR 606. For example, a patient may be able to add notes in relation to particular conditions or events which may arise between visits to their GP. Enabling patients to document their own progress during treatment, and enter this information directly into their own patient EHR, may significantly improve the ability of the GP to provide the most-effective and efficient management of the patient’s medical conditions.

[0074] Records within the database 600 are generally associated with one or more access control lists, e.g. 630. Access control lists define the access permissions for individual users, networks and service providers, in order to secure patient information, and to ensure that information is only shared with the express or implied knowledge and consent of the patient.

[0075] In various embodiments of the invention, access control lists may be applied to individual records within the database 600, to groups of records (e.g. to all history records 610 of a patient), and may or may not be inherited, e.g. such that providing access to the patient EHR 606 also permits access to all associated patient records. The level and granularity of access control may be adapted to suit the specific requirements in a particular embodiment of the invention, and/or to conform with legal and regulatory requirements, such as those relating to patient privacy.

[0076] In general, an access control list 630 defines available permissions (e.g. read, write, delete) available to different individuals, practices, and members of the condition-dependent network 624. Various access permissions may be provided to the GP 632, the patient 634, other individual service providers 636. In some embodiments, permissions may be based on membership of condition-dependent networks 638, enabling automatic many-to-many sharing to be selectively applied across whole networks of practitioners contributing to the treatment of a patient. Alternatively, sharing of access may be limited to one-to-one or one-to-many arrangements wherein express permissions must be granted to one or more individual service providers in the network 624. In some embodiments, only an owner/creator of the associated patient information may be granted editing (e.g. ‘write’, ‘delete’) rights, while other users may be granted or denied only viewing (i.e. ‘read’) permissions. In other embodiments, more flexible granting of access permissions to at least some types of patient information may be supported.

[0077] As noted above, the conceptual structure 600 of the database is provided by way of example only. In some embodiments, there may be redundancy in this structure. For example, the members of the

condition dependent network 624 may, in some embodiments, be inferred from access permissions which have been granted to various service providers, individuals, and organisations in respect of the patient EHR 606, and the various associated records. Alternatively, access permissions may, in some embodiments, be inferred from membership of particular condition-dependent networks 624. In some embodiments, there may be multiple networks 624 associated with an individual patient 604. These networks may, in general, comprise overlapping groups of service providers, and it may therefore be necessary to maintain separate network information and access control information within the database, as exemplified in the conceptual structure 600.

In general, the invention should not be regarded as being limited to the specific contents, structures and relationships established within the database, which is substantially a matter of database design, and which may depend upon a number of factors, including the technology used to implement the database, and choices made by the database designer.

[0078] Figure 6b shows a flowchart 640 illustrating a method of sharing patient healthcare information such as that embodied in the conceptual database structure 600 among providers of health services to patients. At step 642 a request, generated by a user (e.g. patient or healthcare practitioner) via a terminal device, e.g. 108, 114, 118, 120, is received. At step 644 the requestor (a health services provider or a patient) is identified, to retrieve a corresponding record, such as a GP record 602, patient record 604, or other provider record 626, 628 within a health service network 624 embodied within the database structure 600.

[0079] At step 648 the access control structure 630 associated with the electronic health record 606 of the patient 604 is interrogated, in order to determine an access permission of the requesting user. The access permission is checked 650, and if access is not permitted by the requesting user then the request is rejected 652. Otherwise, the request is accepted 654, and access to the requested information within the electronic health record 606 is provided.

[0080] As will be appreciated, the general healthcare information sharing process 640 may be executed in a variety of different circumstances for different users of the system, including the patient, the patient’s GP, and/or a variety of other health services and allied providers wishing to access and share patient information. Further scenarios in which patient information may be accessed, retrieved, updated, and shared, will now be described with reference to Figures 7a to 7℮.

[0081] The flowchart 700 in Figure 7a illustrates an exemplary use case of an embodiment of the invention, corresponding with a consultation between a GP and a patient.

[0082] Assuming that the patient already has a record within the system, the GP retrieves the patient records at steps 702. At step 704, the GP accesses and reviews the patient history stored within the database. In one possible scenario, the patient may have been referred for testing or treatment following a previous visit. In this case, at step 706 the doctor is able to access and review the results from the referral, which have been added to the patient’s records by the other service provider.

[0083] In an alternative scenario, the patient may not have an existing record within the system. In this case, at step 708 a new patient record is created, which may be an initial empty record, or may contain information imported from an alternative record-keeping system.

[0084] In any event, at the commencement of the consultation the doctor creates a new patient note at step 710.

[0085] In the course of the consultation, the GP may determine that additional tests and/or treatments are required. Without limitation, the flowchart 700 shows four possible examples, namely immunisation 712, the issue of a prescription 714, referral for medical imaging, e.g. x-ray 716, and/or referral for pathology 718. In each of these cases, the GP accesses a relevant area of the user interface of the client application 210 executing on the client terminal (e.g. the GP’s desktop PC), in order to create the necessary records, generate requests or documentation, and/or to add new service providers to the condition-dependent network, so that they are able to access relevant components of the patient records, and add new information, such as test results.

[0086] At the conclusion of the consultation, a history record is automatically created 720. The GP then finalises the patient note at step 722, and closes the patient record at step 724.

[0087] Figure 7b is a flowchart 730 illustrating a process that may be executed when a medical practitioner first signs on to the system embodying the present invention. In this scenario, it is assumed that the medical practitioner has an established practice, including a number of existing patients each of whom has a record maintained within an established practice management system.

Accordingly, this scenario contemplates use of an embodiment of the invention in accordance with the heterogeneous architecture 330 illustrated in Figure 3c. The medical practitioner’s existing patients may or may not already possess records within the healthcare information sharing system. For example, a patient may have previously consulted with another practitioner who is a user of the system.

[0088] At step 732, a new practitioner, who has previously registered to use the system, signs in for the first time. The locally executing application, e.g.

components 326, 336, accesses the existing patient database 110, in preparation to retrieve existing patient data. At step 736, unique identifying information of a first patient is retrieved from the database 110. Retrieved information sufficient ο uniquely identify the patient may include the patient name, patient date of birth, patient national healthcare or social security number, a unique healthcare system identifying number, and/or any other information that can be used to uniquely identify a patient within a relevant healthcare system. At step 738 the centralised database 104 is accessed in order to determine whether the patient has an existing EFIR within the system. If so, then a summary of the existing patient information is retrieved 740 from the database 104. This summary may include such information as the identities of other practitioners with whom the patient has consulted, date of the most recent consultation, and/or any other information to which the current healthcare practitioner is permitted access. The summary may be rendered by a user interface component 336 for viewing by the practitioner, alongside information from the local database 110 which is rendered by the third-party application user interface component 334.

[0089] At step 742, further patient information is retrieved from the local database 110 and uploaded to the platform database 104. According to some embodiments of the invention, the information stored within the local database 110 remains the ‘master’ copy, with all such information and updates being synchronised and/or uploaded to the platform database 104 as required.

[0090] At 744 a check is performed to determine whether there are further patient records within the local database 110 and, if so, the steps 736 to 742 are repeated.

[0091 ] Figure 7c is a flowchart 750 illustrating a process of new patient entry embodying the invention. In this scenario, it is presumed that a practitioner is already a registered user of the healthcare sharing information system embodying the invention, and is consulting with a new patient for the first time. The new patient may or may not have an existing record within the information sharing system, depending upon whether or not the patient has previously consulted with a practitioner who is a user of the system.

[0092] At step 752 the practitioner enters new patient information, including unique identifying information such as the information described above with reference to Figure 7b. Within a homogeneous embodiment, the new patient information may be entered directly into the client side user interface 328, for storage in a local database 110 and/or transmission to a centralised database 104. Within a heterogeneous embodiment, new patient information will typically be entered via the third-party practice management software user interface 334, which is monitored by client side components of the system, e.g. 326, 336, which are then able to retrieve the new information and communicate via the platform 306 with the server 106 and associated database 104. In either case, at step 754 a check is performed to determine whether the patient has an existing EFIR within the information sharing system. If so, then at step 756 the corresponding patient summary information is retrieved from the database 104. The client side user interface, e.g. 328, 336, may also be updated with patient summary information.

At step 758 the local database 110 is updated with new patient information, which may include further information provided by the practitioner and/or additional patient information retrieved from the central database 104, where available.

[0093] Turning now to Figure 7d, there is shown a flowchart 760 illustrating a process for sharing patient data embodying the invention. In this scenario, it is assumed that the patient already has an EHR within the information sharing system, e.g. in database 104, as well as a local patient record within the practitioner’s database 110. Accordingly, when the practitioner opens the existing patient record within the local database, at step 702, a corresponding EHR will be identified within the information sharing system. Within a homogeneous embodiment the local and central records may be integrated and maintained in a synchronised state, and this identification will therefore be immediate. In the case of a heterogeneous implementation, the local client software components monitoring activity within the third-party practice management application will identify the patient record-opening event, and then identify and retrieve information from the corresponding EHR within the database 104. Either way, at step 764 patient summary information is retrieved, and at 766 the patient summary information is displayed via the client side user interface component 328, 336.

[0094] As has been noted above, with reference to Figure 4, a patient’s GP 402 may be regarded as the conceptual centre of their healthcare network. In this model, the GP has primary responsibility for managing medical conditions of their patients. Accordingly, the GP may also have primary responsibility for controlling access and sharing of patient information. Of course, in some environments this primary care role may be taken up by an alternative practitioner. Additionally, or alternatively, each practitioner within the system involved in the care and treatment of a patient may have ownership and control of the specific patient information created and entered by that practitioner.

Whatever the case, however, at step 768 a check is performed to determine whether the current practitioner has ownership or control of information within one or more sub-records of the patient record which has been opened. If not, then additional sharing functionality is not enabled.

[0095] However, if the practitioner has control over any healthcare information in the patient record, at step 770 one or more relevant sharing controls are displayed within the user interface 328, 336 in association with the corresponding information. If the practitioner subsequently activates a share control, this is detected at step 772, and at step 774 the user interface 328, 336 updates to display sharable elements of the patient’s EHR, i.e. a list of one or more sharable EHR sub-records. The practitioner may make sharing selections at step 776, such as providing access to particular sharable elements to specific practitioners, to groups of practitioners within the patient’s healthcare network, and/or any other sharing selections that may be available. Sharing selections may have additional parameters, such as the type of access provided (e.g. read only, or read and update), as well as time period information that may allow indefinite access, or which may limit access to a defined time period, after which the sharing access will be automatically revoked.

[0096] At step 778, the access control list for the record corresponding with the selected sharable element is updated within the database 104.

Subsequently, and within the parameters established by the practitioner when providing the sharing selections, the nominated practitioners and/or network members will have the defined access to the selected sharable elements.

[0097] It is also desirable to provide a mechanism whereby other practitioners who may be providing services to the patient are able to request access to sharable information by the primary provider. Figure 7℮ shows a flowchart 780 illustrating a process for requesting patient data access within embodiments of the invention.

[0098] At step 782, the practitioner requiring access opens the corresponding patient record. This results, at step 784, in client side components of the system retrieving the patient summary, and displaying available summary information, as has been described previously with reference to Figure 7b. At step 786 a check is performed to determine whether there is information available within the patient EHR to which the practitioner might be granted access. In particular, if the patient has previously consulted with other practitioners in the network, there may be existing sub-records for this ‘mutual patient’ that may be available for sharing with the current practitioner. If not, then the process terminates. Otherwise, at step 788 the relevant practitioner information is retrieved, and at step 790 a listing of historical and/or current practitioners associated with the mutual patient, and associated available information, is displayed. By interacting with the listing of historical practitioners, the active practitioner may request that information controlled by those practitioners be shared. Accordingly, at step 792 one or more access requests is received as a result of such interactions. At step 794 these access requests are transmitted to the server 106, and are recorded within the database 104.

[0099] At step 796, which may occur either before or after the access requests have been made, a practitioner to whom such a request has been directed signs in to the system. A check is performed at step 798 to determine whether any access requests are pending. If so, then at step 7002 any pending access requests are presented to the practitioner via the user interface components of the practitioner’s client device, e.g. components 328, 336.

Responses to these access requests are received, at step 7004, via suitable interactions with the user interface. Where access is granted, the access control lists of the corresponding sharable element patient records are updated within the database 104 at step 7006. Subsequently, the requesting practitioner will be provided with access to the requested information. As discussed above, with reference to Figure 7d, additional parameters for the sharing, such as access permissions and/or a defined time period for access, may be provided.

[00100] Further checks for new access requests, as at step 798, may be performed periodically while a practitioner is signed in to the system, in order to provide notifications of new requests in real-time. In some embodiments, the server 106 may be programmed to provide push-notifications to client-side software components, such that real-time notifications are provided without the need for periodic polling of the database 104. These, and other alternative configurations such as will be apparent to persons skilled in the relevant art, are all within the scope of the invention.

[00101] It should be appreciated that the various scenarios illustrated in Figures 7a to 7℮ are not exhaustive or mutually exclusive. In various embodiments of the invention, other scenarios may be supported and/or the features, steps and processes of the various described scenarios may be combined. For example, in the case that a practitioner opens an existing ‘own patient’ record, as illustrated in the flowchart 760 of Figure 7d, in addition to being able to grant access to patient information with other practitioners in the network, the practitioner may also be presented with a listing of other practitioners associated with the patient, and enables to request that corresponding patient data be shared, as shown in the flowchart 780 of Figure 7℮. These, and other, variations and combinations of the features and processes described with reference to Figures 7a to 7℮ are encompassed within the scope of the invention as defined in the appended claims.

[00102] While specific details of the user interface designs are not essential to the invention, and various embodiments are possible, Figures 8 to 12 illustrate a number of exemplary display screens in order to facilitate understanding of the capabilities and operation of embodiments of the invention.

[00103] Figure 8 is an exemplary screen display 800 illustrating a patient record interface embodying the invention. More particularly, the display 800 shows an interface for editing patient notes. Prior to arriving at this display, the GP or other practitioner will have initially logged into the system using their own credentials, such as a user name and password. The practitioner will then have identified the required patient record, and opened this record up on the display as shown.

[00104] A series of tabs 802 is provided, each of which enables the practitioner to access an interface for creation and editing different types of patient records.

A number of these interfaces are described, by way of example, with reference to Figures 8 to 12. In order to avoid unnecessary repetition, not all of the interfaces are described in detail, however it will be appreciated that each provides a corresponding set of user interface elements for viewing, creating and editing records of the corresponding type.

[00105] At the top of the patient record display is located a set of button elements 804, enabling the practitioner to save and/or close the patient record.

Notably, these buttons apply to the patient EHR as a whole, i.e. the record 606 shown in the conceptual structure 600 of Figure 6. As described further below, individual records associated with the patient EFIR may be created, edited and saved independently.

[00106] Also in the upper part of the display 800 is a button element 806 enabling the practitioner to log out of the system when access is no longer required.

[00107] In the lower part of the display 800 user interface elements are provided for accessing patient records. A button element 808 is provided to enable the practitioner to select and open the EFIR of another patient. In order to identify the desired patient, a search facility 810 is provided. Additionally, a button element 812 enables the practitioner to access a list of recently viewed patient records, for quick reference.

[00108] Τurning now to the notes tab 814 of the display 800, there are two separate regions 816, 818. On the left, the region 816 is provided for entry of a patient note in relation to a current consultation. As shown, the note has an associated title, and a free-text region for entering note contents. On the right-hand side, is a region 818 which displays notes from previous patient consultations. A search facility 820 is provided, so that the practitioner may rapidly access notes relating to prior consultations which may be relevant to the current consultation, or indeed for any other purpose.

[00109] A save button 822 enables the current note record contents to be saved to the database.

[00110] Figure 9 is an exemplary screen display 900 illustrating a history record creation interface embodying the invention. As discussed above, with reference to step 720 of the flowchart 700, a history record is automatically created at the conclusion of a consultation. The history record, in particular, records the date and time of the consultation. Additionally, the practitioner is able to access a history tab 902, within which new history record information may be entered, for example into the free-text region 904. A save button 906 enables the history record to be saved.

[00111 ] Figure 10 is an exemplary screen display 1000 illustrating an interface to medical imaging records associated with a patient record, according to an embodiment of the invention.

[00112] The practitioner accesses the display 1000 by selecting the imaging tab 1002. The main region 1004 of the imaging tab display comprises a list of past medical imaging requests, enabling the practitioner to review this history of medical imaging, and access results which have been obtained and uploaded to the system.

[00113] A button element 1006 is provided to enable the practitioner to create a new imaging request. Such a request, for example for x-ray imaging to be performed, may be sent directly to the relevant imaging lab via the database system, or may be communicated via other channels. Preferably, however, imaging labs selected for the provision of services are also registered subscribers of the system, to enable requests and results to be shared electronically.

[00114] Figure 11 shows an exemplary screen display 1100 illustrating an interface to letters associated with a patient record. The practitioner accesses the display 1100 by selecting the letters tab 1102. In the exemplary embodiment, the letters tab provides a typical ‘file explorer’-type display, in which letters may be organised into folders, shown in the region 1104 on the left, and letters stored within the current folder are shown in the region 1106 on the right of the display. The practitioner may create a new letter, by selecting the button element 1108.

Additionally, a search facility 1110 is provided, to assist the practitioner in finding letters relating to specific subject matter.

[00115] Figure 12 is an exemplary screen display 1200 illustrating a letter creation interface, accessed by selecting the new letter button element 1108. A letter window 1212 opens, which includes fields for entering a letter title 1204, and a letter recipient 1206. The letter recipient may commonly be another practitioner to whom the patient is being referred, and may be selected from known recipients, the details of which are held within the database. Accessing available recipients may be performed via an address book function 1208.

[00116] Letters created within the interface 1200 are associated with predefined templates, which can be accessed via the change template button element 1210. A template determines the format of the letter, including its appearance (such as appropriate practitioner letterhead), and any specific fields that are required to be completed within the letter.

[00117] Contents of the letter may be input to the text entry field 1212.

[00118] Once the letter is completed, the practitioner may activate the send button element 1214. Depending upon preferences and settings for the selected recipient 1206, this may result in the letter being sent directly, by electronic means (such as via email, or using a messaging facility built into the system).

Alternatively, the letter may be saved and sent to a printer and subsequently forwarded via mail, or provided to the patient for hand delivery upon attendance at the recipient’s premises.

[00119] While the foregoing describes a number of core aspects of embodiments of the invention, additional features to facilitate effective information exchange, teamwork and patient health management can also be provided. For example, in some embodiments secure instant messaging may be implemented among healthcare providers via the platform 306. Such instant messaging features may be implemented via a familiar messaging interface, however communications would be private and securely restricted to identified members of a patient network, e.g. GPs, allied health workers and organisations (e.g.

hospitals, nursing homes). Messaging may be facilitated by a ‘matchmaking’ service designed to identify and introduce users to the system, and/or by identifying mutual patients having electronic health data shared between practitioners.

[00120] Other team-working features may also be provided, such as patientcentred chat rooms, to enable multiple practitioners within a patient network to communicate simultaneously in a virtual conference. Such conferences may be supported by the provision of shared document facilities. For example, some embodiments of the invention may incorporate electronic interactive collaborative chronic complex disease management plans which can be edited by members of a patient network, i.e. team-carers, on a marked-up document basis for shared access and subsequent joint discussion via a chat room facility.

[00121] The foregoing description has been provided to illustrate various exemplary features of specific embodiments of the invention. Flowever, this description is not intended to be limiting of the scope of the invention, which encompasses implementation variations falling within the knowledge and capabilities of the person skilled in the art. Throughout the description, a number of aspects of the implementation which may be subject to variation have been identified. Furthermore, certain features have been described in part and/or by way of example, while the potential for additional, extended and/or analogous features has been indicated. Flowever, the fact that variations and extensions have not been discussed in relation to other features should not be taken to imply that such variations and extensions are not possible, or do not fall within the scope of the invention. Rather, the scope of the present invention is as defined the claims appended hereto.