WO2010052638A1

WO2010052638A1 - Electronic health record management method and system

Info

Publication number: WO2010052638A1
Application number: PCT/IB2009/054870
Authority: WO
Inventors: Jessie Dias-Alf
Original assignee: Jessie Dias-Alf
Priority date: 2008-11-04
Filing date: 2009-11-03
Publication date: 2010-05-14
Also published as: ZA201103781B

Abstract

An electronic health record management system and a method of creating, maintaining and utilising an electronic health record are provided. The electronic health record management system comprises a communication module to receive patient medical encounter files from at least one third party database server. A record building module parses the received patient medical encounter files thereby to obtain patient data and associated medical encounter data from the medical encounter files in accordance with the rule set. This information associated with a particular patient is stored in predetermined fields of the patient record according to a predefined rule set, thereby to create a current patient database with multiple patient records, each patient record to comprise information on multiple medical encounters of the patient.

Description

ELECTRONIC HEALTH RECORD MANAGEMENT METHOD AND

SYSTEM

BACKGROUND OF THE INVENTION

THIS invention relates to an electronic health record management method and system.

Health care service providers may typically be grouped into public sector health care service providers, i.e. service providers where health care is funded and provided by the state or government, and private sector health care service providers, i.e. service providers where health care is funded by individuals, e.g., through health care insurance.

Public sector and private sector health care service providers typically use either electronic or paper administration systems to document and store patient information. This results in fragmented health record systems with no consolidated electronic record of patient medical information.

It is well-known that a consolidated electronic record of patient medical information, where the information is provided as a single patient view across multiple service providers, would be invaluable to health care service providers in assessing a patient's overall health, illnesses, medical history, or the like. Also, a comprehensive electronic record of patient medical information comprising medical information from the birth of an individual to the individual's death would assist governments in planning for medical care spending and health programs, especially in third world countries where illnesses such as Aids are to be managed and monitored. One of the main problems identified with creating a consolidated electronic record of patient medical information is that the creation of a database of such records would be difficult, due to the fragmentation of health care service providers, the lack of uniform systems, the lack of a central information system and the time required to build such a record from nothing. Maintaining an electronic health record may also be problematic after the creation of the relevant databases.

It is therefore an aim of the present invention to provide a system and method for creating, maintaining and utilising a consolidated and structured electronic record of patient health information.

SUMMARY OF THE INVENTION

According to one aspect of the invention there is provided an electronic health record management system comprising:

a communication module to receive patient medical encounter files from at least one third party database server;

a protocol module which stores and maintains a predefined rule set determining data fields for a generated patient record;

a record building module to parse the received patient medical encounter files to obtain patient data and associated medical encounter data from the medical encounter files in accordance with the rule set and to store the obtained data associated with a particular patient in the predetermined fields for the patient record, thereby to create a current patient database with multiple patient records, each patient record to comprise information on multiple medical encounters of the patient. Preferably the data is stored in the predetermined fields in accordance with universal standards relating to the practice area of a third party responsible for the third party database server. For example, the universal standard may be Logical Observation Identifiers Names and Codes (LOINC) used for identifying laboratory observations or Digital Imaging and Communications in Medicine (DICOM) used for handling, storing, printing, and transmitting information in medical imaging. By using the universal standard, the patient records are stored in a form which is unrelated to the format of the patient medical encounter files.

The patient medical encounter files received from the third party database servers are usually a predetermined subset of the files that are stored by the third party database servers.

Preferably, the third party database server is a database server forming part of a laboratory information management system of a laboratory, e.g., a public or private diagnostic pathology laboratory.

The patient medical encounter files may be received periodically.

On receipt of a patient medical encounter file, the record building module may first verify information received in the patient medical encounter files against external verification records maintained by validation entities. In the event that the verification fails, an exception report may be generated by the record building module and may be transmitted to the third party database server and/or a health care service provider for further processing or correction.

The communication module may further receive a consent notification from a health care service provider or from the third party database server confirming that a signed patient consent has been obtained authorising the storage and distribution of the patient medical encounter record.

The consent notification may be a signed consent form transmitted to the system and received by the communication module, to be stored in the -A-

current patient database or may be a consent notification message. Alternatively, the consent notification may be implicit. For example, in receiving a patient update record from a health care service provider a consent notification is deemed to have been received by the communication module.

The system may further comprise an archiving module to archive the multiple patient records on their creation, with the communication module transmitting medical information from the patient records in the current patient database to an archive database.

Typically, the archiving module is further to determine according to archiving criterion whether information on a particular patient medical encounter is to be deleted from the current patient database, thereby to maintain the currency of the data.

The system may further comprise a query module to obtain information from the current patient and/or archive database; the communication module being configured to receive from a health care service provider a patient health enquiry specifying information to be retrieved, and, once obtained by the query module from the current patient database and/or the archive database, to transmit the information to the health care service provider.

The communication module is further to receive a patient update record from a health care service provider, wherein the patient update record comprises a unique patient identifier in order to identify the patient's patient record in the current patient database; and the record building module is to update the identified patient record with data contained in the patient update record.

Preferably, the health care service provider is an authorised registered health care service provider. Typically any patient record is identified through a unique patient identifier, such as an identity number or social security number. The health care service provider may be identified through an identity number and/or a unique service provider identifier which is linked with personal, practice and professional information of the service provider, the unique service provider identifier being allocated to the service provider during a registration process.

The patient update record received from a health care service provider may be received as a message, such as an SMS, through a web page interface, or any other suitable communication means. The patient update record may include or may be accompanied with the unique patient identifier and an encounter code which identifies the type of patient encounter to be updated or logged against the patient record in the current patient database.

The mobile telephone number from which the patient update record or request is received may be associated with the health care service provider in order to identify the health care service provider. Alternatively, a PIN may be transmitted with the record or request message thereby to identify the health care service provider.

Typically, the record building module accesses tables in a protocol module enabling the patient record to be appropriately updated according to the encounter code. Confirmation may be sent to the health care service provider once the database record has been updated.

The encounter code may, for example, be a diagnosis code identifying an illness with which a patient has been diagnosed, a code identifying a patient's medication, (e.g., a NAPPI (National Pharmaceutical Product Interface) code or the like), a procedure code identifying a procedure to be performed or performed on a patient, an allergy code identifying an allergy of the patient, a pre-existing medical condition code or the like.

Additionally, the encounter code may be a service payment code. In the event that a service payment code is received, a payment module of the system performs a validation with the unique patient identifier against records of a medical aid scheme to confirm the membership and benefits of the patient. The payment module generates a patient medical claim message to be transmitted by the communication module to the medical aid scheme for processing and payment. The communication module may further send a notification to the health care service provider to confirm that the patient medical claim is being processed or to advise on the status of a medical claim.

The system may also comprise a reporting module, accessible by health care service providers and/or authorised third parties to generate reports, such as statistical reports, from the various patient records stored in the archive database and/or the current patient database.

The communication module may additionally communicate with validation entities, such as medical aid schemes, health insurance agencies or Medical Councils to enable verification of information received from the third party database server and health care service providers.

According to another aspect of the invention there is provided a method of creating, maintaining and utilising an electronic health record management method comprising:

receiving patient medical encounter files from at least one third party database server;

providing a predefined rule set determining data fields for a generated patient record;

parsing the received patient medical encounter files to obtain patient data and associated medical encounter data from the medical encounter files in accordance with the rule set; and storing the obtained data associated with a particular patient in the predetermined fields for the patient record, thereby creating a current patient database with multiple patient records, each patient record to comprise information on multiple medical encounters of the patient.

The method further comprises archiving the multiple patient records on their creation by transmitting medical information from the patient records in the current patient database to an archive database. Additionally, the method comprises determining according to archiving criterion whether a particular patient medical encounter record is to be deleted from the current patient database and deleting such file if the archiving criterion is met.

Preferably, the patient medical encounter files are received from the third party database server periodically.

The method may further comprise:

receiving over a communications network a patient health enquiry from a health care service provider;

obtaining the requested information from the current patient and/or archiving database and transmitting the information to the health care service provider.

Additionally, the method may comprise:

receiving a patient update record from a health care service provider, wherein the patient update record comprises a unique patient identifier in order to identify the patient's patient record; and

updating the identified patient record in the current patient and/or archiving database with data contained in the patient update record. The method may further comprise, prior to creating a patient record in the current patient database, receiving a consent notification from a health care service provider or from the third party database server confirming that a signed patient consent form has been obtained authorising the storage and distribution of the patient medical encounter record.

The consent notification may be a signed consent form received to be stored in the current patient database or may be a consent notification message. Alternatively, the consent notification may be implicit. For example, in receiving a patient update record from a health care service provider a consent notification is deemed to have been received by the communication module.

The method may further include the health care service provider registering with the system prior to sending a patient update record.

On receipt of a patient medical encounter file or patient update record, the method may extend to first verifying information received in the patient medical encounter files against external verification records maintained by validation entities. In the event that the verification fails, the method include the steps of generating an exception report and transmitting the report to the third party database server and/or a health care service provider for further processing or correction.

The patient update record received from a health care service provider may be received as a message, such as an SMS, through a web page interface, or any other suitable communication means together with the unique patient identifier and an encounter code which identifies the type of patient encounter to be updated or logged against the patient record in the current patient database.

The mobile telephone number from which the patient updater record or request is received may be associated with the health care service provider thereby to identify the health care service provider. Alternatively, a PIN may be transmitted with the message to identify the health care service provider.

Typically, the method includes accessing tables in a protocol module enabling the patient record to be appropriately updated according to the received encounter code. Confirmation may be sent to the health care service provider once the database record has been updated.

Additionally, the encounter code may be a service payment code.

In the event that a service payment code is received, the method may extend to performing a validation on the unique patient identifier against records of a medical aid scheme to confirm the membership and benefits of the patient. A patient medical claim message is generated and transmitted by the communication module to the medical aid scheme for processing and payment. The communication module may further send a notification to the health care service provider to confirm that the patient medical claim is being processed or to advise on the status of a medical claim.

The patient medical encounter file may include data on the patient name, a unique patient identifier, e.g., the identification number, contact details of the patient, a medical service provider requesting the laboratory tests, a secondary doctor to whom the data should be sent, medical aid or health insurance claim information, laboratory results of the patient. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in more detail, by way of example only, with reference to the accompanying drawings in which:

Figure 1 shows a schematic diagram of an electronic health record management system in accordance with an example embodiment of the invention;

Figure 2 shows a block diagram of various modules of the electronic health record management system of Figure 1 , in accordance with an example embodiment of the present invention;

Figure 3 is a high-level flow diagram showing steps of a method of creating and maintaining an electronic health record, in accordance with an example embodiment of the present invention;

Figure 4 is a high-level flow diagram showing further steps of a method of creating and maintaining an electronic health record, in accordance with an example embodiment of the present invention; and

Figure 5 is a high-level flow diagram showing steps of a method of utilising the electronic health record created and maintained through the method steps shown in Figures 3. and 4.

DESCRIPTION OF PREFERRED EMBODIMENTS

Turning to Figure 1, an electronic health record management system 10 is shown in accordance with an example embodiment of the present invention. In this embodiment, the system 10 is configured to create, maintain and utilise a current patient database 12 (electronic health record) in order to provide a consolidated electronic record of patient health information, i.e., patient medical encounter information. These electronic records of the current patient database 12 are generated after one or more medical encounters of a patient in any health care delivery setting. For example, medical encounters may be a visit to a doctor, blood tests being conducted, a medical procedure being performed on a patient, or the like. Information that may be included in such an electronic patient record is patient demographics, health/illness progress notes, general or specific health problems, prescribed medication, vital signs, past medical history, immunizations, laboratory data, radiology reports, or the like.

In addition to various modules of the system 10 and the current patient database 12, the system 10 may further comprise an archive database 14 which may form part of a government network. Alternatively, the archive database 14 may be merely an additional storage medium to which non- current data may be moved once it is determined that information in the current patient database 12 has aged to the point where the information is no longer current. The archive database 14 may also be synchronised with the current patient database 12 and information is typically archived to the archive database 14 in accordance with archiving criteria.

In an example embodiment, the archive database 14 always contains all the information in or previously stored in the current patient database 12, while aged information is simply removed or deleted from the current patient database 12, in accordance with the archiving criteria. In another example embodiment, the archive database 14 may be updated in accordance with archiving criteria.

Various health care service providers 16 (only one of which is shown in Figure 1) interact with the system 10, either to transmit a patient update record to the system 10 for incorporation in the current patient database 12 in order for the records relating to a particular patient to be updated, or alternatively, to retrieve particular electronic patient medical encounter records or reports from the current patient database 12, or from the archive database 14, via the current patient database 12.

The health care service provider 16 may be a doctor, dentist, a physiotherapist, or any other person providing health care services or entities providing medical or health care services such as laboratories.

The current patient database 12 comprises various patient records, with each patient record in turn comprising patient information and information on medical encounters of the particular patient.

In order to create the current patient database 12, and optionally, for this database 12 to be maintained, the system 10 interacts with at least one (potentially many) third party database server 18, shown in this example embodiment as a database server forming part of a laboratory information management system of a laboratory, e.g., a public or private diagnostic pathology laboratory. The system 10 interacts with the third party database server 18 through a communication module which forms part of the system 10.

In the preferred embodiment of the present invention, a public or private diagnostic pathology laboratory provides to the system 10 patient history files in the form of patient medical encounter files from which the current patient database 12 is built. The reason for making use of datasets provided by pathology laboratories is that most laboratories have well- maintained laboratory information management systems. Also, in most scenarios of serious illness, a patient would first be sent for some type of pathology testing, typically blood tests. It is therefore foreseen that a consolidation of patient medical encounter files and records of various laboratories would provide an exceptionally good basic data set to build a database of consolidated patient records. These systems may also be easily configured to share some of the data maintained by these systems with an electronic health care management system 10 of the present invention. It will however be appreciated that any entity that has well-maintained electronic patient records of a suitable size may be employed as a third party database server 18 in the system 10 of the present invention.

In order to ensure the general accuracy levels of the patient medical encounter files to be transmitted to the electronic health record management system 10 it may be prudent to first conduct a due diligence on the patient history files maintained by the third party in control of the third party database server 18. If the due diligence finds the patient medical encounter files of an acceptable format, the system 10 may be configured to receive historical patient medical encounter files on implementation of the system. However, if the due diligence finds that the patient medical encounter files are not of an acceptable format, the system may be configured to only receive files generated and stored by the third party after the implementation of the system 10.

The patient medical encounter files received from the third party database server 18 are usually a predetermined subset of the files that are stored by the third party database server 18.

Each of the patient medical encounter files obtained from the third party database server 18 may include general patient information, e.g., the patient name, a unique patient identifier, e.g., an identity number or social security number of the patient, contact details of the patient, as well as information obtained from medical encounters, e.g., details of a health care service provider which has requested the laboratory tests, a secondary health care service provider to whom the data should be sent, medical aid or health insurance claim information, laboratory results of the patient, or the like.

The format in which patient medical encounter files are sent to the system as well as the format in which the patient records are stored in the databases 12 and 14 are typically standardized, for example according to a universal standard thereby to ensure that the data may not necessarily be identifiable as originating from a particular third party database server 18. In one example embodiment of the invention, a record building module, described in more detail below, adapts the received data to be stored in predetermined fields in accordance with universal standards relating to the practice area of a third party responsible for the third party database server. For example, the universal standard may be Logical Observation Identifiers Names and Codes (LOINC) used for identifying laboratory observations. Data received from laboratories would therefore be adapted to this standard by the record building module acting as an interface. Likewise, Digital Imaging and Communications in Medicine (DICOM) used for handling, storing, printing, and transmitting information in medical imaging may be used to adapt and convert data received from imaging agencies. By using the universal standard, the patient records are stored in a form which is unrelated to the format of the patient medical encounter files.

This ensures a level of confidentiality to the third party and ease of storage. In one embodiment of the invention, personal or specific medical aid scheme or health insurance identifying information need not form part of the patient medical encounter file.

As shown by Figure 2, the electronic health record management system 10 comprises a communication module 30, a record building module 32, an archiving module 34, a query module 36, a protocol module 38, a payment module 40 and a reporting module 42, in addition to the current patient database 12 and the archive database 14 shown in Figure 1. The protocol module 38 stores relevant tables, rule sets, encounter codes (described in more detail below) and protocols, such as the mentioned universal standards, thereby allowing the system to adapt received data, store the saved data in a predetermined format, and interact with various parties during reporting or the like. It will accordingly be appreciated that the tables, rule sets, encounter codes and protocols are to be predefined prior to the creation of the current patient database. Additionally, the information stored in the protocol module 38 may be adapted when changes in the format of patient records are necessary. The communication module 30 is to communicate with the third party database server 18, the archive patient database server 14, the health service providers 16 and patients (indicated by reference numeral 22 in Figure 1). It is foreseen that the communication module 30 has the necessary interfaces to communicate via any telecommunication infrastructure, e.g., via a network such as the Internet, via electronic mail, via a mobile communication network (e.g., SMS or USSD), through the employment of an Interactive Voice Recognition (IVR) system or via fixed line networks, such as facsimile. The communication module 30 may additionally communicate with external verification and validation entities, such as medical aid schemes, health insurance agencies or Medical Councils to enable verification of information received from the third party database server 18 and/or the health care service providers 16.

The communication module 30 is to receive patient medical encounter files from at least one third party database server 18. Also, the communication module 30 is to transmit data from a particular patient record to the archive database 16 on receipt of such information or alternatively during archiving operations. Communications to either receive a patient health enquiry from a health care service provider 16 or to transmit the requested information from the current patient database 12 to health care service provider 16 is also performed by the communication module 10.

Prior to receiving any patient medical encounter files from a third party database server 18, a patient is required to first give consent to the patient's information being transmitted to, stored and re-distributed by the electronic health record management system 10. This consent may be provided by the patient by signing a consent form at the time of requesting laboratory tests to be conducted. The communication module 30 receives a consent notification from the third party service provider 18 or from a health care service provider 16 which confirms that the patient has given written consent authorising the storage and distribution of the patient medical encounter file. The responsibility for obtaining and storing this signed consent form would typically remain that of the entity responsible for the third party database server 18 or health care service provider 16. As mentioned, the consent form will not only apply to the storage of information in the current patient database 12 and the archive database 14, but will also apply to the distribution of patient medical encounter information (with patient identifiable data) to authorised registered health care service providers 16, as well as data for statistical use to be distributed as reports to other relevant parties, typically as faceless data.

From the above it follows that the current patient database 12 is a subset of the records of the third party database. The design and purpose of the current patient database 12 is to ensure that health care service providers 16 receive, on request, timely access to relevant data for improved clinical decision making.

The consent notification may be the signed consent form as received from a third party, then to be stored in the current patient database 12. Alternatively, the consent notification may be a consent notification message transmitted from the relevant party and received by the system 10.

It will be appreciated that the consent notification may also be implicit in certain circumstances. For example, in receiving a patient update record from a health care service provider a consent notification may be deemed to have been received by the communication module.

The record building module 32 is to parse received patient medical encounter files thereby to obtain patient data and in particular, medical encounter data. This data is parsed and obtained by the record building module 32 in accordance with the rule set which is predefined and maintained by the protocol module 38 shown in Figure 2. For example, the rule set may determine the data fields associated with a particular patient that are to be stored thereby to create a current patient database of patient records, with each patient record including a single patient view of multiple patient medical encounter records. As described in more detail above, the information in the received files will be adapted to be stored as patient records in accordance with predetermined universal standards.

Each patient record is identified in either of the databases through the unique patient identifier, e.g., the identity number of the patient.

The protocol module 38 may further define the types of authorised queries that may be received from health care service providers 16 and the format of the information to be provided to the health care service providers 16. Other rules maintained by the rule set may relate to user (whether third parties, health care service provider or patient) access rights and levels, patient privacy rules, a determination on how data should be consolidated and structured through the use of universal standards and validation rules.

In one example embodiment of the present invention, the record building module 32 may first have to verify information received in the patient medical encounter files against external verification records maintained by validation entities (mentioned above and shown by block 20 in Figure 1). For example, the identity number used as the unique patient identifier, as well as the personal details of a patient may be verified against the records of government departments, such as home affairs. Information relating to a patient's medical aid scheme may also be verified against medical aid scheme records. Similarly, health care service provider information contained in the patient medical encounter file may be verified with the relevant Medical Council. In the event that the verification fails, an exception report may be generated by the record building module 32 and may be transmitted to the third party database server 18 and/or a health care service provider 16 for further processing or correction.

Once the patient record of multiple patient medical encounter records has been created in the current patient database 12, copies of the patient medical encounter records may be transmitted to the archive database 14 to be stored in duplicate. In addition, once a patient medical encounter record has been created in the current patient database 12, the records may be updated whenever additional medical information is received from health care service providers 16. Typically, whenever a query or information is received from health care service providers 16, the system 10 will first determine whether a patient record exists for a particular patient by querying the current patient database with the unique patient identifier.

It will be appreciated that the health care service providers 16 may communicate with the system 10 via any communication network such as the Internet, where a webpage user interface is provided, via e-mail, mobile network interfaces (such as SMS or USSD), IVR interfaces or a facsimile interface.

As mentioned, in order for a health care service provider 16 to update the current patient database 12, i.e. to submit information on a new patient medical encounter such as information relating to a particular patient (e.g., information on a diagnosis, scripts or procedure), it is necessary for a health care service provider 16 to first register with the system 10. For health care service providers 16 relying on paper administration systems, the electronic health record management systems 10 of the present invention provides a particular effective method to register with the system and to transmit information to the system 10 via mobile telephone communication or IVR, e.g., through the use of short message system (SMS) commands. It will however be appreciated that other communication technologies such as USSD or the like may also be used.

In order to register as a health care service provider 16 with the system 10, the health care service provider 16 may send an SMS comprising an optional PIN, e.g., a four digit PIN, the identity number of the health care service provider and/or a health care service provider number. These numbers are verified against records of the relevant medical profession association, e.g. against the records of a Medical Council, as mentioned in other parts of this document. The mobile telephone number (from which the request is received) may be associated in a health care service provider database with the other information of the health care service provider 16. During the registration process, in addition or alternatively to the use of the identity number of the health care service provider 16, the health care service provider may also be allocated a unique service provider identifier which is linked with personal, practice and professional information of the service provider 16.

It will be appreciated that the health care service provider database may, but need not, form part of the current patient database 12. Confirmation will be sent to the health care service provider's mobile telephone once he has been registered.

Once the health care service provider 16 (and patient) has registered with the system 10, patient medical information or patient update records may be logged against the patient records of patients of the health care service provider. For example, the health care service provider 16 sends an SMS message to a particular number. This message may contain the abovementioned selected PIN (although optional), the unique patient identifier and an encounter code which identifies the type of encounter to be updated or logged. The PIN, the allocated unique service provider identifier, the identity number or the mobile telephone number associated with the health care service provider may be used to identify the health care service provider 16 as the sender of the particular message, whether the message is a request for information or a patient update record.

As mentioned above, the record building module 32 has access to the information maintained in the protocol module 38 that would enable the patient record to be updated appropriately according to the encounter code. Confirmation may be sent to the health care service provider 16 once the database record has been updated.

In one example embodiment, where a particular diagnosis is made on a patient, the health care service provider 16 may send a message that contains the mentioned PIN, the unique patient identifier and a diagnosis code. For example, the diagnosis code ICD10 may be a code for hypertension.

Similarly, SMS's may be sent to update a patient record with regard to the dispensing of medicine. In this scenario, a NAPPI code for the patient's medication, together with the unique patient identifier and the health care service provider PIN is transmitted. A NAPPI code is a unique identifier for a given ethical, surgical or consumable product which enables electronic transfer of information throughout the healthcare delivery chain. The record building module 32 interprets the NAPPI code and logs descriptive detail of a medicine script dispensed against the patient record (e.g. once daily Norvasc 10mg).

In order to log a procedure performed on a patient against a patient record, a procedure code is transmitted with the other information mentioned above. For logging an allergy or pre-existing medical condition against a patient record, an allergy code or pre-existing medical condition code may be transmitted. It will be appreciated that many other types of data may be logged by the sending of an SMS with a code, provided that there is a key in the protocol module 38 to interpret the code.

It is generally accepted that health care service providers 16 would typically have two types of patients, i.e., patients who belong to a medical aid scheme or patients who have health insurance and then, those patients without any type of medical insurance. It may not be important for the health care service provider to determine the patient type when interacting with the system 10, as the system comprises functionality to perform an online verification of the patient health insurance status when processing a medical encounter. Therefore, the system would receive data for both types of patients as would be required to populate patient records for all patient types irrespective of the method of invoicing used by the health care service provider 16. However, in cases where patients 22 do have medical insurance, the electronic health care management system 10 will incorporate a service to the medical aid schemes and medical insurance companies thereby to provide an incentive to health care service providers 16 to provide the electronic health care management system 10 with patient data.

In this scenario, health care service providers 16 who participate in this model would be requested to send patient medical encounter records to the electronic health care management system 10 and will in effect be treated as a third party database server 18.

Health care service providers 16 will then transmit a service payment code as an encounter code, the service code indicating that payment is necessary for a medical encounter. The payment module 40 forming part of the electronic health care management system 10 may then perform a validation with the unique patient identifier against records of medical aid schemes or health insurers to confirm the membership and benefits of the patient. The payment module 40 may package and pass on the patient medical encounter information as a patient medical claim message to the respective scheme for processing and payment. The payment module 40 may additionally notify the health care service provider 16 through the communication module 30 that the claim is being processed and information on the claim's payment status.

The archiving module 34 is to transmit a copy of medical encounter information from the patient record in the current patient database 12 to the archive database 14, as mentioned above. The upkeep of data in the current patient database 12 is determined, in accordance with archiving criteria (maintained in protocol module 38), that is whether a particular patient record is to be only archived and deleted from the current patient database 12. The archiving criteria are typically dependent on a particular medical condition or illness. For example, if a patient is HIV positive, CD4+ count tests are normally done every three months. Archiving criteria may therefore be predefined in the protocol module 38 to annually archive the CD4+ test results of HIV positive patients and to delete these records from the current patient database 12. Also, the archiving criteria could typically determine that the oldest medical encounter tied to a type of medical encounter is to be deleted, e.g., the archiving criteria could define that only one annual pap smear result is required in the current patient database 12 with older records already duplicated in the archive database 14 being deleted from the current patient database 12.

Archiving has the benefit that it provides a complete patient record accessible by authorised authorities through the reporting module 42. The archived patient record may therefore be seen as a consolidated single longitudinal electronic health record of patient information, from birth to death, generated by one or more encounters in any medical or health care delivery setting. The design and purpose of the patient archive database 14 is to improve outcomes analysis amongst other benefits typically pointed at government.

Although medical information of a patient may be archived and therefore stored in the archive database 14, this information would still be accessible by health care service providers 16 on request.

By archiving medical records it is possible to create a birth to death record of patients.

As mentioned above, the communication module 30 also receives patient health enquiries from various health care service providers 16. On receipt of a patient health enquiry, the communication module 30 communicates the enquiry to the query module 36. The query module 36 has access to the tables maintained by the protocol module 38 that identifies particular illnesses or the like. Once the query module 36 has determined that the enquiry has been received from a registered health care service provider 16 and what the type of information is required, the query module 36 obtains the necessary information either from the current patient database 12 or from the archive database 14 and in some instances, from both the current patient database 12 and the archive database 14.

For example, a health care service provider 16 such as a doctor may request a particular HIV positive patient the patient's CD4+ count test results of the last year. Similarly, for an intensive care unit patient in a diabetic coma, a doctor may request blood glucose test results over a period of seven to ten days.

Based on the information obtained, the query module 36 prepares a response to the enquiry and the communication module 30 transmits this information to the health care service provider 16, the information being transmitted in a suitable format.

The reporting module 42 of the electronic health care management system 10 may be used to draw reports, such as statistical reports, from the various patient records stored in the archive database 14 and/or the current patient database 12. Statistical information that may be drawn into reports could be invaluable to government agencies or health departments in order to verify treatment procedures, current infection rates or the like. The reporting module 42 may provide for an appropriate interface to enable authorised users to draw such reports. The reporting module 42 may further operate in conjunction with the query module 36 to provide medical service providers with information necessary to diagnose patients or to obtain a full medical record for patients.

Reporting and responses to a patient health enquiry is typically governed by predetermined rules defined in the protocol module 38. For example, as one health care service provider may need to contact other health care service providers during the treatment of a patient, details of such health care service providers may be maintained in a patient record and may be transmitted to a health care service provider on request. However, the source of this type of data would not necessarily be accessible to the health care service provider. When reporting to authorities, patient identifying information and information on the health care service providers may however not be disclosed.

Lastly, the electronic health record management system 10 may provide for direct communications with any of the patients 22 for which patient records are maintained. A patient may, for example, transmit a patient query regarding medical encounters to the system 10, which is received by the communication module 30 and processed by the query module 36. In generating a response to a patient query, the query module 36 may access the protocol module 38 to determine the type of information that may be transmitted to the patient. Alternatively, the patient may update the patient's own electronic patient record within a set of predefined rules (maintained by the protocol module 38). Access levels of the patient will also be in accordance with rules in the protocol module 38. Communication between the patient and system may be in accordance with any appropriate communication medium. For example, the patient may make use of an IVR interface provided by the system 10, SMS messages in which the patient identifies him- or herself through the unique patient identifier, web page interfaces or facsimile transmission. The patient would typically have to register with the system 10 and will be issued with a PIN and/or password. In using SMS messaging, predefined message formats may be used in order to make parsing and processing of messages easy.

Figures 3 to 5 show simplified high-level flow diagrams of a method of creating, maintaining and utilising an electronic health record in accordance with the present invention. In one example embodiment of the invention, the method, as shown in the three figures, may be implemented by the system 10 of Figures 1 and 2.

It will be appreciated that the method steps described below are merely a high-level description of the operation of the system 10 of Figures 1 and 2 in order to provide an overview of the various steps of the overall method of creating, maintaining and utilising an electronic health record. Additional more detailed information on these steps is provided throughout the specification and although it has not been reiterated in the description of the method steps, this information does form part of the method of the present invention.

Turning to Figures 3 and 4, methods steps of creating and maintaining the electronic health record are shown. The flow diagram 50 of Figure 3 shows that the method comprises a step 52 where patient medical encounter files are received from at least one third party database server 18, as described in more detail above.

On receipt of a patient medical encounter file, it is first determined whether a consent notification has been received from either the third party managing the third party database server 18 or from a health care service provider (step 54). In the event that no consent notification has been received, or if the consent notification is not implicit, remedial action may be taken (shown by block 56). For example, in one example embodiment of the invention the relevant party may be notified that the patient medical encounter file may not be processed until such time as the consent has been obtained and/or confirmed.

In block 58, it is shown that information received in the patient medical encounter files is first to be verified against external verification records maintained by validation entities. In one example embodiment, this step is to be executed by the record building module 32. As is described in more detail above, should the validation/verification fail, remedial action (block 56) may be taken through the generation of an exception report that is to be transmitted to the third party database server 18.

Once the pre-verification and validation steps have been completed, the record building module accesses predefined rule sets to determine data fields for the generation of patient records (block 60). These rule sets are maintained, in one example embodiment, by the protocol module 38 of the system 10.

The received files are then parsed to obtain patient data and associated medical encounter data from the patient medical encounter files (block 62) in accordance with the rule set whereafter this data associated with a particular patient is stored (block 64) in the predetermined fields for the patient record, thereby creating a current patient database with multiple patient records. Each record thereby comprises information on multiple medical encounters of the patient which is stored in the predetermined fields of the patient record thereby to create a current patient database 12. The method 50 further shows steps of archiving data, which in this embodiment of the invention comprises archiving data in an archive database 14 (block 66). As shown by block 68, the data in the current patient database 12 is checked against archiving criteria to determine whether data records in the current patient database has dated to the point of being deleted (block 72) or whether the data should, for the time being, remain in the current patient database (block 70).

Turning now to Figure 4, further steps 80 of creating and maintaining an electronic health record in accordance with the present invention are described.

In order to maintain patient records stored in the current patient database 12 and the archiving database 14, the method extends to a process whereby health care service providers 16 send patient update records through to the system 10. This patient update record is received by the communication module 30 of the system 10, as shown by block 82.

In order for a health care service provider 16 to be authorised to send such information through to the system or for the service provider to interact with the system in any way, it is necessary for the health care service provider 16 to first register (block 84). Identification of such health care service provider and the association of information with the service provider are described in more detail above.

The method further extends to verifying information received in the patient update record against external verification records (block 86). Similar to the verification process in Figure 3, if the information cannot be verified, the update of the patient record may be abandoned or remedial action may be taken (block 88).

In order to update the patient record (shown by block 92), the health care service provider 16 and patient record are first identified through information in the patient update record or associated therewith (block 90). For example, a patient update record may be sent from a mobile device to the system and the health care service provider may be identified through the mobile device number from which the patient update record is received.

The information that may form part of the patient update record is described in detail above. For example, this information comprises a unique patient identifier in order to identify the patient's patient record and an encounter code which identifies the type of patient encounter to be updated or logged against the patient record in the current patient database. Examples of encounter codes, also mentioned above, are a diagnosis code identifying an illness with which a patient has been diagnosed, a code identifying a patient's medication, a procedure code identifying a procedure to be performed or performed on a patient, an allergy code identifying an allergy of the patient, a pre-existing medical condition code or the like.

The method may further include the step of determining whether the encounter code is a service payment code (shown by block 94). If the encounter code is not a service payment code, the patient record is updated without further processing of the received patient update record (block 96).

However, if the encounter code is a service payment code, the method extends to performing a validation of the unique patient identifier against records of a medical aid scheme to confirm the membership and benefits of the patient (block 98). If membership and benefits cannot be confirmed, processing is abandoned and/or remedial action is taken (block 100).

In the event that membership and benefits of the patient are confirmed, a patient medical claim message is generated and transmitted to the medical aid scheme for processing and payment, shown by block 102.

Although not shown in Figure 4, the method may further extend to sending a notification to the health care service provider to confirm that the patient medical claim is being processed or to advise on the status of a medical claim. Figure 5 shows a simplified flow diagram 110 of utilising the created and maintained electronic health record. As shown by block 112, a patient health enquiry is received over a communications network from a health care service provider. In order to process the query, the health care service provider is to be identified (as described in more detail above) as well as the patient record to which the query relates (block 114).

Once this information is obtained, the query module 36 (in one example embodiment) obtains the requested information from the current patient and/or archiving database (block 116) and transmits the information to the health care service provider through use of the communication module 30.

The present invention therefore provides for the creation, maintenance and utilisation of a consolidated electronic record of patient health information. This information is stored as consolidated single longitudinal electronic health records of patient information, from birth to death, generated by one or more encounters in any medical or health care delivery setting, The information is accessible by various registered or authorised parties, whether for the update of data, the reporting on data or for access to the data in this electronic record thereby to improve clinical decision making or additionally for government agencies to use in determining policy outcomes and the like.

Claims

CLAIMS:

1. An electronic health record management system comprising:

a protocol module which stores and maintains a predefined rule set determining data fields for a generated patient record; and

a record building module to parse the received patient medical encounter files thereby to obtain patient data and associated medical encounter data from the medical encounter files in accordance with the rule set, the record building module further to store the obtained data associated with a particular patient in the predetermined fields of the patient record, thereby to create a current patient database with multiple patient records, each patient record to comprise information on multiple medical encounters of the patient.

2. An electronic health record management system as claimed in claim

1 wherein the data is stored in the predetermined fields in accordance with a universal standard relating to the practice area of a third party responsible for the third party database server.

3. An electronic health record management system as claimed in claim

2 wherein the universal standard is Logical Observation Identifiers Names and Codes (LOINC) used for identifying laboratory observations or Digital Imaging and Communications in Medicine (DICOM) used for handling, storing, printing, and transmitting information in medical imaging.

4. An electronic health record management system as claimed in claim 2 or 3 wherein the employment of the universal standard results in the patient records being stored in a form unrelated to the format of the received patient medical encounter files.

5. An electronic health record management system as claimed in any one of claims 1 to 4 wherein the third party database server is a database server forming part of a laboratory information management system of a public or private diagnostic pathology laboratory.

6. An electronic health record management system as claimed in any one of claims 1 to 5 wherein the patient medical encounter files are received from the third party database server periodically.

7. An electronic health record management system as claimed in any one of claims 1 to 6 wherein, on receipt of a patient medical encounter file, the record building module is first to verify information received in the patient medical encounter files against external verification records maintained by validation entities.

8. An electronic health record management system as claimed in claim 7 wherein, in the event that the verification fails, an exception report is generated by the record building module and is transmitted, by the communication module, to the third party database server for further processing or correction.

9. An electronic health record management system as claimed in any one of claims 1 to 8 wherein the communication module is further to receive a consent notification from a health care service provider or from the third party database server confirming that a signed patient consent form has been obtained authorising the storage and distribution of data from the patient medical encounter record.

10. An electronic health record management system as claimed in claim 9 wherein the consent notification is a consent notification message or a signed consent form received by the communication module to be stored in the current patient database.

11. An electronic health record management system as claimed in any one of claims 1 to 10 wherein the system further comprises an archiving module to archive the multiple patient records on their creation, with the communication module transmitting medical information from the patient records in the current patient database to an archive database.

12. An electronic health record management system as claimed in claim 11 wherein the archiving module is further to determine according to archiving criteria whether information on a particular patient medical encounter is to be deleted from the current patient database.

13. An electronic health record management system as claimed in any one of claims 1 to 12 wherein the system further comprises a query module to obtain information from the current patient and/or archive database; the communication module being configured to receive from a health care service provider a patient health enquiry specifying information to be retrieved, and, once obtained by the query module from the current patient database and/or the archive database, to transmit the information to the health care service provider.

14. An electronic health record management system as claimed in any one of claims 1 to 13 wherein the communication module is further to receive a patient update record from a health care service provider, wherein the patient update record comprises a unique patient identifier in order to identify the patient's patient record in the current patient database; and the record building module is to update the identified patient record with data contained in the patient update record.

15. An electronic health record management system as claimed in claim

14 wherein the health care service provider is to register with the system prior to sending a patient update record.

16. An electronic health record management system as claimed in claim

15 wherein the health care service provider is identified through an identity number of the health care service provider.

17. An electronic health record management system as claimed in claim 15 or 16 wherein, during a registration process, the health care service provider is allocated a unique service provider identifier which is linked with personal, practice and professional information of the service provider.

18. An electronic health record management system as claimed in any one of claims 13 to 17 wherein the patient health enquiry or the patient update record received is associated with a mobile telephone number of a health care service provider from which it was received.

19. An electronic health record management system as claimed in any one of claims 14 to 17 wherein the patient update record received from a health care service provider is received as a message, through a web page interface, or any other suitable communication means together with the unique patient identifier and an encounter code which identifies the type of patient encounter to be updated or logged against the patient record in the current patient database.

20. An electronic health record management system as claimed in claim 19 wherein the record building module accesses tables in the protocol module enabling the patient record to be appropriately updated according to the encounter code.

21. An electronic health record management system as claimed in claim 19 or 20 wherein the encounter code is a diagnosis code identifying an illness with which a patient has been diagnosed, a code identifying a patient's medication, a procedure code identifying a procedure to be performed or performed on a patient, an allergy code identifying an allergy of the patient, a pre-existing medical condition code or the like.

22. An electronic health record management system as claimed in claim 19 or 20 wherein the encounter code is a service payment code.

23. An electronic health record management system as claimed in 22 wherein, in the event that a service payment code is received, the system comprises a payment module which is to perform a validation of the unique patient identifier against records of a medical aid scheme to confirm the membership and benefits of the patient.

24. An electronic health record management system as claimed in 23 wherein the payment module is to generate a patient medical claim message to be transmitted by the communication module to the medical aid scheme for processing and payment.

25. An electronic health record management system as claimed in any one of claims 1 to 24 further comprising a reporting module, accessible by a health care service provider and/or an authorised third party, the reporting module to generate reports from the various patient records stored in the current patient database and/or the archive database.

26. A method of creating, maintaining and utilising an electronic health record comprising:

receiving patient medical encounter files from at least one third party database server; providing a predefined rule set determining data fields for a generated patient record;

parsing the received patient medical encounter files to obtain patient data and associated medical encounter data from the medical encounter files in accordance with the rule set; and

storing the obtained data associated with a particular patient in the predetermined fields for the patient record, thereby creating a current patient database with multiple patient records, each patient record to comprise information on multiple medical encounters of the patient.

27. A method as claimed in claim 26 wherein the data is stored in the predetermined fields in accordance with a universal standard relating to the practice are of the third party responsible for the third party database server.

28. A method as claimed in claim 26 or claim 27 wherein the patient medical encounter files are received from the third party database server periodically.

29. A method as claimed in any one of claims 26 to 28 further comprising first verifying information received in the patient medical encounter files against external verification records maintained by validation entities on receipt of a patient medical encounter file.

30. A method as claimed in claim 29 wherein, in the event that the verification fails, the method comprises generating an exception report and transmitting the report to the third party database server for further processing or correction.

31. A method as claimed in any one of claims 26 to 30 further comprising, prior to creating a patient record in the current patient database, receiving a consent notification from a health care service provider or from the third party database server confirming that a signed patient consent form has been obtained authorising the storage and distribution of the patient medical encounter record.

32. A method as claimed in any one of claims 26 to 31 further comprising archiving the multiple patient records on their creation by transmitting medical information from the patient records in the current patient database to an archive database.

33. A method as claimed in claims 32 comprising determining according to archiving criteria whether a particular patient medical encounter record is to be deleted from the current patient database and deleting a patient medical encounter record which satisfies the archiving criteria.

34. A method as claimed in any one of claims 26 to 33 further comprising:

obtaining the requested information from the current patient and/or archiving database; and

transmitting the information to the health care service provider.

35. A method as claimed in any one of claims 26 to 33 further comprising:

updating the identified patient record in the current patient and/or archiving database with data contained in the patient update record.

36. A method as claimed in claims 35 wherein the patient update record received from a health care service provider is received as a message, through a web page interface, or any other suitable communication means together with a unique patient identifier and an encounter code which identifies the type of patient encounter to be updated or logged against the patient record in the current patient database.

37. A method as claimed in claims 36 wherein the encounter code is a diagnosis code identifying an illness with which a patient has been diagnosed, a code identifying a patient's medication, a procedure code identifying a procedure to be performed or performed on a patient, an allergy code identifying an allergy of the patient, a preexisting medical condition code or the like.

38. A method as claimed in claims 37 wherein the encounter code is a service payment code.

39. A method as claimed in claims 37 further comprising performing a validation with the unique patient identifier against records of a medical aid scheme to confirm the membership and benefits of the patient.

40. A method as claimed in claims 39 further comprising generating a patient medical claim message and transmitting the patient medical claim message to the medical aid scheme for processing and payment.

41. A method as claimed in claims 40 further comprising sending a notification to the health care service provider to confirm that the patient medical claim is being processed or to advise on the status of a medical claim.