WO2013181564A1

WO2013181564A1 - Method and system to generate and manage medical communications

Info

Publication number: WO2013181564A1
Application number: PCT/US2013/043659
Authority: WO
Inventors: Steven Charles Cohn
Original assignee: Steven Charles Cohn
Priority date: 2012-05-31
Filing date: 2013-05-31
Publication date: 2013-12-05

Abstract

A computerized method of generating a medical communication is disclosed, which includes receiving at least one of: (a) a medical communication including a plurality of data fields, the plurality of data fields storing medical data associated with a patient, the data fields corresponding to data storage entities in a medical record storage system, (b) notification that an ordinary communication was received that pertains to medical care of the patient, and (c) notification that an ordinary communication was transmitted that pertains to medical care of the patient. The method further includes providing a graphical user interface (GUI) having a plurality of data fields that correspond to the data storage entity in the medical record storage system; receiving medical data associated with the patient in the plurality of data fields of the GUI; and storing the received data in the data storage entities of the medical record storage system.

Description

METHOD AND SYSTEM TO GENERATE AND MANAGE MEDICAL

COMMUNICATIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 61/654,080, filed on May 31, 2012, which is incorporated by reference herein in its entirety. This application further incorporates by reference herein in its entirety the disclosure set forth in United States Patent Application No. 12/499,468, filed on July 8, 2009.

BACKGROUND

Technical field

[0002] The presently disclosed embodiments are directed to generating and managing medical communications associated with medical treatment of a patient.

Brief Discussion of Related Art

[0003] Communications, such as telephone calls, short message service (SMS) messages, and emails, can include information that is relevant to medical treatment. The communication may include information that is related to the patient's medical history, current treatment, a medical encounter that should be billed to a payor, evidence related to malpractice or proper practice. The information is not stored or accessible in a usable fashion. It may not be recorded. It is not structured, searchable, sortable, or formatted for generating a structured medical communication in response.

[0004] Accordingly, there exists a need for medical communications that are stored in a structured format in order that the information included in the communication and any response is searchable and sortable.

SUMMARY

[0005] The disclosure is directed to a method of generating a medical communication, including receiving, by a processing device, at least one of: (a) a medical communication including a plurality of data fields, the plurality of data fields storing medical data associated with a patient, the data fields corresponding to data storage entities in a medical record storage system, (b) notification that an ordinary communication was received that pertains to medical care of the patient, and (c) notification that an ordinary communication was transmitted that pertains to medical care of the patient.

[0006] The method further includes providing, by the processing device, a graphical user interface (GUI) having a plurality of data fields that correspond to the data storage entity in the medical record storage system; receiving, by the processing device, medical data associated with the patient in the plurality of data fields of the GUI; and storing, by the processing device, the received data in the data storage entities of the medical record storage system.

[0007] The disclosure is further directed to a computing system to generate a medical communication that includes a processing device and a storage device to store instructions that, when executed by the processing device cause the processing device to perform operations including receiving at least one of: (a) - a medical communication including a plurality of data fields, the data fields storing medical data associated with a patient, the data fields corresponding to data storage entities in a medical record storage system, (b) - notification that an ordinary communication was received that pertains to medical care of the patient, and (c) - notification that an ordinary communication was transmitted that pertains to medical care of the patient.

[0008] The operations further include providing a GUI having a plurality of data fields that correspond to the respective data storage entities in the medical record storage system;

receiving medical data associated with the patient in the plurality of data fields of the GUI; and storing the received data in the data storage entities of the medical record storage system.

[0009] The disclosure is further directed to a computer-readable medium storing instructions that, when executed by a processing device, perform operations including: receiving at least one of: (a) a medical communication including a plurality of data fields, the plurality of data fields storing medical data associated with a patient, the data fields corresponding to data storage entities in a medical record storage system, (b) notification that an ordinary communication was received that pertains to medical care of the patient, and (c) notification that an ordinary communication was transmitted that pertains to medical care of the patient. The operations further include providing a GUI having a plurality of data fields that correspond to the data storage entity in the medical record storage system, receiving, by the processing device, medical data associated with the patient in the plurality of data fields of the GUI; and storing, by the processing device, the received data in the data storage entities of the medical record storage system.

[0010] In addition to the above aspects of the present disclosure, additional aspects, objects, features and advantages will be apparent from the embodiments presented in the following description and in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings constitute a part of this disclosure and include examples, which may be implemented in various forms. It is to be understood that in some instances, various aspects of the disclosure may be shown exaggerated or enlarged to facilitate understanding. The teaching of the disclosure can be readily understood by considering the following detailed description in conjunction with the accompanying drawings.

[0012] FIGS. 1-5 show a visual representation of a graphical user interface (GUI) that a first medical practitioner uses to enter and transmit a first medical communication, in accordance with an aspect of the disclosed embodiments;

[0013] FIGS. 6-10 show a visual representation of a GUI that a second medical practitioner uses to enter and transmit a second medical communication based on the first medical communication generated by the first medical practitioner, in accordance with an aspect of the disclosed embodiments;

[0014] FIGS. 11-13 show a visual representation of a GUI that a medical practitioner uses to enter and transmit a request for transport of a patient based on at least one previously generated medical communication, in accordance with an aspect of the disclosed

embodiments;

[0015] FIG. 14 shows a flowchart of a method of generating the second medical communication based on the first medical communication, in accordance with an aspect of the disclosed embodiments;

[0016] FIG. 15 shows a flowchart of a method of generating a medical communication from an ordinary communication; and [0017] FIG. 16 shows a schematic representation of a medical record storage system that stores medical communications, in accordance with an aspect of the disclosed embodiments.

DETAILED DESCRIPTION

[0018] A system and method are provided to generate a medical communication that is stored in a medical record storage system. The medical communication is prepared by a medical practitioner operating a computing device, such as a smartphone. The medical

communication can include notes classified as subjective, objective, assessment, and plan notes (SOAP notes) about a medical encounter with the patient. The SOAP note can include data, such as diagnostic codes and codes that can be used for medical billing. The data is integrated into the medical record storage system and is related to other data already entered for that patient. For example, a diagnostic code entered into the SOAP note is related to other instances of the same diagnostic code for that patient, and can further be related to a genealogy that corresponds to that diagnostic code. Furthermore, a medical bill can be generated based on the medical communication.

[0019] The medical communication is transmitted to a second medical practitioner. The second medical practitioner can respond using a computing device, such as a smartphone, with a second medical communication that can also include SOAP notes and be stored in the medical record storage system. The second medical practitioner's generation of the second medical communication can be a second medical encounter that includes entry of a diagnosis and codes that can be used for medical billing. Thus, a medical bill can be generated based on the second medical communication. Additionally, a medical bill can be generated based on the first medical communication when the first medical communication is generated by a licensed practitioner, such as a medical doctor (MD), nurse practitioner (NP), or physician's assistant (PA). In the example shown, the first practitioner is a nurse that is not licensed to generate medical bills, and a medical bill is not generated for the first medical

communication.

[0020] All or a portion of the second medical communication can be populated using data included in the first medical communication. An indicator is associated with the populating data to indicate that it was originally generated by a third party. The indicator is displayed in association with the populating data. The second medical practitioner can perform an action that removes or hides the indicator, indicating that s/he has accepted the data from the third party (the first medical practitioner) as reliable and correct.

[0021] In one example, the first medical practitioner is a nurse and the second medical practitioner is a doctor. The nurse sends the doctor a first medical communication to alert the doctor that an action is needed by the doctor. The nurse provides SOAP notes in the medical communication. The nurse's medical encounter is not a separately billable medical encounter. It is stored in the medical record storage system in association with the nurse. The doctor receives the medical communication and generates a second medical communication which can include a diagnosis and actions to be taken, such as medical tests or a transfer of the patient (e.g., from a nursing home facility to a hospital). The doctor's medical

communication can be populated with the nurse's information that s/he gathered when s/he examined the patient. Quotations delimit the populating information in the doctor's medical communication that was entered by the nurse to indicate that they were originally entered by a third party (here, the nurse). If the doctor has ordered a transfer of the patient, a special Transfer Request Form medical communication is generated and communicated to selected parties. The Transfer Request Form can also be populated with information from the nurse and/or doctor's medical communication. A medical bill can be generated for the doctor's medical encounter. The medical data from the medical communications is integrated into the medical records storage system and the patient' s medical history.

[0022] FIGS. 1-5 show a series of screen shots of example graphical user interface (GUI) screens 101-105 for creating or updating a medical communication related to a medical encounter. A medical practitioner can operate a computing device (e.g., a smartphone or tablet or laptop computer) to access user screens 101-105 to document a medical encounter, such as a medical treatment or examination of a patient. The medical communication is stored as a medical encounter record in a medical record storage system. Additionally, the medical communication can further be transmitted to and accessed by one or more computing devices (e.g., a smartphone or tablet or laptop computer) operated by a second medical practitioner. Additionally or alternatively, data stored in the medical encounter record can be accessed via the medical record storage system by an authorized user.

[0023] In the present example, the medical communication and medical encounter record are formatted as a traditional SOAP note, where SOAP is used to refer to the data categories Subjective, Objective, Assessment, and Plan herein. The format of the medical communications is not limited to a SOAP format, and other formats are envisioned. A medical practitioner, such as a nurse, may have a medical encounter with a patient in which the medical practitioner interviews the patient to obtain subjective information and record the information using one or more of the GUI screens 101-105. This data is stored in the medical encounter record as Subjective Data. During the same medical encounter, the medical practitioner may also examine the patient for obtaining and recording objective information. The medical practitioner enters the objective information using one or more of the GUI screens 101-105. This data is stored in the medical encounter record as Objective Data.

[0024] As part of the same medical encounter, the medical practitioner may also make an assessment of the patient' s medical condition, and develop a plan, such as a medical treatment (e.g., recommending pharmaceuticals, surgery, or further testing). The medical practitioner enters assessment information and plan information using one or more of the GUI screens 101-105. This data is stored in the medical encounter record as Assessment Data and Plan Data, respectively.

[0025] Each GUI screen 101-105 includes a plurality of data entry fields 110, which may include a text field, a menu (e.g., drop-down or pull-down), a browser window, etc. via which data can be entered. Screen 101 provides data entry fields 110 for entering the name of the first medical practitioner. The data entry fields 110 each correspond to a data storage entity in the medical record storage system or a reference to a data storage entity in the medical record storage system. The data storage entity is an entity that stores data, and can be, for example, a data field, an object, a data record, etc. A reference to a data storage entity can be, for example, an address of the data storage entity, a pointer that points to an address of the data storage entity, a label or identification that identifies the data storage entity, etc. In one embodiment the reference to a data storage entity is implemented by the medical

communication referencing or identifying a medical encounter record stored in the medical record storage system, and the referenced data storage entity is a data storage entity that corresponds to the data entry field 110 of the medical communication. Medical data about a patient can include subjective, objective, assessment, and plan data. Additionally, it can include data related to medical services, such as data about billing, payment, legal matters, and medical referrals.

[0026] In the current example, the medical practitioner is a first practitioner who is a nurse by the name of Jane Smith. The patient is named Barbara Wells. The nurse, Jane Smith, operates a computing device, which in the present example is a smartphone, but is not limited thereto. The nurse's smartphone executes medical communication software, which in the present example is an app, but is not limited thereto. The nurse's medical communication app is configured to cause the nurse's smartphone to generate the GUI screens 101-105. The screens 101-105 are configured for a nurse to enter SOAP notes. It is envisioned that each practitioner, such as a nurse, doctor, and/or therapist, can use a medical communication app that is configured or customized for their specific practice or specialty. The GUI screens provide for generating a medical communication can be customized for the person, and further customized for their specific practice and/or specialty.

[0027] Each screen 101-105 includes a screen menu 112 that allows the user the ability to select a screen from among the screens 101-105 to be the active screen. Additionally, navigation soft buttons 114 are provided for moving to a previous screen or next screen, which allows the user to select the active screen. The active screen is displayed for viewing and/or editing, and its label is highlighted in screen menu 112. Each screen includes a data entry area 116 that includes one or more data fields 110 that can be accessed by the user when the screen is active for viewing, editing and/or data entry.

[0028] The information entered in screens 101-105 that is associated with a medical encounter is stored in a medical record system that includes a database and a database management system (DBMS). The data can be entered into the database as it is entered into the medical communication. Alternatively, the data can be entered into the database only upon completion and/or transmittal of the medical communication. The database and DBMS may be implemented as an object oriented, relational object oriented, or relational database system, or other database system that is known by those skilled in the art. The information collected for a particular medical encounter is stored in the database as a medical encounter record or as associated with a specific medical encounter having an associated identifier. In the current example, the data associated with each medical encounter is associated with a unique medical encounter record that has a unique identifier or combination of identifiers. It is also envisioned that a series of medical encounters may be stored in a single medical encounter record, with data, e.g., attributes, specifying the different medical encounters.

[0029] A medical encounter is an encounter between a patient and a medical practitioner that can provide medical services, for example, an emergency medical technician (EMT), nurse, doctor, PA, dentist, therapist, nutritionist, psychologist, acupuncturist, aid to one of the above, etc. Medical services can include, for example, interviewing, examining, diagnosing, and/or treating a patient. A medical communication and medical encounter record may also be generated for a medical encounter that does not include medical services but is related to medical services provided or to be provided. For example, it may important to record or respond to a communication to or from a person who works with social services, the legal profession, the patient's insurance, or the patient's school or place of employment, where the communication is about the patient's medical services.

[0030] A medical encounter can be conducted by more than one medical practitioner, such as a doctor and a nurse. In the present example, a single medical encounter record can be generated when more than one medical practitioner are treating a patient at the same location. Alternatively, separate, but related, medical encounter records can be generated by the different medical practitioners. Information is associated with each of the related medical encounter records, such as a link or an attribute, to indicate that the medical encounter records are related to one another because they are associated with the same medical encounter.

[0031] When two medical practitioners are treating a patient at the same time, but at two different locations, such as in telemedicine or by providing a remote consultation during the medical encounter (e.g., by telephone and/or a computerized meeting with audio/video), each medical practitioner can generate a different medical encounter record. Again, information is associated with at least one of the medical encounter records, such as a link or an attribute, to indicate that the medical encounter records are associated with the same medical encounter.

[0032] Information associated with a medical encounter record can include the type of medical encounter (e.g., office visit, phone call from patient location, phone call at location remote from patient, bedside visit, telemedicine visit, etc.); the type of medical encounter record (e.g., sharing information for updating another practitioner, practitioner generating an alert, practitioner receiving an alert, emergency patient transfer, etc.); a timestamp (date and time) that the medical encounter record occurred and/or was entered, which may include a beginning and end time; identification of the medical practitioner(s) providing input recorded in the medical encounter record; location of the practitioner during the medical encounter; location of the patient during the medical encounter; link or relationship to a previous or simultaneous medical encounter, etc. The data entered into data entry areas 116 and/or data fields 110 is stored in the medical communication and in the medical record storage system in association with a medical encounter record. The information associated with the medical encounter record can be associated with some or all of data entered into data fields 110, and is herein referred to as attributes.

[0033] Entered data (e.g., information entered via data entry areas 116) may have additional associated data, such as attributes, links, or related data. Such associated data includes, for example, identification of the associated medical encounter record; a timestamp indicating when the data was captured and/or entered; identification of the medical practitioner that originally captured the data that was entered; the method of capturing data (e.g., by measuring, interviewing, observing); the timestamp of data capture; the medical professional level, supervisory level, and/or authority rights level of the medical practitioner that originally captured the data (e.g., nurse, attending doctor, resident, etc.); the location of the medical practitioner that captured the information relative to the patient (e.g., remote or by direct contact with the patient (e.g., on-site)); physical location of the patient at the time of data capture; physical location of the capturing medical practitioner at the time of the data capture; etc.

[0034] Such associated data may also identify relationships between entered data in different medical communications, such as by identifying the related entered data, medical communication its associated information (e.g., timestamp and associated medical practitioner). For example, associated data may be provided for test results in assessment data of a medical communication that identifies that medical practitioner that ordered the test and the timestamp of the order as recorded in plan data of a previous medical communication.

[0035] In the current example, a second medical practitioner, such as a doctor, or a specialist, is notified consulted with reference to a first medical encounter conducted by a first medical practitioner. In such instances, the second medical practitioner can be present during the first medical encounter, or consulted remotely by transmission or notification of the medical encounter record generated by the first medical practitioner in association with the first medical encounter. The second medical practitioner's encounter can be a telemedicine encounter in which the doctor provides a medical service from a remote location, which may include using technology to view the patient and/or control a device that interacts with the patient. The second medical practitioner's encounter may be concurrent with the first medical encounter (e.g., during the time that the first medical encounter with the first medical practitioner occurred), or may be subsequent thereto. The second medical practitioner's encounter is referred to herein as a second medical encounter, but it may temporally overlap with the first medical encounter.

[0036] With reference to FIG. 1, screen 101 is used for entering subjective information into the first medical practitioner's medical encounter note, which in the present example is formatted as a nurse's SOAP note. The data entry area 116 in screen 101 includes a data entry field 110 identifying the nurse carrying out the medical encounter and subjective information entered by the nurse. Examples of subjective information include personal data and medical history gathered from the patient, such as age, address, occupation, etc. Some or all of the personal data may be gathered from personal data already stored for the patient, and can be verified and updated during the medical encounter. The subjective information can also include the patient' s report (or the report of a parent or caretaker) of the patient' s chief complaints, if any; how the patient is currently faring; how the patient has been faring since his/her last medical encounter; the patient' s report of his/her compliance with prescribed or recommended treatment regimens (e.g., taking medicine, following up with a specialist, getting physical therapy, etc.). The subjective data may be entered in a data entry field 110 as free text, and/or multiple data entry fields 110 having check boxes, menus, browsers, and the like, may be provided for entry of different aspects of the subjective information.

[0037] Information may be entered into data entry fields 110 by populating them from information stored in the medical records storage system, or by user entry, such as by using a user input device (e.g., keyboard, touch screen, etc.). When a medical encounter is conducted using audio/video input, such as through a telephone call or telemedicine, the audio or video data can be input and stored in association with the medical encounter record. The audio/video data may be converted into text data for storage as text, such as by transcribing or performing optical character recognition (OCR).

[0038] With reference to FIG. 2, the data entry area 116 in screen 102 includes a data entry field 110 for entering an image of the patient into the first medical practitioner's SOAP note. The image may be captured by the medical practitioner or supplied by the patient.

[0039] With reference to FIG. 3, screen 103 is provided for entering objective data into the first medical practitioner's SOAP note. The objective data includes data about what the medical practitioner has observed, including, for example, vital signs; results of ordered tests; observations of the patient's physical, emotional, and psychological state; results of examination performed during the medical encounter, such as bony and soft tissue palpation and breathing sounds heard with a stethoscope; etc. Screen 102 includes, for example, several data entry fields 110 into which vital sign data and other objective data is entered. A time stamp data entry field is also provided to indicate the time that the vital signs were captured.

[0040] With reference to FIG. 4, screen 104 is provided for entering assessment and plan data into the first medical practitioner's SOAP note. In the example shown, data entry area 116 includes a data entry field 110 for entering assessment data and a data entry field 110 for entering plan data, both shown as text boxes for entering free text. It is envisioned that data entry fields 110 for entering assessment and plan data could include check boxes, menus, and the like for entering the data.

[0041] With reference to FIG. 5, screen 105 is provided for notifying another party about the medical encounter, such as to alert or inform a primary care provider, e.g., the patient's primary care doctor. The data entry area 116 in screen 105 includes data entry fields 110 for entering transmit data, which can include, for example, selection of one or more recipients of the alert or notification; the communication means (e.g., email and email address or SMS message and phone number); and an urgency level of the alert or notification. Some of the data entry fields 110 may be automatically populated. For example, a doctor may require that every SOAP note, or certain instances (e.g., urgent ones) of SOAP notes, be transmitted to him/her, and his/her name and contact information for facilitating the communication are automatically entered. In another example, one or more relatives that have authority within the privacy laws can request that they be notified each time communication of a medical encounter occurs or for certain types of medical encounters, e.g., those with a high urgency level. Their contact data can be automatically entered into the appropriate data entry field 110. A data entry field 110 is provided that indicates the urgency of the medical encounter alert or notification. The urgency level may be selected by the nurse, or it may automatically be set to a high-urgency level based on data entered in screens 101-104.

[0042] A checkbox 160 is provided that can be checked when the first medical

communication requests that the recipient respond with a medical communication that requests an action, such as requests a patient transfer, orders a medical test or treatment, or notifies an insurance company. A checkbox 162 is provided that can be checked when the first medical communication requests that the recipient reply to the first medical practitioner with a return second medical communication. [0043] Activation of a Finish/Send button 118 included with the navigational soft buttons 114 causes the medical communication to be transmitted, e.g., as a notification or alert of the first medical encounter. Data associated with the first medical encounter, including the data entered in screens 101-104 that forms the first medical practitioner's SOAP note, is transmitted to the selected recipients using the designated communication means.

[0044] A second medical practitioner can receive a medical encounter notification or alert from a first medical practitioner based on a medical encounter conducted by the first medical practitioner. In the current example, the first medical practitioner, Nurse Jane Smith, sent a medical encounter alert to the second medical practitioner, Dr. Frank Plotz. The doctor operates a computing device, which in the present example is a smartphone, but is not limited thereto. The doctor' s smartphone executes medical communication software, which in the present example is an app, but is not limited thereto. The doctor's medical communication app is configured to cause the smartphone to generate the GUI screens configured for the doctor to enter a medical communication, e.g., including SOAP notes.

[0045] FIGS. 6-13 show second encounter GUI screens 201-208 that are generated in response to receipt by the second medical practitioner of the medical encounter alert associated with the first medical encounter. A portion, or all, of the information stored in the first medical encounter record is used to populate corresponding data entry fields 110 in second encounter GUI screens 201-208. The first and second encounters described are for the purposes of providing an example, and are not intended to be limiting. The first and second encounters can be any series of encounters in which the first encounter is earlier than the second encounter.

[0046] Information from the first medical communication stored in the first medical encounter record that is used to populate data entry fields in the GUI screens associated with the second medical communication is referred to as populating information. Populating information can be entered automatically by the second practitioner' s computing device and software app. Populating information from the first medical communication into the second medical communication includes extracting data from the first medical communication or from the first medical encounter record and inserting it into the appropriate fields of the second medical communication. Alternatively, populating information can be entered manually by the second medical practitioner, such as by typing in the data or importing the data from other medical records, cutting and pasting from a previous medical communication, or by voice entry that is converted into text. The populating information is associated (e.g., via a link, a relationship, or attribute data) with the source of the information, which in the current example is the first medical practitioner. Additionally, the populating information is associated with the source's location at the time of the first medical encounter. The source's location information can indicate whether the first practitioner was remote from the patient or on site, and identify the location of the medical encounter (e.g., name of the facility, geolocation or address of emergency treatment, or patient's home).

[0047] The populating information can also be associated with information associated with the first medical record, such as the timestamp (e.g., date and time) that the populating information was captured or entered in the first medical encounter GUI screens 101-105. The populating information may also be associated with the first medical encounter record and each medical encounter record it is populated into. It is possible for different data entry fields in second encounter GUI screens 201-208 to be populated from different previous medical encounter records and to have different associated source and timestamp information.

[0048] The medical record storage system can be a universal medical record (UMR) system, such as the medical history system described in U.S. Publication No. 2011/0010195 which has been incorporated by reference, herein. Some or all of the populating information can be accessed from the UMR. In another example, some or all of the populating information is accessed from one or more electronic medical records (EMR) that are accessed by the second medical practitioner's smartphone. The EMRs can be stored in the medical record storage system, in different storage system, in a remote computing device, and/or transmitted to the second medical practitioner's smartphone and stored by his/her smartphone. In one example, the EMR is a continuity of care document (CCD), or the like, that uses an electronic document exchange standard for sharing patient information. The data provided by the CCD can be integrated into the UMR, or alternatively may not he integrated therein.

[0049] The display of the populating information can include an indicator 210 that indicates that the information is derived from an encounter performed by a different medical practitioner or a subordinate medical practitioner. The indicator 210 in the current example is a set of quotation marks that delimit the populating information. The indicator 210 can thus indicate when the populating information was generated or entered by a third party, a subordinate third party, an unsupervised subordinate third party, and/or a third party at a remote location. One or more indicators 210 can include, for example, highlighting the populating information using a particular color or graphic, a particular symbol displayed next to the populating information, blinking the populating information, etc.

[0050] In addition to the indicators 210, populating information attributes are provided that are associated to the populating information as attributes, relationships, links, or the like. The populating information attributes can include, for example, an identification of the location of the first medical practitioner at the time of the first medical encounter; information associated with the first medical record, such as the timestamp (e.g., date and time) that the populating information was captured or entered in the first medical encounter GUI screens 101-105; an identification of the first medical encounter record; and an identification of each medical encounter record the populating information is populated into. The populating information attributes can be displayed near the populating information, or only appear when the user requests display thereof, such as by pointing to with a cursor, or highlighting the populating information or requests.

[0051] Rules can be established that govern when populating information from the first medical communication generated by the first medical practitioner is incorporated into the second medical communication and the corresponding second medical encounter record as third party data that is displayed with a corresponding indicator 210, or is accepted into the medical communication and the corresponding medical encounter record as original data, e.g., as if it had been entered directly. An example rule treats the populating information as third party data when the first medical practitioner is subordinate to (e.g., has a lower ranking) or equal in ranking to the second medical practitioner. A ranking protocol that designates a ranking for each practitioner can be developed and customized. A nurse is ranked lower than a doctor, because the doctor can make orders for medical services that the nurse must perform. Another example rule treats the populating information as original data when the first practitioner has a rank that is higher than the rank of the second practitioner.

[0052] In the present example, ranking is immaterial. The rule applied indicates information sent in a first medical communication by a first practitioner to a second practitioner in a second medical communication is treated as third party data, regardless of rankings of the parties. When the second practitioner sends a third medical communication back to the first medical practitioner, information entered by the second practitioner is treated as third party data, but information entered by the first practitioner is not. [0053] Still, in an embodiment, whether treated as third party data or not, data entered into each data entry field 110 can have attribute data that indicates the party that entered the data, although the attribute data is not displayed unless requested.

[0054] Rules can also be established that govern which data category, Subjective, Objective, Assessment, and Plan the populating information is populated into. In the example shown, Subjective data from the first medical communication is populated as Subjective data in the second medical communication, and so forth for the other categories. In another embodiment, an example rule may require that a subordinate practitioner' s assessment and plan data be populated into a medical communication of a higher ranking practitioner as subjective data. The rules can be customized and altered by an administrator.

[0055] Once GUI screens 201-208 are populated with information from a previous medical encounter record, the second medical practitioner may enter data into screens 201-208.

Screens 201-208 are provided with a screen menu 112 and navigation soft buttons 114 for moving between screens 201-208 for viewing, accessing, and/or editing the screens. Data areas 116 and data entry fields 110 can be populated with populating information or the second medical practitioner can enter data into them. The second medical practitioner can delete populated information and/or replace it with directly entered information.

[0056] With reference to FIG. 6, screen 201 is provided for entering subjective data into the second medical practitioner' s medical encounter note, which in the present example is formatted as a doctor's SOAP note. In the example shown, data entry area 116 includes a data entry field 110, shown as a text box for entering free text, for entering subjective data. It is envisioned that data entry fields for entering subjective data could provide check boxes, menus, and the like for entering the data. The first practitioner's subjective data 212 is populated into data entry field 110 and delimited by an indicator 210, here shown as a set of quotation marks. The indicator 210 indicates that the populated subjective data 212 was not generated by the second medical practitioner, but was generated by a third party, which in the example shown is the first practitioner. Additionally, attribute data associated with the populated subjective notes can be displayed. This data can pop-up when the user places the cursor over the populated information.

[0057] The second medical practitioner can enter his/her own subjective data 214 as well, but this data is not delimited with indicator 210. When the populated subjective data 212 and the presently entered subjective data 214 are displayed side-by-side, they are separated by a separator 216.

[0058] Additionally, when populated subjective data 214 is entered, an Accept/Reject button 218 and checkboxes 219 are provided that allows the second medical practitioner to accept or reject populating information for which an associated checkbox 219 is checked. A separate checkbox 219 may be provided for each data entry field 110 that populating data was entered into, thus allowing independent acceptance or rejection of populating information for each data entry field 110. The Accept/Reject button 218 can be set to accept (accept mode) or reject (reject mode) populating data, with the action acting on populating information in a data entry field 110 whose check box is checked.

[0059] When populating information is accepted, the checkbox remains in an unchecked state and the indicator 210 (e.g., quotation marks) is removed, indicating that the second medical practitioner has accepted the information into his/her SOAP note as trustworthy and correct. Thus, the existence of the blank checkbox 219 indicates that the source of the information was a third party, and that the information has been accepted. The attribute data associated with the accepted populating information is not removed in the present example, and can still be accessed. Additionally, the acceptance is reversible, such as by selecting the checkbox and toggling the Accept/Reject button 218 in the accept mode. In another embodiment, acceptance of populating information causes its attribute information to be removed from the medical communication, although it can be retained in the second medical encounter record. A method can be provided to remove the attribute information from the second medical encounter record as well. This can be configured to be reversible or nonreversible. When the Accept/Reject button 218 is activated to select reject, the populating information is removed. This too can be configured to be reversible or nonreversible.

[0060] In another embodiment, populating information can be accepted based on the type of medical communication or an action performed by the second medical practitioner, such as entering plan data. A type of medical communication, for which populating information may be automatically entered, includes the medical communication related to a telemedicine encounter in which the second medical practitioner is remote from the patient and is not actually examining the patient, but is in communication with the first medical practitioner during the examination, such as by telephone or video conferencing. The treatment of populating information and its acceptance and rejection are provided by way of example, and are not limited to the embodiments described. Other rules and techniques of treating the populating information can be used. The rules can be configured by an administrator.

[0061] With reference to FIG. 7, screen 202 is provided for entering objective data into the second medical practitioner' s medical encounter note, which in the present example is formatted as a doctor's SOAP note. In the example shown, data entry area 116 includes several data entry fields 110 for entering objective data, including vital signs data. The first practitioner's objective data 220 is populated into data entry fields 110 of screen 202, and is delimited by indicator 210, here shown as a set of quotation marks. The indicator 210 indicates that the populated objective data 220 was not generated by the second medical practitioner, but was generated by a third party, which in the example shown is the first practitioner. Additionally, attribute data associated with the populated objective data 220, such as the name of the practitioner that entered the data, can be displayed. A timestamp 222 is provided that indicates the time that the objective data was entered. The timestamp associated with the data entered by a third party is also delimited by indicator 210 to indicate that the timestamp is associated with third party data. Accept/Reject button 218 and checkboxes 219 are provided in association with the populated objective data 220 to allow the second medical practitioner to accept or reject them. The timestamp 222 is not provided with a checkbox, but is rather rejected or accepted together with the populated objective data 220 it is associated with.

[0062] The second medical practitioner can enter his/her own objective data as well, although none are shown in the example screen 202. These would not be delimited with indicator 210.

[0063] With reference to FIG. 8, screen 203 is provided for entering assessment data into the second medical practitioner' s medical communication, which in the present example is formatted as a doctor's SOAP note. In the example shown, data entry area 116 includes a data entry field 110 for entering assessment data, with the data entry field 110 shown as a text box for entering free text. It is envisioned that data entry fields 110 for entering subjective data could provide check boxes, menus, and the like for entering the data.

[0064] The first practitioner's assessment data 230 is populated into data entry fields 110 of screen 203, and is delimited by indicator 210, here shown as a set of quotation marks. The indicator 210 indicates that the populated assessment data 230 was not generated by the second medical practitioner, but was generated by a third party, which in the example shown is the first practitioner. In the example shown, the populated assessment data 230 is entered as free text and delimited by indicator 210. Additionally, attribute data associated with the populated assessment notes 230 can be displayed. This data can pop-up when the user places the cursor over the populated information. Accept/Reject button 218 and checkboxes 219 are provided in association with the populated assessment data 230 that allows the second medical practitioner to accept or reject them. Screen 203 shows that second medical practitioner is about to reject the populated assessment data 230.

[0065] The second medical practitioner can enter his/her own assessment data 232 as well. These are not delimited with indicator 210. In the example shown, the assessment data 232 was selected from a menu of choices, and includes a diagnostic code, such as International Classification of Diseases (ICD) codes, World Health Organization (WHO) Codes, etc.

[0066] With reference to FIG. 9, screen 204 is provided for entering plan data into the second medical practitioner's medical encounter note, which in the present example is formatted as a doctor's SOAP note. In the example shown, data entry area 116 includes a plurality of data entry fields 110 for entering plan data, including data entry fields 110 that can accept free text data or codes data, such as by using a menu. The plan data that is entered specifies actions that are being taken. Some of the actions may be set in motion by storing and/or transmitting the medical communication to another practitioner to notify him that an action needs to be taken.

[0067] The data entry fields allow entry of data specifying a variety of diagnostic tests, disposition statuses, patient education actions, reporting information specifying which referring doctors need response letters to keep them apprised, referral information, immunization actions, medications to be prescribed, and others.

[0068] The diagnostic tests can be specified by codes, such as current procedural terminology (CPT) codes, Healthcare Common Procedure Coding System (HCPCS) codes, and internationally recognized codes. The codes specify the diagnostic tests and also function as medical billing codes. Accordingly, when the medical encounter record associated with the medical communication is stored in the medical records system, a medical bill can be generated for each medical encounter documented with a medical encounter record.

[0069] Diagnosis codes and billing codes of a single medical communication or medical encounter record may be associated with one another, such as by attribute data. The medical communication, the medical encounter record and/or other data stored therein may also include attribute data that identifies diagnoses codes and/or billing codes included in the medical communication. This enables relating the medical communication and data stored therein with diagnoses codes and billing codes. Billing codes can be tracked and accounted for by using the billing codes as a reference code for retrieving information related to all, or selected, diagnoses and/or treatments. The disposition status can indicate a plan to continue to monitor or to transfer the patient. If a transfer of the patient is indicated, the second medical practitioner is prompted to generate a Transfer Request Form, described below with reference to FIGS. 11-13.

[0070] In the example shown, a textual entry from the first medical practitioner has been populated in a textual diagnostic data entry field 110. The second medical practitioner entered a variety of diagnostic tests using standardized codes, and has further ordered transfer of the patient to the emergency room for evaluation.

[0071] The first practitioner's plan data 240 is populated into data entry fields 110 of screen 204, and is delimited by indicator 210, here shown as a set of quotation marks. The indicator 210 indicates that the populated plan data 240 was not generated by the second medical practitioner, but was generated by a third party, which in the example shown is the first practitioner. In the example shown, the populated plan data 240 is entered as free text and delimited by indicator 210. Additionally, attribute data associated with the populated plan data 240 can be displayed. This data can pop-up when the user places the cursor over the populated information. Accept/Reject button 218 and checkboxes 219 are provided in association with the populated plan data 240 that allows the second medical practitioner to accept or reject them. Screen 204 shows that second medical practitioner is about to reject the populated plan data 240.

[0072] The second medical practitioner can enter his/her own plan data 242 as well. These are not delimited with indicator 210. In the example shown, the plan data 242 was selected from a menu of choices, and includes a diagnostic code.

[0073] With reference to FIG. 10, screen 205 is provided for notifying another party about the medical encounter and patient's status, such as to inform another medical practitioner that needs to be apprised or take action, and/or to inform one or more relatives that have authority within the privacy laws to be notified. The family member(s) may have requested notification of each communication or for certain types of medical events, such as a transfer of the patient.

[0074] The data entry area 116 in screen 205 includes data entry fields 110 for entering transmit data, which can include, for example, selection of one or more recipients of the alert or notification and the communication means (e.g., email and email address or SMS message and phone number). Some of the data entry fields 110 may be automatically populated, such as identifying a referring doctor that requires a report of all action, and family member(s) who have requested notification. Their name and contact information for facilitating the communication are automatically entered. Checkbox 160 is provided that can be checked when the first medical communication requests that the recipient respond with a medical communication that requests an action, such as requests a patient transfer, orders a medical test or treatment, or notifies an insurance company. Checkbox 162 is provided that can be checked when the first medical communication requests that the recipient reply to the first medical practitioner with a return second medical communication.

[0075] Activation of the Finish/Send button 118 causes the medical communication associated with the second medical encounter, including the data entered in screens 201-204 that form the second medical practitioner's SOAP note, to be transmitted to the selected recipients using the designated communication means.

[0076] The second medical practitioner' s computing device may be configured to respond to an ordinary incoming communication from a patient, such as phone call, SMS, or an email, by generating a responding medical communication and a corresponding medical encounter record. An "ordinary communication" refers to a communication that is not a medical communication generated by the medical communication app. The medical communication (or a prompt for creating one) can be generated upon request, automatically upon receipt, or automatically while a call is in progress. Similarly, a medical communication and corresponding medical encounter record (or a prompt for creating these) can be generated automatically or by request for outgoing ordinary communications. The second medical practitioner can accept or decline to use a prompt or a newly generated medical

communication.

[0077] In one embodiment, upon receipt of an ordinary incoming communication or generation or transmission of an ordinary outgoing communication, the medical communication app can recognize when a medical encounter is being initiated. This can be based on the identity of the source or target party of the ordinary communication, such as due to a history of interactions with that party, settings applied to the medical communication software, or a category that the source or target party belongs to, such as patient, medical practitioner colleague, lawyer, medical facility administrator, insurance company, etc.

[0078] Also, in one embodiment, the medical communication app can recognize when a medical encounter is in progress during an outgoing or incoming ordinary communication. The medical communication app may recognize content of the communication that indicates the occurrence of a medical encounter. Settings may be applied to the medical

communication app that designate certain words that should trigger generation of a medical communication. The practitioner may purposely say or type a certain word(s) during a communication that will trigger generation of a medical communication.

[0079] A medical practitioner may choose to generate a medical communication for communications with parties such as patients, other medical practitioners, family members of patients, hospital personnel, ambulance personnel, outpatient facility personnel, lawyers, etc. The generated medical communication can serve for documenting medical history, billable medical services, medical information needed by insurance companies, medical information that may be useful for legal issues such as malpractice claims, etc.

[0080] Whether by request or automatically generated, the medical communication and corresponding medical encounter record may be generated by providing the medical practitioner with GUI screens 201-205. Some of the information may be populated with information already stored in other medical records. The communication may be recorded in the medical encounter record, such as a voice recording, a transcribed text version of a voice conversation, an email or SMS message, or text extracted from an email or SMS message. Accordingly, the conversation or recording can be stored as part of the medical encounter record and associated with diagnosis and medical billing codes of the medical encounter record for providing a complete medical and billing history. Additionally, the communication can be associated with a medical billing code, enabling the medical practitioner to be compensated for the medical encounter.

[0081] FIGS. 11-13 show GUI screens 206-208 of a Transfer Request Form that are generated in response to storage of a medical encounter record (or its transmission as a medical communication) in which the disposition includes a request for transfer of the patient. A portion, or all, of the information stored in the first and/or second medical encounter records is used to populate corresponding data entry fields 110 in GUI screens 206- 208 of the Transfer Request Form. The Transfer Request Form includes the SOAP notes associated with the medical communication that requested the transfer. The Transfer Request Form further includes a transfer document (not shown) that specifies non-private information about the transfer, such as the patient' s name, the patient' s present location, the location that the patient is being transferred to, the doctor's name and contact information, the date of the transfer request, and the level of urgency. The Transfer Request Form or the transfer document may specify items that must be transported with the patient, such as prosthetics, dentures, eye glasses, hearing-aids, etc.

[0082] With reference to FIG. 11, screen 206 is populated with subjective and objective data from the first and second medical communications and/or corresponding medical encounter records. Information from a third party, the first medical practitioner, is indicated with indicator 210. Accept/Reject button 218 and checkboxes 219 are provided which allow the second medical practitioner to accept or reject the populating information. In the example shown, the populated subjective data 212 and the populated objective data 220 has not been accepted or rejected.

[0083] With reference to FIG. 12, screen 207 provides basic identifying information that identifies the patient, the second medical practitioner requesting the transfer, and indicates that the screen relates to a request for transfer. The screen 207 is populated with assessment data 232 and plan data 242 that was entered by the second medical practitioner. Since it was not entered by a third party, there is no indicator 210 delimiting the entered assessment or plan data, even though the assessment and plan data is populated information data, since it was populated from data entered by the second medical practitioner in a previous medical communication. The populated assessment data 230 and populated plan data 240 shown in FIGS. 8 and 9 is not included in screen 207, because it was rejected by the second medical practitioner.

[0084] With reference to FIG. 13, screen 209 provides basic identifying information that identifies the patient, the second medical practitioner requesting the transfer, and indicates that the screen relates to a request for transfer. The screen 209 includes transmit data, which can include a list 250 of parties to notify regarding the transfer request and their contact information, e.g., email address. Checkbox 160 is provided that can be checked when the first medical communication requests that the recipient respond with a medical communication that requests an action, such as requests a patient transfer, orders a medical test or treatment, or notifies an insurance company. Checkbox 162 is provided that can be checked when the first medical communication requests that the recipient reply to the first medical practitioner with a return second medical communication.

[0085] Upon selecting the soft navigation Finish/Send button 118, the Transfer Request Form is sent to the selected recipients using the entered contact information.

[0086] In one embodiment, the Transfer Request Form is sent back to the first medical practitioner, the nurse. A new encounter form is not generated. Rather, the nurse, upon receiving the Transfer Request Form handles sending the Transfer Request Form to proper recipients.

[0087] Some of the recipients on the list of notification recipients are approved and documented as compliant with the Health Insurance Portability and Accountability Act (HIPPA). The Transfer Request Form is sent to the HIPPA compliant notification recipients, including the second practitioner's SOAP notes and the transfer document. Non- HIPPA compliant notification recipients are only transmitted the transfer document. The notification recipients can include, for example,

1. designated family member(s);

2. an administrator of the facility being transferred from;

3. director of Nursing of the facility being transferred from;

4. assistant Director of Nursing of the facility being transferred from;

5. chief Financial officer of the facility being transferred from;

6. primary care provider;

7. medical Director; and

8. outside referring facility and transfer agent (e.g., ambulance).

[0088] Other types of medical communications may be automatically generated. For example, when a billable event occurs, a medical communication may be automatically generated for transmission to the patient' s insurance company.

[0089] FIG. 14 shows a flowchart 1400 of an example method of responding to receipt of a medical communication as performed by a second medical practitioner' s computing device executing a medical communication app. At step 1402, a first medical communication is received from a first medical practitioner. The received medical communication includes a plurality of data fields that store or reference medical data about a patient. The data fields correspond to a data storage entity in the medical record storage system.

[0090] At step 1404, a second medical communication is generated in response to receipt of the first medical communication, which may occur automatically or upon user request.

Generation of the medical communication can include providing, including displaying, one or more GUI screens which can be used for entering and viewing data that is to be included in the medical communication. Automatic generation may depend on satisfaction of a condition, such as the use of selected settings for automatic generation in the second medical practitioner's medical communication app, request for generation of a responding medical communication by the first medical communication, content of the first medical

communication that indicates the need for response with a medical communication (e.g., urgent communication from a subordinate medical practitioner).

[0091] The GUI displays the second medical communication, and can further include one or more previous medical communications, which can be viewable at the same time as the second medical communication, or can be viewable by scrolling the displayed medical communications, allowing the viewer to see a progression (e.g., chronological or other order) of the medical communications. Previous medical communications can be distinguished, such as by displaying them in different colors. The second medical communication can overlay a previous medical communication, which can be displayed, for example, in a shadowed font.

[0092] At step 1406, data entry fields 110 in the second medical communication are populated with populating information from the first medical communication. This can include the following example sub-steps:

[0093] Identifying populating information in the first medical communication. In the example shown in FIGS. 1-4 this includes all subjective, objective, assessment, and plan data entered by the nurse. However, the method shown in FIG. 14 is not limited thereto, and rules can be established by an administrator that govern what information is used as populating information.

[0094] Extracting the identified populating information from the first medical

communication. [0095] Identifying the data entry fields in which to insert the extracted data. This is governed by rules established by an administrator. In the example shown in FIGS. 6-9, the subjective, objective, assessment, and plan data from the first medical communication are inserted into corresponding data entry fields of the subjective, objective, assessment, and plan data, respectively. However, the method shown in FIG. 14 is not limited thereto, and different rules may be applied.

[0096] At step 1408, the populated data is designated as populated data with a displayable indicator 210 to indicate that it was entered by a third party. In the example shown in FIGS. 6-9, the indicator 210 is a set of quotation marks that delimit each entry of populated data. Other indicators are envisioned, such as highlighting, blinking the populated data, applying a different font or color to the populated data text, etc.

[0097] At step 1410, user entered data is received and entered into the second medical communication. The user entered data is entered by or on behalf of the second medical practitioner and is not displayed with an indicator 210, because it is not entered by a third party. Additionally, requests for accepting and rejecting the populated data are received and processed. Populated data that is not affected by a request is displayed with indicator 210. Populated data for which an "Accept" request was received is displayed without the indicator 210. Populated data for which a "Reject" request was received is removed from the second medical communication.

[0098] At step 1412, the second medical communication is stored as a medical encounter record. Attribute data is associated with the medical encounter record and with data entries entered into the individual data entry fields 110. The term attribute data is not limited to use of an attribute. Rather, the attribute data can be associated, for example, by establishing a relationship, linking, providing an attribute, or the like, depending on how the database and database management system are configured. The second medical communication is also transmitted to recipients that were designated by transmit data in the second medical communication or by rules applied by the medical communication app that can be established by an administrator.

[0099] At step 1414, a special medical communication is generated and populated using the data in the second medical communication. Examples of special medical communications include a Patient Transfer Request, a billing notification to an insurer, etc. Rules can be established that govern when a special medical communication is generated. Information populated into the special medical communication that was entered by the second medical practitioner is not designated by the indicator as data from a third party.

[00100] At end step 1416, the procedure ends.

[00101] FIG. 15 shows a flowchart 1500 of an example method of receiving or transmitting an ordinary communication and generating a corresponding medical

communication, as performed by a medical practitioner's computing device executing a medical communication app. At step 1502, an ordinary communication, such as an email, phone call, or SMS message is received or transmitted. The ordinary communication does not include data fields, or references thereto, that correspond to data storage entities in the medical record storage system.

[00102] At determination step 1504, a determination is made whether the ordinary communication involves a medical encounter such that it pertains to medical care of a patient for whom medical data is stored in the medical record storage system. The determination can be made, for example, based on user input (which may be prompted or self-initiated), content of the communication, the source or target of the communication, and/or application of rules governing the determination that can be established by an administrator. If the determination outcome is "NO," then end step 1516 is executed. If the determination outcome is "YES," then step 1506 is executed. When the determination is "YES," a notification is generated, such as by setting a flag. At step 1506, a medical communication is generated, including displaying one or more GUI screens which can be used for entering and viewing data that is to be included in the medical communication.

[00103] At step 1508, data entry fields 110 in the second medical communication are populated with populating information from the medical records storage system. This can include the following example sub-steps:

[00104] Information can be obtained that is related to the received ordinary communication to use to search the medical records storage system for related data to use for populating the medical communication. The information can be obtained, for example, by querying the medical practitioner, from the source or target party of the ordinary

communication (which may be the patient, or an entity having a connection with the patient, such as a family member, primary care provider, lawyer, insurance company), and/or from the content of the ordinary communication (such as subject line of an email, or a name included in an SMS message or voice recording of the ordinary communication or transcription of the voice recording or via video/audio based telemedicine.

[00105] Identifying information in the medical records storage system that corresponds to the information obtained from the ordinary communication.

[00106] Extracting the identified information from the medical records storage system.

[00107] Identifying the data entry fields 110 in the medical communication in which to insert the extracted data.

[00108] At step 1510 user entered data is received and entered into data entry fields

110 of the medical communication. This can include removing populated data and replacing it with user-entered data.

[00109] At step 1512, the medical communication is stored as a medical encounter record. Attribute data is associated with the medical encounter record and with data entries entered into the individual data entry fields 110.

[00110] At step 1514, a special medical communication is generated and populated using the data in the medical communication. Examples of special medical communications include a Patient Transfer Request, a billing notification to an insurer, a notification of the communication to a family member, etc. Rules can be established that govern when a special medical communication is generated.

[00111] At end step 1516, the procedure ends.

[00112] FIG. 16 shows a medical record system 1600 that includes a database system

1601 that includes DBMS server 1602 that manages a medical record database 1604. The database system 1601 can be a medical record storage database system that can communicate with the computing devices 1606 for performing the method of the disclosure. The database system 1601 can be a UMR system, such as the medical history system described in U.S. Publication No. 2011/0010195 which has been incorporated by reference, herein. User computing devices 1606 operated by users, such as medical practitioners, can access the database system 1601 for storing, accessing, retrieving, and/or searching, etc. data stored in the medical record database 1604. The DBMS server 1602, medical record database 1604, and user computing devices can communicate with one another directly or via network 1608 using wired or wireless communication. Network 1608 can include, for example, the Internet, an intranet, a LAN, WAN, a cellular network for mobile phone devices, etc.

[00113] DBMS server 1602 is a computer server device that includes at least one processor 1620, storage device 1622, user interface module 1624, communication module 1626, and software modules 1628. Medical record database 1604 stores a plurality of data entries 1630. The medical record database 1604 can include a plurality of databases that may be linked or independent from one another. Each of the databases can have an associated DBMS, which together can provide a medical record storage system that can communicate with the computing devices 1606 for performing the method of the disclosure. The data entries 1630 can be associated with medical records, such as medical encounter records. The data entries 1630 can be associated with one another. The associations can be implemented as by relationships, links, attributes, and/or other means that are used by databases and DBMSs to associate data. Whereas the associations have been described above as attributes, the associations are not limited to an implementation that uses attributes, but can be implemented using other implementations. The database system 1601 can be implemented as an object oriented, relational object oriented, relational database system, or other database system that is known by those skilled in the art.

[00114] Each of the user computing devices 1606 can be a stationary or portable device, such as a smartphone, a mobile phone, a cellular telephone, a palmtop computer, a communication device, a personal trusted device, a web appliance, a network router, a personal data assistant (PDA), a tablet computing device, a laptop computer, a desktop computer, a computer terminal, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.. Each user computing device 1606 includes at least one processor 1640, storage device 1642, user interface module 1644, communication module 1646, and software modules 1648, including medical communication software 1650.

[00115] The at least one processor 1620 and 1640 include processing devices, such as a central processing unit (CPU), a graphics processing unit (GPU),, microprocessor, logic circuit, application specific integrated circuit (ASIC), etc. The at least one storage device 1622 and 1644 can include volatile and/or nonvolatile memory devices, such as random access memory (RAM), read only memory (ROM) devices, DRAM, EEPROM, flash memory, hard drives, removable memory devices, memory cards, etc., for storing programs or data. The user interface modules 1624 and 1644 include hardware and software used for interfacing with a user input device, such as keyboard, mouse, microphone, touchscreen, etc., and a user output device, such as a display screen, printer device, speaker, etc. The communication modules 1626 and 1646 include hardware and software used for

communicating with other computing devices and/or the network 1608.

[00116] Software module 1608 includes programmable instructions that when executed by the at least one processor 1620 cause the DBMS server to perform any one or more of the methodologies disclosed herein, including managing the medical record database 1604 and interacting with the user computing devices 1606. Software module 1608 can be stored one or more machine-readable mediums.

[00117] Software module 1648, including the medical communication module 1650, include programmable instructions that when executed by the at least one processor 1640 cause the user computing device 1606 to perform any one or more of the methodologies disclosed herein. Software module 1608 can be stored one or more machine-readable mediums. The medical communication module 1650 may be configured as an app configured to work with a mobile computing device, such as a smartphone, or as an application configured to work with a personal computing device, such as a laptop or desktop personal computer.

[00118] The medical communications can be stored in the medical records storage system 1601 as medical encounter records. Data entered into the medical communications can be stored as associated with a medical communication or can be stored independently therefrom. The medical communication data can be accessed independently, such as by searching and/or sorting. A user of a user computing device 1606 can access the medical records storage system 1601 to access stored medical encounter records and medical communication data. The data stored in the medical records storage system 1601 can be searched, filtered, organized, sorted, etc. For example, a user of computing device 1606 can request data entered into medical communications only, or combined with other data stored in the medical record database 1604, such as by filtering or sorting by diagnosis, treatment, procedure, time interval, medical provider, facility, patient, etc. The results can be output to the user, such as by displaying them on the display screen of the user computing device 1606 or sending them in printable form to a printer. [00119] The output can be formatted as a report. In one example, a series of medical communications is listed vertically or horizontally, with the categories subjective, objective, assessment, and plan data aligned (horizontally or vertically). A subset of the categories can be selected for viewing, and the order of the categories can be selected as well. A series of medical communications can be displayed horizontally, with like-categories aligned horizontally. A user of a smartphone executing the medical communication software 1650 can swipe the screen in a horizontal or vertical direction to scroll horizontally or vertically through the series, left or right, up or down, one-by-one, many at a time, or skipping all the way to the first or last of the series.

[00120] Another example report can include an aggregated list of medical records associated with a facility, patient, practitioner, etc., including medical encounter records based on medical communications, or other medical records stored in the medical record storage system. The list can be expanded by navigating through a genealogy, or filtered, such as by healthcare codes, practitioner, time periods,

[00121] The reports can be formatted as spread sheets, with data about similar types aligned. For data that was entered via medical communications, specific plan or assessment data may be aligned, such as performed or prescribed medications, procedures, tests, etc. The data can be ordered chronologically.

[00122] The medical records storage system 1601 and the user computing device 1606 can use different methods for storing data entered into the medical communications and the related attributes. For example, one system may associate data using links, attributes, and/or defined relationships, and another system may use links and/or metadata. The metadata may include data about data entered into a medical communication (e.g., an attribute) that is stored in association with the data. It can be displayed or only accessible upon request. The indicator 210 that indicates that data was entered by a third party is data associated with the data, and can be treated as an attribute.

[00123] The medical communication data stored in the medical records storage system

1601, when configured as a UMR system, can use a diagnosis code of a medical

communication and access the genealogy associated with the diagnosis for obtaining a comprehensive report and/or view of a patient's medical history. The genealogy may be referenced using a diagnosis code or other data about the patient, such as whether the patient uses a prosthetic or hearing aid (which may be indicated in subjective or objective data or listed with a Travel Request Form or travel document).

[00124] The genealogy provides a relationship between medical discipline categories, sub-categories and healthcare codes. Medical discipline categories can be generated and partitioned based on a genealogy of the healthcare codes. For example, the healthcare codes are broken down to their genealogy so that the fundamental relationship and meaning of the healthcare codes dictates which medical discipline categories are used and which medical discipline categories are associated with which healthcare codes.

[00125] Using this approach, a healthcare code, and other referenced information associated with the healthcare code, can be integrated into one or more medical discipline categories based on the relationship of the genealogy of the healthcare code to the medical discipline categories. Integrating the healthcare codes, and other referenced information associated with the healthcare codes, into the UMR system based on the genealogy of the healthcare codes enables an evaluation of a primary medical discipline category to automatically point to other secondary medical disciplines categories specifically related to the healthcare codes found in the primary medical discipline category. This facilitates identification of medical records or data entities in the UMR that can be mutually shared, or otherwise contained, by other medical specialties discipline categories.

[00126] Mappings can be provided between standardized healthcare codes, medical discipline categories, and content subcategories. Standardized healthcare codes can include Current Procedural Terminology (CPT) codes, Healthcare Common Procedure Coding System (HCPS), International Statistical Classifications of Diseases (ICD) codes, National Drug Codes (NDCs), Minimum Data Set (MDS) codes, and the like. The mapping can identify one or more medical discipline categories and content subcategories under which a medical encounter record or data stored therein should be referenced based on the healthcare code(s) associated with the medical record. The mapping can be performed using tables, extensible mark-up language (XML) based documents, and the like. An identifier identifying a medical encounter record can be associated with one or more of the medical discipline categories and through the genealogy to subcategories and related categories. [00127] Accordingly, a medical communication can be populated with information from the UMR or from outside the UMR. Additionally, information entered into a medical communication can be integrated into the UMR.

[00128] The data stored in the medical communications and/or the UMR can be translated into different languages. Accordingly, a medical communication that is generated in a first language can be stored in a UMR that uses a different language. The GUI's for managing the medical communications and accessing the UMR can be provided in a language the user is comfortable using.

[00129] It will be appreciated that various of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by this disclosure.

Claims

Claims:

1. A method of generating a medical communication comprising:

receiving, by a processing device, at least one of:

(a) a medical communication including a plurality of data fields, the plurality of data fields storing medical data associated with a patient, the data fields corresponding to data storage entities in a medical record storage system,

(b) notification that an ordinary communication was received that pertains to medical care of the patient, and

(c) notification that an ordinary communication was transmitted that pertains to medical care of the patient;

providing, by the processing device, a graphical user interface (GUI) having a plurality of data fields that correspond to the data storage entity in the medical record storage system;

receiving, by the processing device, medical data associated with the patient in the

plurality of data fields of the GUI; and

storing, by the processing device, the received data in the data storage entities of the medical record storage system.

2. The method of Claim 1, further comprising extracting a portion of the received data from the medical record storage system.

3. The method of Claim 2, further comprising designating the received and extracted

data as entered by a third party.

4. The method of Claim 3, further comprising displaying in the GUI an indicator associated with data that is designated as entered by the third party.

5. The method of Claim 1, further comprising transmitting a medical communication

that includes the received data and references the corresponding data storage entities in the medical record storage system.

6. The method of Claim 1, further comprising storing billing information that can be

used to generate an invoice with the received data in the medical record storage system.

7. The method of Claim 1, further comprising storing data that can be used to access

related medical history data for the patient and that relates to a genealogy of diagnoses with the received data in the medical record storage system.

8. The method of Claim 2, wherein the medical record storage system is a remote universal medical record storage system.

9. A computing system to generate a medical communication comprising:

a processing device;

a storage device to store instructions that, when executed by the processing device,

cause the processing device to perform operations comprising:

receiving at least one of:

(a) - a medical communication including a plurality of data fields, the data fields storing medical data associated with a patient, the data fields corresponding to data storage entities in a medical record storage system,

(b) - notification that an ordinary communication was received that pertains to medical care of the patient, and

(c) - notification that an ordinary communication was transmitted that pertains to medical care of the patient;

providing a graphical user interface (GUI) having a plurality of data fields that correspond to the respective data storage entities in the medical record storage system;

receiving medical data associated with the patient in the plurality of data fields of

the GUI; and

storing the received data in the data storage entities of the medical record storage system.

10. The computing system of Claim 9, wherein a portion of the received data is extracted from the medical record storage system.

11. The computing system of Claim 10, wherein the operations further comprise designating the received and extracted data as entered by a third party.

12. The computing system of Claim 11, wherein the operations further comprise displaying in the GUI an indicator associated with data that is designated as entered by the third party.

13. The computing system of Claim 12, wherein the operations further comprise transmitting a medical communication that includes the received data and references the corresponding data storage entities in the medical record storage system.

14. The computing system of Claim 9, wherein the operations further comprise storing billing information that can be used to generate an invoice with the received data in the medical record storage system.

15. The computing system of Claim 9, wherein the operations further comprise storing data that can be used to access related medical history data for the patient that relates to a genealogy of diagnoses with the received data in the medical record storage system.

16. The computing system of Claim 10, wherein the medical record storage system is

a remote universal medical record storage system.

17. A computer-readable medium storing instructions that, when executed by a processing device, perform operations comprising:

receiving, by a processing device, at least one of:

(b) notification that an ordinary communication was received that pertains to medical care of the patient, and (c) notification that an ordinary communication was transmitted that pertains to medical care of the patient;

receiving, by the processing device, medical data associated with the patient in the plurality of data fields of the GUI; and

18. The computer-readable medium of Claim 18, wherein the operations further extracting a portion of the received data from the medical record storage system.