Claims: CLAIMS
We Claim,
1) A Record Assurance Management System, comprising:
one or more devices configured to:
acquire individual identity information to generate a Unique Universal Record for a plurality of Individual Record Owner known as the Initiator, wherein the acquisition of the individual identity information comprises verification, validation, and collation of the individual identity information;
capture a plurality of Individual Records which are input and self-verified by the Individual Record Owner known as the Initiator, wherein the capture of the plurality of Individual Records information comprises, verification, validation and collation of the Individual Record based on existing record information held by one or more verification authorities;
assess the verified, validated and collated plurality of Individual Records, based on a specific evaluation criteria to categorize and or score the individual records; and
allocate the assessed plurality of Individual Record, under the created Unique Universal Record converting it to a Unique Universal Identification Record upon the allocation of at-least one assessed Individual Record.

2) The record assurance management system according to claim 1, wherein the one or more devices are further configured to:
acquire individual identity information for a plurality of individuals and or entities, wherein the acquisition of the individual identity information comprises verification, validation, and collation of the individual identity information;
capture a plurality of individual pre-selected preferences which are input and self-verified by the Registered User known as Recipient User, and or to capture a plurality of pre-populated fields, which are input and self-verified by other registered users known as the Verification Authority User and the Manufacturing Authority User; and
enables a Registered User known as a Recipient User to seek independent authentication of specific pre-selected Individual Records in real-time and provide the authentication result notification as an independent accurate assured authentication after due approval is obtained from the Individual Record Owner known as the Initiator.

3) The record assurance management system according to claim 2, wherein the one or more registered user devices such as but not limited to, the Recipient User and or the Verification Authorities are further configured to capture feedback and to perform a re-assessment of the plurality of Individual Records.

4) The Record Assurance Management System according to claim 3, further comprising a Universal Secure Engine which is a secure repository and custodian of the plurality of registered users individual identity records, individual records, the assessed Unique Universal Identification Records, the Process Status Notification for each stage of each record process, and the Independent Accurate Assured Authentication requests and results.

5) The Record Assurance Management System according to claim 1, wherein the one or more devices are further configured to capture, verify and validate the individual identity information provided by an individual or a legal guardian of the individual.

6) The Record Assurance Management System according to claim 4, wherein the one or more devices are further configured to re-assess the plurality of Individual Records based on an addition, deletion, amendment or modification provided by the Individual Record Owner known as the Initiator and feedback from a registered user such as the Recipient User and or the Verification Authorities.

7) The Record Assurance Management System according to claim 4, wherein the one or more devices are further configured to notify a result of an authentication of the plurality of individual records based on a colour coded symbol, to each registered user known as a Recipient User seeking an independent accurate assured authentication of a specific pre-selected individual record.

8. The Record Assurance Management System according to claim 1, further configured to provide assurance with justified confidence to a registered user, about a health record of at least one of the plurality of individual record owners, based on the allocated plurality of individual records.

Dated this 6th day of November 2020

Bency Varghese
Patent Agent for the applicant
INPA/2313
, Description:FORM 2
THE PATENT ACT 1970
(39 of 1970)
&
The Patents Rules, 2003
COMPLETE SPECIFICATION
(Section 10 and rule13)

Title: SYSTEM AND METHOD TO DEPLOY A CENTRALIZED HEALTH RECORD ASSURANCE MANAGEMENT SYSTEM

APPLICANT NATIONALITY ADDRESS
PERFECT VENTURES LIMITED UK 1 ALEXANDRA PARADE, HARROW, HA2 8HE, UK

PREAMBLE:
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD

[01] Various embodiments of the disclosure relate to a centralized Health Record Assurance Management System. More specifically, various embodiments of the disclosure relate to a system and method to deploy a centralized Health Record Assurance Management System which enables real-time independent accurate assured authentication to be provided.

BACKGROUND

[02] Since the start of the COVID-19 pandemic the fear of contagion has imposed lock-downs and paralysed life for one and all. Health records of individuals are separately held by individual entities such as clinics, insurance companies and hospitals. However, there are no means available to verify, validate, collate, assess the health records of the individuals at a global level, and to then generate a unique universal health record for each and every individual. Further, there are also no means available to hold a complete consolidated set of assessed records to enable a real-time independent accurate assured authentication of the health records to be provided. The quest to establish a safe environment (free from the fear of contagion) to bring life and business back to normal, has meant that we require to devise a real-time credible and sustainable mechanism for seamless social interaction to occur. This quest has triggered this invention.

[03] Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of described systems with some aspects of the present disclosure, as set forth in the remainder of the present application and with reference to the drawings.

SUMMARY

[04] A system and method to deploy a centralized Health Record Assurance Management System which enables a real-time independent accurate assured authentication to be provided with justified confidence, when sought by a registered Recipient User and after obtaining due approval from the Individual Record Owner known as the Initiator as shown in, and/or described in connection with, at least one of the figures, as defined for completeness in the claims.

[05] These and other features and advantages of the present disclosure may be appreciated from a review of the following detailed description, along with the accompanying figures, in which like reference numerals, refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

[06] FIG. 1 is a block diagram that illustrates an exemplary network environment which includes the interactions between various registered users and or data providers to deploy a centralized Health Record Assurance Management System which enables real-time independent accurate assurance authentication to be provided, in accordance with an embodiment of the disclosure.

[07] FIG. 2 is a block diagram that illustrates an exemplary electronic device which can be classified as: an electronic input and or output devise, and the electronic processing device known as the Universal Secure Engine, to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assurance authentication to be provided, in accordance with an embodiment of the disclosure.

[08] FIG. 3 is a flow diagram that illustrates a method of an Initiator registration, Initiator identity verification and validation; and the generation of a Unique Universal Record for each and every Individual Record Owner known as the Initiator. This is then followed by; input and self-verification of the Individual Health Records which are stored in the Universal Secure Engine, to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assurance authentication to be provided, in accordance with an embodiment of the disclosure.

[09] FIG. 4 is a flow diagram that illustrates a method of verification, validation, and collation of a plurality of Individual Health Records which are provided by the Individual Record Owner known as Initiator, with input received from Health Authorities and Manufacturing Authorities. The flow diagram then illustrates a method to collate the verified and validated plurality of Individual Health Records and stores these collated records in the Universal Secure Engine, to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assurance authentication to be provided, in accordance with an embodiment of the disclosure.

[10] FIG. 5 is a flow diagram that illustrates a method of assessment through categorisation and or scoring of a plurality of Individual Health Records, followed by an allocation of these assessed Individual Health Records, converting the existing Unique Universal Record to a Unique Universal Health Identification Record, and then stores these assessed Individual Health Records in the electronic processing device known as the Universal Secure Engine. The flow diagram also illustrates a method of re-assessment following a change in any Individual Health Record or associated feedback received from a registered user, to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assurance authentication to be provided, in accordance with an embodiment of the disclosure.

[11] FIG. 6 is a flow diagram that illustrates a method of a Recipient registration, Recipient identity verification and validation and the creation of a unique Recipient User and stores these Recipient Users in the electronic processing device known as the Universal Secure Engine to deploy a centralized Health Record Management Assurance System, which enables real-time independent accurate assured authentication to be provided, in accordance with an embodiment of the disclosure.

[12] FIG. 7 is a flow diagram that illustrates a method of a Recipient User requesting for real-time independent authentication of a plurality of Independent Health Records held under a Unique Universal Health Identification Record. The centralized Health Record Assurance Management System provides in real-time an independent accurate assured authentication as at a specific point in time and after having obtained due approval from the Individual Record Owner known as Initiator. The flow diagram also illustrates a method for the Recipient User to provide feedback on specific Individual Health Records and or the Unique Universal Health Identification Record in an effort to enhance the quality of the records, in accordance with an embodiment of the disclosure.
[13] FIG. 8 is a flow diagram that illustrates a method of a Health Authority registration, Health Authority identity verification and validation, followed by the creation of a unique Health Authority User and stores this Health Authority User in the electronic processing device known as the Universal Secure Engine, to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assured authentication to be provided, in accordance with an embodiment of the disclosure.

[14] FIG. 9 is a flow diagram that illustrates a method of a Manufacturing Authority registration, Manufacturing Authority identity verification and validation, followed by the creation of a unique Manufacturing Authority User and stores this Manufacturing Authority User in the electronic processing device known as the Universal Secure Engine, to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assured authentication to be provided, in accordance with an embodiment of the disclosure.

DETAILED DESCRIPTION

[15] The following described implementations may be found in the disclosed apparatus and method to deploy a centralized Health Record Assurance Management System which enables real-time independent accurate assured authentication to be provided. Various embodiments of the disclosed system and method for registration of every and or any Individual Record Owner known as Initiator, to capture, verify, validate and collate the users identity information in order to generate a Unique Universal Record (UUR) for the Individual Record Owner known as the Initiator and to generate a registered user for a plurality of individuals.

[16] Exemplary aspects of the disclosure may include an electronic input and or output devices and an electronic processing device known as the Universal Secure Engine (USE), to deploy a centralized Health Record Assurance Management System which enables real-time independent accurate assured authentication to be provided. The electronic devices may comprise a memory, an interface, and a processor. The electronic processing device known as the USE may be configured to capture, verify, validate and collate a plurality of Individual Health Records (IHRs) against new and existing health records held and obtained from multiple verification authorities. The electronic processing device known as the USE may be further configured to provide an assessment of a plurality of IHRs, based on pre-defined evaluation criteria to categorize and or score the plurality of IHRs. The electronic processing device known as the USE may be also further configured to allocate the assessed plurality of IHRs held under a UUR. The electronic processing device known as the USE may be further configured to convert the generated UUR into a Unique Universal Health Identification Record upon allocation of at-least one assessed IHR.

[17] The electronic processing device known as the USE may be further configured to enable a Registered User (RU) to seek an independent authentication of specific pre-selected IHRs in real-time. The electronic processing device known as the USE may be further configured to output the authentication result notification as an independent accurate assured authentication, after due approval is obtained from the Individual Record Owner known as the Initiator. The electronic processing device known as the USE may be further configured to capture feedback and to perform a re-assessment, designed to enhance the quality of the IHRs held over-time in the electronic processing device known as the USE. The USE is also a secure repository and memory of all data fields processed through this electronic processing device known as the USE.

[18] FIG. 1 is a block diagram that illustrates an exemplary network environment 100 which includes the interactions between various users and or data providers to deploy a centralized Health Record Assurance Management System, which enables real-time independent accurate assured authentication to be provided, in accordance with an embodiment of the disclosure. With reference to FIG. 1, it shows a network environment 100. The network environment 100 may include an Initiator device 102 and or a plurality of Initiator devices, a Health Authority (HA) device 104 and or a plurality of HA devices, a Manufacturing Authority (MA) device 106 and or a plurality of MA devices, the RU device 108 and or a plurality of RU devices, a network 110, and an electronic processing device known as the USE 112. The Initiator device 102, the HA device 104, the MA device 106, the RU device 108 and the USE 112 communicate with each other via the network 110 after due completion of the user identity information registration, verification, validation and collation. The Initiator device 102, the HA device 104, the MA device 106 and the RU device 108, are electronic input and or output devices which capture input and provide output information related to a plurality of IHRs.

[19] Each of the Initiator device 102, the HA device 104, the MA device 106, the RU device 108 may be an electronic input and or output device which may comprise suitable circuitry, interfaces, and/or code that may be configured to deploy the centralized Health Record Assurance Management System, which enables real-time independent accurate assured authentication to be provided through interaction with the electronic processing device known as the USE . Examples of the electronic device may include, but are not limited to, a personal computer, a tablet computer, a smartphone, a laptop, a computer workstation, an augmented reality based device, a computing device, a server, and/or other consumer electronic (CE) devices. In one embodiment, the electronic device may be a server located in a remote location. In another embodiment, the electronic device may be an internal component of a biomedical device. For example, the electronic device may be implemented as a system on chip (SoC) or an Application specific integrated circuit (ASIC) chip in a motherboard of the biomedical device.

[20] The network 110 may include a communication medium through which the electronic input and or output device: Initiator device 102, the HA device 104, the MA device 106, the RU device 108 and the electronic processing device known as the USE, may communicate with each other. Examples of the network 110 may include, but are not limited to, a telecommunication network such as a Public Switched Telephone Network (PSTN), a 2G network, a 3G network, a 4G network, 5G network, the Internet, a cloud network, a Wireless Fidelity (Wi-Fi) network, a Local Area Network (LAN), and/or a Metropolitan Area Network (MAN). Various devices in the network environment 100 may be configured to connect to the network 110, in accordance with various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, at least one of a Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, IEEE 802.11, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and/or any other IEEE 802.11 protocol, multi-hop communication, wireless access point (AP), device to device communication, cellular communication protocols, Light-fidelity (Li-Fi), Internet-of-Things (IoT) network, or Bluetooth (BT) communication protocols, or a combination or variants thereof.

[21] The electronic processing device known as the USE 112 may be an electronic device which may comprise suitable circuitry, interfaces, and/or code that may be configured to deploy the centralized Health Record Assurance Management System, which enables real-time independent accurate assured authentication to be provided. Examples of the electronic device may include, but are not limited to, a personal computer, a tablet computer, a smartphone, a laptop, a computer workstation, an augmented reality based device, a computing device, a server, and/or other consumer electronic (CE) devices. In one embodiment, the electronic device may be a server located in a remote location. In another embodiment, the electronic device may be an internal component of a biomedical device. For example, the electronic device may be implemented as a system on chip (SoC) or an Application specific integrated circuit (ASIC) chip in a motherboard of the biomedical device.

[22] The USE 112, as an electronic processing device will govern and operate, but not be limited to, the following sets of method and processes:
1. Registration and creation for each unique User (Initiator, RU, HA User and MA User).
2. Identity Information data fields captured for each unique user (Initiator, RU, HA User and MA User).
3. Generation of a Unique Universal Record (UUR) with a UUR number, UUR QR code for each unique user (Initiator, RU, HA User and MA User).
4. IHR data fields captured for the Initiator.
5. Self-verification and acceptance of terms and conditions through One-Time Password (OTP) for each unique user (Initiator, RU, HA User and MA User).
6. Verification of captured data fields (Identity information and IHR information).
7. Validation of verified data fields (Identity information and IHR information).
8. Collation of the verified and validated data fields (Identity information and IHR information).
9. IHR assessment through categorisation and or scoring.
10. Allocation of the assessed IHR to the generated UUR for each and every registered Initiator, converting the UUR to a Unique Universal Health Identification Record (UUHIR).
11. Independent accurate assured authentication of UUHIR when requested by the RU and after due approval is obtained from the Initiator.
12. Feedback data fields captured for registered user (RU and HA User) to enhance the quality of the IHR held under the respective UUHIR and then seek input from the Initiator on the feedback obtained.
13. Re-assessment of the IHR triggered by any change such as addition, deletion, amendment, modification and or feedback obtained and as such re-executes all processes related to the verification, validation and collation as applicable to the specific IHR held under the UUHIR.
14. Update the Process Status Notification (PSN) upon completion of any and all methods and processes, so as to provide a PSN notification when requested from either the Initiator and or the RU.
15. The USE captures and acts as a secure repository and memory of all data fields processed.

[23] The USE 112, operates, but is not limited to the following set of core principles:
1. Unique Initiator
Each Initiator will be assigned a unique individual identity record number and unique QR Code or other bio-metric identity.

2. Universal Application of the HRAMS
The IHR/s will be universal irrespective of geographic or physical location, boundary, language, ethnicity, sex or sexual orientation. It will be applicable to all and in any situation of social-interaction. It will ease travel, social interaction, facilitate free movement without the fear of contagion and can be tailored based on requirements defined by the Recipient.

3. Secure Repository
A secure storage facility which is free of the threat of un-authorised assess or use.

4. Compliance with Law and Regulation
All processes, system and records are held in strict conformance and compliance with the law in the jurisdiction in which the individual health records holder resides and or where the recipient user seeks independent accurate assured authentication.

5. Respect and Trust
We respect the universe, the entire world in which we operate. We endeavour to hold ourselves to the highest ethical standards and behave in ways which earn trust of others we work with. We respect these relationships and value their association with us. We care about the consequences of our decisions on those around us.

6. Strict Confidentiality
All records are held under strictly confidentiality and in full adherence with applicable Data Privacy and Data Protection Laws.

7. Absolute Initiator Control
All records are owned by the Individual Health Record Holder (Initiator) who has absolute control to approve, share and manage the record. No records will be shared without the explicit real-time consent and approval of the Individual Health Record Holder or the Legal Guardian in case of a minor.

8. Real-Time Process Notification and Assured Authentication
The Universal Secure Engine will enable actions to be classified with real-time notifications. These will provide the Initiator and the Recipient with notification status so as to enable the Initiator and or the Recipient to identify the source of the pending response, if any.

9. IHRs Verification and Validation through Multiple Authorities
There will be a 4-way validation match processes to ascertain accuracy of the records held, which are as follows:
1. Initiator’s self-verification and assertion: The Initiator will have to complete the registration process, provide substantive evidence and self-verify that the information provided is true and accurate. These records will then be further verified and validated by the Inventor.
2. Health Authority verification: The medical and or health professional body who administers the treatment will verify upon the Inventor’s independent request that they have indeed administered the treatment, medication and or vaccination. These records will then be further verified and validated by the electronic processing device known as the USE.
3. Manufacturing Authority verification: The manufacturer of the treatment, medication or vaccination will verify upon Inventor’s independent request that they have manufactured the treatment, medication or vaccination bearing the serial number or under the batch number. These records will then be further verified and validated by the electronic processing device known as the USE.
4. Feedback Loop: the electronic processing device known as the USE will provide a live feedback loop which will act as a genuine independent channel to capture, authenticate and enhance the quality of the individual’s record held by electronic processing device known as the USE. This feedback facility will be embedded within the tools provided for ease of use.

10. IHRs Validity and Authentication results validity
The IHRs are valid from the point of it being uploaded and self-verified on the electronic processing device known as the USE until the validity of the treatment expires. The authentication results are provided in real-time, valid as at a point in time and the authentication record will have a date and time stamp.

[24] FIG. 2 is a block diagram that illustrates an exemplary electronic input device and or output device and an electronic processing device known as the USE to deploy a centralized Health Record Management System, which enables real-time independent accurate assured authentication to be provided, in accordance with an embodiment of the disclosure. FIG. 2 is explained in conjunction with elements from FIG. 1. With reference to FIG. 2, there is shown an exemplary electronic device, such as the electronic input and or output device and the electronic processing device known as the USE. The electronic device may be any input and or output device such as the Initiator device 102, the HA device 104, the MA device 106, or the RU device 108 and or an electronic processing device known as the USE 112. The electronic device may include one or more processors, such as a processor 202, a memory 204, and a network interface 206. The network interface 206 may be configured to communicate with any input and or output device such as the initiator device 102, the HA device 104, the MA device 106, the RU device 108, and the electronic processing device known as the USE 112 via the network 110.

[25] The processor 202 may comprise suitable logic, circuitry, interfaces, and/or code that may be configured to execute a set of instructions stored in the memory 204. The processor 202 may be implemented based on a number of processor 202 technologies known in the art. Other examples of the processor 202 may be an X86-based processor, a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, and/or other processors.

[26] The memory 204 for the electronic input and or output devices such as the initiator device 102, the HA device 104, the MA device 106, or the RU device 108 which may comprise suitable logic, circuitry, and/or interfaces that may be configured to store a set of instructions executable by the processor 202. The memory 204 may be configured to store operating systems and associated applications. The memory 204 may be further configured to store registered user identity information and or IHRs information of a plurality of individuals. The memory 204 for the electronic processing device also known as the USE 112, may comprise suitable logic, circuitry, and/or interfaces that may be configured to store a set of instructions executable by the processor 202. The memory 204 may be configured to store operating systems and associated applications. The memory 204 may be further configured to store all data processed by the electronic processing device known as the USE 112 for all registered user. Examples of implementation of the memory 204 may include, but are not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Hard Disk Drive (HDD), a Solid-State Drive (SSD), a CPU cache, and/or a Secure Digital (SD) card.

[27] The network interface 206 may comprise suitable logic, circuitry, interfaces, and/or code that may be configured to establish communication between any input and or output device such as the Initiator device 102, the HA device 104, the MA device 106, the RU device 108 and the electronic processing device known as the USE 112 via the network 110. The network interface 206 may be implemented by use of various known technologies to support wired or wireless communication of the electronic device with the network 110. The network interface 206 may include, but is not limited to, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, a subscriber identity module (SIM) card, and/or a local buffer. The network interface 206 may communicate via wireless communication with networks, such as the Internet, an Intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN). The wireless communication may use any of a plurality of communication standards, protocols and technologies, such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), wideband code division multiple access (W-CDMA), Long Term Evolution (LTE), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wireless Fidelity (Wi-Fi) (such as IEEE 802.11, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and/or any other IEEE 802.11 protocol), voice over Internet Protocol (VoIP), light fidelity (Li-Fi), Wi-MAX, a protocol for email, instant messaging, and/or Short Message Service (SMS). The network interface 206 may further comprise a global system for mobile (GSM) module.

In operation, the processor 202 of the electronic processing device known as the USE 112, may be further configured to capture, verify, validate and collate a plurality of Individual identity information for all users to generate a UUR for each of a plurality of registered users.

[28] The processor 202 of the electronic processing device known as the USE 112, may be further configured to capture IHRs input by a registered Initiator device 102, and then independently seek verification information for a plurality of IHRs against new and existing health records held by a plurality of verification authorities. The processor 202 may be further configured to verify, validate and collate the information received from verification authority against the records submitted by the Initiator. The processor 202 of the electronic processing device known as the USE 112, may be further configured to provide an assessment of the plurality of IHRs, based on a pre-defined evaluation criterion to categorize and or score the plurality of IHRs. The processor 202 of the electronic processing device known as the USE 112, may be further configured to allocate the assessed plurality of IHRs to the generated UUR converting it into a UUHIR.

[29] The processor 202 of the electronic processing device known as the USE 112, may be further configured to enable a RU to seek an independent accurate assured authentication of specific pre-selected IHRs in real-time. The processor 202 of the electronic processing device known as the USE 112, may be further configured to output the authentication result notification as an independent accurate assured authentication after due approval is obtained from the Initiator. The processor 202 of the electronic processing device known as the USE 112, may be further configured to capture feedback from a plurality of registered users such as the RU, and HA about the IHRs held under the respective UUHIR. The processor 202 of the electronic processing device known as the USE 112, may be further configured to then seek input from the Initiator on the feedback obtained from these registered users. The processor 202 of the electronic processing device known as the USE 112, may be further configured to perform a re-assessment, designed to enhance the quality of the IHRs over-time in the electronic processing device also known as the USE112. The processor 202 of the electronic processing device known as the USE 112 may be further configured to update the Process Status Notification (PSN) upon completion of any and all stages, so that a PSN can be provided when requested from either, the Initiator and or the RU. The processor 202 of the electronic processing device known as the USE 112 may be further configured to store all information and it is a secure repository and memory of all data fields processed.

[30] FIG. 3 is a flow diagram that illustrates a method of an Initiator registration, Initiator identity verification and validation and the generation of a UUR for each and every individual. This diagram further illustrates, input and self-verification of the IHRs by the Initiator device 102. The diagram further illustrates that both, the UUR and IHRs are stored in an electronic processing device also known as the USE 112, in accordance with an embodiment of the disclosure. FIG. 3 is explained in conjunction with elements from FIG. 2. A process of Initiator registration begins at step 301.

[31] At step 301, the Initiator device 102 is registered into the electronic processing device also known as the USE 112. The Initiator device 102 is registered to an Initiator. The Initiator is a person having a plurality of IHRs. In a case where the individual is an adult, the individual is the Initiator. In a case where the individual is a minor, a legal guardian of the individual is the Initiator. The Initiator owns and has absolute control of the IHR. The Initiator registration may be an online or an offline manual physical application registration process.

[32] At step 302, the identity information (ID) provided is associated with the Initiator device 102, this information is received at the electronic processing device known as the USE 112. The identity information may comprise, but is not limited to, a name, a date of birth, nationality, a proof of identification, identification type, identification number, email, telephone number, and a place of residence of the Initiator.

[33] At 303, a plurality of terms and conditions (T and C) of the electronic processing device also known as the USE 112 are accepted by the Initiator. The Initiator accepts the plurality of T and C via the Initiator device 102.

[34] At 304, the identification information of the Initiator is verified and validated by the electronic processing device known as the USE 112. To verify the identification information, the electronic processing device known as the USE 112 is configured to confirm, and check whether a plurality of identity data fields input by the Initiator exists, are true and are correct, when compared against a proof of valid identification information provided by the Initiator. The electronic processing device also known as the USE 112 further validates the verified identification information based on an examination of whether the individual records are appropriate, acceptable and approved for use. If the identification information is not verified and validated, the process goes to step 305. If the identification information is verified and validated, the process goes to step 306.

[35] At 305 the Initiator device 102 is informed that the identification information is not verified and or validated. At step 305, the process proceeds to step 301.

[36] At 306, the electronic processing device also known as the USE 112 is updated. Further, a Process Status Notification (PSN) is updated in the electronic processing device known as the USE 112.

[37] At 308, a Unique Universal Record (UUR) is generated by the electronic processing device known as the USE 112 for the Initiator. Further, but not limited to, a QR code is also generated for the Initiator. In one example, the USE 112 may further comprise a printer configured to print at least an identification number of the UUR on a paper-based medium. In another example, the UUR may be recorded in a microchip-based card. In yet another example, the USE 112 may be configured to print the UUR as a booklet.

[38] At 310, an IHR or a plurality of IHRs is received by the electronic processing device known as the USE 112, from the Initiator device 102. The IHR comprises individual health information associated with the Initiator, including but not limited to, details of disease and or ailment, details of the treatment administered, date of treatment / vaccination, manufacturer and or brand of treatment / vaccination, serial and or batch number of treatment / vaccination, validity of treatment / vaccination, treatment administered by and or clinician’s name and designation, the HA administering the treatment, HA address, HA email, HA telephone, next booster date (if applicable) and other biological information associated with the Initiator’s treatment.

[39] At 312, the IHRs are self-verified by the Initiator to the electronic processing device known as the USE 112, The Initiator accepts the self-verification via the Initiator device 102.

[40] At 314, a one-time password is generated and transmitted by the electronic processing device known as the USE 112, to the Initiator. The one-time password is transmitted to the Initiator via at least one of a phone call or an email.

[41] At 316, the Initiator IHRs are self-verified based on the generated one-time password transmitted to the initiator which also confirms a self-verification of the IHRs submitted by the Initiator device 102. At 317, the IHRs held under the associated UUR are stored in the electronic processing device also known as the USE 112.

[42] FIG. 4 is a flow diagram that illustrates a method of verification, validation, and collation of a plurality of IHRs, as provided by the Initiator, with information received from the HA and MA. The flow diagram then illustrates a method to collate the verified and validated IHRs and stores these collated IHRs in the electronic processing device known as the USE 112, in accordance with an embodiment of the disclosure. FIG. 4 is explained in conjunction with elements from FIG. 1 and 2. A process of verification, validation, and collation of a plurality of IHRs begins at step 401.

[43] At 401, the electronic processing device USE 112 may be configured to request the HA device 104 to provide a plurality of IHRs information based on consent provided by the Initiator. The HA device 104 provides the information to the electronic processing device known as the USE 112, the electronic processing device known as the USE 112, may be configured to check the plurality of IHRs to verify that the plurality of IHRs exist and are true or correct. The result of the verification is updated in a Process Status Notification (PSN) and then stored in the electronic processing device known as the USE 112.

[44] At 402, the electronic processing device known as the USE 112 may be configured to then validate a plurality of the verified IHRs by examining whether the verified IHRs are appropriate, acceptable and approved for use. The result of the validation is updated in the PSN and then stored in the electronic processing device known as the USE 112.

[45] At 403, the electronic processing device known as the USE 112 may be configured to collate a plurality of verified and validated IHRs when compared with the submission of the IHR data fields input by the Initiator, so that similarities and differences can be identified and reported. The result of the collation is updated in a PSN and then stored in the electronic processing device known as the USE 112.

[46] At 404, the electronic processing device known as the USE 112 may be configured to request the MA 106 to provide the plurality of IHRs information based on consent provided by the Initiator and HA. The MA 106 provides the information to the electronic processing device USE 112, the electronic processing device USE 112, may be configured to check the plurality of IHRs to verify that the plurality of IHRs exist and are true or correct. The result of the verification is updated in the PSN and then stored in the electronic processing device known as the USE 112.

[47] At 405, the electronic processing device known as the USE 112 may be configured to validate a plurality of the verified IHRs by examining whether the verified IHRs are appropriate, acceptable and approved for use. The result of the validation is updated in the PSN and then stored in the electronic processing device known as the USE 112.

[48] At 406, the electronic processing device known as the USE 112 may be configured to collate a plurality of verified and validated IHRs when compared with the submission of the IHRs data fields input by the Initiator and or the HA, so that similarities and differences can be identified and reported. The result of the collation is updated in the PSN and then stored in the electronic device known as the USE 112.

[49] FIG. 5 is a flow diagram that illustrates a method of assessment through categorisation and or scoring of a plurality of IHRs, followed by an allocation of a plurality of these assessed IHRs to a generated UUR, then converting the existing UUR to a UUHIR upon allocation of at-least one assessed IHR. These assessed IHRs are stored in the electronic processing device known as the USE. The flow diagram also illustrates a method of re-assessment following a change in any IHRs or associated feedback received from a registered user, in accordance with an embodiment of the disclosure. FIG. 5 is explained in conjunction with elements from FIG. 1 and 2. A process of assessment through categorisation and or scoring of a plurality of IHRs begins at step 501.

[50] At 501, the electronic processing device known as the USE 112 may be configured to assess and judge a plurality of IHRs based on a specific evaluation criteria used for categorizing and or scoring the plurality of IHRs. The result of the assessed IHRs are updated in the PSN and then stored in the electronic device known as the USE 112.
[51] At 502, the electronic processing device known as the USE 112 may be configured with the evaluation criteria used to judge the categorizing and or scoring of the plurality of IHRs.

[52] At 503, the electronic processing device known as the USE 112, may be configured to send the assessed plurality of IHRs for allocation under a respective Unique Universal Record (UUR) and then converts the existing UUR to UUHIR upon allocation of at-least one assessed IHR.

[53] At 504, the electronic processing device known as the USE 112, may be configured to securely store the plurality of IHRs allocated under respective UUHIR in the USE 112. Further, the Initiator UUHIR is updated. The UUHIR results are updated in the PSN and then stored in the electronic device known as the USE 112. The USE 112 may be further configured to provide assurance to the plurality of individual record owners, based on the allocated plurality of individual health records.

[54] At 506, the electronic processing device known as the USE 112 may be configured to identify if one or more modifications are made for the plurality of IHRs. Further, the electronic processing device known as the USE 112, may be configured to capture feedback as at 507, from any of the registered users which may include but are not limited to, the RU and the HA User. Further, the electronic processing device known as the USE 112, may be configured to establish if modification and or feedback is generated, and then re-assess the IHR at 508, steps 501 to 504 are re-executed for the plurality of IHRs which are either modified and or feedback obtained.

[55] FIG. 6 is a flow diagram that illustrates a method of a Recipient device 108 registration, Recipient identity verification and validation and the creation of a unique Recipient User (RU) and stores these RUs in the USE, in accordance with an embodiment of the disclosure. FIG. 6 is explained in conjunction with elements from FIG. 1 and 2. A process of recipient device 108 registration in a centralized Health Record Assurance Management System which enables real-time independent accurate assured authentication to be provided begins at step 601.

[56] At step 601, a Recipient device 108 is registered into the electronic processing device known as the USE 112. The Recipient device 108 is registered to a Recipient. The Recipient is a person or an entity that seeks an independent accurate assured authentication of specific pre-selected IHRs held under a respective UUHIR, the Recipient device 108 registration may be an online or an offline manual physical application registration process.

[57] At step 602, the identity information (ID) is provided which is associated with a Recipient device 108, this information is received at the electronic processing device known as the USE 112. The identity information comprises of, but is not limited to, the name of the individual Recipient or entity, a date of business incorporation or business start date, a proof of identification, identification type, identification number, email, telephone number and address of the Recipient.

[58] At 603, a plurality of terms and conditions (T and C) of the electronic processing device known as the USE 112 are accepted by the Recipient. The Recipient accepts the plurality of T and C via the Recipient device 108.

[59] At 604, the identification information of the Recipient device 108 is verified and validated by the electronic processing device known as the USE 112. To verify the identification information, the electronic processing device known as the USE 112 is configured to confirm, and check whether a plurality of identity data fields input by the Recipient device 108 exists, are true and are correct when compared against a proof of valid identification information provided by the Recipient. The electronic processing device known as the USE 112 further validates the verified identification information based on an examination of whether the individual records are appropriate, acceptable and approved for use. If the identification information is not verified and validated, the process goes to step 605. If the identification information is verified and validated, the process goes to step 606.

[60] At 605 the Recipient device 108 is informed that the identification information is not verified and or validated. At step 605, the process proceeds to step 601.

[61] At 606, the electronic processing device known as the USE 112 is updated. Further, a PSN is updated and then stored in the electronic processing device known as the USE 112.

[62] At 607, a unique Recipient User (RU) is generated by the electronic processing device known as the USE 112 for the Recipient. Further, but not limited to, a QR code is also generated for the Recipient. In one example, the USE 112 may further comprise a printer configured to print at least an identification number of the RU on a paper-based medium. In another example, the RU may be recorded in a microchip-based card. In yet another example, the USE 112 may be configured to print the RU as a booklet.

[63] At 608, the electronic processing device known as the USE 112 is configured to receive from the now registered RU device 108 the Recipient’s pre-selected IHR and individual data fields required for on-going real-time independent accurate assured authentication based on specific individual and business needs and requirements of the Recipient. These records may include, but are not limited to IHR, IHR validity, Initiator name, Photograph, and other biological information associated with the Initiator.

[64] At 610, the pre-selected IHRs and individual data required are self-verified by the Recipient to the electronic processing device known as the USE 112, The Recipient accepts the self-verification via the Recipient User device 108.

[65] At 612, a one-time password is generated and transmitted by the electronic processing device known as the USE 112, to the RU device 108. The one-time password is transmitted to the RU device 108 via at least one of a phone call or an email.

[66] At 614, the Recipient is verified based on the generated one-time password transmitted to the RU device 108 which also confirms a self-verification of the information provided by the RU device 108. At 616, the pre-selected IHR data field and individual data field required by the Recipients are submitted and then stored in the electronic processing device known as the USE 112.

[67] FIG. 7 is a flow diagram that illustrates a method of a RU to request for a real-time independent accurate authentication of a plurality of IHRs under a UUHIR which is initiated by the Initiator. The centralized Health Record Assurance Management System, which is enabled to provide a real-time authentication notification results as an independent accurate assured authentication as at a specific point in time and after having obtained due approval from the Initiator. The flow diagram also illustrates a method for the RU to provide feedback on specific IHRs and or the UUHIR in an effort to enhance the quality of the IHRs held under the respective UUHIR, in accordance with an embodiment of the disclosure. FIG. 7 is explained in conjunction with elements from FIG. 1, 2 and 5. A process of a UUHIR authentication in a centralized Health Record Assurance Management System which enables real-time independent accurate assured authentication to be provided begins at step 701.

[68] At 701, the Initiator device 102 presents UUHIR (i.e. UUHIR No., QR code, Chip Card or Booklet), to the RU device 108 as identification. In one example, the initiator device 102 may be configured to record the UUHIR in a micro-chip based card. The RU device 108 may further comprise a card reader configured to read the micro-chip based card comprising the UUHIR. In yet another example, the Initiator device 102 may be configured to print the UUHIR as a booklet. The RU device 108 may scan the booklet to extract the UUHIR.

[69] At 702, the RU device 108 may read the identification either via online means, via mobile application, via QR scan, via touch pad, via physical or other means. The RU device 108 may be configured to request and seek an independent authentication from the electronic processing device known as the USE 112.

[70] At 703, the electronic processing device known as USE 112 may be configured to initiate a real-time independent accurate assured authentication process to authenticate the UUHIR.

[71] At 704, the electronic processing device known as the USE 112 may be configured to request for an approval from the Initiator device 102 based on specific pre-selected IHRs results sought by the RU device 108 earlier at the time of the RU registration. If the Initiator device 102 does not approve, then the RU device 108 is informed and the independent accurate assured authentication is NOT provided. Further, a PSN is updated and then stored in the electronic processing device known as the USE 112.

[72] If the Initiator device 102 provides partial approval of some IHRs but not all the specific pre-selected IHRs, then the RU device 108 is informed of the fields which the Initiator device 102 is willing to share information. If the Initiator device 102 provides no response, then the RU device 108 is informed. Further, a PSN is updated and stored in the electronic processing device known as the USE 112.

[73] If the Initiator device 102 grants approval to provide the independent accurate assured authentication of the pre-selected IHRs, then the electronic processing device known as the USE 112 provides the RU device 108 with an independent accurate assured authentication of the pre-selected IHRs held under a respective UUHIR by checking the status of the assessed IHRs. The independent accurate assured authentication is provided in real-time and is valid as at a point in time with a date and time stamped when sent to the RU device 108. Further, the independent accurate assured authentication requests and results updates the PSN and then stores in the electronic processing device known as the USE 112 associated under the respective UUHIR and the RU device 108.

[74] At 705, the electronic processing device also known as the USE 112 can be configured to capture feedback from the RU device 108, and then share this feedback from the Recipient, with the Initiator device 102, so as to grant an opportunity to solicit rebuttal of the feedback received by requesting the Initiator to provide substantive evidence in support.

[75] The feedback response is received from the Initiator device 102. The electronic processing device known as the USE 112 may be configured to checks whether the feedback is credible against the response, along with evidence from the Initiator device 102. If no response is received from the Initiator within a specified period of time, the feedback is recorded and the electronic processing device known as the USE 112, initiates the re-assessment as shown at step 508 in FIG 5. Further, a PSN is updated and then stored in the electronic processing device known as the USE 112.

[76] FIG. 8 is a flow diagram that illustrates a method of a HA registration, HA identity verification and validation, followed by the creation of a unique HA User and stores this HA User in the USE, in accordance with an embodiment of the disclosure. FIG. 8 is explained in conjunction with elements from FIG. 1 and 2. A process of the HA registration in a centralized Health Record Assurance Management System which enables a real-time independent accurate assured authentication to be provided begins at step 801.

[77] At step 801, the HA 104 is registered into the electronic processing device also known as the USE 112. The HA device 104 is registered to a HA. The HA is an individual person or legal entity who administers the treatment for an ailment such as a medical practitioner, national health services, other clinic, doctors surgery. The HA 104 registration may be an online or an offline manual physical application registration process.

[78] At step 802, the identity information (ID) is provided which is associated with the HA device 104, this information is received at the electronic processing device known as the USE 112. The identity information comprises of, but is not limited to, the name of the individual HA or legal entity, a date of business incorporation or business start date, a proof of identification, identification type, identification number, email, telephone number and address of the HA 104.

[79] At 803, a plurality of terms and conditions (T and C) of the electronic processing device also known as the USE 112 are accepted by the HA device 104. The health authority accepts the plurality of T and C via the HA device 104.

[80] At 804, the identification information of the HA 104 is verified and validated by the electronic processing device known as the USE 112. To verify the identification information, the electronic processing device known as the USE 112 is configured to confirm, and check whether a plurality of identity data fields input by the HA 104 exists, are true and are correct when compared against a proof of valid identification information provided by the HA 104. The electronic processing device known as the USE 112 further validates the identification information based on an examination of whether the individual records are appropriate, acceptable and approved for use. If the identification information is not verified and validated, the process goes to step 805. If the identification information is verified and validated, the process goes to step 806.

[81] At 805 the HA 104 is informed that the identification information is not verified and or validated. At step 805, the process proceeds to step 801.

[82] At 806, the electronic processing device known as the USE 112 is updated. Further, a Process Status Notification (PSN) is updated in the electronic processing device known as the USE 112.

[83] At 807, a unique HA User record is generated by the electronic processing device known as the USE 112 for the HA 104. Further, but not limited to, a QR code is also generated for the HA 104. In one example, the USE 112 may further comprise a printer configured to print at least an identification number of the unique HA User record on a paper-based medium. In another example, the unique HA User record may be recorded in a microchip-based card. In yet another example, the USE 112 may be configured to print the unique HA User record as a booklet.

[84] At 808, the electronic processing device known as the USE 112 is configured to receive from the now registered HA User device 104 to capture the pre-populated date information associated with the HA 104 for ease of on-going use, this information may including, but not limited to, the details of disease and or ailment treated, treatment manufacturers, treatment serial numbers and or batch numbers, treatment and or vaccination administered by and or clinician’s names and designation and other relevant information associated with the HA 104.

[85] At 810, the pre-populated data information associated with the HA are self-verified by the HA to the electronic processing device known as the USE 112. The HA User accepts the self-verification via the HA User device 104.

[86] At 812, a one-time password is generated and transmitted by the electronic processing device also known as the USE 112, to the HA User device 104. The one-time password is transmitted to the HA User device 104 via at least one of a phone call or an email.

[87] At 814, the HA 104 is verified based on the generated one-time password transmitted to the HA device 104 which also confirms a self-verification of the HA User. At 816, the pre-populated date fields associated to the specific individual medical treatment which is provided for ease of use is stored in the electronic processing device also known as the USE 112.

[88] FIG. 9 is a flow diagram that illustrates a method of a MA registration, MA identity verification and validation, followed by the creation of a unique MA User and stores this MA User in the USE, in accordance with an embodiment of the disclosure. FIG. 9 is explained in conjunction with elements from FIG. 1 and 2. A process of the MA registration in a centralized Health Record Assurance Management System, which enables real-time independent accurate assured authentication to be provided, begins at step 901.

[89] At step 901, the MA device 106 is registered into the electronic processing device also known as USE 112. The MA device 106 is registered to a Manufacturing Authority. The Manufacturing Authority is an individual or a legal entity that manufacturers the medication, treatment and or vaccination required for the identified ailment treatment and or cure. The MA 106 registration may be an online or an offline manual physical application registration process.

[90] At step 902, the identity information (ID) is provided which is associated with the MA 106 this information is received at the electronic processing device which is known as the USE 112. The identity information comprises of but is not limited to, the name of the individual MA or legal entity, a date of business incorporation or business start date, a proof of identification, identification type, identification number, email, telephone number and address of the MA 106.

[91] At 903, a plurality of terms and conditions (T and C) of the electronic processing device also known as the USE 112 are accepted by the MA device 106. The MA accepts the plurality of T and C via the MA device 106.

[92] At 904, the identification information of the MA 106 is verified and validated by the electronic processing device known as the USE 112. To verify the identification information, the electronic processing device known as the USE 112 is configured to confirm, and check whether a plurality of identity data fields input by the MA device 106 exists, are true and are correct when compared against a proof of valid identification information provided by the MA 106. The electronic processing device also known as the USE 112 further validates the identification information based on an examination of whether the individual records are appropriate, acceptable and approved for use. If the identification information is not verified and validated, the process goes to step 905. If the identification information is verified and validated, the process goes to step 906.

[93] At 905 the MA 106 is informed that the identification information is not verified and or validated. At step 905, the process proceeds to step 901.

[94] At 906, the electronic processing device also known as the USE 112 is updated. Further, a Process Status Notification is updated in the electronic processing device known as the USE 112.

[95] At 907, a unique universal MA User record is generated by the electronic processing device also known as the USE 112 for the MA 106. Further, but not limited to, a QR code is also generated for the MA 106. In one example, the USE 112 may further comprise a printer configured to print at least an identification number of the unique universal MA User record on a paper-based medium. In another example, the unique universal MA User record may be recorded in a microchip-based card. In yet another example, the USE 112 may be configured to print the unique universal MA User record as a booklet.

[96] At 908, the electronic processing device known as the USE 112 is configured to receive from the now registered the MA device 106 to capture the pre-populated detail information associated with the MA 106, for ease of on-going use, which may include, but is not limited to, the details of disease and or ailment treated, treatment serial numbers and or batch numbers, treatment and or vaccination details, validity, and other relevant information associated with the MA 106.

[97] At 910, the pre-populated data information associated with the MA are self-verified by the MA to the electronic processing device known as the USE 112. The MA User accepts the self-verification via the MA User device 106.

[98] At 912, a one-time password is generated and transmitted by the electronic processing device known as the USE 112. The one-time password is transmitted to the MA 106 via at least one of a phone call or an email.

[99] At 914, the MA 106 is verified based on the generated one-time password transmitted to the MA device 106 which also confirms a self-verification of the MA User. At 916, the pre-populated data fields associated to the specific medical treatment which is provided for ease of use is stored in the electronic processing device known as the USE 112.

[100] The present disclosure further discloses a plurality of features such as a Health Record Assurance Management System designed as a mechanism (i.e. processes and systems) to: capture, verify, validate and collate Individual Identity information to generate a Unique Universal Record for each and every individual. The Health Record Assurance Management System captures Individual Health Records which are input and self-verified by the Individual Record Owner known as the Initiator. The Health Record Assurance Management System verifies, validates and collates these Individual Health Records against new and existing health records held by verification authorities. The Health Record Assurance Management System provides an assessment of these Individual Health Records, based on a pre-defined evaluation criteria to categorise and or score. The Health Record Assurance Management System then allocates these assessed Individual Health Records, and converts the existing Unique Universal Record into a Unique Universal Health Identification Record. The Health Record Assurance Management System enables a Registered User to seek independent authentication of specific pre-selected Individual Health Records in real-time. The Health Record Assurance Management System provides the authentication result notification as an independent accurate assured authentication after due approval is obtained from the Individual Record Owner known as the Initiator. The Health Record Assurance Management System provides the means: to capture feedback from registered users and to perform a re-assessment, designed to enhance the quality of the Individual Health Records held over-time in the Universal Secure Engine; which is a secure repository and custodian of all these records, designed to operate in conformance with a set of Core Principles.

[101] The Health Record Assurance Management System verifies and validates the Individual Identity information provided by an individual or their legal guardian. The verification and validation process is operated by either: a software, physical inspection, system or a combination of the three; in which the verification process checks these sets of individual records to verify that these records exists and are true or correct. The Health Record Assurance Management System examines whether the verified records are appropriate, acceptable and approved for use. These verified and validated records are stored in a secured repository for future use.

[102] The Health Record Assurance Management System generates a unique universal record for each and every Individual Record Owner known as the Initiator; in which the verified and validated individual records provided by an individual or their legal guardian is assigned a unique universal identity; such as; a unique number and or QR code. The unique universal identity proves association with the individual Record Owner known as the Initiator, the individual’s biometric attribute/s or other. The unique identity is the only existing one of its type. The unique identity is universal: applicable irrespective of geographic or physical location, boundary, language, ethnicity, sex or sexual orientation. The system generated unique universal record is stored in the secured repository for future use.

[103] The Health Record Assurance Management System captures, verifies, and validates the individual health records provided by an individual or their legal guardian with input received from the verifying health authorities. The verification and validation process is operated by either: a software, physical inspection, system or a combination of the three; in which the verification process, checks these sets of records; so as to verify that these records exists and are true or correct; and followed by the validation process which examines whether the verified records are appropriate, acceptable and approved for use; these verified and validated records are stored in the secured repository for future use.

[104] The Health Record Assurance Management System collates the verified and validated individual health records with the verified and validated health record input received from the verifying health authorities; in which the collation process is operated by either: a software, physical inspection, system or a combination of the three; in which the collation process compares these sets of verified and validated individual health records with verified and validated input from the health authorities so that, similarities and differences can be identified and reported; these verified, validated and collated records are stored in the secured repository for future use.

[105] The Health Record Assurance Management System verifies and validates the inputs received from the manufacturing authorities and then followed by the means to collate the individual health records provided by an individual or their legal guardian with input received from the verifying health authorities and the verifying manufacturing authorities; in which the verification, validation and collation process is operated by either: a software, physical inspection, system or a combination of the three; in which the verification process, checks the input provided by the health authorities and the manufacturing authorities; so as to verify that these records exists and are true or correct; and followed by the validation process which examines whether the verified records are appropriate, acceptable and approved for use; and then is followed by the collation process which compares these sets of verified and validated individual health records provided by an individual or their legal guardian with the input from the verifying health authorities and the verifying manufacturing authorities so that, similarities and differences can be identified and reported; these verified, validated and collated records are stored in the secured repository for future use.

[106] The Health Record Assurance Management System provides an assessment of the verified, validated and collated individual health records; in which the assessment process is operated by either: a software, physical inspection, system or a combination of the three; in which the process of assessment is to judge and decide based on the pre-defined evaluation criteria to categorise and or score; in which these assessed records are stored in the secured repository for future use.

[107] The Health Record Assurance Management System allocates the assessed individual health records and convert the existing unique universal record to a unique universal health identification record upon allocation of at-least one assessed individual health record for each and every individual; in which the allocation process is operated by either: a software, physical inspection, system or a combination of the three; in which the assessed individual health records are allocated to the existing unique universal record, converting this unique universal record to a unique universal health identification record; in which this converted unique universal health identification record can be used as a form of health identification and will be applicable for use to all and in any situation without the need to share the details of the individual health records contained within; in which this unique universal health identification record is stored in the secured repository for future use.

[108] The Health Record Assurance Management System verifies and validates the individual identity information provided by an individual or an entity seeking independent authentication; in which the verification and validation process is operated by either: a software, physical inspection, system or a combination of the three; in which the verification process checks these sets of individual records; so as to verify that these records exists and are true or correct; and followed by the validation process which examines whether the verified records are appropriate, acceptable and approved for use; after which the process generates a unique user identity; which can take the forms, such as; a unique number and QR code; in which this registered user defines selected individual health records which it requires to be authenticated; this verified and validated registered user identity is stored in a secured repository for future use.

[109] The Health Record Assurance Management System seeks independent authentication of specific pre-selected individual health records and for Health Record Assurance Management System to provide an accurate independent assured authentication of these specific pre-selected assessed records in real-time and after due approval is obtained; in which the Individual Health Records independent authentication process is operated by either: a software, physical inspection, system or a combination of the three; in which the individual or their legal guardian who owns and provided the individual health records has to start the process by presenting their Unique Universal Health Identification Record to a registered user; in which the registered user seeks independent authentication; in which Health Record Assurance Management System seeks due approval from the individual or their legal guardian who owns and provided the individual health records; in which upon receipt of such approval, the Health Record Assurance Management System initiates the process to provide a response of an accurate independent assured authentication; in which independent is defined as not influenced or controlled in any manner by other people, events, entities or things; and in which accurate is defined as to provide a correct, exact, and without any mistakes response; and in which assured or assurance is defined as a promise and means to assert with justified confidence or firmly, or a promise to cause someone to feel certain by removing doubt; and in which authentication is defined as the process of proving that the individual health records are real and true; and in which this accurate independent assured authentication is provided and valid as at a point in time with a date and time stamp; and in which this accurate independent assured authentication can be classified as being either: adequate, needs attention, inadequate or incomplete; in which adequate is defined as; the individual health records authenticated under the respective unique universal health identification record is accurate with an independent assessment after being categorised and or scored, verified, validated through multiple processes, and hence some (but not absolute) assurance can be provided; or in which needs attention is defined as; the individual health records authenticated under the respective unique universal health identification record is accurate with an independent assessment after being categorised and or scored, but the verification and validation could not be completed without further information from either one of the verification authorities, hence assurance cannot be provided without further validation and verification; or in which inadequate is defined as; the individual health records authenticated under the respective unique universal health identification record is accurate with an independent assessment after being categorised and or scored, but deficiencies exist and there is substantiated evidence to support that the verification and validation from any one of the verification authorities has failed, hence assurance on authentication cannot be provided; or in which incomplete is defined as; any of the individual health records to be authenticated under the respective unique universal health identification record has insufficient or incomplete data provided by the individual, and or, any, or all verification authorities, or when the registered user pre-selected individual health records information has not been provided, hence assessment of the individual health records cannot be completed; and or in which the definition of the pre-defined evaluation criteria to provide an accurate independent assured authentication can be based on other applicable factors and attributes for authentication at any future relevant point in time and given the environment conditions in which it operates at that time; and in which this independent authentication process is undertaken every time a request is received seeking independent authentication from any registered user; and then these requests from the registered user and associated authentication result notification under the respective unique universal health identification record are stored in the secured repository for future use.

[110] The Health Record Assurance Management System captures feedback provided by any registered user and designed to enhance the quality of the individual health records held over-time. The registered user is any individual or entity registered as a user such as the registered user who seek independent authentication and or verification authorities; such as health authorities and manufacturing authorities or other verification authorities; The feedback process is operated by either: a software, physical inspection, system or a combination of the three; in which the feedback process will enable the registered users to provide open, honest and transparent feedback in relation to specific individual health records or the unique universal health identification record in an effort to enhance the quality of the individual records held; in which this feedback when provided will be dated and time stamped; in which, such feedback will be shared with the individual or their legal guardian, who owns and provided the individual health records, so as to provide an opportunity for a response and to solicit rebuttal of the feedback received with substantive evidence in support; in which, such feedback provided against the individual health records under the respective unique universal health identification record are stored in the secured repository for future use.

[111] The Health Record Assurance Management System reassess the plurality of individual health records to whenever there is any: addition, deletion, amendment or modification and feedback of the individual health records; in which the feedback process is operated by either: a software, physical inspection, system or a combination of the three; in which the process for re-assessment to occur is triggered by any addition, deletion, amendment or modification and any feedback; in which, the re-assessment process re-executes all the steps relating to the verification, validation, collation, assessment through categorisation and or scoring, and the resultant allocation of the re-assessed individual health records to the respective unique universal health identification record; and then these re-assessed individual health records under the respective unique universal health identification record are stored in the secured repository for future use.

[112] The Health Record Assurance Management System a process status notification for the individual health records will be provided to each individual or their legal guardian by a colour coded symbol; in which this process is operated by either: a software, physical inspection, system or a combination of the three; in which this colour coded symbol will have a variation which defines the process status at every stage of the process; these process status notification are stored in the secured repository for future use.

[113] In the Health Record Assurance Management System, an independent authentication result notification for the individual health records will be provided by a colour coded symbol to each registered user who seeks an independent authentication of the specific pre-selected individual records; in which this process is operated by either: a software, physical inspection, system or a combination of the three; in which this colour coded symbol will have a colour variation which defines the different result notification status of the specific pre-selected individual records as at that point in time; these authentication result notifications are stored in the secured repository for future use.

[114] The Universal Secure Engine is a secure repository and custodian of all records which is designed to operate in conformance with a set of core principles; in which the universal secured engine is a software and system driven secure repository used as a storage facility which is free from the threat of un-authorised access and use; in which the core principles of operations currently are: unique individual identity record, universal application of the Health Record Assurance Management System, secure repository, compliance with law and regulation, strict confidentiality, absolute control to individual record holder, real-time notification and authentication and Individual Health Records verification and validation through multiple authorities; in which unique individual identity record is defined as unique and one of a kind; in which universal application is defined as a Health Record Assurance Management System which is applicable irrespective of geographic boundaries; in which secure repository is defined as a storage facility which is free the threat of un-authorised access and use; in which compliance with law and regulation is defined as being complaint with the applicable and relevant laws and regulations in the jurisdiction in which the individual record holder resides; in which strict confidence is defined in full adherence with applicable Data Privacy and Protection Laws in the jurisdiction in which the individual record holder resides; in which absolute control to the individual record holder is defined as the records are owned by the Individual health record holder who has absolute control to approve, share and manage these records with no records shared without the explicit real-time consent and approval of the Individual health record holder or the Legal Guardian in case of a minor; in which real-time notification and authentication is defined as the ability for the universal secured engine to provide the individual record holder with a process status notification in real-time and the ability to provide a registered user with a result status notification in real-time after obtaining due approval from the individual record holder in real-time; in which Individual Health Records are verified and validated through multiple authorities so as to ascertain the authenticity of these individual health records; and or in which the definition and list of the core principles can be based on other applicable operating principles and factors at any future relevant point in time and given the environment conditions in which it operates at that time.

[115] The present disclosure may be realised from the defined operational record assurance management system and or model, and the supporting process to provide an independent authentication which is applied to any or all forms of individual records for which independent authentication is or may be sought; in which this process is operated by either: a software, physical inspection, system or a combination of the three; in which any type of individual records; a piece of information or a description of an event that is written on paper or stored on a computer relating to a specific individual; in which such type of individual records are captured, verified, validated, collated and assessed so that these processed records are used to provide an accurate independent assurance of their authentication when sought by a registered user; and in which these independent assured authentication results are stored in a secured repository for future use.

[116] The present disclosure may be realized in hardware, or a combination of hardware and software or in the form of a manual physical document. The present disclosure may be realized in a centralized fashion, in at least one computer system, or in a distributed fashion, where different elements may be spread across several interconnected computer systems. A computer system or other apparatus adapted to carry out the methods described herein may be suited. A combination of hardware and software may be a general-purpose computer system with a computer program that, when loaded and executed, may control the computer system such that it carries out the methods described herein. The present disclosure may be realized in hardware that comprises a portion of an integrated circuit that also performs other functions.

[117] The present disclosure may also be embedded in a computer program product, which comprises all the features that enable the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program, in the present context, means any expression, in any language, code or notation, of a set of instructions intended to cause a system with an information processing capability to perform a particular function either directly, or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.

[118] While the present disclosure has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departure from the scope of the present disclosure. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present disclosure without departure from its scope. Therefore, it is intended that the present disclosure not be limited to the particular embodiment disclosed, but that the present disclosure will include all embodiments that fall within the scope of the appended claims.