WO2023234852A1

WO2023234852A1 - Personal electronic health record system (pehrs)

Info

Publication number: WO2023234852A1
Application number: PCT/SG2022/050374
Authority: WO
Inventors: Rachna KAIRON; Rakesh Kumar Aggarwal
Original assignee: Genejunction Pte. Ltd.
Priority date: 2022-06-01
Filing date: 2022-06-01
Publication date: 2023-12-07

Abstract

The application provides a personal health record system. The personal health record system includes a health record server device, at least one healthcare provider device, at least one healthcare source, and at least one patient device. The personal health record system provides a patient data acquisition mode, and a patient data inspection mode.

Description

PERSONAL ELECTRONIC HEALTH RECORD SYSTEM ( PEHRS )

This application relates to personal health records .

US5778882 describes a system that tracks the health status of a patient by compiling a chronological multi-parameter health history from multiple sensors that are in contact with the patient ' s body .

US5924074 shows how text-type patient record data can be created and maintained electronically . This information includes complaints , lab orders , medications , diagnoses , and procedure descriptions . The description is of a speci fic implementation that appears to map directly on the structure described by documents associated with the definition of HL7 (Health Level 7 ) , the standard for hospital and medical data record exchange . The key patented innovation relates to the use of pen-based portable computer interfaces .

US5974124 describes a system that assists doctors in treating patients with long-term medical conditions . The system includes storage of medical data taken from the patient ' s body, presentable through the internet or World Wide Web .

US5997476 to Brown describes remote data collection, both in question-answer form and data measurement form, for transmission to the clinician and subsequent display .

US 6032119 describes a display of individuali zed patient health status on an HTML (Hypertext Markup Language ) display that depicts the human body .

It is an obj ective of the application to provide an improved Personal Electronic Health Record System ( PEHRS ) . It is believed that a Personal Electronic Health Record System ( PEHRS ) can be improved by providing an Electronic Health Record (EHR) system that complies with HIPAA (Health Insurance Portability and Accountability Act ) . The EHR system is hosted by a website .

The HIPAA refers to standards for protecting sensitive patient health information from being disclosed without the patient ' s consent or knowledge .

The personal health data can include health conditions , symptoms , allergies , lab reports , medications , prescriptions , diagnoses , procedures , and family and social health history, which are taken from one or more sources .

The EHR system can also incorporate or take in legacy data in the form of paper files and charts . This involves the legacy data being converted to an electronic form by scanning . Text in the scanned data is later extracted using the Optical Character Recognition ( OCR) technique .

Using a computer or a mobile phone with an internet connection, an individual can access the ERH system to create and maintain their health records or data . The computer and the mobile phone include a software application for communicating with a graphical user interface of the website that hosts the ERH system to create and maintain their health data . In short , the health data are created and maintained in a real-time manner .

The data are also encoded or encrypted before trans ferring to allow for secure data trans fer . The EHR system also converts the personal health data into pre-programmed units that follow HL7 (Health Level 7) FHIR

(Fast Healthcare Interoperability Resources) standards. The

HL7 FHIR refers to an interoperability standard created by the standards development organization, Health Level 7. The FHIR is designed to enable health data, including clinical and administrative data, for quick and efficient exchange or transfer .

In detail, code systems used in the improved REHRS are those that are compatible with HL7 and FHIR such as SNOMED-CT, LOINC, and ICD-10CM.

After this, the converted personal health data is consolidated, wherein data from different sources are combined into a single data set.

The individual can grant certain healthcare providers revocable permission to access, analyze, and update their personal health data.

This then allows the healthcare providers to obtain the health data of different individuals, analyze the data, and identify the relationship among the data.

The COVID-19 pandemic has turned the health care system upside down and challenged consumers' sense of well-being. In many ways, consumers are taking charge of their health more than ever before. They are learning about their health risks, communicating with their doctors in new and diverse ways, and changing their attitudes about data privacy. According to the Deloitte 2020 Survey of US Health Care Consumers, it is found that a large majority of consumers of about 65% think that they should own their health data vs about 30% who think their doctor should own it, and even fewer who think that the government should own it.

The PEHRS of this application allows storing of patients' medical or health records in a single place by the patient, instead of storing them at various clinics and hospitals. The patients can create, maintain, and own their health-related data in one location.

The availability of such consolidated data in one location helps clinicians to provide better treatment by making informed decisions. Currently, EHRs (Electronic Health Records) are generated via data entry are done by clinicians, doctors, nurses, etc., who are treating the patient, at hospitals, where the patients are treated. The patients often do not have direct full access to their EHR but are provided with part of the information of the EHRs in the form of lab reports and discharge summaries. This restriction allows a hospital monopoly or full control of the EHR and is may not be in the best interest of the patient. Thus, there is a need to create a framework that is patient-centric where the EHR of a particular patient and all health-related data about the patient is available to the patient and to those to whom the patient wants to give access. In short, the improved PEHRS also allows the individual patient to share his health records with his caregivers, family members, and healthcare providers.

This PEHRS of this application also converts the EHR into a standard format for data, for units of measure, for normal ranges, and for other related significant medical information. This is different from many present systems. For example, a White Blood Count may be called a WBC, a White Count, or a WC at multiple, different hospital sources. Clinical result data may also need to be combined and has similar combination problems in that there is a lack of common format for data, units of measure , normal ranges , and other related signi ficant medical information .

This PEHRS of this application solves this problem by providing a single coding system for units . This application utili zes the Uni fied Code for Units of Measure (UCUM) Application Programming Interface (API ) to convert health and clinical data into commonly defined formats and validate the data against normal ranges . UCUM uses a formal syntax that can be validated, and a matrix of coef ficients that define all legal conversions between values expressed in one unit to values expressed in another commensurate unit . UCUM is very stable in content and has already been adopted by some standard organi zations such as DICOM, HL7 and has been referenced as best practice by the Open Geospatial Consortium in their Web Map Service (WMS ) and Geography Markup Language ( GML ) implementation speci fications .

This PEHRS of this application also allows an update of personal health data on a real-time basis . Many present systems typically update the Master Patient Index (MPI ) of patients on a non-real-time basis using various download techniques , such as batch, magnetic tape , diskette , batch direct communications , resulting in an MPI that is not current . Furthermore , real-time updates are often prevented or hindered by a large amount of work required for a computer server to combine , translate , index, and match the patient information, as well as by di f ferent interface implementations , communication methods , database capabilities , and design implementations .

This PEHRS of this application also encrypts data for transmitting and decrypting received data, thereby allowing for secure sharing of patient data among patients , their caregivers , and their healthcare providers . In other words , the patient can also give secure , encrypted, revocable access permission to any healthcare provider . Any healthcare provider with a computer and internet connection then has the permission to access and update the patient ' s health records in the improved PEHRS in real-time when the patient is seeking or undergoing treatment .

This PEHRS of this application also enables interoperability in allowing communication and collaboration among di f ferent healthcare systems . The data of PEHRS of this application are adapted such that the data complies with a single standard, such as the HIPAA standard, which facilitates the safe and secure sharing of healthcare information .

The application provides a personal health record system .

The personal health record system includes a health record server device , at least one healthcare provider device , at least one healthcare source , and at least one patient device .

In detail , the health record server device includes a health record server device memory unit and a health record server device communication module .

The healthcare provider device includes a healthcare provider device input device and a healthcare provider device communication module .

The healthcare source includes a healthcare source communication module . The patient device includes a patient device display device , a patient device input device , and a patient device communication module .

In use , the personal health record system provides a patient data acquisition mode , a patient data inspection mode , and a patient registration mode .

In the patient data acquisition mode , the healthcare provider device provides a first health data of a patient via the healthcare provider device input device , encrypts the first health data, and sends out the first health data via the healthcare provider device communication module .

The healthcare source then provides a second health data of the patient . After this , the healthcare source encrypts the second health data . The healthcare source then sends out the second health data via the healthcare source communication module .

Later, the health record server device receives the first health data and the second health data via the health record server device communication module . The health record server device then decrypts the first health data and the second health data . Following this , the health record server device trans fers the first health data and the second health data to a personal health record in a predetermined format . The health record server device later stores the personal health record in the predetermined format in a database of the health record server device memory unit .

In the patient data inspection mode , the health record server device , upon receiving a request for a predetermined personal health record from the patient device , allows access to the requested personal health record according to a set of patient data access data . The health record server device later encrypts the requested patient health record . Following this , the health record server device sends out the requested patient health record .

The patient device then receives the requested patient health data . Later, the patient device decrypts the requested patient health data and displays the requested patient health data to a user .

In the patient registration mode , the health record server device , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device , allows access to the requested patient healthcare provider registration data according to the set of patient data access data . After this , the health record server device encrypts the requested patient healthcare provider registration data . The health record server device then sends out the requested patient healthcare provider registration data .

Subsequently, the healthcare provider device receives the requested patient healthcare provider registration data . The healthcare provider device then decrypts the requested patient healthcare provider registration data . After this , the healthcare provider device prints a patient registration form according to the requested patient healthcare provider registration data .

The patient does not need to manually fill in his health data in an intake registration form . This is useful as the patient is often unwell . The health record server device can be is provided as a cloud server. The cloud server often refers to a pooled, centralized server resource that is hosted and delivered over a network— typically the Internet— and accessed on demand by multiple users. The cloud servers can perform the same functions as a traditional physical server in terms of processing power, storage, and software applications.

The health record server device communication module often comprises an Internet communication module. The communication module acts to transmit and received from the Internet.

The healthcare provider device communication module often also comprises an Internet communication module.

Likewise, the patient device communication module often comprises an Internet communication module.

The predetermined format often complies with the standard of at least one standard of a group. The group consists of HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) , SNOMED-CT (Systematized Nomenclature of Medicine - Clinical Terms) , LOINC (Logical Observation Identifiers Names and Codes) , and ICD-10CM (International Classification of Diseases, Tenth Revision, Clinical Modification) code system.

The encrypting and the decrypting support HIPAA (Health Insurance Portability and Accountability Act) compliance and often complies with the Google Cloud's ISO (International Organization for Standardization) /IEC (International Electrotechnical Commission) 27001, ISO/IEC 27017, and ISO/IEC 27018 standards. The application provides a health record server device for a personal health record system .

The health record server device includes a health record server device memory unit and a health record server device communication module .

In use , the health record server device provides a patient data acquisition mode , a patient data inspection mode , and a patient registration mode .

In the patient data acquisition mode , the health record server device receives a first health data from a healthcare provider device and a second health data from a healthcare source via the health record server device communication module . The health record server device then decrypts the first health data and the second health data . After this , the health record server device trans fers the first health data and the second health data to a personal health record in a predetermined format . The health record server device then stores the personal health record in the predetermined format in a database of the health record server device memory unit .

In the patient data inspection mode , the health record server device , upon receiving a request for a predetermined personal health record from a patient device , allows access to the requested personal health record according to a set of patient data access data . Later, the health record server device encrypts the requested patient health record . The health record server device then sends out the requested patient health record to the patient device .

In the patient registration mode , the health record server device , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device, allows access to the requested patient healthcare provider registration data according to the set of patient data access data. After this, the health record server device encrypts the requested patient healthcare provider registration data. The health record server device then sends out the requested patient healthcare provider registration data to the healthcare provider device.

This is useful as the patient does not need manually fill in his health data in an intake registration form. The patient can be unwell, and this thus provides convenience for the patient .

The health record server device is often provided as a cloud server .

In one aspect of the application, the health record server device communication module (75d) comprises an Internet communication module.

The predetermined format often complies with a standard of one of a group consisting of HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) , SNOMED-CT (Systematized Nomenclature of Medicine - Clinical Terms) , LOINC (Logical Observation Identifiers Names and Codes) , and ICD-10CM (International Classification of Diseases, Tenth Revision, Clinical Modification) code system.

The encrypting and the decrypting support HIPAA (Health Insurance Portability and Accountability Act) compliance and often complies with the Google Cloud's ISO (International Organization for Standardization) /IEC (International Electrotechnical Commission) 27001 , ISO/ IEC 27017 , and ISO/ IEC 27018 standards .

The application provides a method of operating a personal health record system .

The method includes a step of the personal health record system providing a patient data acquisition mode , a patient data inspection mode , and a patient registration mode ,

In the patient data acquisition mode , a healthcare provider device provides a first health data of a patient via a healthcare provider device input device , encrypts the first health data, and sends out the first health data via a healthcare provider device communication module .

A healthcare source then provides a second health data of the patient . The healthcare source later encrypts the second health data and sends out the second health data via a healthcare source communication module .

After this , the health record server device receives the first health data and the second health data via the health record server device communication module . The health record server device then decrypts the first health data and the second health data, transfers the first health data and the second health data to a personal health record in a predetermined format , and stores the personal health record in the predetermined format in a database of the health record server device memory unit .

In the patient data inspection mode , the health record server device , upon receiving a request for a predetermined personal health record from a patient device , allows access to the requested patient health record according to a set of patient data access data, encrypts the requested patient health record . The health record server device then sends out the requested patient health record,

Later, the patient device receives the requested patient health data and decrypts the requested patient health data . After this , the patient device displays the requested patient health data to a user .

In the patient registration mode , the health record server device , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device , allows access to the requested patient healthcare provider registration data according to the set of patient data access data .

The health record server device then encrypts the requested patient healthcare provider registration data and sends out the requested patient healthcare provider registration data .

Later, the healthcare provider device receives the requested patient healthcare provider registration data, decrypts the requested patient healthcare provider registration data, and prints a patient registration form according to the requested patient healthcare provider registration data .

In other words , this eliminates the need for a patient to manually fill in his health data in the intake registration form . Thus , providing convenience for the patient , especially when the patient is unwell .

The application also provides a method of operating a health record server device for a personal health record system . The method includes a step of the health record server device providing a patient data acquisition mode , a patient data inspection mode , and a patient registration mode .

In the patient data acquisition mode , the health record server device receives a first health data from a healthcare provider device and a second health data from a healthcare source via a health record server device communication module . The health record server device then decrypts the first health data and the second health data . After this , the health record server device trans fers the first health data and the second health data to a personal health record in a predetermined format . The health record server device later stores the personal health record in the predetermined format in a database of the health record server device memory unit .

In the patient data inspection mode , the health record server device , upon receiving a request for a predetermined personal health record from a patient device , allows access to the personal health record according to a set of patient data access data . The health record server device then encrypts the requested patient health record . After this , the health record server device sends out the requested patient health record to the patient device .

In the patient registration mode , the health record server device , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device , allows access to the requested patient healthcare provider registration data according to the set of patient data access data . The health record server device then encrypts the requested patient healthcare provider registration data . After this , the health record server device sends out the requested patient healthcare provider registration data to the healthcare provider device.

The subject matter of the application is described in greater detail in the accompanying Figures, in which

Fig. 1 illustrates an improved Personal Electronic Health Record System (PEHRS) ,

Fig. 2 illustrates a method for aggregating health records, clinical observations, and medical imagery and storing these into a common database of the improved PEHRS of Fig. 1,

Fig. 3 illustrates a method of transfer of online health records of the improved PEHRS of Fig. 1,

Fig. 4 illustrates a method of transfer of data of image from imaging systems and data from image server systems to the improved PEHRS of Fig. 1,

Fig. 5 illustrates a method to transfer offline documents that include films or paper documentation to the improved PEHRS of Fig. 1,

Fig. 6 illustrates the improved PEHRS of Fig. 1 receiving health data from various sources,

Fig. 7 illustrates the transfer of data among a patient device, a healthcare provider device, a server device, and healthcare sources of the improved PEHRS of Fig. 1,

Fig. 8 illustrates a process of a patient or a caregiver of the patient granting rights to the healthcare provider to access the improved PEHRS of Fig. 1, and

Fig. 9 illustrates a process of decoding data in the improved PEHRS of Fig. 1.

In the following description, details are provided to describe the embodiments of the specification. It shall be apparent to one skilled in the art, however, that the embodiments may be practiced without such details.

Some parts of the embodiments have similar parts. The similar parts may have the same names or similar part numbers with an alphabet symbol or prime symbol. The description of one part applies by reference to another similar part, where appropriate, thereby reducing the repetition of text without limiting the disclosure.

Fig. 1 shows an improved Personal Electronic Health Record System (PEHRS) 10.

The PEHRS 10 includes a health record website 12, one or more healthcare providers 14, a patient health record database 17, and patients or caregivers 19 of the patients.

The health record website 12, the healthcare providers 14, the patient health record database 17, and the patients or the caregivers 19 are communicatively connected to the internet 21.

The improved PEHRS 10 enables patient information obtained from an electronic health record or health data of an individual in the patient health record database 17 to be transmitted to various entities, such as patients 19, caregivers 19, and healthcare providers 14. The transmission is done in a secure manner.

The healthcare provider 14 may be a healthcare provider authorized to practice medicine, such as a physician, nurse, physician's assistant, or nurse practitioner. Other examples include chiropractors, optometrists, and dentists. In addition, the healthcare providers 14 may include service providers , such as pharmacists and lab technicians , who provide services to primary healthcare providers such as physicians .

Fig . 2 shows a method 23 for aggregating health records , clinical observations , and medical imagery and storing these into the common patient health record database of the improved PEHRS 10 of Fig . 1 .

This method 23 enables the data to be viewed and/or updated by medical practitioners or healthcare providers regardless of their locations worldwide . The information may also be viewed and monitored by patients or their caregivers for accuracy regardless of their locations .

The method further allows the health records to be updated by manually controlled or automated instrumentation which measures medical parameters . The instrumentation can be in a doctor' s of fice , in a hospital setting, in a patient ' s home . The instrumentation can be worn by the patient .

Data from the instrumentation is transmitted via common data access points in a point-to-point transmission manner over the global grid, or over public access common data networks supporting TCP/ IP, which is often referred to as the internet .

The improved PEHRS 10 uses several critical elements , which are already available , required to make a fully integrated health information resource . The improved PEHRS 10 combines these elements into an innovative information access/ management system that may be accessed via the internet .

The elements include :

1 ) a worldwide digital data interconnection infrastructure , 2) cloud-based data management systems large enough and fast enough to store the health data,

3) a universal data interface model which allows the patients, the caregivers, and the healthcare providers to view the health data,

4) a method 25 for acquiring medical data from self-recording instruments, online instruments, imaging systems, health record-keeping systems, and manual (paper-based) records, in other words, the health data is a) transferred from online health records, b) transferred from online instruments and/or image sources , c) transferred from offline films, and d) transferred from offline paper documents, and

5) a method 27 to provide relevant health data in commonly defined formats,

6) a method 29 to check the health data,

7) a method 31 for motivating institutions and individuals (patients) to present or store said data to the improved PEHRS 10.

With the improved PEHRS 10 using a cloud storage solution, storing the relevant data is feasible. By providing access to this data via the internet, access to the data from anywhere on any data terminal becomes feasible.

Thus, the individual is enabled by the improved PEHRS 10 to have their health records centrally stored and made accessible while taking adequate security measures.

In short, the improved PEHRS 10 presents a common interface to individuals and healthcare providers, which allows viewing of health data, and which allows convenient uploading or updating of data, as described above. Fig . 3 shows a method 33 of trans fer of online health records of the improved PEHRS 10 of Fig . 1 .

The method uses an interface that allows individuals and healthcare providers to upload or update the health data, in step 35 .

The data is converted and validated to comply with the UCUM standard, in step 36 .

The UCUM standard uses a formal syntax that can be validated, and a matrix of coef ficients that define all legal conversions between values expressed in one unit to values expressed in another commensurate unit . The UCUM standard is very stable in content and has already been adopted by some standard organi zations such as DICOM, HL7 and has been referenced as best practice by the Open Geospatial Consortium in their Web Map Service (WMS ) and Geography Markup Language ( GML ) implementation speci fications .

The data is then converted, i f needed, to comply with the HL7 FHIR standards , in a step 38 . For online instruments which allow for the trans fer of the health data, an Application Programming Interface (API ) is used to collect and convert the data .

The data is then encrypted or encoded for sending through the internet via links that may be wired, optical or wireless , in a step 40 .

During the sending, the data is routed to an internal buf fer, wherein the data is stored for redundancy, processed, or buf fered to act against any delays or temporary stoppages . When the data reaches its destination, the data is decrypted, in a step 43.

After this, the data is transferred to an area of the patient health record database, in a step 50.

Finally, the HL7 FHIR data is converted to HTML format for end users to view the data using user devices, in a step 51.

Fig. 4 shows a method 45 of transfer of data of image from imaging systems and data from image server systems to the improved FEHRS 10 of Fig. 1.

As shown in Fig. 4, an imaging system 47 generates image data.

The image data is typically stored online in a distributed file system 49, which may be separated from the imaging system. The distributed file system 49 is also called an image server system.

The image data uses industry-standard image formats such as GIF (Graphics Interchange Format) , TIFF (Tag Image File Format) , JPEG (Joint Photographic Experts Group) , or others or DICOM (Digital Imaging and Communications in Medicine) , the DICOM is the most used medical image standard.

The image data is then encrypted or decoded for transferring, via the internet, to the patient health record database 17 of the improved FEHRS 10 for storing.

Fig. 5 shows a method 52 to transfer offline documents that include films or paper documentation to the improved FEHRS 10 of Fig . 1. The method includes a step 53 of scanning the documents using a scanner or digital document capture system to produce a document image 55 in a standard image format like GI F, JPEG, or DICOM .

I f the document image 55 includes text , the document image is then subj ected to automated optical character recognition, OCR, in a step 57 . This step sometimes produces "dirty" text 59 because the character recognition may be incorrect .

The document image 55 is then coded, in a step 62 , into an HTML document 64 that comprises the scanned image 64a and recogni zed text 64b in the form of meta tags .

With this method, no manual intervention is necessary, and the resulting image record is searchable .

The HTML document 64 can be part of a form that allows a patient , a physician, or a hospital staf f to add or fill in additional information .

This HTML document is then stored in database 17 with searchable index 66 , where a user can access database 17 via the internet and can search database 17 for this HTML document 64 .

Fig . 6 illustrates the improved PEHRS 10 of Fig . 1 receiving health data from various sources .

The health data can relate to health conditions 68a, allergies 68b, medications 68c, supplements 68d, prescriptions 68e , vitals 68 f , social health history 68g, family history 68h, lab reports 68 i , care plans 68 j , consultation notes 68 k including procedures, diagnoses, and symptoms, doctor's contact 681, insurance details 68m, emergency contact 68n, personal files 68o, digital gene assets 68p, genetic profiles 68q, and immunization shots 68r,

The health data can be sent from the source as and when the health data is available.

Alternatively, the patient 19, the caregiver 19, the healthcare provider 14 can provide health data to the improved PEHRS 10 and maintain or update these health data. The patient 19, the caregiver 19, the healthcare provider 14 can access the improved PEHRS 10 via a graphical user interface that accesses the website that hosts the improved PEHRS 10.

Fig. 7 shows the transfer of data among a patient device 70, a healthcare provider device 73, a server device 75, and healthcare sources 77 as well as a collection of Application Programming Interfaces (APIs) 79 of the improved PEHRS 10 of Fig. 1. The server device 75 is also called a computer server.

The patient device 70 and the healthcare provider device 73 connect to the server device 75 through the internet 21. The server device 75 connects to the healthcare sources 77 and the Application Programming Interfaces (APIs) 79 through the internet 21.

Regarding the patient device 70, it includes a user interface 70a, a computing processor 70b, a memory unit 70c, and a communication module 70d. The user interface 70a includes an input device and an output device. The user interface 70a is called a user interface unit. The memory unit 70c is also called memory. Preferably, the input device includes a keyboard, but also maybe a touch screen, a microphone with a voice recognition program, a sensor or measuring device connected to a smartphone , as an example .

Preferably, the output device is a display, but also may be a speaker, as an example .

The patient device 70 is preferably implemented using a personal computer . The personal computer may be the fixed or mobile type and may be implemented in a variety of forms including a desktop, a laptop, a tablet , and a smartphone .

The patient device 70 may include one or more devices that are located at the same or di f ferent physical or geographic locations .

In use , the patient device 70 may be considered as a requesting device that receives information via the communication module 70d upon making requests .

The user interface 70a is intended for interfacing with an end-user . Therefore , the data is provided for an easy user interface in a format , such as in hypertext markup language (HTML ) that is executed by a browser .

The input device allows a user to input information into the patient device 70 and an output device that permits a user to receive information from the patient device 70 .

The output device provides information to the user responsive to the input device receiving information from the user or responsive to other activity by the patient device 70 or the healthcare provider device 73 . A web browser receives information from the input device and the output device displays information from the web browser .

Regarding the healthcare provider device 73 , it has parts similar to the parts of the patient device 70 . The healthcare provider device 73 includes a user interface 73a, a processor 73b, a memory unit 73c, and a communication module 73d .

The memory unit 73a of the healthcare provider device 73 stores patient information that is local to device 73 . For example , the healthcare provider device 73 may reside at a medical center and the patient information represents or relates to only the patients that go to the medical center for care .

Regarding the server device 75 , it includes a memory unit 75c, a user interface 75a, a processor 75b, and a communication module 75d . The server device 75 is preferably implemented as a cloud server .

The user interface 75a includes a display 75al , a keyboard 75a2 , but also maybe a touch screen, and an internet browser 75a3 .

The memory unit 75c includes patient authentication software 75cl and a list 75c2 of available healthcare sources 77 . The memory unit 75c also includes programs for running the server device 75 .

The patient authentication software 75cl in the memory unit

75c includes log-in information related to a patient including email address and encrypted password . The processor 75b manages the communications between the server device 75 and the healthcare sources 77 . The processor 75b may be implemented in software and/or hardware and operates responsive to the programs stored in the memory unit 75c .

The list 75c2 of available healthcare sources , otherwise called a predetermined directory of data, keeps track of all the healthcare sources 77 that are available to interface with the server device 75 . The list 75c2 may be updated manually or using an automatic registration procedure . Responsive to the list 75c2 , the server device 75 knows which available healthcare sources 77 to query and knows which available healthcare sources 77 to expect a response from, as described in Fig . 7 .

The list 75c2 of healthcare sources may be represented in a variety of file formats including plain text , text files such as documents , graphic files such as a graphical trace including, for example , an electrocardiogram (EKG) trace , an electrocardiogram (ECG) trace , and an electroencephalogram (EEG) trace , video files such as a still video image or a video image sequence , an audio file such as an audio sound or an audio segment , and visual files , such as a diagnostic image including, for example , a magnetic resonance image (MRI ) , an X-ray, a positive emission tomography ( PET ) scan, or a sonogram .

The list 75c2 of healthcare sources is an organi zed collection of clinical information concerning one patient . The patient record can narrowly be considered as a file cabinet or repository with divisions and indexing mechanisms . These divisions resemble a hierarchy with folders , documents , and document components , or other obj ects representing collections of clinical elementary information. Such folder divisions include classifications such as user profile, health conditions, health monitor, health records, genetic profile, notes, investigations, medications, care plans, correspondence, results.

Regarding the healthcare source 77, it includes health data 77a, a database 77b, a file storage 77c, and a communication module 77d.

Regarding the Application Programming Interfaces (API) 79, they support certain recognized standards. The API 79 allows communications between computers, systems, or programs. The API 79 provides a service to other software.

The standards include, without limitation, HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) , SNOMED-CT (Systematized Nomenclature of Medicine - Clinical Terms) , LOINC (Logical Observation Identifiers Names and Codes) , and ICD-10CM (International Classification of Diseases, Tenth Revision, Clinical Modification) code system.

The HL7 FHIR is a set of international standards used to provide guidance regarding the transfer and sharing of data between various healthcare providers. In detail, the HL7 FHIR provides a way for hospitals to exchange their data without paper files as an intermediary.

The SNOMED CT is a standardized, multilingual vocabulary of clinical terminology that is used by physicians and other health care providers for the electronic exchange of clinical health information. The SNOMED CT currently contains more than 300,000 medical concepts, divided into hierarchies as diverse as body structure, clinical findings, geographic location, and pharmaceutical/biological product. By using numbers to represent medical concepts, the SNOMED CT provides a standard by which medical conditions and symptoms can be referred, eliminating the confusion that may result from the use of regional or colloquial terms. The numerical reference system also facilitates the exchange of clinical information among disparate health care providers and electronic medical records (EMR) systems.

The LOINC is the international standard for identifying health measurements, observations, and documents. It provides a common language to unambiguously identify things that can be measured or observed that enables the exchange and aggregation of clinical results for care delivery, outcomes management, and research. The LOINC is a rich catalog of measurements, including laboratory tests, clinical measures like vital signs and anthropometric measures, standardized survey instruments, and more.

The ICD-10-CM is a globally used diagnostic tool for epidemiology, health management, and clinical purposes. It is designed as a health care classification system, providing a system of diagnostic codes for classifying diseases, including nuanced classifications of a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances, and external causes of injury or disease. This system is designed to map health conditions to corresponding generic categories together with specific variations, assigning for these a designated code, up to six characters long.

In Fig. 7, a first network provides a communication network among the patient device 70, the healthcare provider device 73, and the server device 75. A second network provides a communication network between the server device 75 and the healthcare sources 77 and API s 79 .

The patient device 70 , the healthcare provider device 73 , and the server device 75 can send a query, and each of the server device 75 , the healthcare source 77 , and the API s 79 can communicate a reply over a communication path coupled to the appropriate network .

The patient device 70 , via the communication module 70d, and the healthcare provider device 73 , via the communication module 73d, can send a query and receive a reply over a communication path to the first network .

The server device 75 via the communication module 75d can receive a query and then send a reply over a communication path coupled to the first network . The server device 75 can also send a query and then receive a reply over a communication path coupled to the second network .

The healthcare sources 77 , via the communication module 77d, and API s 79 can receive a query and send a reply over a communication path coupled to the second network .

Preferably, all the replies from the healthcare sources 77 to the server device 75 are in XML and/or JSON format .

Each of the communication paths is preferably adapted to use one or more data formats , otherwise called protocols , depending on the type and/or configuration of the various elements in the improved PEHRS 10 . Examples of the information system data formats include an RS232 protocol , an Ethernet protocol , a Medical Interface Bus (MIB ) compatible protocol , an Internet Protocol ( I . P . ) data format , a wide area network (WAN) protocol, an IEEE bus compatible protocol, and a Health Level Seven (HL7) protocol.

The communication paths use an I.P. data format to permit the patient device 70 and the healthcare provider device 73, the server device 75, the healthcare sources 77, and the APIs 79 to communicate with each other using a common data format.

The I.P. data format, otherwise called an I.P. protocol, uses IP addresses. Examples of the I.P. addresses include, without limitation, Transmission Control Protocol Internet Protocol (TCPIP) address, an I.P. address, a Universal Resource Locator (URL) , and an electronic mail (Email) address.

Fig. 8 shows a process 80 of a patient 19 or a caregiver 19 of the patient granting rights to the healthcare provider 14 to access the improved PEHRS 10 of Fig. 1, in a step 82.

The patient 19 or the caregiver 19 may choose to grant access rights to the patient health data to an individual or entity, such as a healthcare provider 14, in a step 84. The access rights can refer to reading, in a step 88, and/or writing privileges, in a step 89.

The patient 19 or a caregiver 19 may also later deny or revoke the access rights, in a step 86. The access rights can refer to reading, and/or writing privileges.

Even when a particular healthcare provider 14 has not granted access rights to personal health data, the healthcare provider 14 can still access the health data in an event of emergencies . Fig . 9 shows a process 91 of encrypting or decoding health data for sending to the improved PEHRS 10 of Fig . 1 .

The process 91 includes uploading patient data, in a step 93 . The patient data is afterward converted to a predetermined format , i f necessary, in a step 95 . The health data is encrypted before sending, in a step 97 , via the internet , to the patient health record database of the improved PEHRS 10 for storing, in a next step . The health data is then decrypted in a step 99 . The data is then trans ferred to an area of the patient health record database , in a step 102 . After this , the data is converted to a predefined format in a step 104 .

The encryption/decryption includes a public/private key system so that the central archive can validate that the source of the data .

To track the changes to the health record, an auditing trail is maintained . In detail , the person modi fying the health record is identi fied while changes made by that person and the date and time that the change made are recorded . In this manner, the patient 19 may track changes made to the health record, as well as make corrections , as necessary .

Each user has access to a particular patient record is given a unique identi fier .

Information from a patient ' s electronic personal health record can be provided to a healthcare provider 14 .

Upon the arrival of patient 19 at the of fice of healthcare provider 14 , the healthcare provider 14 can provide an intake registration form with relevant data that is extracted from the personal health record of the patient 19 . The relevant data is then printed onto the intake registration form . This eliminates the need for the patient 19 to manually fill in his health data in the intake registration form .

Data from the electronic personal health record may also serve as the gateway or point of entry to third-party provider databases containing detailed medical information on the patient 19 . These provider databases include , but are not limited to hospitals , medical centers , and labs .

The improved PEHRS 10 utili zes the Google Cloud Healthcare API to address security and compliance with secure-by-design infrastructure , built-in safeguards , comprehensive identity management , network security, and threat detection and response capabilities . The Google Cloud Healthcare API supports HIPAA (Health Insurance Portability and Accountability Act ) compliance and complies with the Google Cloud' s ISO ( International Organi zation for Standardi zation) / IEC ( International Electrotechnical Commission) 27001 , ISO/ IEC 27017 , and ISO/ IEC 27018 standards .

The improved PEHRS 10 can have several di f ferent implementations .

In one implementation, the improved PEHRS 10 allows a patient 19 to moneti ze their health data through a platform for health data exchange between patients 19 and researchers , such as G JXchange .

In another implementation, the improved PEHRS 10 enables healthcare partners to digiti ze their whole , and even multiple clinic systems and healthcare solutions , while providing the capability to impanel or enrolled consultants , and control of payments and commission . In a special implementation, the improved PEHRS 10 enables medical centers and labs to upload investigative reports , which can relate to radiology and labs onto a healthcare provider' s account . The healthcare providers 14 can then trans fer these data with veri fiable electronic signatures to patients 19 and provide documented consultations .

The improved PEHRS 10 can allow healthcare providers to pass veri fiable e-prescription to impanel vendors .

The improved PEHRS 10 can include the management of the delivery of prescriptions to the homes of patients 19 .

Although the above description contains many speci ficities , these should not be construed as limiting the scope of the embodiments but merely providing an illustration of the foresee-able embodiments . Especially the above-stated advantages of the embodiments should not be construed as limiting the scope of the embodiments but merely to explain possible achievements i f the described embodiments are put into practice . Thus , the scope of the embodiments should be determined by the claims and their equivalents , rather than by the examples that are given .

REFERENCE NUMBERS

10 PEHRS

12 health record website

14 healthcare provider

17 patient health record database

19 patient or caregiver

21 internet

23 method

25 method

27 method

29 method

31 method

33 method

35 step

36 step

38 step

40 step

43 step

45 method

47 imaging system

49 distributed file system

50 step

51 step

52 method

53 step

55 document image

57 step

59 "dirty" text

62 step

64 HTML document

64a scanned image

64b recogni zed text

66 searchable index 68a health conditions

68b allergies

68c medications

68d supplements

68e prescriptions

68 f vitals

68g social health history

68h family history

68 i lab reports

68 j care plans

68 k consultation notes

681 doctor' s contact

68m insurance details

68n emergency contact

68o personal files

68p digital gene assets

68q genetic profiles

68r immuni zation shots

70 patient device

70a user interface

70b computing processor

70c memory unit

70d communication module

73 healthcare provider device

73a user interface

73b processor

73c memory unit

73d communication module

75 server device

75a user interface

75al display

75a2 keyboard

75a3 internet browser

75b processor c memory unit cl patient authentication software c2 list of available healthcare sources . d communication module healthcare source a health data b database c file storage d communication module Application Programming Interfaces (API s ) process step step step step process step step step step 2 step 4 step

Claims

1. A personal health record system (10) comprising a health record server device (75) comprising a health record server device memory unit (75c) and a health record server device communication module (75d) , at least one healthcare provider device (73) comprising a healthcare provider device input device (73a) and a healthcare provider device communication module (73d) , at least one healthcare source (77) comprising a healthcare source communication module (77d) , at least one patient device (70) comprising a patient device display device, a patient device input device (70a) , and a patient device communication module (70d) , wherein the personal health record system (10) provides a patient data acquisition mode, a patient data inspection mode, and a patient registration mode, in the patient data acquisition mode, the healthcare provider device (73) provides a first health data of a patient via the healthcare provider device input device (73a) , encrypts the first health data, and sends out the first health data via the healthcare provider device communication module (73d) , the healthcare source (77) provides a second health data of the patient, encrypts the second health data, and sends out the second health data via the healthcare source communication module (77d) , the health record server device (75) receives the first health data and the second health data via the health record server device communication module (75d) , decrypts the first health data and the second health data, transfers the first health data and the second health data to a personal health record in a predetermined format , and stores the personal health record in the predetermined format in a database of the health record server device memory unit ( 75c ) , in the patient data inspection mode the health record server device ( 75 ) , upon receiving a request for a predetermined personal health record from the patient device ( 70 ) , allows access to the requested personal health record according to a set of patient data access data, encrypts the requested patient health record, and sends out the requested patient health record, and the patient device ( 70 ) receives the requested patient health data, decrypts the requested patient health data, and displays the requested patient health data to a user, and in the patient registration mode , the health record server device ( 75 ) , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device ( 73 ) , allows access to the requested patient healthcare provider registration data according to the set of patient data access data, encrypts the requested patient healthcare provider registration data, and sends out the requested patient healthcare provider registration data, and the healthcare provider device ( 73 ) receives the requested patient healthcare provider registration data, decrypts the requested patient healthcare provider registration data, and prints a patient registration form according to the requested patient healthcare provider registration data . The personal health record system (10) according to claim 1, wherein the health record server device (75) is provided as a cloud server. The personal health record system (10) according to claims 1 and 2, wherein the health record server device communication module (75d) comprises an Internet communication module. The personal health record system (10) according to one of above-mentioned claims, wherein the healthcare provider device communication module (73d) comprises an Internet communication module. The personal health record system (10) according to one of above-mentioned claims, wherein the patient device communication module (70d) comprises an Internet communication module. The personal health record system (10) according to one of above-mentioned claims, wherein the predetermined format complies with a standard of one of a group consisting of HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) , SNOMED-CT (Systematized Nomenclature of Medicine - Clinical Terms) , LOINC (Logical Observation Identifiers Names and Codes) , and ICD-10CM (International Classification of Diseases, Tenth Revision, Clinical Modification) code system. The personal health record system (10) according to one of above-mentioned claims, wherein the encrypting and the decrypting support HIPAA (Health Insurance Portability and Accountability Act) compliance and complies with the Google Cloud's ISO (International Organization for Standardization) /IEC (International Electrotechnical Commission) 27001, ISO/IEC 27017, and ISO/IEC 27018 standards.

A health record server device (75) for a personal health record system (10) , the health record server device (75) comprising a health record server device memory unit (75c) and a health record server device communication module (75d) , wherein the health record server device (75) provides a patient data acquisition mode, a patient data inspection mode, and a patient registration mode, in the patient data acquisition mode, the health record server device (75) receives a first health data from a healthcare provider device (73) , and a second health data from a healthcare source (77) via the health record server device communication module (75d) , decrypts the first health data and the second health data, transfers the first health data and the second health data to a personal health record in a predetermined format, and stores the personal health record in the predetermined format in a database of the health record server device memory unit (75c) , in the patient data inspection mode, the health record server device (75) , upon receiving a request for a predetermined personal health record from a patient device (70) , allows access to the requested personal health record according to a set of patient data access data, encrypts the requested patient health record, and sends out the requested patient health record to the patient device (70) , and in the patient registration mode, the health record server device (75) , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device (73) , allows access to the requested patient healthcare provider registration data according to the set of patient data access data, encrypts the requested patient healthcare provider registration data, and sends out the requested patient healthcare provider registration data to the healthcare provider device (73) . The health record server device (75) according to claim 8, wherein the health record server device (75) is provided as a cloud server. The health record server device (75) according to claims 8 and 9, wherein the health record server device communication module (75d) comprises an Internet communication module. The health record server device (75) according to one of claims 8 to 10, wherein the predetermined format complies with a standard of one of a group consisting of HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) , SNOMED-CT (Systematized Nomenclature of Medicine - Clinical Terms) , LOINC (Logical Observation Identifiers Names and Codes) , and ICD-10CM (International Classification of Diseases, Tenth Revision, Clinical Modification) code system. The health record server device (75) according to one of claims 8 to 11, wherein the encrypting and the decrypting support HIPAA (Health Insurance Portability and Accountability Act) compliance and complies with the Google Cloud's ISO (International Organization for Standardization) /IEC (International Electrotechnical Commission) 27001, ISO/IEC 27017, and ISO/IEC 27018 standards. A method of operating a personal health record system (10) , the method comprising the personal health record system (10) providing a patient data acquisition mode, a patient data inspection mode, and a patient registration mode, wherein in the patient data acquisition mode, a healthcare provider device (73) provides a first health data of a patient via a healthcare provider device input device (73a) , encrypts the first health data, and sends out the first health data via a healthcare provider device communication module (73d) , a healthcare source (77) provides a second health data of the patient, encrypts the second health data, and sends out the second health data via a healthcare source communication module (77d) , the health record server device (75) receives the first health data and the second health data via the health record server device communication module (75d) , decrypts the first health data and the second health data, transfers the first health data and the second health data to a personal health record in a predetermined format, and stores the personal health record in the predetermined format in a database of the health record server device memory unit (75c) , in the patient data inspection mode, the health record server device (75) , upon receiving a request for a predetermined personal health record from a patient device (70) , allows access to the requested patient health record according to a set of patient data access data, encrypts the requested patient health record, and sends out the requested patient health record, and the patient device ( 70 ) receives the requested patient health data, decrypts the requested patient health data, and displays the requested patient health data to a user, and in the patient registration mode , the health record server device ( 75 ) , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device ( 73 ) , allows access to the requested patient healthcare provider registration data according to the set of patient data access data, encrypts the requested patient healthcare provider registration data, and sends out the requested patient healthcare provider registration data, and the healthcare provider device ( 73 ) receives the requested patient healthcare provider registration data, decrypts the requested patient healthcare provider registration data, and prints a patient registration form according to the requested patient healthcare provider registration data . A method of operating a health record server device ( 75 ) for a personal health record system ( 10 ) , the method comprising the health record server device ( 75 ) providing a patient data acquisition mode , a patient data inspection mode , and a patient registration mode , wherein, in the patient data acquisition mode , the health record server device (75) receives a first health data from a healthcare provider device (73) , and a second health data from a healthcare source (77) via a health record server device communication module (75d) , decrypts the first health data and the second health data, transfers the first health data and the second health data to a personal health record in a predetermined format, and stores the personal health record in the predetermined format in a database of the health record server device memory unit (75c) , in the patient data inspection mode, the health record server device (75) , upon receiving a request for a predetermined personal health record from a patient device (70) , allows access to the personal health record according to a set of patient data access data, encrypts the requested patient health record, and sends out the requested patient health record to the patient device (70) , and in the patient registration mode, the health record server device (75) , upon receiving a request for a healthcare provider registration data with regards to a patient from the healthcare provider device (73) , allows access to the requested patient healthcare provider registration data according to the set of patient data access data, encrypts the requested patient healthcare provider registration data, and sends out the requested patient healthcare provider registration data to the healthcare provider device (73) .