PORTABLE COMPUTING DEVICE BASED SECURE MEDICAL RECORDS MANAGEMENT
BACKGROUND
Field
[0001] Embodiments of the present disclosure generally relate to the field of electronic medical health record management. More particularly, the present disclosure relates to storage and management of health records on a portable computing device for access by a medical professional through low energy wireless interfaces.

Description of the Related Art
[0002] The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
[0003] A variety of Internet-based systems for providing access to a patient's health record and related healthcare information have been proposed. Health record management is crucial for both patients as well as hospitals. Typically, records are managed on a Hospital Information System (HIS) and are not available for access by other hospitals. The records could be paper-based or in digital format. Some developed nations such as Denmark and Taiwan have systems that can retain health information on a centralized database, which requires all hospitals to be able to access the centralized database to access extended health records. The infrastructure requirements for such a system are large, and require high-speed connectivity and centralized/secure servers. A patient can access the health records through a web-based interface. However, there is no interoperability between records of various hospitals that the patient has consulted. Hence centralized systems cannot be used due to large population, infrastructure requirements, and connectivity problem. In developing countries, there is no centralized management of health records and records are mostly retained by patients in a paper format OPD (Out-Patient Department) cards, which are cumbersome to maintain along with the paper-based reports, which are prone to errors and are unreliable.
[0004] Some hospitals or medical insurance companies issue Healthcards on plastic smartcards. Healthcards are based on smartcards that are plastic cards that have been used in many nations to store basic patient identification information and health information. The smartcard has a secure region and a cryptographic processor to securely store the information, and authenticate an external reader and allow only permissible information to be accessed. Due to the space limitations, the smartcard can only retain part of the patient health records. Smartcard based healthcards are still to come into existence in developing countries like India. Work is still being done for a secure, electronic patient record management as a Healthcard on a Smartcard in India.
[0005] In developed countries, owing to better infrastructure, there is an expectation of better quality healthcare. The digitized records can be on a centralized server such as on a cloud, and patient can be provided with a healthcard on a smartcard that retains basic medical history. The expectation of right healthcare provided at the right time is very high, especially in case of emergency care, care of the elderly, and care in remote locations. There may be difficulty in accessing detailed medical history of the patient in these situations. For right care to be provided, detailed patient medical records are essential and should easily be accessible.
[0006] Even though digitization of records is being done at a hospital level, patient is required toretain all records in some paper-based format when consulting various medical professional’s spread across different hospitals with different sets of record management techniques. Hence, the patient may end up carrying paper/ electronic based reports, leading to burden of maintaining records by the patient.
[0007] Current implementations of portable health records on mobile devices use it temporarily for aggregating information stored in different servers, as an authentication device, or for taking readings from health sensor devices. Hence, the records may not be current ones. Moreover, accessing records from different locations may not be possible when connectivity is unavailable. The portable solutions also do not address the ease of access of the records from the patient device.
[0008] There is therefore a need in the art to retain Electronic Health Records (EHR) digitally by patients on portable devices so that the patients can seek medical treatment irrespective of the hospital that they are associated with, even in cases of emergency and while getting second opinions for specialized treatments, among other like situations.
[0009] All publications herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
[0010] In some embodiments, the numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term “about.” Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.
[0011] As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
[0012] The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. “such as”) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.
[0013] Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.

OBJECTS OF THE INVENTION
[0014] It is an object of the present disclosure to provide secure interaction and/or transfer/access of health information/records between a patient and a medical professional.
[0015] It another object of the present disclosure to utilize hardware tamper resistant storage on a SE on a memory device such as a micro SD card/SIM to store credentials and setup a security handshake.
[0016] It is another object of the present disclosure to provide a memory device that stores health records/information in a format that can enable seamless integration with heterogeneous HIS.
[0017] It is another object of the present disclosure to provide the patient with right medical care provided at the right time due to the availability of records.
[0018] It is another object of the present disclosure to provide interoperability of EHR between hospitals.
[0019] It is another object of the present disclosure to enable secure and authenticated transfer of health information/records between portable communication devices such as mobile devices of patients and respective medical professionals.

SUMMARY
[0020] The following disclosure presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.
[0021] Embodiments of the present disclosure generally relate to the field of electronic medical health record management. More particularly, the present disclosure relates to storage and management of health records on a portable computing device for access by a medical professional through low energy wireless interfaces.
[0022] According to one embodiment, the present disclosure relates to a system for managing health records of a patient, wherein the system can include a memory device that can be configured in a first portable computing device of the patient, and wherein the memory device can be configured to store health information/records of the patient and include a SE that can be configured to store any or a combination of session security key(s), patient identification information, certificates, and security information of the patient. The proposed system can further include a second portable computing device of a medical professionalthat can be configured to tap with the first portable computing device of the patient through a low energy wireless interface, wherein the coupling between the second portable computing device and the first portable computing device can enable the medical professional to access at least a part of the health information/records after secure authentication and authorization.
[0023] In an aspect of the present disclosure, the health information/records can be stored in the memory device in an encrypted manner. In another aspect, the medical professionals can include a nurse, a hospital administrator, a doctor, a lab technician, a pharmacist, an emergency personnel, or any other authorized stakeholder in the medical industry. In yet another aspect, the low energy wireless interface can include Near Field Communication (NFC) and Bluetooth.
[0024] According to one embodiment, the medical professionalcan be configured to have a defined set of rights based on which he/she can read/write/modify the part of the health information/records. In another embodiment, the second computing device can include a (SE) that can be configured to store any or a combination of session security key(s), patient identification information, certificates, security information of the medical professional, and security information of the patient. In yet another aspect, the second portable computing device and the first portable computing device can undergo a handshake process for secure exchange of at least a second part of the health information/records, and wherein the handshake process can enable setting up of at least one secure session key that can be stored in the SE of the first portable computing device and/or in the SE of the second portable computing device.
[0025] According to one embodiment, system of the present disclosure can include a health service server that can be accessible to a medical professional through the second portable computing device, wherein the health service server can be configured to perform any or a combination of authentication of the medical professional, registration of an appointment of the medical professional with a patient, configuration of a part of the health information/records that would be accessible to the medical professional, access right management for the medical professional, and provision of security services to the medical professional. In another aspect, the proposed system can further include a means to enable backup of the health information/records of the patient on a secured server and/or on the health service server.
[0026] Furthermore, the memory device can store the health information/records of the patient in a format/protocol that is compatible with multiple Health Information Systems (HIS).
[0027] According to one embodiment, the proposed architecture addresses the issues of retaining health records on a patient’s computing/mobile device. In an aspect, portable computing device of the patient can be used as a contactless card, and can be accessed by an authorized medical professional mobile/computing device with a simple tap. In spite of the simplicity of access, there is secure interaction between the patient and the medical professional through incorporation of a hardware tamper resistant storage on Secure Element (SE) on the memory devices of the patient(s) and/or the medical professional(s) such as micro SD cards/ SIM cards, which can be used to store credentials and setup a security handshake. In an aspect, format of the health records stored on the card can be such that it can be integrated with heterogeneous HIS. According to one embodiment, the proposed system can provide a patient with right medical care provided at the right time due to the availability of records. The proposed system can also provide interoperability of EHR between heterogeneous hospitals.
[0028] In another aspect, the present disclosure relates to health records from various hospitals that need to be retained in digital format (EHR) with patient on a medical/memory card/device on a portable mobile device. The present disclosure further relates to an integrated system that retains patient EHR securely on a portable mobile device retained by the patient, wherein the medical card, also referred to as memory card/device hereinafter can store medical/patient’s information/records in an encrypted format in any storage space on the mobile device. The security credentials including patient identification, certificates, security key and temporary session security key, for say an OPD session, can be stored on the SE portion (say a Java Card) of the memory device such as a microSD/SIM card. Through such an architecture, the patient can have all the current/medical records always available with him on the portable mobile device. Patients can also view medical records on their portable computing devices by accessing the encrypted health card internally. A medical professional such as doctor, nurse, lab test technician, pharmacist, emergency personnel can access part of the medical card/memory device storing the patient’s medical records based on their access rights, through low energy wireless interface like NFC based Host Card Emulation (HCE) and Bluetooth by tapping medical professional’s mobile device to patient’s mobile device. Patient’s mobile/computing device can therefore be used as a contactless card. After an initial security handshake, a secure session key can be setup and stored on the SE of the patient and/or medical professional mobile devices. It can be used for encrypting data exchanged between the patient and the medical professional. A health service server on a cloud, for instance, can be accessible to the medical professional for cryptography support and can assist in providing security services for authentication and management of access rights. A patient can also store copy of EHR on a patient digital health locker on the same or another cloud service/server in order to maintain backup of patient health records. In case of theft or damage of the patient mobile device or health card, security credentials can be revoked and medical card may be retrieved from locker. The card can be maintained in formats such as HL7, so that EHR from patient’s medical card can be integrated with various HIS, which can provide interoperability between heterogeneous hospitals. A patient can also therefore seek medical care across heterogeneous hospitals by retaining his/her medical information securely on a hand held device, and reduce the burden of accessing a central server or carrying paper based records.
[0029] In another aspect, the present disclosure relates to EHR to be retained on a patient portable mobile device and providing secure access to medical professional through contactless interfaces of NFC based HCE and Bluetooth. The records can be accessed by an authorized medical professional in a hospital. The records can be integrated into the HIS and hence provide interoperability of records across heterogeneous HIS.
[0030] Other systems, methods, features, and advantages of the present invention will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS
[0031] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
[0032] FIG. 1 illustrates an exemplary network architecture of the proposed health record management system in accordance with an embodiment of the present disclosure.
[0033] FIG. 2Aillustrates an exemplary system block diagram of a portable patient EHR stored on patient mobile device in accordance with an embodiment of the present disclosure.
[0034] FIG. 2B illustrates an exemplary system block diagram of a medical professional portable computing device used to read the memory device/card in accordance with an embodiment of the present disclosure.
[0035] FIG. 3 illustrates an exemplary block diagram illustrating communication interface between health card and medical professional mobile device in accordance with an embodiment of the present disclosure.
[0036] FIG. 4 illustrates an exemplary block diagram illustrating personalization of Patient Mobile Device by a Health Service Administrator to setup of security credentials in SE in accordance with an embodiment of the present disclosure.
[0037] FIG. 5 illustrates an exemplary block diagram illustrating personalization of Medical Professional Mobile Device by the Health Service Admin setup of security credentials in the SE in accordance with an embodiment of the present disclosure.
[0038] FIG. 6 illustrates an exemplary block diagram illustrating system architecture and interaction between the entities in accordance with an embodiment of the present disclosure.
[0039] FIG. 7 illustrates an exemplary block diagram illustrating medical professional’s check-in for a counseling/consulting session in a hospital in accordance with an embodiment of the present disclosure.
[0040] FIG. 8illustrates an exemplary block diagram illustrating patient registration for a counseling/conducting session in a hospital in accordance with an embodiment of the present disclosure.
[0041] FIG. 9illustrates an exemplary block diagram illustrating execution of a medical/consulting session in accordance with an embodiment of the present disclosure.
[0042] FIG. 10illustrates an exemplary block diagram illustrating lost patient mobile device recovery in accordance with an embodiment of the present disclosure.
[0043] FIG. 11A illustrates an exemplary block diagram illustrating NFC card emulation with a SE in accordance with an embodiment of the present disclosure.
[0044] FIG. 11B illustrates an exemplary block diagram illustrating NFC based HCE in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION
[0045] Embodiments of the present disclosure generally relate to the field of electronic medical health record management. More particularly, the present disclosure relates to storage and management of health records on a portable computing device for access by a medical professional through low energy wireless interfaces.
[0046] Embodiments of the present disclosure include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, firmware and/or by human operators.
[0047] In various embodiments, the article(s) of manufacture (e.g., the computer program products) containing the computer programming code may be used by executing the code directly from the machine-readable storage medium or by copying the code from the machine-readable storage medium into another machine-readable storage medium (e.g., a hard disk, RAM, etc.) or by transmitting the code on a network for remote execution. Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present disclosure with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present disclosure may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the present disclosure could be accomplished by modules, routines, subroutines, or subparts of a computer program product.
[0048] Throughout the following discussion, numerous references will be made regarding servers, services, interfaces, engines, modules, clients, peers, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor (e.g., ASIC, FPGA, DSP, x86, ARM®, ColdFire®, GPU, etc.) configured to execute software instructions stored on a computer readable tangible, non-transitory medium (e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions. One should further appreciate the disclosed computer-based algorithms, processes, methods, or other types of instruction sets can be embodied as a computer program product comprising a non-transitory, tangible computer readable media storing the instructions that cause a processor to execute the disclosed steps. The various servers, systems, databases, or interfaces can exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, known financial transaction protocols, or other electronic information exchanging methods. Data exchanges can be conducted over a packet-switched network, the Internet, LAN, WAN, VPN, or other type of packet switched network.
[0049] Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.
[0050] If the specification states a component or feature “may”, “can”, “could”, or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.
[0051] Embodiments of the present disclosure generally relate to the field of electronic medical health record management. More particularly, the present disclosure relates to storage and management of health records on a portable computing device for access by a medical professional through low energy wireless interfaces.
[0052] According to one embodiment, the present disclosure relates to a system for managing health records of a patient, wherein the system can include a memory device that can be configured in a first portable computing device of the patient, and wherein the memory device can be configured to store health information/records of the patient and include a SE that can be configured to store any or a combination of session security key(s), patient identification information, certificates, and security information of the patient. The proposed system can further include a second portable computing device of a medical professional that can be configured to operatively couple with the first portable computing device of the patient through a low energy wireless interface, wherein the coupling between the second portable computing device and the first portable computing device can enable the medical professional to access at least a part of the health information/records.
[0053] In an aspect of the present disclosure, the health information/records can be stored in the memory device in an encrypted manner. In another aspect, the medical professionals can include a nurse, a hospital administrator, a doctor, a lab technician, a pharmacist, an emergency personnel, or any other authorized stakeholder in the medical industry. In yet another aspect, the low energy wireless interface can include NFC and Bluetooth.
[0054] According to one embodiment, the medical professional can be configured to have a defined set of access rights based on which he/she can read/write/modify the part of the health information/records. In another embodiment, the second computing device can include a SE that can be configured to store any or a combination of session security key(s), patient identification information, certificates, security information of the medical professional, and security information of the patient. In yet another aspect, the second portable computing device and the first portable computing device can undergo a handshake process for secure exchange of at least a second part of the health information/records, and wherein the handshake process can enable setting up of at least one secure session key that can be stored in the SE of the first portable computing device and/or in the SE of the second portable computing device.
[0055] According to one embodiment, system of the present disclosure can include a health service server that can be accessible to a medical professional through the second portable computing device, wherein the health service server can be configured to perform any or a combination of authentication of the medical professional, registration of an appointment of the medical professional with a patient, configuration of a part of the health information/records that would be accessible to the medical professional, access right management for the medical professional, and provision of security services to the medical professional. In another aspect, the proposed system can further include a means to enable backup of the health information/records of the patient on a secured server and/or on the health service server. Furthermore, the memory device can store the health information/records of the patient in a format/protocol that is compatible with multiple medical professionals.
[0056] According to one embodiment, the proposed architecture addresses the issues of retaining health records on a patient’s computing/mobile device. In an aspect, portable computing device of the patient can be used as a contactless card, and can be accessed by an authorized medical professional mobile/computing device with a simple tap. In spite of the simplicity of access, there is secure interaction between the patient and the medical professional through incorporation of a hardware tamper resistant storage on SE on the memory devices of the patient(s) and/or the medical professional(s) such as micro SD cards/ SIM cards, which can be used to store credentials and setup a security handshake. In an aspect, format of the card can be such that it can be integrated with heterogeneous HIS. According to one embodiment, the proposed system can provide a patient with right medical care provided at the right time due to the availability of records. The proposed system can also provide interoperability of EHR between hospitals.
[0057] In another aspect, the present disclosure relates to health records from various hospitals that need to be retained in digital format (EHR) with patient on a medical/memory card/device on a portable mobile device. The present disclosure further relates to an integrated system that retains patient EHR securely on a portable mobile device retained by the patient, wherein the medical card, also referred to as memory card/device hereinafter can store medical/patient’s information/records in an encrypted format in any storage space on the mobile device. The security credentials including patient identification, certificates, security key and temporary session security key, for say an OPD session, can be stored on the SE portion (say a Java Card) of the memory device such as a microSD card. Through such an architecture, the patient can have all the current/medical records always available with him on the portable mobile device. Patients can also view medical records on their portable computing devices by accessing the encrypted health card internally. A medical professional such as doctor, nurse, lab test technician, pharmacist, emergency personnel can access part of the medical card/memory device storing the patient’s medical records based on their access rights, through low energy wireless interface like NFC based HCE and Bluetooth by tapping medical professional’s mobile device to patient’s mobile device. Patient’s mobile/computing device can therefore be used as a contactless card. After an initial security handshake, a secure session key can be setup and stored on the SE of the patient and/or medical professional mobile devices. It can be used for encrypting data exchanged between the patient and the medical professional. A health service server on a cloud, for instance, can be accessible to the medical professional for cryptography support and can assist in providing security services for authentication and management of access rights. A patient can also store copy of EHR on a patient digital health locker on the same or another cloud service/server in order to maintain backup of patient health records. In case of theft or damage of the patient mobile device or health card, security credentials can be revoked and medical card may be retrieved from locker. The card can be maintained in formats such as HL7, so that EHR from patient’s medical card can be integrated with various HIS, which can provide interoperability between heterogeneous hospitals. A patient can also therefore seek medical care across heterogeneous hospitals by retaining his/her medical information securely on a hand held device, and reduce the burden of accessing a central server or carrying paper based records.
[0058] In another aspect, the present disclosure relates to EHR to be retained on a patient portable mobile device and providing secure access to medical professional through contactless interfaces of NFC based HCE and Bluetooth. The records can be accessed by an authorized medical professional in a hospital. The records can be integrated into the HIS and hence provide interoperability of records across heterogeneous HIS.
[0059] FIG. 1 illustrates an exemplary network architecture 100 of the proposed health record management system in accordance with an embodiment of the present disclosure. In an aspect of the present disclosure, the architecture 100 can include one or more patients 102, represented through a single patient 102 in the present illustration for simpler/clear understanding, and one or more medical professionals 104represented through a single medical professional 104 in the present illustration for simpler/clear understanding, both of which have respective portable computing devices, i.e. device 108 for patient 102 and device 110 for medical professional 104. According to one embodiment, the portable computing devices 108/110 can include, but are not limited in any manner to, a mobile phone, a smart phone, a tablet PC, a laptop or any other portable computing device.
[0060] In an aspect, the device 108 can include a display 112 and a memory 114, wherein the memory 114 can be configured to store one or more medical information/records pertaining to the patient 102, which information/records can be viewed by the patient 102 on the display 112. In an aspect, the medical records can be stored in a categorized/defined format that remains same for all patients 102 that form part of the system 100 so that consistency in record management/extraction can be maintained. For instance, the records can be kept in a chronological and disease/medical condition based manner so that in case the patient 102 has diabetes, all his tests, evaluations, medication, prescription can be simply extracted by using the data in the defined medical condition category of diabetes. In another instance, records can be stored as visit-based records for a department such that the records are viewed based on departments or visit view. The records can be parsed to store list of medications, diseases, allergies, vaccinations. In yet another embodiment, HL7 records and the list can be stored in a Jason format.
[0061] Furthermore, any other parameter can be used to categorize/configure the stored medical information, and all such embodiments/formatting configurations are completely within the scope of the present disclosure.
[0062] In an embodiment, memory 114 can include a first storage portion 116 where medical records/information can be stored in an encrypted format (for instance), and a SE 118 that can be configured to store any or a combination of session security key(s), patient identification information, certificates, and security information of the patient 102. Such a construction is completely exemplary in nature and any other configuration/embodiment is completely within the scope of the present disclosure. For instance, certain medical records can also be stored the SE 118.
[0063] Similar to device 108, device 110 of the medical professional 104 can include a display 120 and a memory 122, wherein the memory 122 can be configured to store one or more medical information/records pertaining to the patient(s) 102 and/or to the medical professional(s) 104, which information/records can be viewed by the medical professional 104 on the display 120. In an aspect, the medical records can be stored in a categorized/defined format that remains same for all medical professionals 104 that form part of the system 100 so that consistency in record management/extraction can be maintained. For instance, the records can be kept in a chronological and disease/medical condition or appointment based on patient name based or based on any other parameter/attribute or a combination thereof.
[0064] In an embodiment, memory 122 can include a first storage portion 124 where medical records/information can be stored in an encrypted format, for instance, and a SE 126 that can be configured to store any or a combination of session security key(s), patient identification information, certificates, security information of the medical professional, and security information of the patient(s) 102. Such a construction is completely exemplary in nature and any other configuration/embodiment is completely within the scope of the present disclosure. For instance, certain medical records can also be stored the SE 126.
[0065] In an exemplary implementation, portable computing device 108 of the patient 102 can be communicatively coupled with the device 110 of the medical professional 104 through a low energy wireless interface such as through a NFC or a Bluetooth connection to enable transfer/access/management of the medical/health information/records between the devices 108/110. For instance, based on the coupling, the medical professional 104 can access a defined/desired/configured portion of the memory 114 of the patient to review, say the previous medical history, test reports, previous doctors/hospitals visited, among any other information that is configured and authorized to be accessed by the system 100. Test reports/prescriptions or any other medical record of the patient 102 can also be shared/transmitted by the medical professional 104 using the computing device 110 of the professional 104 after the session/tests/examination has been performed by the medical professional.
[0066] According to another embodiment, before any access and/or exchange data takes place between the computing devices 108/110, a handshake exercise can first be performed between the devices using information stored in their respective SE’s 118/126. After the initial security handshake, a secure session key can be setup and stored on the SE 118 of the patient’s device 108 and/or on the SE 126 of the medical professional/professional’s device 110, wherein the session key can be used for encrypting data exchanged between the patient 102 and the medical professional 104.
[0067] According to one embodiment, the proposed system 110 can further include a health service server 106 that can be operatively coupled with the patient’s computing device 108 and/or with the medical professional’s device 110, wherein the server 106 can be configured to provide cryptography support to the concerned stakeholders and can assist in providing security services for authentication and management of access rights. In an aspect, the patient 102 can store a copy of his/her EHR on say a patient digital health locker that can be configured on the server/cloud 106 or on any other backup device/means to maintain a backup of his/her health records. In case of theft or damage of the patient’s computing device such as the mobile phone 108 or health card/memory device 114, security credentials can be revoked and medical card/memory device114 can be retrieved from the patient’s digital locker. In an aspect, the card/device 114can be maintained in formats such as HL7 so that EHR from patient medical card can be integrated with various HIS, which can provide interoperability between heterogeneous hospitals. A patient 102 can therefore seek medical care across heterogeneous hospitals by retaining his medical information securely on a hand held device 108,and reduce the burden of accessing a central server or carrying paper-based records. It is to be appreciated that although the memory devices 114 and/or 122 have been shown to be a part of the computing devices 108/110, the devices can themselves be portables and insertable into the computing devices in a slot, wherein the computing device and the memory devices can authenticate each other based on security information stored in the SE of the memory devices to confirm if the computing devices are authorized to access medical records stored in the memory devices. Any other configuration/construction is also completely within the scope of the present disclosure.
[0068] According to another embodiment, aspects of the present disclosure enable the patient to configure the data/medical records/information that they would like to share with the medical professional, else configure the records that the medical professional can access/retrieve/process/copy/review/view. Similarly, the medical professional can write new records and/or observations to the patient’s device to update the health status.
[0069] In another embodiment, any change in the configuration/construction of the computing device/mobile device can trigger the proposed system to check and validate the integrity of the proposed device, including for instance, to ensure that no medical records are tampered with and that all security/session keys are intact. Authentication of the patient can also be configured at defined/regular intervals to ensure that only a validated/desired patient accesses his/her device at any time.
[0070] The proposed system, in another embodiment, can also be configured to include automatic means for performing any or a combination of scanning, indexing, auto-uploading of documents, editing, OCR, patient scheduling, medication management component, lab order component, base EHR component, general practice-patient-chart-level component (other sub-specialties will vary and are also included), and general practice-level component.
[0071] Various aspects of the present disclosure relate to an example involving EHRs, although the various aspects of the invention may relate to the management and access of other types of records, including legal records, financial records, employment records, and so on. For example, certain aspects of the invention are applicable to point-of-sale authorization and identification of the parties to a transaction. In another example, certain aspects of the invention may enable secure transactions and exchange of information between clients and financial institutions.
[0072] According to one embodiment, when transferring records between patient terminal and medical professional, the patient/medical professional’s identification may be authenticated at any configured time using any combination of a user ID, password, challenge question and biometric information. Typically, the transfer can be made contingent upon a two-way identification of a record holder and a receiver. In-person identification may be made using direct sight. Additionally, both users' portable devices may establish a connection that is confirmed by both the patient and the medical professional. In one example, the connection can include a session secured using encryption keys that are exchanged between the users. The encryption keys may be used to encrypt and decrypt information transmitted between the devices of the users. The transfer may be made only between proximately located devices.
[0073] In yet another embodiment, the memory device configured to store medical records can be a flash drive/external memory device that is to be operatively coupled with the computing device to enable presentation/access of EHR data. Certain embodiments enable automated access to multiple data sources. In one example, electronic credentials can include encrypted "electronic keychain" that may be maintained as a knowledge base that can include identification and lists of sources of health related information for an individual. The knowledge base can include both the Internet address as well as identification and other credentials needed to enable access to the data. Typically, the health information can be maintained by a plurality of healthcare providers or professionals, and information may be accessible through repositories or databases, including insurance databases and healthcare record portals.
[0074] With reference to FIGs. 2-11, the present disclosure provides a secure portable device based patient electronic health card system. One should appreciate that healthcard or card in the instant disclosure can be interchangeably referred to for the memory device of computing/portable devices that stores the health/medical records/information along with, in the SE, storing session keys, authentication/identifier information along with any other configured information/content.
[0075] In an aspect, FIG. 2A illustrates a patient computing device 108 that can support NFC (202) based HCE and Bluetooth (204) communication interface in computing devices (for instance devices based on Android operating system). Any computing device, as mentioned in FIG. 1, can be incorporated to communicate with computing devices of the medical professionals. In an instance, the computing device 108 can have a provision of accessible SE 118 that forms part of memory device 114 of the device 108 in the form factors of either a SIM card or a micro SD card such as a micro SD card.
[0076] According to one embodiment, a patient health card 206 can be deployed on a micro SD card/memory device114, which can have a SE providing Secure Region (SR) 208 for storage of, for instance, Indent (Identification), Private Key KPr_P, Certificate with the public key and validity of time Cert_P, security key Key_Rec that can be used to store encrypted data. Key_Rec can be entered in the SR through an application on the mobile device 108. In an aspect, SE can be configured/implemented in the form of Java Card and can be a hardware tamper resistant area. In an embodiment, the Java Card can be accessed internally by an Android/software application that has been compiled with special API libraries provided by the micro SD card manufacturer, e.g. GoTrust. In an exemplary implementation, TrustZone, which is a hardware-backed security region, can be implemented by the application processor in the devices with ARM processors. In another exemplary implementation, remaining part of the memory device 114 can be configured as Unsecure Region (USR) 210 that can be configured to store the Healthcard 206, which can include the EHR with text and image portions, say in encrypted format with the security key Key_Rec stored in the SR 208. In an aspect, the health card 206 can include personal information, billing/insurance, records to various department visits with the observations made by the medical professional, list of medications, list of allergies, emergency information. The healthcard 206 can also be stored in a Jason file that can store HL7 based records for various doctor visits as well as a non HL7 region consisting of pre processed text data that can help in fast display of health information such as medications, allergies, vaccinations, emergency information. Non-HL7 data can involve parsing of all previous Hl7 records. In an aspect, a Health Level 7 (HL7) Clinical Document Architecture (CDA) document can be generated/created, wherein the HL7 CDA document can be in a tagged format that is computer readable. In an aspect, the CDA document can be absorbed into the proposed system by, for instance, placing specifically tagged information into the EHR for the purpose of medical record capture, data comparison and analysis, and automatic diagnosis and procedure identification.
[0077] One should appreciate that the representation of FIG. 2A is completely exemplary in nature and no limitation of the type of card, configuration of memory 114 should be construed as limiting the scope of the present invention in any manner.
[0078] According to one embodiment, the patient computing device 108 can be configured with an application that can parse the EHR records securely and display 112 the contents in an organized manner. Since the EHR should be confidential, it can be read using a PIN or Biometric key entered by the patient to display the records. The EHR can be stored on the USR encrypted with the Key_Rec, for instance. On entering the correct PIN, the application can read the Key_Rec internally from the SR and can decrypt the EHR to display the contents in an organized manner.
[0079] With reference to exemplary representation of FIG. 2B of the medical professional/professional’s computing device 110, the device 110 can be configured to support NFC 252 based HCE and/or Bluetooth 254 based communication interface, such as devices with Android operating system (Kitkat and above). The device 110 can have a provision of an accessible SE 126 in the form factors of either a SIM card or a micro SD card such as the GoTrust micro SD card. The SE 126 on the microSD can be configured to provide Secure Region (SR) 256 for storage of Indent (Identification), Private Key KPr_C, and Certificate with the public key and validity of time Cert_C, and an unsecure region 258 to store medical records (say temporarily or permanently as configured) of patients or any other information of the medical professional such as years of practice, past cases, performance statistics, referral information, patient data, or any other configured information.
[0080] With reference to FIG. 3, an authorized medical professional’s computing device 110 can be used to read the patient health card stored on the patient computing device 108 by a simple tap 302 as shown in FIG 3. The tap 302 can initiate communication over bidirectional HCE interface and can also automate Bluetooth pairing between the devices. The basic card can be stored in a text format with references to images. The basic text portion of the EHR can be communication over bi-directional HCE interface, and extended text portions of the EHR along with the images can be transferred over the Bluetooth interface on demand when accessed by application on medical professional mobile device. Bluetooth can be used since it has a higher throughput. One should appreciate that these are merely illustrative examples/embodiment, and should be construed to limit the scope of how the devices would be sharing/accessing/exchanging data from each other. All possible combinations are therefore well within the scope of the present disclosure.
[0081] In an embodiment, a medical professional can be a medical doctor, nurse, pharmacist, Lab test technician, Insurance personnel, and emergency personnel. In an exemplary implementation, patient’s computing device 108 can emulate a card based on NFC based HCE such that when contacted by a reader mobile/portable computing device, data on the patient mobile device 108 can be routed to the host processor on which applications are running directly, instead of routing the NFC protocol frames to a SE as is done is pure card emulation. The two modes are shown in FIGs. 11A and 11B. In HCE, the card can be emulated at software level as shown in FIG. 11B. In an embodiment, a customized Java Card can be emulated. A medical professional such as 104 can access this card in NFC reader mode without the requirement of an external PCSC reader. Originally, HCE allows unidirectional flow of data where the emulated card interacts with the reader once in which it can send the data and request a response, which in the present disclosure is overcome by allowing creation of a bidirectional channel to allow communication between reader and card.
[0082] FIG.11B illustrates NFC based HCE having a device 1152 with a host CPU 1154 configured to execute one or more applications, and a NFC Controller 1156, wherein the Host CPU 1154 can emulate the software card, which can be accessed by an external NFC reader 1158 directly through NFC Controller 1156. An external mobile device can act as a NFC reader 1158 and does not require an external PC/SC reader to be attached.
[0083] FIG.11A illustrates NFC Card emulation with a SE having a mobile/portable computing device 1102 with a host CPU 1104, NFC Controller 1106, and a SE1108 that emulates a card. An external NFC Reader 1110 can accesses it directly through the NFC controller 1106. The NFC Reader 1110 can be a Personal Computer/Smart Card Reader that can be attached to a mobile device or a PC.
[0084] For secure communication, the medical professional and patient mobile devices can retain the security credentials in the SE, which can be done through a personalization phase of the cards. In an implementation, personalization of the patient mobile device 108 is illustrated in FIG. 4. In an aspect, the health service administration/administrator 406 can generate credentials and register patient for the system, wherein information can be stored on a database 402 in a server/cloud 404 (or any other central computing device), so that they be managed when required (deletion of a patient upon death, revocation of keys on theft of patient health card). The patient mobile device 108 can interact with the administrator406 to retrieve security credentials OTA (Over the air) on secure channel and set any or combination of Patient Identification Identifier, Private Key KPr_P, Certificate Cert_P in the Secure Region (SR) of the memory device. As shown, the administrator 406 can initialize the new health card (containing EHR) with the personal information of the patient. A patient mobile device application can be compiled with special libraries that can access the secured region of the memory device/card and prompt the patient to set an internal encryption key Key_Rec on the secured region (SR), which can be used to encrypt the EHR on unsecured region (USR) of the patient mobile device.
[0085] Similarly, a medical professional mobile device 110 can be personalized so that it can be authorized to access the patient health card, which is illustrated as an example in FIG.5. In an implementation, medical professional’s computing device 110 can be configured to interact with the health service administrator 502, who/which can generate credentials and register medical professional(s) for the system. The information can be stored on the database 504 in the cloud/server506 so that they may be managed in future when required (revoking the keys, deleting doctor records in case doctor resigns). In an aspect, medical professional’s computing/mobile device 110 can interact with the administrator 502 and retrieve the security credentials OTA (Over the air) on secure channel and set the Identification Indent, Private Key KPr_M, Certificate Cert_M in the SE.
[0086] FIG. 6 illustrates an exemplary system architecture for an OPD session between a registered patient and a medical professional in a hospital. As shown, patient’s mobile device 108 can retain the health card of the patient, wherein the medical professional’s mobile/computing device 110 can read the card through a simple tap. The patient and medical professional mobile devices can be personalized by a health service admin 602 in the cloud 604 as in FIG. 4 and 5. Security credentials and identifications can be stored in the database 606. The entire EHR of the patient can be stored in the patient mobile device 108. However, a backup can be maintained on the cloud in a patient digital health vault 608, which can be used to allow remote access if required by the patient for special cases and re-issuing the health card in case of damage/ theft of the old patient mobile device. In an aspect, the SE on SR regions of the mobile devices of the patient and the medical professional can be personalized in 610 and 612 respectively by, say the Health Service Admin. The hospital premises can have a hospital admin 614 that can register the patient 616 for an authorized doctor for an OPD session after the doctor checks in 618. In an exemplary implementation, the hospital records can be retained on the HIS620. The Hospital Administrator 614can create a new entry and/or update a patient’s visit for new and old patient respectively. The Hospital Administrator 614can access the Health Service on a Hybrid Cloud 604. The patient registration 616 and doctor check in 618 processes are illustrated in FIGs.8 and 7 respectively, which can ensure that a session key is generated for OPD session and stored on the SE of the patient’s and medical professional’s mobile/portable computing devices. During an OPD session, medical professional mobile device 110 can tap (held close together with) the patient mobile device 108. Communication can be initiated over bi-directional HCE. FIG. 9 illustrates implementation of a detailed OPD session in accordance with an embodiment of the present disclosure.
[0087] In an implementation, after a security handshake at 622, request for reading EHR for the OPD department from the healthcard/memory device of the patient can be sent by the doctor/medical professional at 624. The patient mobile device can send encrypted department EHR at 626, wherein the doctor’s application can display the EHR in an organized manner. The doctor can analyze the previous visits EHR at 628, and the new visit EHR can be initiated by the doctor at 630, which can be updated on the patient device at 632. The doctor device can also update the new visit EHR in HL7 format on the HIS at 634. Due to HL7 communication interface, health information can easily be integrated in the heterogeneous HIS irrespective of the database schema. Hence, each hospital can maintain its own digital records and patient can retain EHR’s for all visits on a patient health card on a mobile device 108. On exit, the patient can store the new EHR 636 on the Patient Digital Health Vault for backup.
[0088] FIG.7 illustrates an exemplary medical professional’s check-in into a hospital for conducting an OPD session. In an aspect, the medical professional’s mobile device 110 can tap(at 704) with hospital admin mobile device 702 to initiate mutual authentication (at 706) with the hospital admin, and verify (at 708) the doctor by interfacing (at 712) with the Hybrid Cloud 710. After verification, session key Key_Sesscan be set in the SE of the medical professional’s mobile device.
[0089] Illustration of the patient registration in a hospital for an OPD session with a specific doctor is shown in FIG.8. In an exemplary implementation, the patient’s mobile device 108 can tap(at 804) device with hospital administrator’s mobile device 802 to register. After mutual authentication (at 806) and verification (at 808) of the patient with the help of database on the hybrid cloud (810), the hospital administrator 802can set the session key Key_Sess for the OPD session (812). The key Key_Sess as set in FIG. 7 and FIG.8 can be valid for the OPD session and can have an expiry time after which the patient and medical professional cannot interact for the OPD session.
[0090] FIG. 9 illustrates an exemplary representation of a secure OPD session, wherein patient mobile device 108 taps (at 908) with the medical profession mobile device 110. In an implementation, the cloud 902, which can be accessible to the medical professional mobile device 110 in the hospital premises, can be configured to retain a database 904 to store valid patients and doctors on the panel along with their identification and security credentials. The patient digital health vault 906 can retain backup of the patient health card. In an implementation, a tap (at 908) between patient and medical professional mobile devices can initiate a bi-directional HCE interaction. Both the devices 108/110 can retain session keys Key_Sess on their SE’s that are internally accessible to the special applications on their respective devices. After a mutual authentication phase at 910, the doctor can get certified rights for the session by accessing the cloud 902. The access rights AR (retrieved by the medical professional’s/doctor’s device 110 at step912)can be sent (at 914) to the patient mobile device 108 encrypted with the session key Key_Sess. The Key_Sess can also be used to initiate automated Bluetooth pairing (at 916) between the two mobile devices. After initial setup, doctor’s mobile device 110 can send a read request (at 918) to the patient mobile device 108 to read EHR for a specific department and role of a medical professional. Role could be a nurse, pharmacist, lab technician etc. The patient mobile device application can then decrypt the EHR with Key_Rec internally, and send selective EHR (at 920) for the department along with the observations OBx encrypted with Key_Sess. The medical professional mobile device 110 can then decrypt the record (at 922) with the Key_Sess stored in its SE. The medical professional mobile device application can display(at 924) the EHR in an organized manner, allow the user to choose personal records, visit based views, analyze observations over past few visits to be displayed in a graphical manner. For a specific observation whose values are an image such as an X-ray result, the image can be retrieved (at 926) over the Bluetooth (at 928) from the patient mobile device since throughput is higher compared to the HCE interface. The medical professional may choose new records (at 930) to be initiated in the application and can put the values for observations, prescribe medications, give tests to be done and generate a new HL7 visit record for the OPD session. On pressing the update button on the application (at 932), the new EHR can be sent (at 934) to the patient’s device 108 over HCE interface. The doctor’s application can then send the visit records to be stored in the HIS 950. Upon removal of the patient mobile device, Bluetooth pairing can be disabled (at 936). The patient can then store (at 938) new visit EHR on the Patient Digital Health Vault on check out from the hospital by accessing special kiosks in hospital that help him to access the vault on the cloud.
[0091] According to one embodiment, in case the patient’s mobile device 108 is broken or is lost, card credentials can be revoked to prevent records being read by an unauthorized person and the card can be invalidated. In such a situation, new health card and credentials can be issued to the patient as illustrated in FIG. 10. A patient 1002 can approach a health service administrator1004 with a complaint for lost card 1006. The administrator 1004 can then verify (at 1008) the patient 1002 to ensure that it is the correct patient 1002. The patient 1002 can then send a request (at 1010) to revoke old credentials 1010, based on which the admin 1004 can revoke keys 1012 stored on the cloud 1014 and retrieve new card credentials and backup from the patient digital health vault 1016. The new keys and backup of EHR can be used to setup the new patient healthcard(at 1018)that are stored on the patient’s new mobile device 1020 with a process similar as in FIG. 4.
[0092] Various categories of medical professionals can access the EHR besides the medical doctor in say an OPD session as illustrated in the above FIGs. 1-10. In an implementation, medical professional’s application can be configured to require an initial login in which the application can verify the professional, the role, and the access rights for the Patient EHR access. In an instance, the hospital administrator can be given the role of being able to read personal data on the healthcard and set the sessions keys. Similarly, doctor can be configured with a role of being able to read old department specific visit records and should not be able to modify them. The doctor can be allowed to create a new visit records for the sessions consisting of health observations, other observations for medication prescriptions and health tests to be performed. Similarly, nurse can be configured to able to read personal data, and if the patient is registered, set records to note basic health observations. Pharmacist, on the other hand, can be enabled to read records for visits whose prescriptions are pending. For these visits, the pharmacist should be able to update status of only the observations related to medications. Similarly, lab test technician can be enabled to read records for visits whose health tests are pending. For these visits, the technician can be enabled to update status of only the observations related to tests. The observations may be updated to note stating test done results awaited and when results updated, update observations with values or related images.
[0093] In an aspect, the present disclosure aims at providing storage of HER in standard HL7 format on mobile device internal storage in an encrypted form. The EHR can be accessible by a medical professional device by a simple tap without requiring any additional external reader. The seamless device-to-device/peer-to-peer interface between the patient and medical professional can be based on NFC based HCE. In an aspect, the healthcard can be interoperable with HIS such as OpenMRS.
[0094] In an aspect of the present disclosure, the proposed patient EHR system can include a patient mobile device that can retain the entire patient EHR on a health card including text as well as images, wherein the EHR can be stored on an insecure region, in an encrypted form and can be communicated to the medical professional device without any intermediate reader, using HCE. HCE is a promising platform where the APDU service runs on the host processor, and therefore the patient and medical professional devices can tap for a secure exchange and update of health information without any external reader being used. The proposed architecture also offers secure NFC communication, larger space, faster speed than card emulation communication.
[0095] According to another embodiment, the proposed portable patient mobile device can be implemented with NFC and/or Bluetooth Interfaces, wherein communication interface between the patient mobile device and the medical professional mobile device can use bi-directional HCE and Bluetooth for larger data, which provides smooth device to device communication after a simple tap, eliminating the requirement of an external reader.
[0096] According to another embodiment, patient EHR system can be interoperable with HIS using HL7 protocol. Since the proposed architecture enables storage of the entire health records on patient mobile device, it should be easily be integrated with the HIS in any hospital that the patient visits. The proposed technology uses HL7 based protocol for communicating the healthcard details to the HIS.
[0097] According to another embodiment, the patient EHR system can be supported by a Health secure service comprising of a DFS (Distributed File System) for backup using say Hadoop. To ensure backup of records in case of theft, the proposed framework stores the records on the Distributed File System, where access time gets reduced when multiple records are accessed simultaneously. Secure servers consisting of replicated Kerberos, for instance, can be provided with cryptographic service. The security servers on the cloud are proposed based on replicated Kerberos system for authentication between patient and medical professional. In another embodiment, patient EHR can be encrypted with cryptographic key and can be stored on an insecure region on the patient mobile device. The encryption key can be stored in SE, TEE or on cloud and be accessible to the reader using tokenization schemes.
[0098] According to another embodiment, the proposed platform provides a patient mobile/portable computing device configured to store health information in a health card, wherein the device can be used as a contactless card (such as a credit card), which can be accessed by a medical professional’s mobile/portable computing device by a simple tap, enabling minimum human intervention. In an aspect, usage of HCE with a customized healthcard deployed at software level can be configured to store health card in a HL7 format. Basic information can be transferred using a tap of medical professional device. The HCE can ensure secure pairing of Bluetooth. Extended bulkier data such as past records and images can be seamlessly transferred using Bluetooth with minimum user intervention. Once the card is not in contact, it cannot be read and/or updated. In an aspect, the healthcard format can be chosen as HL7 since it used as a standard for communicating between hospital modules. The HL7 based healthcard, emulated on a patient mobile device, can allow the patient to tap his/her device as a contactless card on the registration centre in a hospital and after being read can easily be integrated with his information is the HIS. This provides interoperability between hospitals.
[0099] In an aspect, the present disclosure configures health/medical records/information of a patient to be stored on a healthcard that can be configured in the patient’s mobile device, and use it as a contactless card, which can be accessible by a simple tap by the medical professional’s mobile device, and initiate a secure communication. An authorized reader can read and update the portion that he is authorized to access, wherein basic card information can be transferred through NFC based HCE but detailed card or images can be configured to be exchanged through Bluetooth. This is merely an illustrative implementation and any other configuration is completely within the scope of the present invention. The proposed HCE tap can initiate a secure automated Bluetooth communication for exchange of extended health data.
[00100] In another aspect, a server can be configured only for maintaining the backup, and all records can be stored/configured on the patient mobile device itself to make the health records available all the time. As explained above, in another embodiment, server can also be configured to provide authentication support, wherein the server/cloud database can be configured to maintain a database of valid patients and doctors registered on the system with their security credentials. The server can support in mutual authentication and access control of various sections to the medical professional based on the role as in FIG. 9.The proposed disclosure also suggests that the most recent health record is on the healthcard emulated on the patient mobile device. It can be stored in an encrypted format and can be read by authorized medical professional who can update a section that he is authorized to update. Hence, it is updated instantaneously. The proposed system can also promptly read and update records on the healthcard using HCE, thereby not deferring synchronization. Hence, as the patient moves from one medical professional to another, information is most up to date since it is read and updated promptly.
[00101] In an aspect, a server on a hybrid cloud can be configured only for backup of records in case of theft of device (there is not mention of theft of device). Security credentials of the old card can be revoked so that it cannot be used. The backup information can be used to generate a new healthcard. In an aspect, format of the card for interoperability between hospitals can be determined. In the present disclosure, the healthcard can be stored in a HL7 healthcard format for interoperability of healthcard with other HISs. HL7 is a set of international standards for transfer of clinical and administrative data between HIS, and therefore the present disclosure enables a health card that can be interfaced with the HIS through HL7 and hence provide interoperability. Hl7 gives the liberty to store data of various types, with URI of images and documents stored externally. In an aspect, medical information can be stored in a customized/configurable Jason format storing medical professional’s visit records in HL7 format, and can be retrieved from different HIS using HL7 messages. A medical professional application module can be configured to read the patient card and send HL7 message to integrate the information to the HIS. Hence, there is no requirement of an additional support centre.
[00102] In another aspect, the security/session key can be stored on the mobile device itself, wherein the present disclosure stores the health card in HL7 format on the memory of mobile device in a encrypted format. In an implementation, the key for encryption can be retained on a SE that can be accessible internally only to the mobile device. In another implementation, the key can also be stored in the internal memory of mobile device using white box cryptography. In yet another implementation, the key can also be stored in the cloud and be accessed through tokenization. In an embodiment, in an exemplary hospital scenario, patient and medical professional devices can have a pre-registration phase in which they acquire one time secure session key available from a private cloud within the healthcare premises. They can utilize this secure session key for the health interaction for the visit. In an instance, the shared session key Ks can be used to exchange the key with which the data is encrypted. Patient can store the data using Key Ke. Secure session key between the patient and the medical professional can be Ks, wherein the data can be encrypted as Ks(Ke(data)).
[00103] According to one embodiment, the health card can have different sections that can be accessed by various medical professionals like physician, nurse, and pharmacist. Each member can have access permissions to certain sections. Role Based Access Control can be suggested for access control. The reader of the computing devices must seek its access rights from an authentication server before being allowed to access healthcard from patient mobile device. In the present disclosure, the mobile phone acts as a health card as well an authentication device. The medical data can be stored on the portable mobile device itself in a secure format, wherein the encryption key can either be on a SE in software using white box cryptography or can be accessible through a cloud/server. In another aspect, the mobile device can store data as well as authenticate the external reading device. In yet another aspect, the healthcard can be stored in HL7 for interoperability with HIS.
[00104] As used herein, and unless the context dictates otherwise, the term "coupled to" is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms "coupled to" and "coupled with" are used synonymously. Within the context of this document terms "coupled to" and "coupled with" are also used euphemistically to mean “communicatively coupled with” over a network, where two or more devices are able to exchange data with each other over the network, possibly via one or more intermediary device.
[00105] It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refers to at least one of something selected from the group consisting of A, B, C, …, and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.

ADVANTAGES OF THE INVENTION
[00106] The present disclosure provides secure interaction and/or transfer/access of health information/records between the patient and the medical professional.
[00107] The present disclosure utilizes hardware tamper resistant storage on a SE on a memory device such as a micro SD card/SIM to store credentials and setup a security handshake.
[00108] The present disclosure provides a memory device that stores health records/information in a format that can enable seamless integration with heterogeneous HIS.
[00109] The present disclosure provides the patient with right medical care provided at the right time due to the availability of records.
[00110] The present disclosure provides interoperability of EHRs between hospitals.
[00111] The present disclosure enables secure and authenticated transfer of health information/records between portable communication devices such as mobile phones of patients and respective medical professionals.

we claims:-
1. A system for managing health records of a patient comprising:
a memory device configured in a first portable computing device of the patient, wherein said memory device stores health information/records of the patient and comprises a secure element (SE) that is configured to store any or a combination of session security key(s), patient identification information, certificates, and security information of the patient; and
a second portable computing device of a medical professional configured to tap with the first portable computing device of the patient through a low energy wireless interface, wherein the coupling between the second portable computing device and the first portable computing device enables the medical professional to access at least a part of the health information/records.
2. The system of claim 1, wherein the health information/records are stored in the memory device in an encrypted manner.
3. The system of claim 1, wherein the medical professional is a trusted authorized reader and comprises a nurse, health administrator, a doctor, a lab technician, a pharmacist, and an emergency personnel.
4. The system of claim 1, wherein the low energy wireless interface comprises Near Field Communication (NFC) and Bluetooth.
5. The system of claim 1, wherein the medical professional has defined rights based on which he/she can read/write/modify the part of the health information/records.
6. The system of claim 1, wherein the second computing device comprises a second memory device having a SE that is configured to store any or a combination of session security key(s), patient identification information, certificates, security information of the medical professional, and security information of the patient.
7. The system of claim 6, wherein the second portable computing device and the first portable computing device undergo a handshake process for secure exchange of at least a second part of the health information/records, and wherein the handshake process enables setup of at least one secure session key that is stored in the SE of the first portable computing device and/or in the SE of the second portable computing device.
8. The system of claim 1, wherein the system further comprises a health service server accessible to the medical professional through the second portable computing device, wherein the health service server is configured to perform any or a combination of authentication of the medical professional, registration of an appointment of the medical professional with a patient, configuration of a part of the health information/records that would be accessible to the medical professional, access right management for the medical professional, and provision of security services to the medical professional.
9. The system of claim 1, wherein the system further comprises a means to enable backup of the health information/records of the patient on a secured server.
10. The system of claim 1, wherein the memory device stores the health information/records of the patient in a format/protocol that is compatible with multiple heterogeneous HISs.