WO2013070895A1 - Systèmes et procédés permettant d'assembler des dossiers médicaux électroniques - Google Patents

Systèmes et procédés permettant d'assembler des dossiers médicaux électroniques Download PDF

Info

Publication number
WO2013070895A1
WO2013070895A1 PCT/US2012/064125 US2012064125W WO2013070895A1 WO 2013070895 A1 WO2013070895 A1 WO 2013070895A1 US 2012064125 W US2012064125 W US 2012064125W WO 2013070895 A1 WO2013070895 A1 WO 2013070895A1
Authority
WO
WIPO (PCT)
Prior art keywords
adm
database
contributor
emr
patient
Prior art date
Application number
PCT/US2012/064125
Other languages
English (en)
Inventor
François CEDRIC
Original Assignee
Apellis Pharmaceuticals, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apellis Pharmaceuticals, Inc. filed Critical Apellis Pharmaceuticals, Inc.
Publication of WO2013070895A1 publication Critical patent/WO2013070895A1/fr
Priority to US14/272,714 priority Critical patent/US20140244309A1/en
Priority to US15/597,759 priority patent/US20180082022A1/en

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Z—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS, NOT OTHERWISE PROVIDED FOR
    • G16Z99/00—Subject matter not provided for in other main groups of this subclass

Definitions

  • the disclosure provides a computer program product for assembling a database comprising electronic medical records (EMRs).
  • EMRs electronic medical records
  • An "electronic medical record” may sometimes be referred to as an “electronic health record”, “electronic health care record”, “electronic patient record”, or various similar terms. Such terms may be considered equivalent and interchangeable.
  • a computer program product for assembling a database comprising electronic medical records (EMRs) or modules thereof
  • the computer program product comprising a computer-readable medium encoded with computer- executable instructions for performing a method comprising: (a) receiving from a contributor a dataset comprising health information regarding an individual; and (b) providing an incentive to the contributor or the contributor's designee.
  • the database or computer program product may be at least partly owned by a business entity.
  • a business entity which may at least partly own the database or computer program product, may provide an incentive.
  • health information is checked, e.g., to determine whether it meets a set of predetermined criteria.
  • an incentive is provided following verification that the health information meets a set of predetermined criteria.
  • a dataset meeting said predetermined criteria may be deemed adequate to assemble an EMR or a module thereof.
  • an incentive is issued following receipt of a request from a subscriber to access or analyze an EMR or a module thereof, wherein the EMR or module is assembled at least in part from data contributed by the contributor.
  • an EMR or database contains one or more active diagnosis modules (ADMs).
  • ADMs active diagnosis modules
  • an incentive is issued following receipt of a request from a subscriber to access or analyze an ADM, wherein the ADM is assembled at least in part from data contributed by the contributor.
  • an incentive comprises a share, e.g., a share in a business entity that at least in part owns or controls or administers the database or computer program product.
  • a contributor is a health care provider (HCP).
  • HCP health care provider
  • a contributor is a HCP and the health information pertains to a patient of the HCP.
  • a form comprising predetermined fields for entering health information is provided to a contributor.
  • a dataset is analyzed to determine whether it contains health information that meets predetermined criteria, e.g., criteria indicating that the dataset is adequate to assemble an EMR or a module thereof; and the dataset is accepted or rejected based at least in part on said analyzing.
  • a computer program product analyzes a proposed definitive diagnosis (e.g., in a submitted health information dataset) to determine whether it satisfies a set of predetermined criteria and, if so, updates a status from "tentative" to "definitive”.
  • a computer program product provides feedback to the contributor regarding the dataset, said feedback optionally comprising: (i) informing the contributor whether the dataset was accepted or rejected; (ii) informing the contributor of a rejected dataset of one or more reason(s) why the dataset was rejected; (iii) informing a contributor of or to a deficient proposed definitive ADM why the proposed definitive ADM was deemed deficient; (iv) suggesting a diagnostic test; (v) suggesting a therapeutic.
  • a computer program product maintains, e.g., in one or more computers, account data pertaining at least in part to datasets received from contributors.
  • a computer program product maintains, e.g., in one or more computers, account data of outstanding shares of the business entity. In some embodiments there may be multiple contributors, and the account data may include an account for each contributor.
  • a method may further comprise electronically providing to a contributor account data regarding said contributor's account.
  • said account data is provided in response to a request from the contributor.
  • said request is received from a portable electronic device, said account data is provided to the portable electronic device.
  • a portable electronic device comprises a cellular phone.
  • a database is searchable based on at least one element of an ADM.
  • a method comprises receiving a request from a subscriber; accessing the database in response to the request; and providing a response to the subscriber.
  • de-identified data from the database is accessed, retrieved, analyzed, or provided to a subscriber in response to the request.
  • an EMR in the database contains one or more ADMs adapted for identifying or enrolling subjects in a clinical trial and/or for gathering data pertaining to a clinical trial.
  • a computer or computer readable medium comprising a computer program product, e.g., as set forth herein, is provided.
  • an electronic device providing (e.g., having stored on computer- readable medium thereof and/or having computer-executable instruction steps contained therein) an application operative to interface with a computer that maintains a database or account data as set forth herein, is provided.
  • a device is a portable electronic device.
  • an application may allow a contributor to access at least some of his or her account data upon request.
  • an electronic device provides an application that allows a contributor to purchase and sell shares in the business entity and, e.g., track the share price over time.
  • a database tangibly embodied in a non-transitory computer- readable medium, wherein the database comprises: a plurality of ADMs, wherein an ADM comprises at least a tentative diagnosis or a definitive diagnosis, wherein a definitive diagnosis has been determined to satisfy at least one predetermined criterion.
  • a diagnosis is a conventional disease diagnosis.
  • an ADM comprises a diagnosis status.
  • an ADM comprises a tentative diagnosis and a definitive diagnosis.
  • an ADM comprises a molecular diagnosis, wherein said molecular diagnosis has been determined to be consistent with a conventional diagnosis.
  • an ADM comprises at least one diagnostic test and, e.g., a result thereof.
  • an ADM comprises at least one diagnostic test suggested at least in part based on a tentative diagnosis.
  • an ADM comprises at least one diagnostic test and a result thereof, and wherein the definitive diagnosis has been confirmed as definitive based at least in part on a result of said diagnostic.
  • an ADM comprises at least one therapeutic, and wherein said therapeutic has been confirmed as appropriate for the definitive diagnosis.
  • an ADM comprises at least one therapeutic, and wherein the therapeutic has been confirmed as appropriate for the patient.
  • an ADM comprises at least one therapeutic, and wherein the therapeutic has been confirmed as appropriate for the patient.
  • ADM comprises an indication of the presence, absence, or characteristic(s) of at least one symptom, sign, complication, or outcome of the definitive diagnosis.
  • an ADM does not comprise a patient name. In some embodiments an ADM does not comprise a patient social security number. In some embodiments an ADM does not comprise protected health information. In some
  • At least some information in an ADM is selected from a set of predetermined options. In some embodiments at least some information in an ADM is selected from numerical values. In some embodiments at least 50%, 60%, 70%, 80%, 90%, or more of the data items in an ADM are selected from a set of predetermined options or numerical values.
  • one or more non-transitory computer-readable media comprising: a database, wherein the database comprises a database as set forth herein, and wherein the one or more non-transitory computer-readable media store instructions that, when executed by one or more processors, cause the one or more processors to: access the database to determine a response to a user's query. In some embodiments, said instructions further cause the one or more processors to transmit a result to a user.
  • one or more non-transitory computer-readable media comprising: a database, wherein the database comprises a database as set forth herein, and wherein the one or more non-transitory computer-readable media store instructions that, when executed by one or more processors, cause the one or more processors to: access the database to retrieve or analyze at least one ADM or an element thereof from the database in response to a user's query. In some embodiments, said instructions further cause the one or more processors to transmit a result to a user.
  • instructions further cause the one or more processors to update account information for a contributor after accessing an EMR or ADM stored in the database, wherein the EMR or ADM comprises information submitted by the contributor, wherein said account information is optionally stored in an account database.
  • one or more non-transitory computer-readable media comprises a first medium and a second medium, and wherein the first medium comprises a database and the second medium comprises the instructions to retrieve or analyze data from the database.
  • the instructions form part of a computer program used to access the database and the instructions are stored separately from the database.
  • a method comprising accessing a database as set forth herein to create, retrieve, analyze, or modify an EMR or ADM is provided. In some aspects, a method comprising accessing a database as set forth herein to respond to a query by a user is provided. In some embodiments the user is a subscriber.
  • one or more non-transitory computer-readable media comprising at least one ADM
  • an ADM comprises at least a tentative diagnosis or a definitive diagnosis, wherein a definitive diagnosis has been determined to satisfy at least one predetermined criterion.
  • a diagnosis is a conventional disease diagnosis.
  • an ADM comprises a diagnosis status.
  • an ADM comprises a tentative diagnosis and a definitive diagnosis.
  • an ADM comprises a molecular diagnosis, wherein said molecular diagnosis has been determined to be consistent with a conventional diagnosis.
  • an ADM comprises at least one diagnostic test and, e.g., a result thereof. In some embodiments an ADM comprises at least one diagnostic test suggested at least in part based on a tentative diagnosis.
  • an ADM comprises at least one diagnostic test and a result thereof, and wherein the definitive diagnosis has been confirmed as definitive based at least in part on a result of said diagnostic.
  • an ADM comprises at least one therapeutic, and wherein said therapeutic has been confirmed as appropriate for the definitive diagnosis.
  • an ADM comprises at least one therapeutic, and wherein the therapeutic has been confirmed as appropriate for the patient.
  • an ADM comprises an indication of the presence, absence, or characteristic(s) of at least one symptom, sign, complication, or outcome of the definitive diagnosis.
  • a symptom, sign, complication or outcome is a key symptom, sign, complication or outcome.
  • an ADM does not comprise a patient name.
  • an ADM does not comprise a patient social security number.
  • an ADM does not comprise protected health information.
  • the one or more non-transitory computer-readable media comprises a plurality (more than one) of ADMs.
  • the one or more non-transitory computer-readable media comprises a plurality of ADMs for a patient. In some embodiments the one or more non- transitory computer-readable media comprises a plurality of ADMs for different patients.
  • an ADM for a patient is associated with information identifying said patient.
  • an ADM for a patient comprises a module of an EMR for said patient.
  • a method is provided comprising accessing the one or more non-transitory computer-readable media to create, retrieve, analyze, or modify an ADM.
  • said retrieval, analysis, or modification is at least in part or solely for a patient care purpose.
  • said retrieval or analysis is at least in part or solely for a research purpose.
  • apparatus comprising: (i) one or more processors; memory, the memory comprising: a database as set forth herein, wherein the memory stores instructions that, when executed by the one or more processors, cause the one or more processors to: (a) access the database to create, modify, or retrieve an EMR or ADM; or (b) provide a template for entry of health information, wherein said template is optionally an
  • said instructions cause the one or more processors to retrieve information from a plurality of EMRs in response to a query, wherein the query optionally specifies a patient characteristic, conventional disease diagnosis, molecular diagnosis, diagnostic, treatment, symptom, sign, complication, or outcome, or combination thereof.
  • said instructions cause the one or more processors to analyze information from a plurality of EMRs in response to a query, wherein the query may specify a patient characteristic, conventional disease diagnosis, molecular diagnosis, diagnostic, treatment, symptom, sign, complication, or outcome, or combination thereof.
  • said instructions cause the one or more processors to retrieve information from a plurality of ADMs in response to a query, wherein the query may specify a conventional disease diagnosis, molecular diagnosis, diagnostic, treatment, symptom, sign, complication, or outcome, or combination thereof.
  • said instructions cause the one or more processors to analyze information from a plurality of ADMs in response to a query, wherein the query may specify a conventional disease diagnosis, molecular diagnosis, diagnostic, treatment, symptom, sign, complication, or outcome, or combination thereof.
  • said memory further comprises an account database.
  • said database, account database, or both is at least in part owned or administered by a business entity.
  • said database, account database, or both is at least in part owned or administered by a business entity, and said memory comprises a database comprising shareholder account information.
  • apparatus comprising: one or more processors;
  • the memory comprising: a database as set forth herein, wherein the memory comprises: an account database and wherein the memory stores instructions that, when executed by the one or more processors, cause the one or more processors to: (a) update information in the account database following receipt from a contributor of health information that meets at least one set of predetermined criteria; or (b) update information in the account database following a request by a subscriber to retrieve, access, or analyze an EMR or ADM, wherein said account information optionally comprises information tracking incentives earned by contributor(s) or (c) determine an incentive due to a contributor based at least in part on one or more requests received from subscriber(s) to retrieve, access, or analyze an EMR or ADM, wherein said EMR or ADM comprises information contributed by the contributor; or (d) issue an incentive to a contributor based at least in part on receiving a request by a subscriber to retrieve, access, or analyze an EMR or ADM, wherein said EMR or ADM comprises information contributed by the contributor.
  • the request causes the one or more processors to execute instructions to retrieve, access, or analyze an ADM.
  • the contributor is a HCP.
  • said database is at least in part owned or administered by a business entity.
  • said database is at least in part owned or administered by a business entity, and said memory comprises a database comprising shareholder account information.
  • apparatus comprising: one or more processors;
  • memory comprising: a database as set forth herein, and wherein the memory stores instructions that, when executed by the one or more processors, cause the one or more processors to: analyze information received from a contributor to determine whether such information at least in part meets a set of predetermined criteria for inclusion in an EMR or ADM or for storage in the database.
  • said instructions cause the processor to store at least some of said information in the database if predetermined criteria are met.
  • said instructions cause the processor to provide feedback based at least in part on said analysis.
  • said information comprises at least a tentative diagnosis.
  • said information comprises at least a proposed definitive diagnosis.
  • said instructions cause the processor to determine whether a proposed definitive diagnosis is consistent with other information regarding a patient to whom said proposed definitive diagnosis pertains, wherein said other information optionally comprises a result of at least one diagnostic test.
  • said instructions cause the processor to update the status of an ADM if a proposed definitive diagnosis is confirmed.
  • said instructions cause the processor to suggest at least one diagnostic test suitable for confirming a tentative or proposed definitive diagnosis.
  • said instructions cause the processor to suggest at least one treatment suitable for a tentative, proposed definitive, or definitive diagnosis.
  • said instructions comprise instructions for interfacing with an application for an electronic device.
  • said device is a portable electronic device.
  • said application allows a user to access the database or to access user account information.
  • a method comprising assembling a database as set forth herein.
  • a method comprises (a) receiving health information datasets pertaining to a plurality of patients; and (b) storing at least some of said health information in the database, optionally after checking said information to determine whether it meets a set of predetermined criteria.
  • a method comprise (a) receiving health information datasets from a plurality of HCPs; and (b) storing at least some of said health information in the database, optionally after checking said information to determine whether it meets a set of predetermined criteria.
  • a method comprises (a) receiving health information datasets pertaining to a plurality of patients; and (b) storing at least some of said health information in the database, optionally after checking said information to determine whether it meets a set of predetermined criteria.
  • a method comprises providing a template to subscribers and receiving information entered into said template, said template optionally comprising a disease-specific or discipline-specialized template.
  • a method comprises providing an incentive to a contributor based at least in part on submission of health information by said contributor, said incentive optionally being determined based at least in part on access of such health information by subscribers.
  • a method comprises providing a subscription to said database, optionally in exchange for a fee.
  • a method comprises retrieving, accessing, analyzing, or modifying information in said database, e.g., in response to a query from a user.
  • a database comprising EMRs is provided, said database being usable by HCPs for health care purposes and usable in addition for at least one non-health care purpose (e.g., a research purpose).
  • health information is provided at least in part in modules comprising de-identified health information.
  • a HCP may access such module(s), e.g., in the context of providing health care to a patient.
  • An individual who is not an HCP of the patient may access or retrieve data from said module(s), e.g., for research purpose(s).
  • database updates, feedback, or response may be performed or provided in a timely manner.
  • an average time for providing feedback or response to a HCP or updating an EMR or ADM may be selected so as to not substantially interfere with or delay normal workflow of the HCP.
  • an average response or update time may be selected to be below a
  • a predetermined value may be equal to or less than 1, 2, 5, 10, 15, 20, 30, 40, 45, 50, or 60 seconds for, e.g., at least some classes of actions .
  • an alert pertaining at least in part to time anticipated to be required for response or update may be provided, said alert comprising, e.g., an estimated time, an indication that a response or update may take more than a predetermined time, an option to abort an update or query, etc.
  • database accesses, updates, or queries are at least in part prioritized.
  • Prioritization may take into account, e.g., factors such as the user (e.g., whether the user is a contributor or subscriber), the nature of the action, prior response times to the user or during a session, etc. For example, an action performed in response to a contributor, e.g., a HCP, may be assigned a higher average priority than an action performed by a non-contributor.
  • Figure 1 is a block diagram showing an exemplary implementation of a system and interaction with various categories of users in accordance with some implementations.
  • Figure 2 is a block diagram showing details of exemplary interactions between a EMR system and contributors in accordance with some embodiments.
  • Figure 3 is a flow chart in accordance with some embodiments.
  • Figure 4 is a flow chart in accordance with some embodiments.
  • Figure 5 is a flow chart in accordance with some embodiments.
  • Figure 6 is a flow chart in accordance with some embodiments.
  • Figure 7 is a diagram showing an implementation of a cloud computing system in accordance with some embodiments.
  • a computer- implemented process of acquisition of health information by a business entity, the health information being useful for assembly of electronic medical records (EMRs), is presented.
  • a computer-implemented process of administering a business entity that has, as a business purpose, the acquisition of health information, e.g., health information sufficient to assemble a database of EMRs, is presented.
  • health information e.g., health information sufficient to assemble a database of EMRs
  • health information (data) regarding an individual may be electronically received from a contributor.
  • a contributor may be a health care provider (HCP) of the individual.
  • HCP health care provider
  • a collection (set) of health information regarding an individual may be referred to as a "health information dataset”.
  • the health information dataset received from the contributor may be evaluated to determine whether the dataset fulfills a predetermined set of criteria that are required for assembly of a EMR (the "EMR criteria"). If the dataset fulfills the EMR criteria, the dataset may be deemed adequate.
  • An EMR may be generated using the dataset and may be stored in a database (the "EMR database").
  • a system including the EMR database, may be at least in part owned or controlled or administered by a business entity.
  • "At least in part owned or controlled by the business entity” may mean, with regard to the EMR database, that the business entity may at least exerts control over the format and/or use of the database.
  • the business entity may control the type of information included in the database and/or may control access to or use of the database by contributors and, e.g., other parties.
  • the format of the database may be proprietary to the business entity.
  • Ownership of the data itself may at least in part reside with a contributor, health care organization (HCO), and/or patient, e.g., in the sense that such individuals or organizations may be legally entitled to require removal of at least some of the data from the database or may be entitled to receive a copy of the data or use the data for their own purposes or may receive remuneration in exchange for certain uses of the data.
  • HCO health care organization
  • assembling a database of EMRs may involve expenditure of time and effort on the part of health care providers, e.g., health care professionals such as physicians.
  • HCPs may need to spend time familiarizing themselves with a data input format and/or transmitting existing health information pertaining to their patients to the EMR system.
  • an ongoing commitment may be required to maintain the quality of the EMRs by, for example, submitting new health information that becomes available.
  • the business entity may compensate contributors based at least in part on the health information that the contributor submits.
  • Such compensation may provide an incentive for contributors to submit health information adequate to meet certain standards specified by the business entity and, for example, to complete such tasks as are appropriate to maintain the quality of the data. Compensation may be provided based on any of a number of factors and in any of a variety of forms in various embodiments. For example, in certain embodiments, submission by a contributor of a sufficient number of adequate datasets to generate a selected number of EMRs or modules thereof, may entitle the contributor to receive an incentive. In some embodiments an incentive comprises a share in the business entity.
  • the EMR database may be used by any of a variety of individuals and/or entities.
  • HCPs who contribute health information may use the EMRs in the ordinary course of providing care for their patients.
  • patients may use the EMR database to, for example, review their health information.
  • the business entity may permit third parties to access the EMR database in exchange for a fee. Such third parties (sometimes referred to as "subscribers" herein) may use the database, for example, to perform medically related research or for any of a variety of other purposes.
  • a "user”, e.g., of the EMR database or of a system or apparatus comprising or accessing such database, may refer to any individual that transmits (submits) information for potential inclusion in the EMR database or that receives information retrieved from the EMR database (e.g., in response to a request by the user).
  • Users may, for example, be contributors, subscribers, patients, patient representatives, government employees, or employees of the business entity, in various embodiments.
  • a user may, in some embodiments, be an organization that, through its employees, contractors, or representatives, transmits or receives information to or from a database, apparatus, or system.
  • an inventive system may comprise a database that contains user account data, e.g., contributor account data.
  • account data may include, for example, data relating to EMRs to which the contributor contributed and/or incentives earned by the contributor.
  • the business entity may maintain or cause to be maintained (e.g., through another entity) a database that contains shareholder account data, as discussed further below.
  • shareholder account data may include, for example, information identifying the business entity's shareholders and the number of shares owned by each shareholder.
  • the present invention or any one or more aspects thereof may be embodied, for example, as a system, apparatus, method or computer program product. Accordingly, the present invention or any one or more aspects thereof may take the form of hardware, software, or embodiments combining software and hardware aspects that may all generally be referred to herein as a "system", which may comprise one or more "components". Furthermore, the present invention or any one or more aspects thereof may take the form of a computer program product embodied in any tangible medium (e.g., a non-transitory storage medium) having computer usable program instructions embodied in the medium. Any combination of one or more computer usable or computer readable medium(s) may be utilized in various embodiments.
  • the computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device.
  • Examples of a computer-readable medium include the following:, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (e.g., EPROM or Flash memory), a portable compact disc read-only memory (CDROM), a floppy disk, an optical storage device, or a magnetic storage device.
  • a computer-usable or computer-readable medium may in some embodiments be paper or another suitable medium on which the program is printed or embodied, as the program may be electronically captured, for instance, via optical scanning of the paper or other medium (optionally employing optical character recognition), then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory and/or executed by a computer processor.
  • a computer-usable or computer-readable medium may be any medium that may contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the computer-usable medium may include a propagated data signal with the computer-usable program code embodied therein.
  • the computer usable program code may be transmitted using any appropriate medium, including but not limited to wireless, physical wires, wireline, optical fiber cable, etc.
  • the term "EMR system” may be used to refer to the one or more aspect(s) or feature(s) that receive health information from contributors, assemble EMRs therefrom, and/or perform any of a variety of other functions associated with the retrieval and/or processing of health information submitted to and/or stored in the EMR database.
  • the EMR system may interact with users (e.g., via a standard graphical user interface (GUI), analyze submitted health information, and/or assemble the health information into EMR database records.
  • GUI graphical user interface
  • the EMR system may comprise multiple components. For example, one or more components may receive and/or transmit information to or from users. One or more components may analyze information received from users. One or more components may add information to the EMR database.
  • One or more components may extract information from the EMR database, e.g., in response to a query from a user.
  • One or more components may analyze extracted data and/or convert the data into an appropriate format for transmission to a user.
  • One or more components may receive and/or transmit information between other component(s) of the EMR system or external to the EMR system.
  • the EMR system may include a clinical decision support system (CDSS) component.
  • the CDSS may, for example, provide advice or suggestions to HCPs based at least in part on information entered into the EMR database and may perform any of a variety of other functions of such systems.
  • Various other components that may be included in the EMR system are described below.
  • a user may transmit or receive health information via any type of electronic transmission in various embodiments.
  • An electronic transmission may occur over a network, e.g., a computer network such as the Internet or a phone network.
  • a network e.g., a computer network such as the Internet or a phone network.
  • the terms “transmit” and “submit” may be used interchangeably herein, as are related terms such as “transmitting” or “transmission”, “submitting” or “submission”, etc. Where reference is made to “entering” or “entry” of data into the EMR system, it should be understood that such data may be submitted to the EMR system unless otherwise indicated.
  • submission may occur in response to a request or action initiated by a user or in response to a request initiated by the EMR system.
  • at least some health information entered by a user may remain stored on a user's computer for a period of time prior to being transmitted to the EMR system. Such transmission may occur in response to a request initiated by the EMR system, which may occur automatically, e.g., at predetermined time intervals.
  • at least some health information may remain stored on a computer or data storage system owned or controlled at least in part by a user (e.g., a HCP) or HCO but is made available to the EMR system for analysis and/or retrieval. For purposes hereof, such information may be considered to be submitted to the EMR system.
  • the disclosure provides a computer program product sometimes referred to herein as an "application" for a portable electronic device.
  • the application may allow contributors and/or shareholders to access at least some of their account data.
  • An application that allows a user to access at least some of his or her account data may be referred to as an "account access application”.
  • the disclosure provides a computer readable medium having an account access application embodied in its memory.
  • the disclosure provides a portable electronic device having an account access application embodied in its memory.
  • the EMR system may interface with an application, e.g., an application for a portable electronic device, wherein said application allows users to interact with the EMR system using the portable electronic device.
  • an application e.g., an application for a portable electronic device
  • HCPs may be able to enter or retrieve patient information, communicate with patients or other HCPs, or perform other activities described herein (e.g., data analysis activities) using a portable electronic device having such application embodied thereon.
  • the disclosure may provide a computer readable medium having such application embodied in its memory.
  • the disclosure may provide a portable electronic device having such application embodied in its memory.
  • Fig. 1 shows a block diagram of an exemplary system 10 in accordance with some implementations.
  • System 10 may include a EMR system 20 that handles (e.g., receives, analyzes, stores, transmits) health information.
  • System 10 may include ancillary components
  • system 10 may interact at least with multiple health care providers.
  • system 10 may interact with multiple patients and/or multiple subscribers.
  • HCPs, patients, and subscribers may interact with system 10 using any of a variety of electronic systems labeled in Fig. 1 as systems 60 (for use by HCPs), 70 (for use by patients), and 80 (for use by subscribers), respectively that link to system 10 via one or more networks.
  • Systems 60, 70, and 80 may comprise one or more computers, smart phones, or other suitable electronic devices.
  • HCP systems 60, patient systems 70, and subscriber systems 80 are labeled 1 through n to indicate that numerous different HCPs, patients, and subscribers may interact with system 10. It should be understood that employees of the business entity may also interact with system 10 (not shown).
  • EMR system 20 may comprise EMR system manager 22, EMR database 24, and one or more additional EMR system components 26, labeled as EMR componenti - EMR component ⁇
  • EMR system manager 22 at least in part manages communication (interaction) between users and various components of the EMR system and, in some embodiments, at least in part manages interactions between various components of the EMR system.
  • EMR manager 22 may receive health information from an HCP, transfer health information to a EMR component 26 for analysis, receive a response from EMR component 26, and/or transmit the response to the user.
  • EMR manager 22 may include or interface with a database management system (DBMS) for the EMR database 24, which database stores EMR data, as described further herein.
  • EMR manager 22 may (via the DMBS) extract information from EMR database 24 in response to a request from a user or add data to EMR database 24 in response to a request from a user, e.g., after said data has been analyzed and approved by a EMR component 26.
  • EMR manager 22 may perform one or more additional functions. For example, EMR manager 22 may process information received from users or from EMR components 26 prior to transmitting such information to EMR database 24.
  • EMR manager 22 may perform various functions of the EMR system itself and/or may issue instructions to one or more EMR components 26 to perform any one or more functions of the EMR system described herein and/or may issue instructions to ancillary system components (described below).
  • EMR components 26 may include at least an analysis component that analyzes health information received from a HCP. Such analysis may include, for example, determining whether a health information dataset is adequate to meet EMR criteria, determining whether a conventional disease diagnosis proposed by a user meets conventional disease diagnosis criteria, etc. The analysis component may provide feedback based on the analysis, which feedback is transmitted to the user. EMR analysis component 26 may inform EMR manager 22 whether particular information is adequate to entitle a contributor to an incentive.
  • EMR manager 22 may inform user account manager 30 and/or incentive management component 40 accordingly.
  • EMR components 26 may include a component that analyzes and, e.g., processes queries from users (e.g., HCPs, patients, subscribers). For example, the analysis component may convert a raw query (e.g., a natural language query) into a format acceptable to the DBMS.
  • EMR components 26 may include a clinical decision support system component (CDSS) or an interface thereto, a computerized physician order entry component or an interface thereto, a billing component or an interface thereto, and/or a scheduling component or an interface thereto, etc.
  • CDSS clinical decision support system component
  • EMR components 26 may include one or more components that analyze health information entered into the EMR system and provide or trigger provision of an alert to a user upon entry of particular data, as described herein.
  • EMR components 26 may include one or more components that interface with an application running on a portable electronic device, as described herein.
  • Ancillary components of system 10 may include, for example, a user account manager 30, an incentive management component 40, and/or a share issue component 50.
  • User account manager 30 may perform any of a variety of functions connected with the establishment, maintenance, updating, etc., of user accounts. For example, user account manager 30 may perform functions such as receiving registration information from users, assigning user IDs or passwords, checking login information received from users, etc.
  • User account manager 30 may maintain and/or interface with a user account database 32, which stores user account data.
  • User account manager 30 may store user account information in user account database 32, extract information from user account database 32, and, e.g., analyze such information or transmit the information to other system component(s).
  • User account manager 30 may be at least in part responsible for checking login credentials supplied by users against information stored in user account database 30 and instructing EMR manager 22 to provide, limit, or deny access to the EMR system or portions thereof based at least in part on the comparison. User account manager 30 may perform functions relating to subscriptions (e.g., billing subscribers, transmitting renewal reminders to subscribers, monitoring and controlling use of the EMR system by subscribers, etc.).
  • subscriptions e.g., billing subscribers, transmitting renewal reminders to subscribers, monitoring and controlling use of the EMR system by subscribers, etc.
  • Incentive management component 40 may perform any one or more functions connected with the distribution of incentives to contributors, as described herein. For example, incentive management component 40 may determine the amount or nature of incentives due to a contributor, direct share issue component 50 to issue one or more shares to a contributor, may arrange for the dispatch of a check to a contributor, may arrange for a direct deposit of funds to a contributor's account at a financial institution, etc. In some embodiments, incentive management component 40 may perform such function(s) at least in part in response to instructions or information received from EMR manager 22 and/or user account manager 30.
  • Share issue component 50 may issue shares in the business entity, e.g., in response to a request from incentive management component 40.
  • share issue component 50 may receive and/or respond to external requests (not shown), e.g., requests from within the business entity, directing the issuance of one or more shares.
  • share account database 52 may receive and/or respond to external requests (not shown), e.g., from within the business entity.
  • share issue component 50 and/or share account database 52 may perform any conventional functions connected with the issuance, management, or tracking of shares in a business entity.
  • Fig. 1 shows only a subset of potential interactions that may occur between various components in certain embodiments. It should also be understood that at least some components of system 10 may communicate directly with one another and/or with users as well as, or in addition to, communicating via EMR manager 22, and that any communications may take place over a network or within or between one or more processors, as appropriate. For example, at least some requests for certain user account data or shareholder account data, and responses thereto, may be handled by a component of system 10 (not shown on Fig. 1) without involving EMR system 20. It should be understood that EMR manager 22 and any of EMR components 26 or ancillary components 30, 40, and/or 50 may be composed of multiple subcomponents and may include or access one or more databases in addition to those depicted.
  • aspects or features comprising compensating contributors e.g., health care providers
  • third parties e.g., subscribers
  • the business entity may be any of a variety of types of business entity in various embodiments.
  • the business entity may be a limited liability partnership (LLP), a limited liability company (LLC), a C corporation (C corp), or an S corporation (S corp), as those terms are understood in the United States.
  • the business entity may be organized under the laws of any state in the US (e.g., Delaware, New York,
  • the business entity may be privately held or may be a public company (i.e., its shares may be publicly traded), in various embodiments. If publicly traded, the shares may be listed on one or more stock exchanges. It should be understood that the term "share” may be employed in regard to corporations. In embodiments in which the business entity is not a corporation, "share” as used herein may refer to an ownership interest in the business entity, which may include, for example, a share of the net profits of the business entity and the right to receive distributions of the business entity's assets, and may or may not include the right to vote and participate in management of the business entity.
  • the business entity may be a not-for-profit organization, also referred to as a nonprofit organization. It will be understood that if the business entity is a nonprofit organization, certain aspects or features pertaining to shares in the business entity may not apply.
  • the business entity may in various embodiments have one or more subsidiaries that may, for example, be organized under the laws of different states or countries.
  • the business entity at least in part owns or controls a system of the present disclosure, e.g., an EMR system.
  • a contributor may be any individual who has health care information pertaining to one or more individuals and the right to submit the health information to the business entity.
  • a contributor may be a HCP of the individual to whom the health care information pertains, such that the individual may be a "patient" of the HCP.
  • a patient may, and often does, have multiple HCPs.
  • HCPs may include, for example, a patient's primary care physician, specialist medical practitioners such as cardiologists, dermatologists, or ophthalmologists who may provide care to a patient on a regular or as- needed basis, physician assistants, nurse practitioners, nurses, pharmacists, surgeons, dentists, or any other health care provider who has sufficient interaction with a patient to acquire health information adequate for assembly of, or appropriate for inclusion in, a EMR.
  • a HCP may be member of an allied health profession, which term may refer to health professions distinct from medicine, surgery, dentistry, and nursing.
  • a contributor that first contributes health information regarding a patient that is used to assemble a EMR may be referred to as the "primary contributor" for that EMR.
  • Contributors that subsequently submit health information regarding that patient may be referred to as “secondary contributors" for that EMR.
  • a contributor e.g., a HCP
  • HCO health care organization
  • a HCP may be employed by and/or may be an at least partial owner of a health care organization (HCO) and/or a HCP may be affiliated with one or more HCOs.
  • HCO health care organization
  • a physician affiliated with a hospital may not be an employee of the hospital but may be entitled to admit patients to the hospital.
  • HCO Health care organization
  • a HCO may provide inpatient services, outpatient services, or both.
  • a HCO may be a for-profit entity or a nonprofit entity.
  • a HCO may have custody over and/or access to medical records of multiple patients.
  • Certain types of outpatient health care may be delivered via organizations such as pharmacy clinics or temporary health clinics that offer services such as vaccinations, cholesterol screenings, and, in some instances, more extensive medical services.
  • organizations may be considered HCOs.
  • a HCO may authorize multiple different individuals, e.g., employees, partners, or affiliates thereof to contribute health information to the EMR system.
  • a HCP or HCO may be engaged mainly in primary care, secondary care, or tertiary care.
  • a contributor may be a patient. In some embodiments, a contributor may be a patient's parent, legal guardian, health care proxy, or other
  • a representative may be any individual legally authorized (e.g., by the subject) to provide health information regarding the subject to the business entity.
  • a person who contributes health information concerning himself or herself may be referred to herein as an "auto-contributor".
  • a person who contributes health information concerning a child, ward, or other individual for whom the person is acting as a representative may be referred to herein as a "proxy contributor”.
  • an auto-contributor or proxy contributor may only be permitted to be a secondary contributor.
  • Contributions by auto- contributors or proxy contributors may include, for example, symptom diaries, medication usage diaries, exercise diaries, food intake diaries, and/or results of self-administered monitoring tests such as weight, blood glucose tests, blood pressure checks, etc.
  • results of self-administered monitoring tests may be uploaded directly from a monitoring device into the EMR database.
  • feedback is provided to a patient or HCP based at least in part on said results. For example, a patient or HCP may be advised to schedule a patient visit, modify a treatment, etc.
  • contributors or other users may be offered an opportunity to elect to receive electronic updates (e.g., via email, text message, voicemail, or other electronically communicated form), said updates may contain information relevant, for example, to particular medical conditions, therapeutic agents, or other medically relevant topics.
  • updates may be customized based on HCP discipline, patient roster, or user preferences.
  • the EMR system may store information pertaining to issuance of such updates, e.g., in account information.
  • contributors or other users may or may be able to interact with each other, e.g., via or assisted by the EMR system.
  • contributors may be able to allow at least some other users or categories of users to contact them via, for example, email, text messaging, Internet forum, or Internet chat room, for any of a variety of purposes.
  • email between patients and their HCPs and/or email between HCPs may be supported.
  • such emails may be stored in the relevant patient's EMR.
  • patients may allow themselves to be contacted by individuals or organizations seeking subjects for clinical trials, or vice versa.
  • patients may allow themselves to be contacted by individuals or organizations engaged in or planning to engage in research relating to particular medical conditions from which the patient suffers, or vice versa.
  • patients may interact with each other. Interaction may be anonymous, e.g., at the option of either interactor, in various embodiments.
  • At least some categories of users may be able to access information pertaining to HCOs or HCPs. For example, users may be able to view the number of patients having a particular diagnosis who are or have been under care of particular HCO or HCP within a predetermined time period, or to view HCO or HCP rankings, etc.
  • a contributor may submit health information to the EMR system and retrieve information from the EMR database in any of a variety of ways in various embodiments.
  • the EMR system may interact with a user via one or more computer-based documents (e.g., web pages, e.g., dynamic web pages).
  • the user may navigate between different pages or portions thereof by clicking on "links" (which may be indicated using text of a different color or font), arrows, and other navigation methods typical of web page navigation.
  • links which may be indicated using text of a different color or font
  • arrows arrows
  • users may log on to the EMR system using a computer and will be presented with a computer-based document (displayed on a screen) from which various options may be selected.
  • HCP his or her patients
  • options such as accessing existing EMRs of his or her patients, initiating creation of a new EMR, ordering a medication, or any of a variety of other functions.
  • the options may be presented in a hierarchical manner.
  • GUI elements sometimes referred to as GUI widgets
  • buttons e.g., boxes to check or fill in, radio buttons
  • lists e.g., scroll-down or dropdown lists from which to select among various options
  • menus etc.
  • entry of health information by a contributor may be facilitated by providing the contributor on his or her computer with one or more document(s) (forms) that contain a template or other structured format in which the contributor is presented with various input fields to complete. At least some of the input fields may be presented as buttons or lists of options from which to select. Typical webform elements may be used.
  • a document having a preset input format may be referred to as a "template".
  • a template may contain at least some fields that are to be completed by (a) making a selection from a set of predetermined options (whether presented visually, orally, or otherwise); (b) entering a numerical value; (c) answering questions where there may be a limited number of potential responses (such as yes/no questions).
  • an option may be "none of the above” (indicating that none of the other presented options is appropriate), “unknown", “not applicable", “other”, or like terms. If “other" is selected, the contributor may in some embodiments be permitted to enter an item not included in the set of predetermined options, e.g., as free text.
  • a template may contain at least some fields that request or permit entry of a specified type of data whose content may at least in part not be readily or conveniently entered by way of selecting from methods (a), (b), or (c). Examples of such data may be physician notes (e.g., progress notes) or images (e.g., images produced by diagnostic imaging devices, photographs, sketches, video or audio files, etc.).
  • An appropriately labeled field allowing entry of free text may be provided, such as a field for entering physician notes.
  • Appropriately labeled fields allowing the user to upload or provide a reference number or storage location for an image may be provided.
  • the EMR system may generate a EMR by assembling the information and adding it to the EMR database, e.g., as a database record.
  • Fig. 2 shows certain details of exemplary interactions between EMR system 20 and certain types of contributors (physicians) in accordance with some embodiments. It will be understood that EMR system 20 may include additional components not shown on Fig. 2. EMR system 20 may interact with various systems 90 that communicates with (links to) system 20 via one or more networks. Systems 90 may each include one or more computers that may or may not be in communication one another but in some embodiments each such system may include at least one device that is capable of communicating with system 20.
  • system 90 may comprise, e.g., a computer located in a physician's office, a computer located in a facility that performs clinical chemistry tests, a computer that interfaces with or is part of a medical imaging system, or any standard EMR system or a system in which a standard EMR is stored, etc.
  • the term "standard EMR system" or "existing EMR system” may refer to an existing (as of the date of the present invention) EMR system, e.g., a computer program product for creation or maintenance of EMRs, that is commercially available or otherwise publicly known or used as of the date of the present invention.
  • a "standard EMR" may be created in or using a standard EMR system.
  • a standard EMR system may be, for example, listed on the Certification Commission for Health Information Technology website or another certification body.
  • EMR Europay, MasterCard, and Visa
  • inventive EMR system in the Summary, Brief Description of the Drawings, Drawings, Detailed Description, or Claims hereof should be understood to refer to an inventive EMR or inventive EMR system, respectively, unless indicated or evident from the context as referring to a standard EMR or standard EMR system or as evident from the context, respectively.
  • a physician may enter the patient's social security number (SS#).
  • the SS# may be encrypted at least during transmission.
  • the first entry of the patient's SS# by the physician may require that the patient be present at the same location as the physician (indicated as 1 st time location on Fig.
  • the EMR system may provide a patient with a unique EMR
  • the physician may enter health information pertaining to the patient. As shown in Fig. 2, the EMR system may provide feedback and/or an incentive to the physician based on analysis of the health information, as described herein.
  • EMR system 20 may be entered into EMR system 20 from one or more standard EMR systems, e.g., via system 90.
  • Standard EMR systems are labeled 102 and 104 in Fig. 2.
  • the EMR system will interface with any of a variety of standard EMR systems.
  • the EMR system may, for example, with authorization from a contributor, extract information pertaining to the contributor's patients from such standard EMRs and use the information to at least partially assemble EMRs for such patients as appropriate. Contributors may be requested to verify and/or supplement such imported health information.
  • standard EMR systems may be running at least in part on a system 90 in a physician's practice or health care organization.
  • Physician input may be requested or required in order to transmit information from system 90 into the EMR system and/or physician input may augment the information extracted from standard EMR systems.
  • information extracted from existing EMR system 102 may be used to populate at least some fields of a form, and the physician may input additional information to complete or correct the form.
  • EMR system 20 may cause the information to be displayed for physician review and input.
  • EMR system 20 may cause the information to be displayed for physician review and input.
  • health information may be entered at least in part using dictation.
  • the EMR system may include, make use of, or accept input from appropriate voice recognition software and/or speech recognition software.
  • the EMR system may ask the HCP a series of questions, either orally or by presenting the questions on a computer screen (or combinations thereof).
  • the EMR system may receive responses from the contributor, assemble the information into a EMR, and/or add the EMR to the EMR database.
  • a contributor need not physically enter all of the health information for a patient.
  • the contributor may delegate at least part of the task of entering at least some portion of the health information to an appropriately authorized individual operating under the contributor's direction. In some embodiments such information would not be eligible for incorporation into a EMR until the contributor acknowledges having reviewed the information.
  • policies may be set where the contributor permits incorporation from trusted entities or delegates directly into an EMR.
  • the EMR system may analyze a health information dataset to ensure that it meets predefined criteria and may provide feedback to the contributor based on such analysis. For example, if a contributor fails to provide an item of information that is required according to the EMR criteria, the contributor may be informed that the health information dataset is not adequate and may be provided with suggestions regarding the additional information needed and/or the reason why the dataset was determined to be inadequate.
  • the data may be checked for possible inconsistencies or other errors, e.g., laboratory values or drug doses outside the possible range or otherwise likely to be incorrect.
  • the HCP may be requested to confirm such data and/or the data may be tagged in the database as being possibly erroneous.
  • Health information added to an existing EMR may be checked in a similar way as it is entered.
  • more stringent criteria may be applied to current data than to data generated prior to creation of the EMR.
  • the particular criteria that a health information dataset generally must meet in order to be deemed adequate to assemble a EMR may vary and may be determined by the business entity (or other entity that at least in part controls or administers the EMR system) within its discretion. In other embodiments, the criteria may be requirements or recommendations. In this regard, it should be understood that the term
  • EMR may indicate that the health information contained therein, or at least a portion thereof, may have met predetermined criteria (such as completion of a set of fields of a template, e.g., a template that may be provided by the EMR system) but may not specify the criteria that must be met and may not require that the health information have any specific content. For example, at least some of the health information, may have been analyzed and determined to meet predetermined criteria.
  • the criteria may be selected in any way of a variety of ways and may take into consideration any of a variety of different factors as appropriate for any one or more uses envisioned for the EMR or portion(s) thereof.
  • a EMR may be used by HCPs or HCOs in their ordinary activities and may replace wholly or at least in part the use of paper-based records or, in at least some embodiments, the use of standard electronic medical record systems.
  • a EMR database may be structured in a way that facilitates the ability to perform useful research, e.g., medically related research, such as to collect information regarding outcomes or side effects associated with various treatments, medications, or combinations thereof or any of various types of analysis (which may be referred to as "meta-analysis").
  • the use of the EMR database to perform activities (e.g., medically related research) not directly pertaining to care for a particular patient may, in many embodiments, be subject to appropriate privacy and/or legal rules or considerations such as those of the Health Insurance Portability and Accountability Act (HIPAA), the Common Rule (45 CFR 46, Subparts A, B, C and D), etc. In some embodiments, such use may be subject to the privacy and/or other legal rules or considerations of a country or union in which a patient resides and/or in which a patient seeks health care and/or in which a HCP is registered to practice.
  • HIPAA Health Insurance Portability and Accountability Act
  • C and D Common Rule
  • the EMR system may facilitate the integration of health information held or generated at or by multiple different locations or individuals (e.g., at different HCOs or HCPs), which may exist or be generated in multiple diverse formats.
  • the EMR system may facilitate the integration of health information held or generated at or by multiple different locations or individuals (e.g., at different HCOs or HCPs), which may exist or be generated in multiple diverse formats.
  • EMR system may convert information existing in diverse formats into a standard format that may, for example, be viewable on diverse computer hardware platforms or display devices, which may be supplied with appropriate software.
  • a set of standard terms e.g., to describe symptoms, physical exam findings, findings on diagnostic tests or images, diagnoses, treatments, etc., may be defined and used.
  • a glossary may be provided so that users of the
  • EMR system may look up the meaning of any term of whose meaning they are uncertain.
  • health information suitable for inclusion in a EMR may comprise, for example, any of the following elements: medical history, surgical history, obstetric history, medications (sometimes abbreviated as Rx herein), allergies to medications, family history, social history, habits that potentially have an impact on health, immunization history, growth chart, developmental history, or any other health-related information.
  • a medical record may contain at least several of the foregoing elements and that not all elements may be relevant, appropriate, available, or necessary for all or even most patients.
  • a growth chart may be relevant for a young child but not for a typical adult.
  • a medical record may contain potentially individually identifiable information such as the patient's name, address, phone number, birth date, social security number, etc.
  • a EMR may be presented to a user as one or more computer-based documents (e.g., web pages, e.g., dynamic web pages). The user may be able to navigate between different pages or portions thereof by clicking on links, arrows, icons, menu options, and/or other methods typical of web page navigation.
  • the various elements of a EMR may be stored in different fields of the database record.
  • a EMR may include at least some of the elements listed below under the heading "Central EMR Database Format".
  • a EMR may often include a Patient ID, at least some Patient Data, and at least one Active Diagnosis Module (described further below).
  • Central is used to indicate that the database records in the EMR system may have a common or uniform format and should not be interpreted as indicating that the EMR database must be a centralized database, although it may be in some embodiments.
  • the EMR database may be a distributed database comprising multiple databases that may be uniform, similar, or heterogeneous in structure and may be stored in a single computer or multiple computers (or on single or multiple computer-readable media).
  • Such computers or computer-readable media may be geographically located in the same place or different places and may be interconnected by a network in various embodiments.
  • the EMR system components may in some embodiments include components for interfacing between multiple different databases, and, in some embodiments, providing data integration and/or presenting a uniform format to users.
  • Patient ID e.g., encrypted SSN - retrievable by physician or other Health Care
  • HCP Health Provider
  • Demographic Information e.g., date of birth, gender, etc.
  • Patient ID may refer to an identifier that may identify a particular individual having a EMR stored in the EMR database.
  • a patient ID may be a social security number.
  • a patient ID may be provided by the contributor who submits the health information dataset used to assemble the EMR.
  • a patient ID may be provided by the business entity following submission by a contributor of a health information dataset adequate to assemble a EMR for the patient.
  • Exemplary "Patient Data" may generally include information of the type that may be found in a typical medical record, such as demographic information, family history, information regarding the patient's diseases and surgeries, diagnostic tests, treatments, allergies to medications, etc.
  • Patient Data may not apply to a particular patient or may be unknown to the contributor.
  • a patient may not have any known allergies to medications, may not have any current medications, or may not have had any surgeries.
  • the relevant field of the EMR could be marked with a designation such as "none", "unknown", or “not applicable”.
  • Diseases may include, e.g., data regarding at least those diseases of the patient that were diagnosed after creation of the EMR and may also include data regarding at least some diseases that were diagnosed before creation of the EMR, e.g., diseases that have been monitored or treated since the time that the EMR was created or that resolved prior to creation of the EMR.
  • Data pertaining to a disease may include, for example, a diagnosis, symptoms experienced by the patient, physical exam findings, physician notes, treatment and/or follow-up plan, or any other disease-related information.
  • “Surgeries” may include, e.g., information regarding surgeries (if any) that the patient has had since the EMR was created and may include information regarding at least some surgeries that the patient had before the EMR was created.
  • "Historical Diagnostic Tests” and “Historical Rx” may refer to diagnostic tests (e.g., with results) and/or treatments that were performed or administered in the past (with respect to a time point at which the EMR is accessed).
  • a EMR may include a
  • Past Medical/Surgical History section which may contain at least some of the patient's past medical/surgical history as of the date of the date of creation of the EMR. It should be understood that the information under “Patient Data” may be arranged in the EMR database and/or displayed to the user in any of a variety of ways, and the list below is not intended to require any particular structure or format. For example, diagnostic tests and treatments may be together with the particular disease or surgery to which they are relevant. Information may be arranged at least in part chronologically, e.g., by date of patient visit. Different formats may be used for outpatient visits versus hospitalizations. In some embodiments, the "Patient Data" section may comprise or may have at least some of the functionality of a standard EMR.
  • the EMR system may provide one or more medical history templates or physical exam templates, which may be specialized for a particular health care discipline.
  • a general physical exam template or a specialized physical exam template such as a neurological exam template or ophthalmological exam template may be provided.
  • a HCP may select from among a set of such templates.
  • a EMR may comprise or may be organized at least in part around a module referred to as an "active diagnosis module” (ADM), e.g., as shown below in some exemplary, non-limiting embodiments.
  • ADM active diagnosis module
  • an ADM may correspond to a disease or a risk factor for a disease that has come to the attention of a HCP.
  • Exemplary Active Diagnosis Module e.g., designed at least in part to facilitate future research or meta-analysis
  • an ADM may be designed to contain or reference at least a substantial portion of the health information that is directly relevant to a particular disease in a patient (at least to the extent that such health information has been gathered by or made available to HCPs who utilize the EMR system) so that it may be possible by reviewing the
  • an ADM may, for example, include at least the following four elements:
  • each ADM may be assigned a unique identifier.
  • the identifier may be used to refer to the ADM in research studies, publications, reports, etc., thereby potentially facilitating verification of the study results or performance of follow-on studies.
  • Existing Active Diagnosis Module may refer to an Active Diagnosis Module that has already been created at a particular time that the EMR is accessed.
  • New Active Diagnosis Module may refer to an Active Diagnosis Module that is being created or has been created during a current access session.
  • a new ADM may be created by a HCP when or shortly after a patient health problem initially comes to the attention of the HCP, e.g., during or shortly after a patient visit during which the health problem is first discussed or detected.
  • a HCP may be presented with the option of creating an ADM by, for example, selecting an icon labeled "create ADM" or selecting such option from a list.
  • the HCP may then be presented with a template ("ADM template") containing fields for entering the relevant information for elements (1) through (4), as available. If there are already existing AD Ms for the patient, the HCP may be presented with the option of opening such ADMs. The HCP may then add information to the ADM, such as an entry for a patient visit or a newly received diagnostic test result.
  • ADM template a template containing fields for entering the relevant information for elements (1) through (4), as available. If there are already existing AD Ms for the patient, the HCP may be presented with the option of opening such ADMs. The HCP may then add information to the ADM, such as an entry for a patient visit or a newly received diagnostic test result.
  • Conventional Disease Diagnosis may be selected from, e.g., a predetermined set of possible diagnoses, which may be presented in the form of one or more scroll-down lists, for example.
  • Disease may be used herein to refer to any disease, disorder, syndrome, injury, or condition for which a person may seek or receive professional advice or treatment by a health care provider (or on whose behalf such advice or treatment may be sought), e.g., any disease, disorder, syndrome, injury, or condition that would be documented in a medical record.
  • "disease” may refer to any diagnostic entity that has been assigned a code in the International Statistical Classification of
  • ICD-10 International Health Organization
  • the, e.g., predetermined set of possible diagnoses may be at least in part, selected from the diagnoses included in ICD-10 or any updated version or successor thereof.
  • the predetermined set of diagnoses may be, at least in part, selected from the diagnoses included in International Statistical Classification of Diseases and Related
  • ICD-10-CM Health Problems, 10th Revision, Clinical Modification, 201 1 (known as "ICD-10-CM"), developed by The National Center for Health Statistics (NCHS), the US Federal agency that is responsible for coordination of all official disease classification activities in the United States relating to the ICD and the use, interpretation, and/or periodic revision of the classification activities.
  • conventional disease diagnoses may be at least in part selected from diseases discussed in a standard medical or surgical textbook such as Goldman's Cecil Textbook of Medicine, Saunders, 23 rd or 24 th ed. (2007, 2012), Lango, D., et al, Harrison's Principles of Internal Medicine, McGraw Hill, 18 th ed.
  • the EMR system may assign or assist the user to assign, an ICD diagnosis and code based on the conventional disease diagnosis.
  • an HCP may often enter a conventional disease diagnosis when (or soon after) creating a new ADM.
  • a conventional disease diagnosis may initially be deemed "tentative" and may be marked as such in the EMR system. For example, the correct diagnosis may be unclear until results of appropriate diagnostic tests have been received.
  • the HCP may be required to select a single tentative diagnosis in order to create an ADM.
  • the HCP may select multiple alternative or co-existing tentative diagnoses.
  • a differential diagnosis may be entered.
  • the HCP may be able to modify the tentative diagnosis at any time, e.g., as results of such tests are obtained.
  • the HCP may update the status of the ADM to "definitive" (e.g., after changing the tentative diagnosis if appropriate).
  • the EMR system may only permit the status of the ADM to be changed to "definitive” if a set of predetermined criteria ("EMR system diagnostic criteria") for the proposed definitive diagnosis have been met, based on data that have been entered into the EMR system. For example, the EMR system may check whether results of appropriate tests have been entered and, if so, whether such results are consistent with the proposed definitive diagnosis.
  • the EMR system may not permit the tentative status to be updated to definitive and may inform the HCP accordingly, or may require an additional action on the part of the HCP to override the tentative status of the ADM.
  • a HCP may be required to enter a reason for overriding the tentative status.
  • a diagnosis status may be indicated in any of a variety of ways in various embodiments, such as by using a field (e.g., a check box), color coding, icon shape, etc.
  • the EMR system may provide additional feedback to the HCP following entry of a tentative or proposed definitive diagnosis or may offer the HCP the option of consulting the CDSS.
  • the EMR system may suggest one or more alternative tentative diagnoses and/or may suggest one or more diagnostics that may be useful to confirm or reject a tentative diagnosis or alternative tentative diagnosis or that may be useful to assist with treatment selection.
  • the EMR system may also indicate which of the EMR system diagnostic criteria have not been met. It should be understood that a definitive diagnosis may or may not actually be the correct diagnosis of a patient's disease.
  • a definitive diagnosis may be changed if, for example, additional health information is gathered that suggests to the EMR system and/or to a patient's HCP, that a definitive diagnosis may be incorrect.
  • Various means and/or criteria for changing a definitive diagnosis may be provided.
  • a definitive diagnosis refers to a diagnosis that has at least met predetermined criteria or, if such predetermined criteria have not been met, a tentative status has been overridden by specific HCP action.
  • the term "definitive" diagnosis may be used interchangeably with "confirmed” or "established” diagnosis herein.
  • EMR diagnostic criteria may be based at least in part on recommended diagnostic guidelines published or approved by professional associations of various medical/surgical specialties or subspecialties, by expert panels or committees of HCPs in the relevant disease area, or by national or international organizations or government medical research institutes such as the National Institutes of Health (U.S.) or corresponding government entities in other countries, World Health Organization, the European
  • EMR diagnostic criteria may be revised over time in at least some embodiments or diseases.
  • certain diagnoses may be deleted from or added to the set of possible diagnoses.
  • a diagnosis stored in the EMR database may be tagged with information indicating a version number for the diagnostic criteria that were applied at the time the diagnosis was entered.
  • the EMR system may check ADMs that have previously been assigned that diagnosis and may determine whether the diagnosis is still valid according to the revised diagnostic criteria.
  • the EMR system may tag the ADM accordingly and, in some embodiments, may attempt to assign a valid diagnosis to the ADM.
  • the newly assigned valid diagnosis may not replace the previously assigned diagnosis but rather may be provided as an additional element, e.g., of the ADM.
  • Molecular Disease Diagnosis may include information regarding to certain biomolecules found in the patient (e.g., DNA, R A, protein, etc.) that may be relevant to the disease and/or its treatment. Such information may have been obtained by analyzing, at the molecular level, a sample obtained from the patient. For example, a conventional disease diagnosis might be "lung cancer” or “lung adenocarcinoma” or “non- small cell lung cancer” (NSCLC).
  • NSCLC non- small cell lung cancer
  • a molecular disease diagnosis of the same condition might be "non-small cell lung cancer positive for abnormal anaplastic lymphoma kinase (ALK) gene” (or simply “ALK-positive non-small cell lung cancer", where "positive for abnormal anaplastic lymphoma kinase (ALK) gene” may indicate that the patient's tumor exhibits an abnormal ALK gene (e.g., as assessed using an FDA-approved test).
  • ALK abnormal lymphoma kinase
  • Such patients may be candidates for particular treatments shown to be effective for treating patients with lung cancers that express ALK.
  • a molecular disease diagnosis may be of use to classify a conventional disease into one or more categories that differ in regard to prognosis or likelihood of responding favorably to a particular therapeutic agent or class of therapeutic agent.
  • a molecular disease diagnosis may represent the result of analyzing a single biomolecule or multiple biomolecules, ranging from a small set up to hundreds or thousands.
  • a contributor may be presented with a list of potential molecular disease diagnoses that may be based at least in part on the identity of a tentative or definitive conventional disease diagnosis.
  • the contributor may select from the list based, e.g., on results of one or more appropriate tests.
  • such a list may be presented after a tentative diagnosis is entered.
  • such a list may be presented after conventional disease diagnosis is changed to definitive.
  • the EMR system may present an error message and/or may not permit the status of the ADM to be updated to "definitive" or may require the HCP to override the tentative status of the ADM.
  • molecular disease diagnosis may not be available or applicable for some diseases, in which case, in some embodiments, this element may be omitted from the ADM template.
  • whether to perform the diagnostic tests that may be needed to establish a molecular diagnosis may be within the discretion of the HCP. For example, if a molecular diagnosis would not alter the treatment, such tests may not be performed.
  • Diagnostics may include diagnostic tests performed that relate to the disease and, in some embodiments, at least some diagnostic test results. For example, continuing with the example of NSCLC discussed above, the name of the test that was performed to demonstrate ALK positivity and results thereof may be included in element 3, as would names and, in some embodiments, results of other tests used to diagnose or monitor the disease.
  • diagnostics may be selected from a predetermined set, which may be provided by the EMR system and may be based at least in part on the tentative diagnosis or diagnoses.
  • diagnostics may include, e.g., laboratory tests
  • results may include, for example, "raw data” and/or reports describing, analyzing, or interpreting the data.
  • diagnostic images e.g., X-rays
  • histopathology slides as well as reports interpreting such images/slides may be included.
  • Examples of the type of molecular characteristics that may be assessed may include, e.g., to provide a molecular diagnosis
  • DNA sequence or epigenetic modifications, RNA or protein level, or activity or post- translational modification of specific proteins may be used as molecular diagnostics.
  • Any suitable method for analyzing the relevant biomolecule(s) may be used as molecular diagnostics.
  • DNA may be analyzed to determine the presence or absence of particular mutations,
  • Exemplary techniques may include sequence analysis, hybridization-based analysis (e.g., microarray analysis), immunological techniques such as immunohistochemistry, ELISA assay, protein microarrays, mass spectrometry, etc.
  • an ADM template may include one or more fields in which results of certain tests may be entered by a HCP by selecting from a predetermined set of options. For example, if an imaging study has been ordered, the ADM template may request entry of particular information regarding the resulting image, such as the presence, absence, or dimensions of lesion(s), so as to facilitate searching or analysis.
  • the EMR system may comprise appropriate analytical tools to extract, e.g., relevant searchable information from images or other test results.
  • an ADM template may include one or more medical history templates or physical exam templates, which may be general or may be specialized for a particular health care discipline or disease. For example, a general physical exam template or a specialized physical exam template such as a neurological exam template or ophthalmological exam template may be provided.
  • a HCP may select from among a set of such templates.
  • the EMR system may suggest diagnostic tests that may be useful to, e.g., establish a tentative diagnosis as definitive or to rule out a potential alternative diagnosis or to guide selection of appropriate therapy. It is noted that the use of "diagnostics” or “diagnostic tests” is not limited to determining the identity of a disease or determining whether a disease is or is not present. Diagnostic tests may be used after a diagnosis has been established, e.g., in order to monitor the disease and/or the effect(s) of treatment.
  • Treatment Information may include information relating to treatments prescribed or performed to treat the disease.
  • information may include, e.g., medication- related information (e.g., name of medication administered or prescribed, dosage unit, administration instructions such as frequency and timing of doses), description of surgery, physical therapy, or other procedures performed or prescribed, medical or surgical devices used (e.g., external devices, implantable devices, prostheses), etc.
  • Treatment information may include data entered by pharmacies or other providers of pharmaceutical agents. Such information may include, e.g., drug lot number, date of prescription fulfillment, etc.
  • a medication may be any product or combination product listed in, e.g., the United States Pharmacopeia (USP) or the National Formulary (NF) (both published by The United States Pharmacopeial Convention, Rockville, MD) or listed in The Anatomical Therapeutic Chemical (ATC) classification system (WHO Collaborating Centre for Drug Statistics Methodology (WHOCC) (Oslo, Norway) or having an assigned code in the US National Drug Code (NDC) numbering system
  • USP United States Pharmacopeia
  • NF National Formulary
  • ATC Anatomical Therapeutic Chemical
  • WHOCC WHO Collaborating Centre for Drug Statistics Methodology
  • NDC National Drug Code
  • the EMR CDSS may suggest therapies (e.g., medications) that may be useful to treat a disease, based on, e.g., the conventional disease diagnosis, molecular disease diagnosis, and/or results of diagnostics.
  • the EMR CDSS may take into consideration one or more patient data items, such as age, weight, co-existing diseases (e.g., as represented by ADMs in the EMR), etc.
  • the EMR CDSS may suggest alternate diagnostics or therapies that may be more suitable for the patient (e.g., having a better benefit-risk profile) or may be less costly without sacrificing quality of care.
  • Such suggestions may, for example, be based at least in part on analysis of patient data, other ADMs for that patient, genetic information, etc.
  • the EMR system via the use of ADMs, may encourage use of evidence-based approaches in health care.
  • diagnostic or therapeutic recommendations made by the EMR system may be based at least in part on diagnostic or therapeutic guidelines published or approved by, e.g., professional associations of various medical/surgical specialties or subspecialties, by expert panels or committees of HCPs in the relevant disease area, or by national or international organizations or government medical research institutes such as the National Institutes of Health (U.S.), the World Health
  • the EMR system may provide research findings or guidelines that support its suggestions, or a link thereto.
  • Diagnostics ( ⁇ .3) and Rx ( ⁇ .4) from Active Diagnosis Modules may be automatically added to the Patient Data (1.2) as diagnostics accumulate.
  • items from 1.2 may also or alternately be imported to II.3 and II.4 but may require active transfer or approval by a patient's HCP.
  • patient symptoms described to the HCP and/or the HCP's findings on physical examination may be included in Diagnostics.
  • the ADM may include one or more elements for patient symptoms and/of physical examination findings, in addition to the above-mentioned four elements. As noted above, at least some such information may be entered by way of templates provided by the EMR system in some embodiments.
  • an ADM may include one or more fields for entering information pertaining to complications that may arise as a result of a disease or as a result of treatment.
  • One of ordinary skill in the art would be aware of complications that may arise in patients with particular diseases. Certain complications may be the subject of an additional ADM for the complication.
  • an ADM for a complication of an existing disease (or of a treatment for a disease) may be a "sub-ADM" of an ADM for the existing disease or may be connected to it via a link or other connecting means such as arrows, menus, or a hierarchical arrangement.
  • an EMR may include a problem list for a patient.
  • a problem list may at least include diagnoses in patient's unresolved ADMs and may further include significant items from Patient Data.
  • a problem list is generated or updated at least in part by the EMR system, and may be subject to modification by a patient's HCP.
  • an ADM template may include one or more elements in which the HCP may enter notes, thought processes, plans, etc., as text. Alternately, or additionally, such information may be entered in Patient Data in some embodiments.
  • an ADM template may interface with or may be integrated with a standard EMR system.
  • a EMR in some embodiments may comprise a standard EMR for the patient, one or more ADMs in accordance with the present disclosure and, e.g., a patient summary.
  • a HCP may select one or more ADM templates from the
  • the ADM template may interface with components of the EMR system such as the
  • the EMR database may thus at least in part comprise ADMs that may reside on HCP's computers but that may be accessed by other
  • a EMR database record may thus have different formats or may be a virtual database record that comprises a standard EMR (which may be created by any of diverse EMR systems) and one or more ADMs.
  • the EMR system may thus allow HCPs or HCOs that have, e.g., invested in standard EMR systems and integrated them with other legacy health information systems or operations such as scheduling or billing to continue using such standard EMR systems if desired while adding ADMs and other functions of the EMR system and, e.g., transitioning completely to the central EMR database format over time.
  • the EMR system may provide multiple different versions of an ADM template, the different versions being adapted for integration into or interfacing with different standard EMR systems.
  • a patient summary may be generated by the EMR system from information in the standard EMR.
  • the patient's HCP may review and, if appropriate, may correct and/or supplement the automatically generated patient summary.
  • the patient's HCP may enter information into a patient summary template provided by the EMR system to generate a patient summary.
  • the EMR system may provide tools to extract or analyze data contained in standard EMRs as well as in ADMs.
  • the EMR system may provide tools that support at least partial sharing of health information stored among multiple different standard EMR systems.
  • the EMR system may provide a uniform user interface, which may enable users (e.g., HCPs) to store and/or retrieve data from multiple heterogeneous standard EMR systems in addition to using and analyzing ADMs.
  • the EMR system may fulfill or substitute for the functions of a health information exchange (HIE), e.g., a regional health information organizations (RHIO) in addition to providing users with the functionality of ADMs and, in some embodiments, the ability to search and analyze them.
  • HIE health information exchange
  • RHIO regional health information organizations
  • ADMs may be implemented in conjunction with or as part of a HIE, e.g., a RHIO.
  • a database comprising ADMs may be implemented in conjunction with or as part of a HIE, e.g., a RHIO.
  • ADM templates may at least in part share a common predetermined format.
  • ADMs may at least have fields for conventional and (if applicable) molecular disease diagnosis, diagnostics, and treatments. They may in some embodiments differ at least in part with regard to fields for specific symptoms, signs, complications, etc.
  • different ADM templates may be designed so as to use the same design elements such as fonts, page layout, spacing, color, GUI elements, across different templates, etc., so as to provide a uniform user experience.
  • ADM templates may include a logo (e.g., a graphic mark or emblem, which may be purely graphic
  • an ADM template may include the term "ADM", e.g., as an unregistered or registered trademark (ADMTM or ADM ® ). Such term may be further specialized, e.g., by discipline or disease, such as ADM-Oncology, ADM-Neurology, etc.
  • ADMTM or ADM ® unregistered or registered trademark
  • an EMR system and/or ADM template comprises one or more features adapted for use in outpatient care.
  • an EMR system and/or ADM template comprises one or more features adapted for use in inpatient care. For example, one or more fields for tracking symptoms, signs, or performing tests or procedures or monitoring actions that may be performed in an outpatient or inpatient context, respectively, may be provided.
  • an ADM template may include an option to toggle back and forth between outpatient and inpatient versions.
  • an ADM which may be a discipline-specific or disease-specific ADM, may be denoted as ADM-Inpatient or ADM-Outpatient.
  • an ADM may be characterized in that it comprises at least a tentative diagnosis and a definitive diagnosis.
  • an ADM may be characterized in that it comprises a diagnosis status, wherein said diagnosis status may be tentative or definitive, and wherein said status may, e.g., be indicated to a user via a field, color or other indication means.
  • both a tentative diagnosis and a and definitive diagnosis may be retained.
  • a tentative diagnosis may, e.g., at the selection of a contributor that submitted it, be deleted or made unavailable for access (e.g., by at least some users of the EMR database) after a definitive diagnosis has been established.
  • a field for entering a conventional diagnosis wherein an entered diagnosis is presumed to be tentative unless a contributor, e.g., an HCP, indicates otherwise.
  • a field is provided, wherein an option of tentative or proposed definitive may be selected for an entered diagnosis.
  • an ADM is characterized in that it comprises a definitive diagnosis that has been confirmed by determining, based at least in part on entered results (e.g., results of at least one diagnostic test) that a predetermined set of diagnostic criteria have been met.
  • an indication is provided to a contributor, e.g., a HCP, when a predetermined set of criteria for confirming a tentative diagnosis as definitive have been met.
  • a "set”, wherever such term appears herein, may contain a single member or multiple members in various embodiments.
  • a set of predetermined criteria may be one criterion or may comprise multiple criteria.
  • an ADM template may be characterized in that it comprises a field for a tentative diagnosis and a field for a confirmed diagnosis and/or a field for indicating whether an entered diagnosis is tentative or proposed definitive, and/or a field for indicating that a diagnosis is definitive.
  • an ADM is characterized in that it comprises a conventional diagnosis and a molecular diagnosis.
  • an ADM template is characterized in that it comprises a field for a conventional diagnosis and a field for a molecular diagnosis.
  • an ADM template may have associated with it a set of predetermined options for selection of diagnostics or therapeutics, wherein the set of predetermined options may be based at least in part on conventional and/or molecular diagnostics.
  • an ADM template may have associated with it a set of rules, a knowledge base and/or an inference engine, which may be at least a portion of an expert system.
  • said rules, knowledge base, inference engine, and/or expert system may be at least in part embodied within an ADM template.
  • said rules, knowledge base, inference engine, and/or expert system may be an
  • said rules, knowledge base, inference engine, and/or expert system may be at least in part invoked in response to data entered into an ADM template.
  • said rules, knowledge base, inference engine, and/or expert system provide a determination or recommendation based at least in part on data entered into an ADM template. For example, a determination may be a confirmation that a proposed definitive diagnosis meets a set of predetermined criteria.
  • all or at least 90%, 95%, or 99% of the AD Ms in a EMR or EMR database may be created at or shortly after the time at which the patient corresponding to the particular ADM initially seeks care for the relevant disease or the time at which symptom(s) or sign(s) of the disease first come to the attention of a patient's HCP.
  • Such ADMs may be referred to as "tyP e 1" ADMs.
  • an ADM may be created during the first patient visit during which symptoms or signs of the disease are discussed or detected or within the time period in which an HCP would ordinarily record information pertaining to such symptom(s) or sign(s) in a patient's medical record. If properly completed and updated, such an ADM may provide substantial information pertaining to the disease in that patient starting from the time that the disease first came to medical attention.
  • an ADM may pertain to a disease for which a diagnosis has already been established or for which the patient has already received at least one therapeutic intervention at the time the ADM is created.
  • Such ADMs may be referred to as "tyP e 2" ADMs.
  • the comprehensiveness of a type 2 ADM in terms of the extent to which the type 2 ADM includes information gathered prior to the ADM's creation may vary.
  • a type 2 ADM may include a diagnosis and current treatment as of the creation date of the ADM but may not include information pertaining to previously performed diagnostics and/or previous treatments. Alternately, at least some information pertaining to previously performed diagnostics and/or previous treatments may be included in a type 2 ADM.
  • Such information may, for example, be collected from existing health records (paper or electronic) and/or from the Patient Data section of the EMR.
  • a type 2 ADM may contain less comprehensive health information pertaining to the disease than would ordinarily be the case for a type I ADM.
  • a HCP may not have access to health records held by previous HCPs of the patient, or it may be too burdensome to enter data that may not be directly relevant to the patient's current condition.
  • an ADM may be tagged with metadata indicating whether it is a type 1 or type 2 ADM.
  • type 1 ADMs may be preferred for certain purposes, e.g., for certain research or analysis purposes.
  • an ADM may contain health information pertaining to a disease in a patient over a period of at least 3, 6, 9, or 12 months.
  • an ADM may contain health information pertaining to a disease in a patient over a period of at least 3, 6, 9, or 12 months.
  • ADM may contain health information pertaining to a disease in a patient over a period of at least 1, 2, 3, 4, or 5 years.
  • an ADM may contain health information pertaining to a disease in a patient over at least 3, 5, 10, or more patient visits, which visits may be separated in time by, e.g., intervals of at least 1 week or more, on average.
  • an ADM contains health information pertaining to a disease in a patient over a period of at least 1, 2, 3, 4, or 5 years.
  • a diagnosis e.g., a tentative diagnosis, proposed definitive conventional diagnosis, and/or molecular diagnosis is entered by a HCP, e.g., a physician, during or after an outpatient visit by the patient.
  • a diagnosis e.g., a tentative diagnosis, proposed definitive conventional diagnosis, and/or molecular diagnosis is entered by a HCP, e.g., a physician, during or after a visit by the HCP to a hospitalized patient.
  • a HCP e.g., a physician
  • an EMR or ADM may comprise a field for entering information pertaining to patient satisfaction, e.g., patient satisfaction with care received from a HCP or HCO.
  • entering information in such fields may be limited to a patient or patient representative(s).
  • entering information in such fields may require verification by a patient or patient representative(s).
  • patient satisfaction is determined based at least in part on a questionnaire or survey.
  • information pertaining to patient satisfaction may be at least in part accessible to at least some users or categories of users.
  • an ADM does not contain information included solely for billing, reimbursement, or insurance claim purposes.
  • aspects or features may comprise creating a database comprising modules containing health information, e.g., active diagnosis modules, wherein such modules may have an at least partially predetermined format, may be searchable on e.g., disease diagnosis, diagnostics, and treatment, and may further be searchable on key symptoms, signs, complications, and/or outcomes, are independent of any particular implementation of the system or components thereof.
  • a database may comprise at least
  • modules may have any one or more features of ADMs, as described herein.
  • modules containing health information may be created at least in part through providing templates and/or incentives to HCPs.
  • such modules may be made available to third parties, the use of such modules by third parties may be tracked, and, e.g., incentives may be provided to HCPs based at least in part on use of such modules by subscribers.
  • a collection may include templates that may have an at least partially predetermined format, that may have fields for entering e.g., disease diagnosis, diagnostics, and treatment, and that further may have, e.g., fields for entering key symptoms, signs, complications, and/or outcomes, such embodiments, collection(s) and/or template(s) are independent of any particular implementation or use thereof.
  • a collection may comprise at least 2, 5, 10, or more such templates, e.g., at least some of which may be disease-specialized or discipline-specialized.
  • such templates may comprise means for providing feedback to a user who enters data into the fields; such feedback may in various embodiments include offering suggestions for completing the template and/or for disease diagnosis or management.
  • At least some information may be time and date stamped upon receipt by the EMR system and/or upon addition to a EMR.
  • any additions or changes to a EMR may be time and date stamped and/or may include information identifying the contributor.
  • a EMR may contain health information relating to preventive health care (e.g., screening tests such as colonoscopies or cholesterol measurements; vaccinations, etc.), vital signs, or other data that may not necessarily be associated with a particular ADM.
  • Health information pertaining to preventive care may be included in one or more preventive health care modules (PHCM). At least some such information may also or may instead be included in an ADM if appropriate. For example, a routine blood pressure check may be included in a PHCM, but if the patient has a diagnosis of hypertension or is discovered to have
  • an ADM may be an "active disease risk module" (ADRM), wherein the patient has not actually developed a disease but has one or more identified risk factors indicative of an increased risk of developing the disease and potentially warranting therapeutic intervention or more intensive monitoring than would otherwise be the case.
  • ADRM active disease risk module
  • the patient could have a family history of the disease or a genotype or phenotypic characteristic associated with increased risk of developing the disease.
  • the ADRM may, for example, include at least some of the same elements as an ADM pertaining to a disease.
  • a EMR may contain genetic information regarding the patient, which may include, for example, results of tests for the presence or absence of particular genetic variations, such as single nucleotide polymorphisms (SNPs), or, in some embodiments, partial or complete genome sequences.
  • genetic information may include the patient's genotype with regard to at least some polymorphisms or mutations that are associated with (correlated with) increased risk of developing a disease or condition or that are associated with e.g., outcome, severity, treatment response, or drug metabolism variation (e.g., polymorphisms in genes encoding cytochrome P-450 enzymes that are associated with increased or decreased metabolism of various drugs).
  • At least some such genetic information may be included in a relevant ADM or ADRM.
  • a relevant ADM or ADRM For example, if the patient has a disease that is associated with particular haplotype(s), polymorphism(s), or mutation(s), the patient's genotype with respect to at least some such haplotype(s), polymorphism(s), or mutation(s) may be included in the ADM for that disease.
  • the patient has particular haplotype(s), polymorphism(s), or mutation(s) that are associated with increased risk of a disease the patient's genotype with respect to at least such haplotype(s), polymorphism(s), or mutation(s) may be included in an ADRM for that disease.
  • the EMR interface may depict ADMs as icons. Selecting an icon for a particular ADM (e.g., by clicking on it) may take the user to a document that displays information pertaining to that ADM.
  • the icons may be labeled with a tentative or definitive diagnosis.
  • different colors, shapes, and/or sizes may be used to mark the status of an ADM as tentative or definitive. For example, a tentative ADM may be pink. According to the example, when the diagnosis is deemed definitive, the color may be changed, e.g., to green.
  • an HCP may designate an ADM as "resolved" or "recurrent” if appropriate for the particular disease or condition. Additional colors or symbols may be used to distinguish such ADMs and/or to distinguish ADMs for which the definitive diagnosis may be deemed invalid according to revised diagnostic criteria.
  • a EMR may contain a patient summary.
  • the patient summary may include, for example, (a) demographic information; (b) physiologically important measurements such as height, weight, blood pressure; (c) list of conventional disease diagnoses for current (unresolved) ADMs; (d) list of current therapeutics; (e) any hospitalizations within the preceding 6 months, etc.
  • the patient summary may provide a user, e.g., a HCP or subscriber with a rapid overview of many or most significant aspects of a patient's current condition and may provide additional context that may be important for understanding or using an ADM.
  • a patient summary may be automatically generated by the EMR system and may be updated as new health information is entered.
  • the EMR system may comprise a component that supports computerized physician order entry (CPOE).
  • CPOE computerized physician order entry
  • a HCP may order a test or prescribe a treatment (e.g., a medication) from within an ADM (e.g., while viewing an ADM).
  • the screen may include a menu option that permits the HCP to order a test or prescribe a treatment.
  • a HCP may order a test or prescribe a treatment from within a non-ADM element of a particular EMR and may be offered an option to designate one or more ADMs at the time of ordering the test or prescribing the treatment.
  • test name may be automatically become part of the appropriate ADM once entered.
  • a prescription may be automatically transmitted to a pharmacy.
  • "Pharmacy" as used herein may include e.g., traditional pharmacies, online pharmacies, and other medication suppliers able to fulfill a prescription. It is envisioned that in some embodiments, pharmacists or other pharmacy workers may access the EMR system and/or the EMR system may interact directly with existing pharmacy computer systems.
  • Any one or more of the EMR or ADM elements or portions thereof may, in some embodiments, be selected by a HCP from a predetermined set of options.
  • entry of conventional disease diagnosis may be facilitated by providing an appropriate GUI element such as a scroll-down list, which may be organized at least in part based on discipline (e.g., physician specialty) or at least in part based on the ICD
  • molecular disease diagnosis may be facilitated by providing a scroll-down list (or other suitable GUI element) which may include items determined based on the conventional disease diagnosis.
  • molecular disease diagnosis may include the epidermal growth factor receptor (EGFR) mutation status of the tumor (e.g., whether the tumor harbors an EGFR mutation and, if so, the identity thereof).
  • EGFR epidermal growth factor receptor
  • a scroll-down list is but one of a variety of suitable formats by which a set of options may be presented to an HCP.
  • diagnoses are presented in a hierarchical manner. For example, a high level diagnosis might be "lung cancer". According to this example, if the HCP selects this diagnosis, a set of more specific diagnoses within the general category of "lung cancer" may be made available for selection.
  • predetermined and standardized terms, options, and/pr formats may enable different HCPs who may use the EMR for a particular patient to more clearly understand the patient's health care history. It is also envisioned that the use of predetermined and standardized terms, options, and/or formats may facilitate a variety of other uses of the EMR database such as, for example, (i) searching for, analyzing, and/or extracting relevant health information from the database for any of a wide variety of research purposes; or (ii) identifying HCPs or HCOs experienced in caring for patients that have a particular disease or that have particular disease characteristics (e.g., unusual symptoms or signs).
  • the ADM will be searchable at least based on conventional disease diagnosis, molecular diagnosis, diagnostics, and treatments. For example, a user could extract or analyze all AD Ms for patients diagnosed with NSCLC who were treated with a particular combination of chemotherapeutic agents.
  • test results e.g., lab test results, images, etc.
  • entry of test results may be performed at the site where such results are obtained, e.g., by appropriately authorized individuals.
  • results may not become part of the EMR until the contributor who ordered the test acknowledges having reviewed them.
  • individuals operating under the direction of a contributor or responsible for entering test results may be assigned an ID that allows them to perform a selected set of tasks relating to entering data but may have limited or no ability to view or modify previously entered data.
  • the contributor when a contributor logs on to the EMR system, the contributor may be informed of any new information that has been entered for his or her patients, e.g., results of tests ordered by the contributor or entered at the contributor's direction, and that have not yet been reviewed by the contributor. The contributor may then review the information and may be offered an opportunity to acknowledge having done so, e.g., by checking a box. The information may then become part of the EMR and the relevant ADM(s). (If the information had been entered, e.g., by or under direction of a different HCP of the patient, the information may already be part of the EMR and relevant ADM.) In some embodiments the contributor may assign the information to an ADM. In some embodiments the information may be automatically assigned to the appropriate ADM and further may besubject to review and acknowledgement by a contributor.
  • a contributor may order a test from within an ADM.
  • an ADM screen may include an option that permits the contributor to order a test.
  • a contributor may order a test from the main screen for a particular EMR and may be offered an option to designate one or more
  • test result may automatically become part of the appropriate ADM once entered (subject to review and acknowledgement by the contributor).
  • screening tests may become part of the PHCM.
  • a contributor may receive or may elect to receive an alert (e.g., via email, text message, voicemail, fax, etc.) when information about that contributor's patients (or about specific patient(s) of the contributor) is entered.
  • the system may thus facilitate timely conveyance of important health information to health care providers. Alerts may be prioritized by importance.
  • the EMR system may provide a contributor with reminders or suggestions to order particular diagnostic tests, fill or refill prescriptions, discontinue or consider discontinuing medications when no longer required or appropriate, etc.
  • a EMR or ADM may comprise one or more types of data that may facilitate medically relevant research but that may not be directly relevant to the care of the patient.
  • data may include, for example, information regarding availability for use in research studies of biological samples obtained from the patient, answers to health-related questionnaires or surveys to which the patient has responded, etc.
  • the EMR system may provide computer-based tools (which may be embodied in hardware, software, or a combination thereof) that permit HCPs to perform analyses of their patient population.
  • a tool may permit an HCP to retrieve the identity or number of patients in his or her patient population that have e.g., a particular disease diagnosis, are taking a particular medication, have received a particular screening test, etc. and, further may permit the HCP to track such information over time (e.g., in graphical or other display format).
  • a tool may permit a HCP to perform comparisons of his or her patient population with the overall population of patients having a particular disease.
  • a tool may permit a HCP to search for physicians who have within their patient population one or more patients who exhibit symptoms, signs, or other features similar to those of a particular patient of the HCP. The HCP may thereby identify physicians with particular expertise or experience who may be consulted for advice or to whom a patient may be referred.
  • a tool may permit a HCP to search for ADMs of patients who have received a particular treatment. Reviewing or analyzing such ADMs may assist the HCP in deciding whether such treatment may be appropriate for a particular patient.
  • the EMR system may comprise multiple different types of
  • An ADM template may be a generic or universal template usable for any disease or may be a more specialized template.
  • the EMR system may comprise an ADM template designed for a particular disease, e.g., wherein the ADM template may be designed to be able to capture, in a searchable format, information pertaining to diagnostics and treatments relevant to the disease and, e.g., other features relevant to the disease and/or its treatment.
  • an ADM template designed for that disease may be used henceforth.
  • Such an ADM template may be referred to as a "disease-specialized ADM template".
  • a disease-specialized ADM template may be adapted to capture information pertaining to e.g., a set of common or significant symptoms, signs (which may include diagnostic test results and/or physical exam findings),
  • Such common or significant symptoms, signs, complications, or potential outcomes may be referred to as "key" symptoms, signs, complications, or potential outcomes.
  • the designation of a set of key symptoms, signs, complications, or potential outcomes for a disease may be within the discretion of the individual or entity that implements or controls implementation of the EMR system or ADM template, e.g., the business entity. Designation of key symptoms, signs, complications, and potential outcomes may, for example, be based on sound medical judgment and current state of the art knowledge.
  • a key symptom, sign, complication, or outcome may be one whose presence, absence, and/or characteristics (e.g., severity) may affect management of the disease or may provide means to assess the effectiveness of disease management.
  • a key symptom, sign, complication, or outcome may be predictive or indicative of treatment efficacy or failure or side effect(s) or may be predictive or indicative of a possible need to modify disease management.
  • the EMR system may comprise disease-specialized ADM templates for each of multiple different diseases. It will be understood that the EMR system in at least some embodiments may not provide a disease-specialized ADM template for every disease.
  • an ADM template may be, e.g., discipline-specialized but not disease-specialized.
  • the EMR system may provide an ADM template applicable for a range of diseases within the scope of a particular discipline.
  • the EMR system may include disease-specialized ADM templates for at least the 3, 5, or 10 most commonly diagnosed diseases in one or more disciplines.
  • the EMR system may include a disease-specialized ADM template for each of at least 10, 20, 30, 50, 100, or 200 diseases.
  • an ADM template may be, e.g., discipline-specialized and disease-specialized.
  • a disease-specialized ADM template may be applicable to multiple distinct diseases, which form a "disease group".
  • Disease group may refer to a group of diseases that are sufficiently similar such that the same ADM template may reasonably be used to capture information pertaining to at least diagnostics and treatments, and, e.g., key symptoms, signs, complications, and/or potential outcomes relevant to the disease while not requesting entry of significant amounts of information that is relevant to only a minority of diseases in the group.
  • the designation of a particular set of diseases as a disease group may be within the discretion of the individual or entity that implements or controls implementation of the EMR system or ADM template, e.g., the business entity and may, for example, be based on sound medical judgment and current state of the art knowledge.
  • the EMR system may comprise more than one disease- specialized ADM template for a particular disease.
  • the EMR system may comprise a "standard" ADM template for a disease and at least one additional ADM template.
  • an additional ADM template may comprise a standard ADM template and further may comprise fields for one or more supplementary data elements to be entered.
  • an additional ADM template may contain one or more fields included at least in part for particular research purposes.
  • an additional ADM template may include at least some fields for data elements that pertain specifically to, e.g., a particular treatment, age group, or presence of a concomitant disease and may not be relevant to most patients having the disease.
  • the disclosure provides a method of collecting health information, the method may comprise providing an ADM template to a HCP and receiving information entered into the ADM template by or under direction of the HCP.
  • the disclosure may provide a database stored on a computer-readable medium, the database comprising multiple ADMs.
  • the disclosure may provide a computer program product comprising at least one ADM template.
  • the ADM template may be a disease-specialized ADM template adapted for collecting information pertaining at least to diagnostics and treatments for a disease and, e.g., to key symptoms, signs, complications, and/or potential outcomes relevant to the disease.
  • the computer program product may comprise a collection of disease- specialized ADM templates, each applicable to a different disease.
  • a collection of disease-specialized ADM templates may pertain to diseases corresponding to a particular health care discipline.
  • the disclosure may provide a computer- readable medium having a computer program product of the disclosure stored thereon, wherein the computer program product comprises at least one ADM template.
  • the disclosure may provide a computer-readable medium having a computer program product of the disclosure stored thereon, wherein the computer program product comprises a disease-specialized ADM template or a collection of disease-specialized ADM templates, wherein the ADM templates, e.g., pertain to a particular health care discipline.
  • Many diseases may affect multiple organ systems and/or may be appropriately treated by HCPs who practice in any of various different specialties or subspecialties. ADMs for such diseases may be included in multiple discipline-specific sets of ADM templates.
  • a health care "discipline” may refer to an area of practice in the art and science of health care. Broadly, disciplines may be classified as, e.g., medical (in which the main diagnostic and therapeutic activities are not major surgery) or surgical (in which surgery is a significant or main part of the diagnostic and/or therapeutic activities), by age range of patients (e.g., pediatrics), body system (where symptoms and diseases typically diagnosed and/or treated arise from or mainly affect a particular organ system or physiological system), as mainly diagnostic or mainly therapeutic, or based on techniques used (e.g., radiology).
  • medical in which the main diagnostic and therapeutic activities are not major surgery
  • surgical in which surgery is a significant or main part of the diagnostic and/or therapeutic activities
  • age range of patients e.g., pediatrics
  • body system where symptoms and diseases typically diagnosed and/or treated arise from or mainly affect a particular organ system or physiological system
  • diagnostic or mainly therapeutic e.g., radiology
  • a discipline may be a specialty or subspecialty in which certification is offered by, e.g., a member board of the American Board of Medical Specialties (ABMS, http://www.abms.org), such as the American Board of Internal Medicine fhtt ://www . abi m. org./) or other ABMS member boards listed on the ABMS website
  • exemplary specialties and subspecialties include, e.g., allergy and immunology; cardiovascular disease; dermatology; endocrinology, diabetes & metabolism; family medicine; gastroenterology; hematology; infectious disease; internal medicine; nephrology; neurology; obstetrics & gynecology;
  • oncology e.g., medical oncology
  • ophthalmology e.g., ophthalmology
  • otolaryngology pediatrics
  • pulmonary disease e.g., pulmonary disease
  • psychiatry e.g., rheumatology
  • urology e.g., urology
  • a discipline may be long term care, rehabilitation, or physical therapy.
  • a specialty may embrace multiple specialties and/or subspecialties.
  • internal medicine encompasses multiple subspecialties. It will be understood that the scope of various specialties and subspecialties may overlap or change over time or not be precisely defined. However, specialties and subspecialties are well recognized by those of ordinary skill in the art, and they would know which diseases are commonly treated by HCPs practicing in a particular specialty or subspecialty.
  • multiple subspecialties or specialties may be aggregated into a single discipline for purposes of the EMR system.
  • a specialty or subspecialty may be divided into multiple (e.g., 2, 3, or more) disciplines for purposes of the EMR system.
  • the EMR system may comprise a scheduling component.
  • the scheduling component may, in various embodiments, include, e.g., any capability included in existing electronic or paper-based scheduling systems.
  • the scheduling system may, for example, assist in the scheduling of, e.g., patient appointments (e.g., follow-up appointments, referrals, appointments for tests, etc.), scheduling of resources (e.g., examination rooms, diagnostic equipment, etc.).
  • the EMR system may comprise a billing component.
  • the billing component may, in various embodiments, include, e.g., any capability included in existing electronic or paper-based medical coding or billing system.
  • the EMR system may provide input to an existing medical billing system based on information entered into the EMR system.
  • the EMR system may include, e.g., any capability included in any standard EMR system and/or practice management system.
  • the EMR system may include or may access any of a variety of collections of information in addition to patient health information incorporated into EMRs.
  • information may include information pertaining to, e.g., diseases, diagnoses, diagnostics, medications (e.g., National Drug Data File Plus drug database), health related costs (e.g., of diagnostics and/or therapeutics), medical terms (e.g., glossaries, translations), medical coding systems, means for converting between different coding or terminology systems, etc.
  • Such compilations may, in some embodiments, be in the form of tables in a database.
  • the EMR system may use such information in the course of analyzing health information submitted by contributors, assembling EMRs, and/or analyzing requests for information submitted by contributor or subscribers.
  • data submitted to the EMR system may be tagged with metadata of any of a variety of types, which metadata may, for example, facilitate analysis of the data for research purposes.
  • a histopathologic test, biopsy, or surgery may be tagged with metadata indicating whether a related biological sample (e.g., a tissue sample) is available for research studies.
  • An ADM may be tagged with metadata indicating whether the ADM was used in a published research study and, if so, a citation of the study or a link to the relevant study or an abstract thereof online, e.g., in Pubmed.
  • a user may register (or be registered) with the business entity before beginning to use the EMR system.
  • a contributor may register or may be registered before the contributor first submits health information.
  • Contributor registration may entail providing information that includes at least the contributor's name and an address and, e.g., if applicable, any other information requested by the business entity (collectively "registration information").
  • registration information e.g., if applicable, any other information requested by the business entity.
  • HCPs e.g., physicians
  • HCPs may be required to provide their license number, DEA number or other prescriber number, employer name or hospital affiliation (if applicable), mobile phone number, business address, and/or email address.
  • the HCP's credentials may be checked by the EMR system.
  • the EMR system may determine whether that HCO has registered and, if so, whether the HCP is included among the list of HCPs provided by the HCO. In some embodiments, subscribers may be required to provide a name and billing address. In some embodiments, the EMR system may collect such information as the business entity may deem appropriate to, e.g., maintain proper shareholder lists and satisfy any relevant legal requirements.
  • the user may select an identifier (user ID) and, e.g., a password, for use in accessing the system. In other embodiments a user ID and/or password may be assigned by the business entity. A user ID and/or password may, for example, comprise numbers, letters, non-alphanumeric symbols, or a combination thereof.
  • the EMR system may assign an internal identifier
  • Information contributed by a contributor may be tagged with that contributor's user ID, internal ID, and/or password, allowing the source of the information to be traced.
  • a user account for the contributor may be established by the EMR system that allow the contributor to submit health information to the EMR system and retrieve information therefrom.
  • the particular access rights may vary depending at least in part on whether the contributor is an HCP, auto-contributor, or proxy contributor.
  • a user account may allow an auto-contributor to view his or her EMR and, e.g., to add certain types of health information to it.
  • a proxy contributor may view and add to the EMR of an individual for whom he or she serves as proxy contributor.
  • a user account allows HCPs to access EMRs for his or her current patients and submit data to be added thereto.
  • patient authorization may be required prior to the initial access to the patient's EMR.
  • an HCP may have access to only certain portions of the EMR of at least some of their patients. For example, in some embodiments not all HCPs may have access to all ADMs for a patient.
  • a patient may be able to designate which HCPs are to be provided with access to an ADM, whether a particular HCP is to be provided with access to an ADM, or whether access to an ADM should be provided by default to all HCPs authorized to access the EMR.
  • ADMs may be assigned an access status at the time of their creation. For example, an ADM may be assigned an access status of "unrestricted" or "restricted".
  • ADMs with an access status of "unrestricted” may be automatically accessible by a patient's HCPs (after initial authorization), while ADMs with a status of "restricted” may be accessible only with patient authorization.
  • a patient may assign or request an HCP to assign a status of "restricted” to an ADM for a mental health disorder.
  • an HCP may select an access status for an ADM as part of the process of creating it.
  • at least some ADMs may be assigned a default access status of "unrestricted” at the time of creation.
  • at least some ADMs may be assigned a default access status of "restricted” at the time of creation.
  • access to one or more non-ADM elements of a EMR or to selected portions of an ADM may also or alternately be restricted.
  • an exemplary system may include a database containing information pertaining to the user accounts ("user account database").
  • the user account database may include, for example, at least the registration data, user ID, and access rights for each user.
  • an exemplary system may maintain a record for each contributor that contains data relating to the contributor's submissions and the incentives earned by the contributor.
  • This data may be included in the user account database as part of the user account information or as a separate account. For purposes of description herein it will be assumed that such data may be maintained as part of the user account, but it should be understood that the data may be maintained as a separate account.
  • the account data may include, e.g., any of the following: (a) a record of at least some of the submissions from the contributor to the EMR system; (b) the number of EMRs or ADMs assembled from the contributor's submissions; (c) the number of EMRs or ADMs in which the contributor has an interest and may further include, the extent of such interest; (d) the number of times each EMR or ADM in which the contributor has an interest has been accessed by a subscriber; (e) the number of patients of the contributor for whom a EMR has been established; (f) the incentives that the contributor has earned, etc.
  • Incentives may be used herein to refer to any form of tangible or intangible good or service provided as compensation to a contributor by the business entity.
  • an incentive comprises a share in the business entity.
  • one or more shares would be issued by the business entity to the contributor or the contributor's designee upon submission of health information adequate to assemble a selected number of EMRs or ADMs.
  • share(s) are issued based at least in part on the number of times the EMR or ADM is accessed by subscribers.
  • the primary contributor of a particular EMR or ADM would be entitled to receive one share each time that access to the EMR or ADM, respectively, has been accessed a specified number of times (e.g., 10, 20, or 50 times, etc.).
  • a contributor is said to have an "interest" in a particular EMR or ADM if the contributor is entitled to receive an incentive based at least in part on the contributor's submission of health information that is incorporated into the EMR or ADM or based at least in part on access of the EMR or ADM by a subscriber.
  • an incentive comprises a monetary incentive (also referred to herein as "money”), which may be provided as cash (currency), check, direct deposit to a contributor's account at a financial institution (optionally located in Switzerland), etc.
  • a monetary incentive also referred to herein as "money”
  • cash currency
  • check direct deposit to a contributor's account at a financial institution (optionally located in Switzerland), etc.
  • an incentive comprises a gift certificate that may be redeemed, for example, at any of one or more retailers, service providers, or other entities offering tangible or intangible items (goods and/or services).
  • an incentive may consist at least in part of one or more tangible or intangible items (s), such as medical supplies or equipment.
  • a contributor may receive an incentive in the form of "points" (which may also or alternately be termed virtual money) that the contributor may, for example, apply towards acquisition of selected tangible or intangible item(s), or exchange for money or shares in the business entity.
  • the Contibutor's account may keep track of the number of points earned by the contributor and their application by the contributor towards the acquisition of selected item(s) or their exchange for money or shares.
  • the share may be issued to the contributor or the contributor's designee, and the share database may be updated accordingly.
  • an incentive may comprise multiple different forms of incentive.
  • an incentive may include cash and one or more shares or points.
  • a contributor may receive an incentive under any of a variety of circumstances in various embodiments.
  • receipt of an incentive may be based at least in part on submission of health information by the contributor and/or request(s) for use of such health information by a subscriber. For example, in some embodiments submission of health information that is, e.g., adequate to assemble a selected number of EMRs, may entitle the contributor to an incentive. In some embodiments submission of health information that is, e.g., adequate to assemble a selected number of tentative ADMs, may entitle the contributor to an incentive.
  • submission of health information that is, e.g., adequate to assemble a selected number of definitive ADMs may entitle the contributor to an incentive.
  • submission of health information that contributes to an ADM may entitle the contributor to an incentive.
  • submission of health information that may allow a tentative diagnosis to be established as a definitive diagnosis according to the EMR system diagnostic criteria for that diagnosis may entitle the contributor to an incentive.
  • a contributor may receive an incentive following a request by a subscriber to access a EMR to which the contributor contributed, e.g., as a primary or secondary contributor.
  • a contributor may receive an incentive following a request by a subscriber to access an ADM to which the contributor contributed, e.g., as a primary or secondary contributor. For example, if a subscriber requests access to
  • ADMs having a definitive diagnosis of "rheumatoid arthritis” contributors to such ADMs may receive an incentive. For example, if a subscriber requests access to ADMs having a definitive diagnosis of "rheumatoid arthritis", and in which the patient was prescribed
  • the incentive may be considered as a royalty to the contributor for use of the EMR or ADM.
  • the contributor may be entitled to a certain sum of money per access to a EMR or ADM to which the contributor contributed information, wherein the total amount to which the contributor is entitled (e.g., within a given month) depends at least in part on the number of requests for access to such EMRs or ADMs by subscribers and, e.g., at least in part on the subscription class of the subscriber(s) making such requests.
  • an incentive may be larger if the access was by a subscriber paying a larger fee for access versus a smaller fee (or no fee).
  • the incentive may be a fraction of the revenue attributable to the EMR or ADM. For example, an incentive may be between
  • a contributor e.g., an HCP may be guaranteed at least a minimum incentive for participation, regardless of whether the health information contributed is accessed by subscriber(s).
  • an incentive may comprise or consist of at least one share in the business entity.
  • the contributor may receive one share as remuneration for submission of a health information dataset adequate to assemble one EMR or if an ADM contributed by the contributor is accessed by a subscriber.
  • the number of shares received may depend at least in part on the share price.
  • the payment per EMR may be a number of shares worth a selected amount of money.
  • the payment may be distributed in a variety of ways. In some embodiments, if multiple contributors contribute to a EMR or ADM for a particular patient, the payment may be distributed in a variety of ways. In some
  • the primary contributor of the EMR for that patient may receive the payment.
  • the contributor who contributed the ADM may receive the payment.
  • the contributor who contributed the tentative diagnosis that is ultimately deemed definitive may receive the payment.
  • the contributor who contributed the final item of data required to establish a tentative diagnosis as a definitive diagnosis may receive the payment.
  • the contributor who contributed the definitive diagnosis may receive the payment.
  • only a patient's HCPs may contribute a tentative or potentially definitive diagnosis.
  • a contributor who is not the patient's HCP but who has access to the ADM may contribute a tentative or potentially definitive diagnosis that could be confirmed by the system as definitive.
  • a HCP who is not the patient's HCP or a subscriber who may or may not be a HCP may contribute a proposed definitive diagnosis in some embodiments.
  • an incentive may be divided among multiple contributors who have contributed to the definitive ADM.
  • the formula for dividing an incentive may vary. For example, in some embodiments between 10% and 90% may be given to the primary contributor of the EMR that contains the ADM, and the balance may be distributed among secondary contributors (if any) who contributed data contained in the ADM. In some embodiments 10% may be given to the primary contributor of the EMR that contains the
  • ADM 50% may be given to the contributor of the ADM (who may or may not be the primary contributor of the EMR), and the balance may be distributed among secondary contributors who contributed data contained in the ADM (if any). In some embodiments, if the primary contributor contributed the ADM, all data contained therein, and the definitive diagnosis, then the entire incentive may be given to the primary contributor.
  • an incentive may be distributed at least in part randomly. For example, any contributor to an ADM may have an equal chance of receiving an incentive attributable to a request of that ADM by a subscriber.
  • an incentive distribution scheme may be disclosed to contributors. In some embodiments, an incentive distribution scheme may be at least in part not disclosed to contributors.
  • HCOs may have different policies regarding the distribution of incentives to their employees or affiliated HCPs. For example, in some embodiments, some HCOs may permit incentives, e.g., shares, to be issued to and owned by employees or affiliated HCPs. In some embodiments, some HCOs may require that incentives, e.g., shares, be issued to and owned by them. In some embodiments, some HCOs may require that incentives be issued to them for subsequent transfer to employees or affiliated HCPs. Some HCOs may restrict the type or amount of incentive that may be provided to their employees or affiliated HCPs. Various embodiments may accommodate these models for distribution and ownership of incentives and, e.g., other models as appropriate. In some embodiments, the type and/or amount of incentive for which a contributor may be eligible may be included in the account information for that user. It should be understood that incentive distribution schemes may change over time.
  • different incentives may be provided for contribution to a type 1 ADM versus a type 2 ADM or for contribution to ADMs created using different ADM templates.
  • an ADM template containing numerous fields may merit a larger incentive than an ADM template that contains only a few fields.
  • an exemplary system may include a component that may be used to manage incentives, e.g., to keep track of the number and type of incentives earned by each contributor and, e.g., to analyze or provide information or report(s) relating to a contributor's remuneration, as requested, to arrange for distribution of incentives to contributors, etc.
  • Data regarding the number and type of incentives may be stored in a database, e.g., in a user account database, a separate database, or both.
  • the component may at least in part arrange for transfer of incentives to contributors.
  • the component may transmit instructions to a financial institution, retailer, or other entity in order to effect transfer of money, items, etc., to the contributor.
  • the component may interface with the database and may, for example, update the database accordingly after arranging for transfer of an incentive.
  • the disclosure may provide an application that allows a contributor to request (via, e.g., a portable electronic device) information regarding the incentives earned by the contributor.
  • an incentive may be a share of the business entity
  • the component may keep track of the number and type of shares owned by each contributor and, e.g., may analyze or provide information or report(s) relating to the contributor's ownership interest as requested.
  • the database may keep track of those shares of the business entity that are owned by non-contributors.
  • the disclosure may provide an application that allows a contributor to request (via, e.g., a portable electronic device) information regarding the number of shares owned by or earned by the contributor. Information or reports generated using information in the database may be used by the business entity in the course of doing business.
  • the business entity may provide remuneration to patients based at least in part on access of their (ordinarily de-identified) health information (e.g., ADMs pertaining to them) by subscribers.
  • the remuneration may take the form of incentives, as described herein, and may be managed by the business entity in the same way.
  • the patient may or may not be a contributor.
  • patients may have accounts and may, e.g., be provided with account data pertaining to use of their health information and/or remuneration, as described herein for incentives.
  • the business entity may offer access to the EMR database to third parties, e.g., in exchange for a fee.
  • third parties may be, for example, medical researchers, organizations such as pharmaceutical companies or insurance companies, government entities (e.g., Federal, state, and/or local government entities), or simply individuals interested in the content of the database.
  • individuals, organizations, or entities that are provided with access to the database, e.g.,, in exchange for a fee may be referred to as "licensees" or "subscribers”.
  • the arrangement under which such access is granted or the set of access rights provided may be referred to as a "subscription" or "license”.
  • a subscription may provide a single access session to the database in exchange for a one-time fee.
  • a subscription allows the subscriber to access the database multiple times over a defined period of time, such as 1 month, 3 months, 1 year, etc. The number of access sessions and/or queries permitted within the defined time period may be limited or unlimited in various embodiments.
  • a site license may be provided that allows multiple users to have access to the database.
  • Each subscriber and/or user may select or may be assigned a user ID and, in at least some embodiments, a password.
  • Some types of subscription may permit the licensee to print and/or download information while other types may only permit viewing.
  • Some types of subscription may permit the licensee to access ADMs only.
  • Some types of subscriptions may permit the licensee to access de-identified EMRs or portions thereof such as patient summary data. For example, if a researcher is interested in identifying potential combination therapies for a particular disease, the researcher may want to obtain a complete list of the patient's medications in addition to the particular medications prescribed for the disease of interest.
  • the fee for accessing different EMRs or ADMs may differ based at least in part on diagnosis, treatment or other elements of the EMR or ADM.
  • the business entity may give subscriptions to at least some contributors (e.g., the contributor may receive a subscription without paying a fee). In some embodiments the business entity may give subscriptions to at least some HCPs who are not contributors (e.g., the HCP may receive a subscription without paying a fee). In some embodiments, the business entity may give subscriptions to at least some HCOs. In some embodiments, the business entity may give subscriptions to students (e.g., students studying a health care profession, such as medical students, nursing students, dentistry students, pharmacy students) and/or trainees in a health care profession (e.g., interns, residents, etc.).
  • students e.g., students studying a health care profession, such as medical students, nursing students, dentistry students, pharmacy students
  • trainees in a health care profession e.g., interns, residents, etc.
  • subscriptions may be provided to members of HCP professional organizations, e.g., as a membership benefit.
  • third parties may purchase or otherwise sponsor subscriptions for others.
  • the business entity may give subscriptions to nonprofit organizations that are engaged in research, e.g., medical research.
  • the business entity may require at least some subscribers to publish, or to deposit in a publicly available repository, results of any studies performed using the EMR database. Such results may be required to be published or deposited within a reasonable time such as, for example, within no more than 12 months from obtaining a result or completing a study. It is envisioned that the value and utility of the EMR system, according to some embodiments, may increase over time in part as a result of the performance of such studies.
  • users may be provided with access to the content of the EMR database up to the extent permitted by applicable law (including any regulations issued by government agencies pursuant to such laws), such as the U.S. Health Insurance Portability and Accountability Act of 1996 (" ⁇ ") Public Law 104-191, as amended from time to time.
  • applicable law including any regulations issued by government agencies pursuant to such laws
  • ⁇ Health Insurance Portability and Accountability Act of 1996
  • the extent of access that is permissible under applicable law may vary depending upon the user.
  • a patient's HCPs and the patient (and patient representatives, if any) may have access to the patient's complete EMR.
  • Certain subscribers would be provided with access only to de-identified health information.
  • de-identification comprises removing or blocking access to protected health information (PHI) as defined in the regulations issued by the U.S.
  • PHI protected health information
  • HHS Health and Human Services
  • Primary Rule Standards for Privacy of Individually Identifiable Health Information
  • tertain subscribers may be provided with access to at least some PHI if performing Research (as defined by the Privacy Rule) and if the requirements of the Privacy Rule have been satisfied.
  • laws and/or rules of countries or jurisdictions other than the U.S. may be applied in addition to or instead of those of the U.S., which may be selected based at least in part on where the patient resides, where the HCP practices, and/or where the business entity is incorporated or physically located.
  • An exemplary system may comprise one or more components that at least in part facilitates use of the EMR database by subscribers.
  • a component may provide subscribers with a GUI that facilitates query creation. Subscribers may, for example, be permitted to search the EMR database using various fields, Boolean operators, and/or natural language queries.
  • Subscribers may, in various embodiments, download ADMs or portions thereof onto their own computer systems for analysis independently of the EMR system (e.g., using their own proprietary tools) or may perform analysis using computer-based tools provided by the EMR system or may use a combination of such approaches.
  • the EMR system may provide one or more computer-based tools that include facilities for data manipulation, calculation, graphical display, and/or statistical analysis of ADMs.
  • a subscriber could perform any of a variety of types of analysis on ADMs in various embodiments.
  • a subscriber may determine the frequency with which particular symptoms or signs are present in patients with particular disease(s), determine the frequency with which particular diagnostic tests or treatments are utilized in patients with particular disease(s), identify correlations between various symptoms, signs, complications, treatments, etc. For example, in some embodiments, a subscriber may determine the percentage of rheumatoid arthritis patients receiving Enbrel® (etanercept) versus Humira® (adalimumab) versus other medications or no medication, or may determine the distribution of patients receiving Enbrel or Humira by disease or may determine the percentage of patients receiving Enbrel or
  • Humira who developed an infection from a particular pathogen within a given time period.
  • a tool may assist in data mining activities.
  • tata mining may encompass the automatic or semi-automatic analysis of large quantities of data to extract previously unknown interesting patterns such as groups of data records or structures in the data that are in some way "similar" (e.g., cluster analysis), unusual records
  • the EMR system may provide tool(s) that facilitate assembling a more compact representation of a data set, such as visualization tools or report generation tools.
  • tools may be provided to extract data into standard available data analysis or statistical software programs, packages or environments such as SAS ® , SPSS, Systat ® ,
  • Minitab ® , R, etc. or to analyze data using tools such as those provided in such software.
  • the EMR system may empower HCPs to develop and explore health-related questions or hypotheses that may arise in the course of their practice activities. Such questions or hypotheses may be explored by analyzing ADMs from the EMR database.
  • the EMR system may allow HCPs to submit the results of such analyses and makes the results available to other users and, e.g., to the public.
  • tools that facilitate HCP interaction or collaboration to address health-related questions may be provided.
  • HCPs may submit suggestions via the EMR system for fields to be included in future ADM templates.
  • the EMR system may assist HCPs in remaining up to date with current health care-related knowledge, e.g., current diagnostic and/or therapeutic approaches.
  • the EMR system may provide information or links to information pertaining to at least some conventional disease diagnoses, molecular disease diagnoses, diagnostics, and/or therapeutics.
  • Such information may include, for example, publications such as diagnosis or treatment guidelines, research articles, educational materials prepared by or on behalf of the business entity, etc.
  • the EMR system may in some embodiments be useful as a tool to help students or HCPs learn or prepare for examinations including, but not limited to, board examinations or recertification examinations.
  • the EMR system may be useful in preparing future revisions of diagnostic or therapeutic guidelines.
  • revisions may be based at least in part on information in published research studies (e.g., studies described in articles available in PubMed).
  • Review and/or analysis of ADMs may supplement such information or may be used to address unanswered questions about a disease or therapy.
  • an ADM template may incorporate one or more fields designed to help an address a question or unresolved issue relating to disease diagnosis or treatment.
  • a subscriber may elect to receive an alert (e.g., via email, text message, phone call, voicemail, fax, etc.) when particular information of interest to the subscriber is entered or when particular conditions of interest to the subscriber are met. For example, if a subscriber is interested in analyzing ADMs having a definitive diagnosis of rheumatoid arthritis and for which the patient was prescribed Enbrel, the EMR system may provide an alert to the subscriber when a predetermined number of such ADMs have been created. As another example, the EMR system may provide an alert to a government entity when a predetermined number of tentative diagnoses of "influenza" are entered within a particular geographic area during a particular time period. The system may thus, in some embodiments, facilitate timely conveyance of important health information to government authorities. In some embodiments, alerts may be prioritized by importance, e.g., as predetermined by the subscriber.
  • an exemplary system may comprise one or more components that at least in part manages subscriptions.
  • the component may keep track of access rights, use of the database by subscribers, payments due and received, etc.
  • Such a component may be, e.g., part of a user account manager.
  • the EMR system may be used to facilitate the performance of clinical studies, e.g., clinical studies aimed at obtaining or maintaining regulatory approval or clearance or complying with legal requirements for marketing of medically related products such as pharmaceutical agents (also referred to as "drugs" herein, as defined, e.g., by the US Federal Food, Drug, and Cosmetic Act (FD&C Act)), diagnostic agents (for in vivo or ex vivo use) or diagnostic kits, or medical devices (e.g., implantable devices such as pacemakers, artificial joints, etc.
  • pharmaceutical agents also referred to as "drugs” herein, as defined, e.g., by the US Federal Food, Drug, and Cosmetic Act (FD&C Act)
  • diagnostic agents for in vivo or ex vivo use
  • diagnostic kits e.g., implantable devices such as pacemakers, artificial joints, etc.
  • the regulatory agency is the U.S. Food & Drug Administration (FDA) and the medically related or health related product may be a drug.
  • FDA U.S. Food & Drug Administration
  • the agency may be another regulatory agency such as a regulatory agency in another jurisdiction, such as Europe, Japan, China, India, Brazil, etc.
  • the medically related or health related product may be any medically related or health related product, e.g., any regulated medically related or health related product.
  • All U.S. federal legislation (laws and related regulations) pertaining to regulation of medically related and/or health related products and processes included in the Code of Laws of the United States of America (variously abbreviated to Code of Laws of the United States, United States Code, U.S. Code, or U.S.C.) and/or included in the U.S.
  • a pharmaceutical company may be any company engaged in the development, production, and/or marketing of one or more pharmaceutical agents, diagnostic agents, diagnostic kits, medical or surgical devices, combination products (as defined in 21 CFR 3.2(e)).
  • a drug may be a brand name drug, a generic drug, a prescription drug, or an over-the-counter (OTC) drug.
  • clinical study may be used interchangeably herein with “clinical trial” or “clinical investigation.”
  • the term may be intended to encompass any biomedical or health- related research study in human beings (often referred to as “subjects”).
  • a clinical study may follow an at least in part pre-defined protocol.
  • a clinical study may be an interventional study or an observational study.
  • Interventional studies may be those in which subjects are assigned to a treatment or other intervention, and one or more outcomes are assessed, e.g., to determine whether the intervention had an effect on the outcome.
  • Observational studies may be those in which individuals are observed and at least one outcome is assessed (without having provided an intervention believed or known to potentially have an effect on such outcome(s)).
  • the term "sponsor” may refer to an entity, organization, or individual who takes responsibility for and, may initiate a clinical investigation.
  • the sponsor may be, for example, an individual or pharmaceutical company, governmental agency, academic institution, private organization, or other organization.
  • a trial may have multiple sponsors and/or the sponsor may change during the course of the trial.
  • a sponsor may engage an organization such as a contract research organization, also referred to herein as a clinical research organization, (CRO) to fulfill at least some of its responsibilities for the trial or otherwise provide services relating to the trial (which services may include using the EMR database).
  • CRO clinical research organization
  • the EMR system may be used in a clinical trial by using ADMs to identify or enroll subjects and/or to gather data pertaining to the trial.
  • ADMs a clinical study in which an ADM is used, e.g., to identify or enroll subjects and/or to gather data pertaining to the study may be referred to as an "ADM-assisted study".
  • an ADM may be used to determine whether a subject meets predetermined inclusion criteria (subject eligibility) and/or to gather data pertaining to outcome.
  • outcome encompasses any event, occurrence, measurement, etc., of interest in the context of a clinical study, e.g., any event, occurrence, or measurement that is relevant or possibly relevant to the effect of an entity being studied on a subject.
  • An outcome may be an occurrence or change in a symptom, sign (e.g., physical exam finding, laboratory value or other test result), or disease (e.g., improvement or worsening).
  • An outcome may be a predefined outcome (i.e., the outcome is defined as being of interest prior to the initiation of the study) or an outcome that is not necessarily predefined, such as an unexpected adverse event.
  • An outcome may be a composite outcome derived from multiple individual outcomes or measurements.
  • an outcome is an "endpoint", which term generally refers to an outcome that is a target outcome of a trial (e.g., an outcome that the trial is intended to assess, e.g., an outcome that may be evaluated to determine whether a drug or device is effective or whose occurrence may mandate that a subject discontinue treatment with the entity under study).
  • a clinical trial endpoint may, in some embodiments, be a clinical endpoint or a surrogate endpoint.
  • An endpoint may be designed or selected specifically for a particular clinical trial.
  • Many typical clinical trial endpoints are known in the art.
  • a common surrogate endpoint is serum cholesterol measurement.
  • a relevant clinical endpoint for such agents may be major coronary heart disease events as myocardial infarction.
  • common clinical endpoints include discovery of local recurrence, discovery of regional metastasis, discovery of distant metastasis, onset or change in symptoms (e.g., quality of life assessment), hospitalization, increase or decrease in pain medication requirement, onset of toxicity (e.g., dose-limiting toxicity), requirement of salvage chemotherapy, requirement of salvage surgery, requirement of salvage radiotherapy, death from any cause or death from cancer.
  • onset or change in symptoms e.g., quality of life assessment
  • hospitalization increase or decrease in pain medication requirement
  • onset of toxicity e.g., dose-limiting toxicity
  • requirement of salvage chemotherapy requirement of salvage surgery
  • requirement of salvage radiotherapy death from any cause or death from cancer.
  • Clinical trials in cancer may measure objective response rate, e.g., as defined using the Response Evaluation Criteria In Solid Tumors (RECIST) guideline (Therasse, P., et al, Journal of the National Cancer Institute, 92(3): 205- 216 (2000) or revised RECIST guideline (version 1.1) (Eisenhauer,E.A., et al, Eur J Cancer. 45(2):228-47 (2009)) or other accepted guidelines, e.g., for hematological malignancies or brain tumors. For example, an outcome may be classified as a complete response, partial response, progressive disease, or stable disease. An endpoint may be agreed upon by a sponsor and the FDA prior to starting a trial.
  • RECIST Response Evaluation Criteria In Solid Tumors
  • Fields that specify entry of data appropriate to determine subject eligibility or outcome may be incorporated into an ADM template. Such data may, in various
  • an ADM template provided by the EMR system for the particular disease of interest may be sufficient for purposes of a clinical trial.
  • an ADM template may be designed specifically for purposes of a clinical trial.
  • a standard ADM template for a disease of interest may be augmented to include additional fields ("trial-specific fields") for purposes of using the ADM in a clinical trial. It will be understood that an ADM or trial-specific fields thereof may be modified during the course of a study under appropriate conditions.
  • an ADM template or trial-specific fields thereof may be designed such that data gathered thereby may comply with a particular set of regulatory requirements and/or requirements agreed on by a sponsor and the FDA.
  • the EMR system may check an ADM to determine whether a potential subject meets trial eligibility criteria and, in some embodiments, informs the HCP accordingly.
  • a subject may be considered to be enrolled in an ADM- assisted clinical trial after the subject's HCP has agreed to serve as an investigator and such agreement may be documented in the EMR system, the subject has met inclusion criteria for the study (if any) or at least does not meet exclusion criteria (if any), and an informed consent document for the subject has been entered into the EMR system.
  • at least one intervention being studied in the trial e.g., administration of a drug being studied
  • the number of subjects enrolled in a trial may be between 300 and 5,000 for, e.g., a Phase III trial. In some embodiments, the number of subjects enrolled in a trial may be between 5,000 and 10,000 for, e.g., a Phase III trial. In some embodiments the number of subjects enrolled is in the order of tens of thousands or hundreds of thousands of patients, e.g., 10,000 - 20,000; 20,000 - 50,000; 50,000 - 100,000; or more, in various embodiments.
  • the EMR system may check an ADM to ensure that the entered data meets specified criteria required for use of the ADM in a clinical trial. For example, the EMR system may check to ensure that all fields of an ADM pertinent to outcomes to be assessed in the trial are completed. In some embodiments, the EMR system may check to ensure that ADMs are updated at appropriate times. For example, if a trial protocol requires that a patient be evaluated at specified time intervals or over a specified time period, the EMR system may send an alert to the patient's HCP if the data is not entered in a timely manner or is incomplete or may reject the ADM as inadequate for use in the study if the data are not entered within a predetermined time period or are incomplete. The EMR system may thus help enforce compliance with protocol requirements. In some
  • the EMR system may check an ADM to determine whether one or more endpoints for a clinical study is/are met. In some embodiments the EMR system may send an alert to a HCP and/or to a sponsor if it determines, based on data entered into an ADM, that an outcome that requires subject withdrawal from a study has occurred. In some
  • enrollment in an ADM-assisted clinical trial may be considered to be completed once a predetermined number of subjects have been enrolled via the EMR system.
  • an ADM-assisted clinical trial may be considered to be completed once data adequate to determine whether an endpoint has been met (and, if applicable, any required follow-up data) has been entered into a specified (e.g., predetermined) number of ADMs.
  • an ADM-assisted clinical trial may be conducted for purposes of generating data to be included in a New Drug Application (NDA), Biologic
  • BLA License Application
  • AND A Abbreviated New Drug Application
  • BLA License Application
  • AND A Abbreviated New Drug Application
  • an ADM-assisted clinical trial may be conducted to generate data to be included in an application for approval of a so-called follow-on or biosimilar biologic drug, e.g., as specified in the framework established under Patient Protection and Affordable Care Act of 2010 ("PPACA").
  • PPACA Patient Protection and Affordable Care Act
  • an ADM-assisted clinical trial may be conducted at least in part for purposes of generating data to be included in a Pre-market Application (PMA) for a medical device, e.g., a class III medical device.
  • PMA Pre-market Application
  • an ADM-assisted clinical trial may be conducted at least in part for purposes of generating data to be included in an application for 510(k) clearance for a medical device, such as class II medical device, e.g., to show that the device is "substantially equivalent" to a predicate device already on the market is required for class II devices.
  • an ADM-assisted clinical study may be performed for any purpose in which it is legally permissible to perform a clinical study, including, but not limited to, for regulatory approval purposes.
  • a clinical study may be performed to evaluate the efficacy of a treatment, e.g., to support a contention that a treatment may be efficacious or may not be efficacious, e.g., for purposes of showing that the cost of the treatment should be covered by health insurance or (if the treatment is found not to be efficacious) need not be covered by health insurance, or to compare efficacy or side effects of different treatments, etc.
  • an ADM-assisted clinical trial may be performed to test a medically related product that has already been approved in at least one indication.
  • the trial may be performed to evaluate the product in an indication different from that for which it was approved or in a patient population having specified characteristics (e.g., patients within a specified age group (e.g., children), or having particular disease characteristics).
  • an ADM-assisted study may, as appropriate, be registered with ClinicalTrials.gov or other appropriate public clinical trial registry.
  • the information provided for such registration and posted on the ClinicalTrials.gov website (or other registry) may indicate that the study is an ADM-assisted study.
  • a HCP who has at least one patient participating in an
  • An investigator may be a HCP who administers a drug or under whose immediate direction a drug or medical device may be administered or dispensed or deployed, or, may be a HCP who performs a medical or surgical procedure or under whose immediate direction such procedure is performed. It will be understood that an investigator may have one or more co-investigators or associate investigators. It will also be understood that in some instances an investigator may be a pathologist, radiologist, or other medical specialist who may not be directly responsible for administration or deployment of an intervention for patient treatment.
  • the EMR system may provide a document that sets forth requirements to which a HCP must agree in order for the HCP to be an investigator in an ADM-assisted study and/or checks to ensure that such a document maybe appropriately completed and entered into the EMR system before permitting a HCP to serve as an investigator in an ADM-assisted trial.
  • the EMR system may provide informed consent documents and/or checks to ensure that such a document may be appropriately completed and entered into the EMR system before permitting a subject to be enrolled in an ADM-assisted trial.
  • the EMR system may send reminders to subjects regarding upcoming scheduled visits or otherwise assists in scheduling patient visits or follow-up.
  • access to an ADM being used in an ADM-assisted trial, or access to at least some trial-specific fields may be restricted, as compared, for example, with accessibility of the subject's other ADMs. In other words, only a subset of users of the EMR database may be able to access such ADMs or trial-specific fields.
  • access to the ADMs or trial-specific additional fields may be limited to the subject's HCP who is serving as an investigator or their designees (or, e.g., may also be provided to at least some of the subject's other HCPs, if any) and/or to the sponsor or individuals or entities authorized by the sponsor.
  • ADMs being used in a clinical study or trial- specific fields thereof may not be accessed by subscribers to the EMR database (other than the sponsor or sponsor-authorized subscribers).
  • the complete ADMs may be made available to subscribers after a specified time period (e.g., between 3 months and 5 years) has elapsed following termination or completion of the trial or when results of the trial are published.
  • the EMR system may be used to facilitate clinical studies that may at least in part replace the currently mandated randomized controlled Phase III trial(s) required for regulatory approval of drugs in the U.S. and various other jurisdictions. For example, in some embodiments, following standard Phase I and
  • a drug may be made available (e.g., by a sponsor) for use by physicians under a so-called "white label".
  • the white label would, in various embodiments, permit the drug to be administered to patients who meet certain criteria ("inclusion criteria") or do not meet certain criteria ("exclusion criteria”) or at the physician's discretion.
  • Inclusion or exclusion criteria may be agreed upon by the sponsor and the FDA.
  • the sponsor and the FDA may agree on certain endpoint(s) that must be met in a white label trial in order for the drug to receive approval for marketing.
  • Data that may be used to determine whether inclusion criteria and/or endpoints are met may be incorporating fields specifying entry of such data into an ADM template.
  • At least one of two Phase III studies required for regulatory approval may be a white label, ADM-assisted study.
  • a standard Phase III trial (which may or may not be ADM-assisted) may overlap in time or may proceed substantially concurrently with a white label, ADM-assisted study.
  • a white label, ADM-assisted study may take place after a standard Phase III trial, e.g., a standard Phase III trial that demonstrates efficacy.
  • a white label drug is made available to any HCP who agrees to use the EMR system and, in at least embodiments, agrees to use a designated ADM for patients to whom the drug may be administered.
  • a white label drug may be made available to only a subset of HCPs (provided such HCPs agree to use the
  • EMR system and, in at least some embodiments, agrees to use a designated ADM for patients to whom the drug is administered).
  • a sponsor may desire to limit a study to
  • HCPs who have at least a minimum number of patients with a disease of interest.
  • only a subset of patients who receive a white label drug may be evaluated for purposes of determining whether an endpoint is met in a clinical trial.
  • the criteria for permitting a white label drug to be used in a patient may be different to the inclusion criteria for a clinical trial.
  • safety-related data may be gathered via an ADM for all patients who receive the drug, but only a subset of patients (i.e., those who meet specified inclusion criteria) may be assessed for purposes of determining whether an endpoint is met.
  • a study may be randomized. In some embodiments, a study may not be randomized. In some embodiments a study is at least in part blinded. In some embodiments a study may be at least in part not blinded (e.g., the HCP and, e.g., the patient, may be aware of which of various drugs is used). In some embodiments, a control group may be selected from among patients who have been diagnosed with the disease of interest but who are not receiving the drug being studied.
  • the sponsor may select ADMs having appropriate characteristics for a control group from among the set of ADMs for the relevant disease in the EMR database. For example, in a clinical trial of a new cholesterol-lowering agent, a sponsor may select ADMs for patients who are diagnosed with elevated cholesterol levels within a particular time period and who receive typical standard of care therapy for use as a control group. In some embodiments, a matched control patient (i.e., a subject having characteristics comparable to those of a subject who is treated with a study drug but who receives a different treatment (e.g., a standard of care therapy, or any particular specified therapy) may be selected. In some embodiments, ADMs to be used as a control group may be selected randomly (e.g., from among ADMs that meet a predetermined set of criteria).
  • the EMR system may facilitate recruitment of HCPs for service as investigators and/or facilitates recruitment of subjects for participation in an ADM- assisted clinical study. For example, in some embodiments, if a HCP enters a tentative or definitive disease diagnosis into the EMR system or into an ADM, and a drug is available for the disease under a white label, the HCP may receive an alert informing him or her of the availability of the drug. In some embodiments the EMR system may periodically inform HCPs, e.g., physicians, of the availability of white label drugs. Such information may be provided at least in part based on HCP specialty.
  • oncologists may receive alerts regarding white label drugs for cancer treatment; ophthalmologists may receive alerts regarding white label drugs for macular degeneration or glaucoma; neurologists may receive alerts regarding white label drugs for multiple sclerosis, etc.
  • a link to a web page for the study on ClinicalTrials.gov or other public clinical trial registry is provided. The information posted for the trial on the ClinicalTrials.gov website (or other registry) may indicate that the study is a white label study.
  • a patient may receive an alert informing him or her of the availability of the drug.
  • a EMR system described herein may be used to facilitate one or more aspects of a managed access program.
  • the term "managed access program” refers to a program under which a drug or other medical product such as a medical device is made available, under a particular regulatory regime, to one or more patients with unmet medical needs in situations in which such patient(s) are not able to obtain the drug or medical product by participating in a clinical trial or through ordinary commercial routes, e.g., by prescription or over-the-counter.
  • MAPs may be referred to by a variety of terms including, e.g., expanded access program, early access, compassionate use, named patient, pre-approval access, unlicensed use, or off-label use (in jurisdictions where off-label prescription is prohibited), and like terms.
  • expanded access program early access
  • compassionate use named patient
  • pre-approval access unlicensed use
  • off-label use in jurisdictions where off-label prescription is prohibited
  • a MAP relates to a drug.
  • the disclosure provides analogous embodiments in which a EMR system may be used to facilitate a MAP under which a device or other medical product that may not include a drug is provided.
  • a EMR system may (i) determine whether a patient meets criteria for participating in a clinical trial or MAP; (ii) analyze an ADM or EMR to determine whether a patient is eligible or potentially eligible for a clinical trial or MAP; (iii) generate or provide, optionally in response to a request from a user, a list of clinical trials or MAPs for which a patient is eligible or potentially eligible; (iv) complete or assist a HCP to complete at least a portion of a form to request that a patient be permitted to participate in a clinical trial or MAP; (v) transmit, to a sponsor or regulatory agency, a request that a patient be permitted to participate in a clinical trial or MAP; (vi) receive, from a sponsor or regulatory agency, an indication whether the patient is permitted to participate in a clinical trial or MAP; (vii) provide an ADM template designated for a clinical trial or MAP; (viii) comply or assist an investigator or sponsor to comply with a law or regulation pertaining to a clinical trial or
  • a MAP may encompass, for example, providing a drug that: (1) is still in clinical development but has not been approved in any jurisdiction; (2) is not in clinical development and has never be approved, but still has or may have medicinal value for one or more patients; (3) is approved in at least one jurisdiction but is not approved in the jurisdiction in which a patient resides or receives health care or in which a patient's HCP is authorized to prescribe drugs; (4) has been discontinued in a particular market that includes the jurisdiction in which a patient resides or receives medical care or in which a patient's HCP is authorized to prescribe drugs; (5) has been discontinued globally; (6) is approved but not marketed; (7) is related to an approved drug, but is not approved for marketing and there is a shortage of the approved drug or the approved drug is unavailable due to failure to meet the conditions of the approved application; (8) is approved but whose availability is limited because the drug is subject to a risk evaluation and mitigation strategy; (9) is approved but the use for a particular patient would be "off-label" and the
  • MAPs exist in a number of jurisdictions. Laws and regulations governing the various types of MAPs available in different jurisdictions are known in the art. In the United States, FDA regulations authorize MAPs, typically referred to as expanded access programs, which allow patients access to investigational drugs under specified conditions. In some embodiments a MAP is an expanded access program. FDA regulations governing expanded access programs are set forth in 21 CFR ⁇ 312 (or amended versions or successors thereof as applicable). See, e.g., the final rule entitled "Expanded Access to Investigational Drugs for Treatment Use", effective Oct. 1, 2009, published (along with Supplementary Information) in the Federal Register / Vol. 74, No. 155 / Thursday, August 13, 2009, pp. 40900-40945).
  • a MAP comprises a single-patient IND, e.g., as described in FDA regulations set forth in 21 CFR ⁇ 312.310 (or amended versions or successors thereof as applicable).
  • a single-patient IND refers to a request to the FDA that an individual patient be allowed access to a drug.
  • a MAP is for an intermediate-size patient population, e.g., as described in FDA regulations set forth in 21 CFR ⁇ 312.315 (or amended versions or successors thereof as applicable).
  • a MAP under which a drug may be provided to an intermediate size patient population may be implemented when the FDA receives a significant number of requests (e.g., about 10 to about 100 in some embodiments) for single- patient access to an investigational drug for the same use.
  • the FDA may ask the trial sponsor (e.g., the entity that is developing the drug for marketing) to consolidate these requests.
  • the number of patients in an intermediate-size patient population is between 10 and 100, between 100 and 200, between 200 and 500, or between 500 and 1,000.
  • a MAP comprises a treatment IND or treatment protocol, e.g., as described in ⁇ 312.320 (or amended versions or successors thereof as applicable).
  • a treatment IND or treatment protocol permits access for a large number of patients, e.g., at least 100 patients.
  • at least 100 patients may be treated under a treatment IND or treatment protocol, e.g., between 100 and 1,000 patients, between 1,000 and 10,000 patients, or more, e.g., up to about 100,000 patients, or more. In some embodiments at least some such patients would not otherwise qualify for clinical trials of such drug.
  • a MAP is listed on ClinicalTrials.gov. In some embodiments a MAP is listed on ClinicalTrials.gov. In some embodiments a MAP is listed on ClinicalTrials.gov. In some embodiments a MAP is listed on ClinicalTrials.gov. In some
  • a MAP is not listed on ClinicalTrials.gov.
  • a MAP is implemented in one or more countries outside the US.
  • a MAP is implemented in the European Union (EU), e.g., in one or more countries that are members of the EU.
  • EU European Union
  • MAPs are often referred to as named patient compassionate use program (NP-CUP) or cohort compassionate use programs (Coh-CUP).
  • NP-CUP patient compassionate use program
  • Coh-CUP cohort compassionate use programs
  • a NP-CUP is typically initiated by a physician for an individual patient.
  • a Coh-CUP is typically a defined program initiated by a pharmaceutical company to allow access for a group of patients to an unauthorized drug provided by such company.
  • a MAP in the EU allows access to an investigational drug.
  • a MAP in the EU allows access to a drug that is not approved in a patient's country of residence but is approved in one or more other countries.
  • a program may permit a patient to use a drug during the time period between centralized European Medicines Agency (EMA) approval and the launch of such drug in the patient's country of residence.
  • EMA European Medicines Agency
  • a drug is provided to one or more patients with a chronically or seriously debilitating disease, or a life threatening disease, and who cannot be treated satisfactorily by an authorized medicinal product in the EU or in the patient's country of residence.
  • a patient who cannot be treated satisfactorily refers to a patient left without treatment options or a patient whose disease does not respond to or relapses to available treatments, or for whom available treatments are contraindicated or inadequate.
  • a MAP is implemented in Canada.
  • a MAP may be referred to as a "special access program".
  • a special access program provides access to non-marketed drugs to practitioners treating patients with serious illnesses when conventional therapies have failed, are unsuitable, or are unavailable.
  • a MAP is implemented in Australia. Australia provides patients access to experimental drugs via MAPs under the "special access scheme”.
  • a MAP is implemented in Japan. For example, Japan's "named patient access" scheme makes drugs available if they are approved in the exporting nation.
  • a MAP allows for access to a drug that is in an early stage of development, e.g., following completion of at least one Phase I trial of the drug but prior to initiation of a Phase II trial. In some embodiments a MAP allows for access to a drug following initiation of a Phase II trial of the drug but prior to initiation of a Phase III trial. In some embodiments a MAP allows for access to a drug for which at least one Phase II trial has been completed. In some embodiments a MAP allows for access to a drug for which at least one Phase II trial has been completed and from which compelling data regarding efficacy of the drug are available.
  • a MAP allows for access to a drug for which sufficient data regarding safety and efficacy to support initiation of a Phase III trial has not been acquired. In some embodiments a MAP allows for access to a drug for which sufficient data regarding safety and efficacy has been acquired to support initiation of a Phase III trial. In some embodiments a MAP allows for access to a drug in which a Phase III trial is ongoing. In some embodiments a MAP allows for access to a drug in which at least one Phase III trial has been completed. In some embodiments a database for a completed trial has been locked. In some embodiments data from a completed trial has been analyzed. In some embodiments it has been determined that a trial met at least one endpoint.
  • a MAP allows access to a drug by patient(s) with a severe and/or life-threatening illness.
  • a severe disease is a disease associated with morbidity that has substantial impact on day-to-day functioning.
  • an immediately life-threatening illness is a stage of disease in which there is reasonable likelihood that death will occur within a matter of months or in which premature death is likely without early treatment.
  • the disease is one for which commercially available treatment options are limited or entirely lacking.
  • the primary purpose of a MAP is to diagnose, monitor, or treat a patient's disease or condition, not to generate scientific data intended to characterize the drug.
  • a patient has failed to respond to one or more commercially available treatments.
  • a patient cannot participate in a clinical trial of the drug to be provided under a MAP.
  • a patient cannot participate in a clinical trial of any drug open to individuals with the patient's disease.
  • a patient cannot participate in a clinical trial because, e.g., the patient fails to meet criteria for entering or remaining in a clinical trial.
  • a patient is unable to participate in a clinical trial at least in part because the patient resides at a location that is so remote from a site at which the trial is being conducted as to make it unreasonable for the patient to participate in the trial.
  • a EMR system provides information regarding MAPs, e.g., single-patient, named patient, or other individual MAPs, intermediate-size population MAPs, treatment INDs or treatment protocols, etc., that are in place or have been in place to permit patients to have access to a particular drug. Such information may include, for example, the number of patients who have been treated or are being treated under one or more MAPs, outcomes of such treatment, etc.
  • a EMR system provides information regarding one or more drugs available under a MAP. For example, the EMR system may provide a monograph on a drug, a summary of clinical trials conducted on the drug, a link to publications on the drug, etc.
  • a EMR system provides information to inform HCPs regarding the availability of and/or requirements of a MAP.
  • a EMR system provides one or more forms to be filled out by, e.g., a HCP or patient to facilitate participation of a patient in a MAP.
  • a form is to be filled out, e.g., by a HCP, in order to comply with regulatory requirements, to request a drug from an entity, e.g., a pharmaceutical company, that supplies the drug, or to obtain an import permit.
  • a EMR system provides one or more form(s) selected at least in part based on applicable regulatory requirements, e.g., regulatory requirements governing MAPs in a jurisdiction in which an HCP is licensed to practice medicine.
  • a form is an informed consent form.
  • a EMR system provides assistance to an HCP in preparing an expanded access submission to, e.g., the FDA or a sponsor.
  • a EMR system may provide a form for an expanded access submission.
  • a form may contain fields to be completed by a HCP or sponsor.
  • information may be entered into one or more of the fields automatically by a EMR system based on information available in the patient's EMR. For example, demographic information, diagnosis, results of one or more diagnostic tests, treatments that the patient has received or is receiving may be entered.
  • a HCP may be required to confirm agreement with at least some such information.
  • a HCP may select at least some such information from a menu.
  • a EMR system may suggest diagnostic tests to be performed to determine whether a patient is eligible for a MAP.
  • one or more such tests may be required by a sponsor or by the FDA as a condition of granting access to a drug.
  • information may be entered into one or more of the fields
  • an ADM template includes fields sufficient to permit a determination of whether a patient meets criteria for participating in a clinical trial or MAP.
  • the fields are sufficient to allow a determination that the potential patient benefit justifies the potential risks of the treatment use and those potential risks are not unreasonable in the context of the disease or condition to be treated.
  • a EMR system database stores a list of drugs that have been or are being made available under one or more clinical trials and/or MAPs. In some embodiments a EMR system stores a list of clinical trials and/or MAPs under which a drug has been made available or is currently available. In some embodiments a EMR system provides means by which a sponsor is able to submit information regarding clinical trials and/or MAPs being sponsored by such sponsor. In some embodiments a EMR system may provide information about such clinical trials and/or MAPs to users of the EMR system, e.g., HCPs or patients. In some embodiments a EMR system comprises information acquired from publicly available sources such as ClinicalTrials.gov or other websites (e.g., pharmaceutical company websites, hospital or clinic websites) or journal articles.
  • a EMR system generates or is capable of generating a list of drugs that a patient may be eligible to receive under a clinical trial and/or MAP. In some embodiments a EMR system generates or is capable of generating a list of clinical trials and/or MAPs for which a patient may be eligible. Such list(s) may be generated, for example, after a tentative diagnosis is entered or after a definitive diagnosis is entered or confirmed. In some embodiments a EMR system allows a user to enter or select a diagnosis (e.g., by clickin on it) and provides a list of drugs available under one or more MAPs for that diagnosis.
  • a diagnosis e.g., by clickin on it
  • a EMR system analyzes data in a patient's EMR and generates a list of drugs that a patient may be eligible to receive under a MAP and/or generates a list of MAPs for which the patient may be eligible.
  • at least some of the data analyzed is an ADM.
  • a list is generated automatically and, in some embodiments, may be provided upon request by a user.
  • users may access a list of MAPs available for a particular disease or drug.
  • a list may be revised based on information entered into an ADM.
  • an EMR or ADM comprises an icon or link that when selected may take the user to a document that displays a list of MAPs for which a patient may be eligible and/or that comprises other information pertaining to one or more such MAPs.
  • a user may select a MAP from a list, e.g., by clicking on it.
  • selecting a MAP takes the user (directly or via one or more further links or documents) to a document that provides information regarding the MAP or to a form to be completed to request permission, e.g., from a sponsor or regulatory agency, for a patient to participate in a MAP.
  • a HCP submits a request via an EMR system.
  • a sponsor receives a request submitted via an EMR system and supplies a drug to be used in a MAP.
  • a HCP who has at least one patient participating in an ADM-assisted MAP may be referred to as an "investigator”.
  • an investigator agrees to comply with sponsor-specified requirements (such as completing or ensuring completion of the appropriate ADM).
  • an ADM template is specialized for a particular MAP.
  • An ADM template specialized for a particular MAP may be referred to as a MAP-specific ADM template.
  • a MAP in which an ADM is used, e.g., to enter patients and/or to gather data pertaining to the MAP may be referred to as an "ADM-assisted MAP".
  • a MAP-specific template may be used for a patient being treated in an ADM- assisted MAP.
  • a MAP-specific ADM template may include one or more fields designed to gather information regarding efficacy and/or potential side effects regarding the drug provided under the MAP and/or to facilitate satisfying one or more regulatory requirements associated with the MAP.
  • a MAP-specific ADM template may be developed at least in part by or in cooperation with a sponsor of the MAP.
  • a MAP-specific template may comprise one or more fields designed to gather safety and/or efficacy data regarding the drug or to enable detection of potential adverse events or contraindications that may, for example, indicate that treatment of a particular patient with the drug should be stopped.
  • a EMR system may check an ADM to ensure that the entered data meets specified criteria required for use of the ADM in a MAP. For example, the EMR system may check to ensure that all fields of an ADM required by a sponsor are completed. In some embodiments, the EMR system may check to ensure that ADMs are updated at appropriate times.
  • the EMR system may send an alert to the patient's HCP if the data is not entered in a timely manner or is incomplete or may reject the ADM as inadequate if the data are not entered within a predetermined time period or are incomplete.
  • the EMR system may thus help enforce compliance with MAP protocol requirements.
  • a drug is made available under a MAP to a HCP who agrees to use the EMR system for a patient to be treated with the drug under the MAP.
  • the HCP agrees to use a MAP-specific ADM for patient(s) to be treated with the drug under the MAP.
  • an HCP is required to complete and/or update the ADM template satisfactorily in order for initial and/or ongoing participation of the patient to be permitted.
  • a drug may be made available under a MAP to any HCP who agrees to use the EMR system and agrees to use a MAP-specific ADM template for a patient to whom the drug may be administered.
  • a drug may be made available under a MAP to only a subset of HCPs (provided such HCPs agree to use the EMR system and, in at least some embodiments, agree to use a MAP-specific ADM for patients to whom the drug is administered).
  • a sponsor may desire to limit participation in a MAP to HCPs who have at least a minimum number of patients with a disease of interest.
  • a EMR system reduces the administrative burden associated with implementing a MAP or complying with one or more MAP requirements. In some embodiments a EMR system reduces the time required to enroll a patient in a MAP. In some embodiments a EMR system reduces the time from submission of a request for a patient to participate in a MAP and receipt of a decision as to whether the patient is permitted to participate in the MAP. In some embodiments a EMR system reduces the time from submission of a request for a patient to participate in a MAP and receipt of the drug. In some embodiments a EMR system reduces the time required on the part of a HCP to comply with requirements of a MAP.
  • a EMR system facilitates communication between a first HCP who is considering seeking approval to initiate a single-patient MAP to treat a patient with a particular drug or is considering seeking approval to treat a patient under an ongoing MAP and one or more second HCPs who have treated or are treating patient(s) with the same drug, e.g., under a MAP.
  • a EMR system provides means by which HCPs may share their experiences regarding use of the drug or regarding participation in a MAP.
  • a EMR system assists an investigator or sponsor in complying with one or more regulatory requirements associated with a MAP, such as adverse event reporting (e.g., reporting to an appropriate government agency such as the FDA and/or to the entity providing the drug), maintaining accurate case histories, maintaining accurate drug disposition records, retaining records in a manner consistent with the requirements of ⁇ 312.62, and/or complying with one or more other investigator responsibilities under subpart D that may apply.
  • a sponsor may be an individual or entity that submits an expanded access IND or protocol.
  • An investigator may be an investigator- sponsor.
  • a EMR system facilitates approval of a MAP by an IRB or facilitates approval by an IRB of a patient's participation in a MAP.
  • a EMR system may provide information that identifies one or more IRBs that has previously approved participation of a patient in a particular MAP or that identifies one or more IRBs that has previously approved a protocol for a clinical trial of the drug to be provided under a MAP.
  • a EMR system facilitates gathering safety and/or efficacy data for patients participating in a MAP.
  • a EMR system facilitates the acquisition of useful safety and/or efficacy data from a MAP.
  • a EMR system may, e.g., through use of ADM templates, which may be MAP-specific ADM templates, enhance acquisition of useful safety and/or efficacy data from a MAP.
  • ADM templates which may be MAP-specific ADM templates, enhance acquisition of useful safety and/or efficacy data from a MAP.
  • an EMR system or ADM template may require entry of particular information for proper completion or updating, may provide feedback to a HCP if appropriate information is not entered in a timely manner, etc.
  • a MAP-specific ADM template may make it possible to draw meaningful conclusions from a MAP or from multiple single-patient MAPs by, e.g., ensuring collection of a defined sets of data by different HCPs who may be responsible for treating different patients receiving the drug.
  • a EMR system may increase the safety and/or effectiveness of MAP programs for patients by, e.g., detecting patient data that may indicate a potential adverse event or providing timely updates to HCPs regarding safety or potential adverse events associated with the drug.
  • safety and/or efficacy data from a MAP may be used, e.g., by a sponsor. In some embodiments safety and/or efficacy data from a MAP may be used to, e.g., support a marketing application to a regulatory authority, e.g., a new drug application
  • safety-related data may be gathered via an ADM for all patients who receive the drug, but only a subset of patients (i.e., those who meet specified criteria) may be assessed for purposes of evaluating efficacy in a particular indication. It may thus be possible to gather safety-related data in a large number of patients, which data may be considered along with efficacy data gathered in a smaller number of patients, for evaluating a drug.
  • a MAP may typically not include a control group as part of a protocol, in some embodiments, a control group for comparison purposes may be selected from among patients who have been diagnosed with the disease of interest but not receiving the drug.
  • ADMs having appropriate characteristics for a control group may be selected from among the set of ADMs for the relevant disease in the EMR database.
  • a matched control patient i.e., a subject having
  • ADMs to be used as a control group may be selected randomly (e.g., from among ADMs that meet a predetermined set of criteria).
  • data obtained from a MAP may be compared with data obtained from a Phase II or Phase III clinical trial.
  • data from a MAP may be submitted to a regulatory agency together with data from a Phase II or Phase III trial.
  • a MAP-specific ADM may comprise one or more fields designed to collect data that may be combined with or may supplement data obtained from a controlled clinical trial.
  • a tentative or definitive disease diagnosis for a patient is entered into a EMR system or into an ADM template, and a drug is available for the disease under a MAP
  • one or more of the patient's HCPs may receive an alert informing him or her of the availability of the drug.
  • a EMR system may periodically inform HCPs, e.g., physicians, of the availability of MAPs. Such information may be provided at least in part based on HCP specialty. For example, oncologists may receive alerts regarding drugs for cancer treatment; infectious disease specialists may receive alerts regarding drugs for infectious diseases, etc.
  • a link to a web page for the MAP on ClinicalTrials.gov or other public clinical trial registry is provided.
  • Information posted for the MAP on the ClinicalTrials.gov website may indicate that the drug is available under a MAP.
  • a patient may receive a tentative or definitive diagnosis of a disease for which a drug may be available under a MAP and such diagnosis is entered into a EMR system or into an ADM template, the patient may receive an alert informing him or her of the availability of the drug under a MAP.
  • HCPs who agree to be investigators in a MAP but subsequently fail to reasonably comply with the applicable requirements may be identified in the EMR database and/or may be precluded (for at least a period of time, or indefinitely) from future service as investigators in ADM-assisted MAPs.
  • the opportunity to prescribe a white label drug and/or to be an investigator in a clinical trial of a white label drug serves as an incentive for a HCP to use a EMR system and/or to use a designated ADM for a patient who receives the white label drug.
  • the opportunity to provide a drug under a MAP and/or to be an investigator in a MAP serves as an incentive for a HCP to use a EMR system and/or to use a designated ADM for a patient who receives the drug under a MAP.
  • HCPs who agree to be investigators in an ADM-assisted study but subsequently fail to reasonably comply with the applicable requirements may be identified in the EMR database and/or may be precluded (for at least a period of time, or indefinitely) from future service as investigators in ADM-assisted trials.
  • HCPs who agree to be investigators in an ADM-assisted managed access program but subsequently fail to reasonably comply with the applicable requirements may be identified in the EMR database and/or may be precluded (for at least a period of time, or indefinitely) from future service as investigators in ADM-assisted managed access programs.
  • the EMR system may be used to facilitate Phase IV (post-approval) studies. Such trials may sometimes be required by the FDA as a condition to the approval. Failure to conduct such trials or failure of the drug to show adequate efficacy and safety in such studies may lead to revocation of the approval.
  • subjects who participated in a Phase III trial (which may or may not be an ADM-assisted Phase III trial) are followed after completion of the Phase III trial in an ADM-assisted clinical study.
  • ADMs appropriate for a Phase IV study may be included in the EMR system.
  • a HCP and/or HCO may receive an incentive for serving as an investigator or site, respectively, for an ADM-assisted clinical study.
  • incentives may be provided, for example, on a per- ADM or per-subject basis.
  • an incentive may differ in type or amount from that which may be provided to the HCP or HCO as consideration for contributing the ADM. For example, a larger incentive may be provided.
  • an incentive may be calculated to be approximately equivalent to that which the HCP would receive had the HCP not chosen to serve as an investigator, such that the HCP does not receive a direct financial benefit from serving as an investigator.
  • an incentive may not be provided to HCPs or HCOs in instances where an ADM is used for a clinical study.
  • reimbursement of the HCP and/or HCO may be provided in order to cover the costs of extra labor, tests, or other expenses incurred by the HCP or HCO as a result of HCP' s service as an investigator in the clinical study.
  • subjects may be compensated (e.g., with money) for their participation in a study.
  • the EMR system at least in part manages reimbursement or compensation.
  • the business entity may charge sponsors a fee n exchange for the opportunity to conduct an ADM-assisted trial.
  • the business entity may provide assistance to sponsors with the design, implementation, and/or data analysis of trial-related ADMs.
  • the business entity may offer assistance to sponsors regarding assembly of data from an ADM-assisted study into a format appropriate for submission to the FDA. In some embodiments any of such services or assistance may be provided for a fee.
  • ADMs may be made available to the FDA, to an internal review board (IRB), or to a data safety monitoring board (DSBM) via the EMR system.
  • FDA employees or IRB or DSMB members may be users of the EMR system.
  • a sponsor may provide the FDA, IRB, or DSMB with a list of the ID numbers of the appropriate ADMs of subjects in the trial.
  • the ADM may include the identity of the treatment or other intervention being studied or indicates that the subject serves as a control.
  • such information may not be included in the ADM (in which case it may be provided separately to the FDA) or such information may be included in a field that is not made accessible to the HCP.
  • the sponsor may enter the appropriate data into such field.
  • a disease e.g., a disease for which a drug is tested or used in a clinical trial or MAP or for which an ADM template is provided, may be any disease.
  • a disease is cancer.
  • a cancer is a carcinoma.
  • a cancer is a sarcoma.
  • a cancer is a cancer of the adrenal gland, biliary tract, bladder, bone, breast, brain, cervix, colon, endometrium, esophagus, head or neck, kidney, liver, lung, oral cavity, ovary, pancreas, prostate, rectum, skin, testis, thyroid, or uterus.
  • a cancer is a hematologic cancer, e.g., a leukemia, lymphoma, multiple myeloma, or myeloproliferative neoplasm.
  • a cancer is metastatic.
  • a cancer is resistant to one or more drugs ordinarily used to treat cancers of that type.
  • a disease is an infectious disease.
  • an infectious disease is any disease caused by a virus, bacterium, fungus, or parasite.
  • a virus, bacterium, fungus, or parasite is resistant to one or more drugs that are ordinarily used to treat patients infected by the virus, bacterium, fungus, or parasite, e.g., the virus, bacterium, fungus, or parasite has acquired drug resistance.
  • the virus, bacterium, fungus, or parasite is multi-drug resistant.
  • an infectious disease is HIV infection, a HIV-related condition, or AIDS.
  • an infectious disease is an opportunistic infection.
  • a disease is an orphan disease.
  • a disease is a rare disease.
  • a rare disease is a disease that affects less than 200,000 persons in the United States, or less than about 1 in 1,500 people.
  • a rare disease is a disease that affects less than about 1 in 2,000, less than about 1 in 2,500, less than about 1 in 3,000, less than about 1 in 4,000, or less than about 1 in 5,000 people.
  • an orphan disease or rare disease is defined as set forth in a law or regulation such as the US Orphan Drug Act of 1983, US Rare Disease Act of 2002, or relevant law or regulation in an ex-US jurisdiction.
  • a disease is a genetic disease.
  • a genetic disease is an inherited disease.
  • a genetic disease is a single gene disorder, i.e., the disorder is the result of a single mutated gene.
  • a single gene disorder may have an autosomal dominant, autosomal recessive, X-linked dominant, X-linked recessive, Y-linked, or maternal (mitochondrial) inheritance pattern.
  • a genetic disease is cystic fibrosis.
  • a disease is a metabolic disease, e.g., an inborn error of metabolism.
  • a metabolic disease comprises an enzyme deficiency.
  • a disease is a neurodegenerative disease, e.g., Huntington's disease or amyotrophic lateral sclerosis.
  • EMR system and ADMs may be implemented and used mainly in the context of human health care, the disclosure may encompass embodiments relating to veterinary medicine.
  • a EMR system and/or ADMs may be established for veterinary medicine and/or diseases that affect animals, or an ADM-assisted clinical trial may be conducted in animal subjects.
  • Such animals may be mammals or avians or fish.
  • Animals may be, for example, cows, horses, pigs, goats, sheep, chickens, turkeys, or other animals used commercially as sources of food for humans;
  • an ADM-assisted clinical trial may be conducted at least in part for purposes of generating data to be included in a NADA. In some embodiments, such trial may be conducted using a white label drug.
  • EMR system for enrolling subjects and/or gathering data for clinical trial purposes may not be limited to ADM-assisted clinical trials.
  • the business entity may offer shares of a single class.
  • the business entity may offer multiple share classes, including, in some embodiments, at least one class of shares reserved for contributors.
  • Other classes may be made available to investors in the business entity, who may or may not also be contributors.
  • Investors may, for example, be members of the general public, government entities, accredited investors (as defined in Rule 501 of Regulation D of the U.S. Securities and Exchange Commission and as amended by the Dodd-Frank Wall Street Reform and
  • HCPs e.g., physicians
  • HCOs at least one class reserved for auto-contributors.
  • share ownership may be managed such that the business entity remains at least 50% owned or controlled by contributors.
  • share ownership may be managed such that the business entity remains at least 50% owned or controlled by contributors who are HCPs.
  • share ownership may be managed such that the business entity remains at least 50% owned or controlled by contributors who are physicians.
  • share ownership may be managed such that the business entity remains at least 50% owned or controlled by physicians, who may or may not be contributors. In some embodiments, at least 50% owned or controlled may be more than 50% owned or controlled e.g., at least 50.1% owned or controlled.
  • shares of at least one share class provides the shareholder with a subscription to the database. Varying levels of subscription privileges may be provided, e.g., as described above.
  • the business entity may have a share account database that keeps track of the ownership of the business entity's shares.
  • each shareholder has an account in the share account database.
  • the component comprising the share account database may, via appropriate computer instructions, communicate with the component comprising the user account database.
  • the component that comprises the user account database may inform the component that comprises the share account database when a contributor earns a share.
  • the component that comprises the share account database may issue the share and may update the share account database accordingly. It should be understood that the share account database need not be separate from the user account database (discussed above) in some embodiments.
  • a single account database format with appropriate fields could serve as a user account database and a shareholder account database.
  • shareholders may automatically receive user accounts along with their share ownership.
  • share ownership may be restricted to contributors and, e.g., at least some other types of users.
  • the disclosure provides a system for assembling EMRs wherein the system comprises security features that guard against the fraudulent or unauthorized submission of health information, help protect the integrity of the health information submitted, and help limit the rights to access, contribute, or change information to those persons with credentials that entitle them to do so.
  • Security and data integrity may be addressed in any of a variety of ways. It is contemplated that any methods known in the art for identity and access management may be used or adapted for purposes of the disclosure.
  • the disclosure provides security-enhancing methods particularly suited for various embodiments. It should be understood that these aspects and features of the disclosure may find use in other contexts as well.
  • one or more passwords may be selected by or assigned to a user and may be used for access control. Passwords may be required to be "strong" passwords and/or may be required to be changed on a regular or irregular basis. Access from a particular computer, device, or Internet address may be automatically disabled after a predetermined number of incorrect password entries.
  • smartcards which may contain an embedded computer chip or magnetically stored identifying information
  • digital certificates optionally encrypted in a smart card
  • biometric identification may be used to control access.
  • an EMR system maintains a list of an HCP's patients, which may be referred to as an HCP list or roster, e.g., a physician list or roster.
  • An HCP may be permitted to access EMRs of patients on his or her roster but may not be permitted to access EMRs of patients not on his or her roster (except to the extent such access may be permitted to the HCP as a subscriber, e.g., in de-identified form).
  • An HCP may be permitted to modify (e.g., change or add information to) EMRs of patients on his or her roster but may not be permitted to modify EMRs of patients not on his or her roster.
  • An HCP may be permitted to modify ADMs of patients on his or her roster but may not be permitted to modify ADMs of patients not on his or her roster.
  • an EMR system of the disclosure may maintain a list of the HCPs who are authorized to access and/or modify a patient's EMR and/or to modify a patient's ADMs.
  • a location-based identification system may be used wherein, for example, a EMR may only be accessed from a particular computer if an electronic device belonging to an individual authorized to do so is located within a specified distance of the computer.
  • the electronic device may include a suitable positioning system.
  • the positioning system may include any suitable system such as, for example, a global positioning system ("GPS") receiver for, e.g., accessing a GPS application function call that returns the geographic coordinates (i.e., the geographic location) of the electronic device.
  • GPS global positioning system
  • the positioning system may utilize any suitable trilateration or triangulation technique to determine the geographic coordinates of the electronic device.
  • localization may occur either via multilateration (e.g., trilateration) of radio signals between radio towers of the network and the phone.
  • the positioning system may determine various measurements (e.g., signal-to-noise ratio or signal strength measurements) of a network signal (e.g., a cellular telephone network signal, a wireless network access point or "hot spot", or any other suitable network signal) associated with the electronic device to determine its location.
  • a network signal e.g., a cellular telephone network signal, a wireless network access point or "hot spot", or any other suitable network signal
  • the business entity issues such electronic devices to a patient or patient representative. The patient or patient representative may take the electronic device with him or her when visiting a HCP.
  • patient consent may be required in order for a contributor to initiate establishment of a EMR for that patient or to initially gain access to the patient's EMR.
  • patient consent could be verified, for example, using a password-based approach, wherein both the contributor and the patient (or the patient's agent) need to enter a password into the same electronic device, and/or using a location-based approach, wherein the patient (or the patient's agent) and the contributor need to be co- localized (as determined, for example, by mobile phone tracking).
  • a patient (or their agent) could authorize different levels of access.
  • a patient may want a particular HCP to be able to update that patient's EMR with new information but not to be able to view the entire EMR.
  • a feature is provided that may, e.g., if selected by the patient, permit overriding the requirement for patient consent.
  • patient consent may be overridden in case of an emergency, such as the patient being admitted unconscious to a hospital after an accident.
  • a signature capture pad may be used in various aspects herein, e.g., to document informed consent for diagnostic tests, treatments, etc. and/or for capturing HCP signature.
  • health information may be encrypted at least while being transferred over a network. In some embodiments at least some health information is stored in encrypted form.
  • an encryption standard that has been adopted by the U.S. Federal government or mandated by U.S. federal law (e.g., under the Health Information Technology for Economic and Clinical Health (HITECH) Act (part of the 2009 American Recovery and Reinvestment Act) as it may be amended or updated from time to time may be used.
  • the encryption standard known as Advanced Encryption Standard (AES) or its successors may be used.
  • voice recognition technology may be used to facilitate security and/or integrity of the health information. For example, in some embodiments, only a user whose voice may be recognized by the EMR system as belonging to an individual authorized to modify a EMR or ADM may be able to do so. Multilanguage support and/or translation capability may be provided in some embodiments.
  • the EMR system may comply with and/or facilitate HCP and/or HCO compliance with legal requirements such as those of the HITECH Act and/or HIPAA.
  • the EMR system qualifies as an EMR system whose adoption and demonstration of meaningful use may entitle HCPs and/or HCOs (e.g., eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) to incentive payments available under U.S. federal laws such as the HITECH Act and regulations issued pursuant thereto (see 42 CFR Parts 412, 413, 422 et al. Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule, published in the Federal Register on July 28, 2010, Vol. 75, No.
  • the EMR system may satisfy standards, implementation specifications, and/or certification criteria set forth in 45 CFR Part 170; Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule, published in the Federal Register on July 28, 2010, Vol. 75, No. 144; http://edocket.access.gpo.gov/2010/pdf/2010-17210.pdf), and/or any subsequent standards issued pursuant to the HITECH Act.
  • the EMR system or at least some components or functions thereof comply with applicable HL7 standards version 2.x or version 3, if any, and/or are adapted to interface with other systems that comply with such standards.
  • the EMR system is certified by an organization recognized by the Office of the National Coordinator for Health Information Technology (ONC) as an Authorized Testing and Certification Body (ONC-ATCB)
  • the EMR system is certified by the Certification Commission for Health Information Technology (CCHIT®) http://cchit.org and/or another certification body.
  • the EMR database or at least a portion thereof is accessible via a virtual private network (VPN).
  • VPN virtual private network
  • a VPN is a mobile VPN.
  • FIG. 3 shows a flow chart of a process in accordance with some embodiments.
  • a system receives login information from a potential contributor (e.g., a HCP).
  • the system checks the information to determine whether it corresponds with information in a user database. For example, the system may check a username, password, HCP identifier, biometric information, etc., against information stored in a database. If the information does not match, login may be refused (step 220). The system may terminate login attempts after a predetermined number of failed attempts. If login is successful, the system may receive health information (step 230).
  • the system may check the health information to determine whether it satisfies a predetermined set of criteria, e.g., a set of EMR criteria (step 240). If said criteria are met, the health information may added to the database, e.g., as a created EMR (step 260), optionally after providing feedback indicating that submission was successful (step 250). A user account database may be updated upon successful submission (step 270). If health information to is determined not to satisfy a predetermined set of criteria, e.g., a set of EMR criteria, feedback may be provided accordingly (step 280). Such feedback may identify the deficiency and/or provide suggested remedy.
  • a modified dataset may be received (step 290), which may then be checked (step 240). The process may continue, e.g., until a dataset is accepted.
  • a modified dataset may comprise, for example, additional data, or at least some different data, e.g., as compared with a previously submitted version, in various embodiments.
  • Figure 4 shows a flow chart of a process in accordance with some embodiments.
  • the HCP submits a patient ID, which is received by the system (step 400).
  • the system checks the patient ID against a roster of patients that have EMRs stored in the database (step 410). If there is no matching patient ID in the patient roster, an error message may be issued (step 420).
  • the system may terminate patient ID submission attempts after a predetermined number of failed attempts. If successful, the system may checks the patient ID against a HCP roster (step 430).
  • the system may request patient confirmation (step 440).
  • the system may check whether patient confirmation has been received (step 442) and may issue repeated requests therefor, which may terminate after a predetermined number of requests or failed submissions (e.g., 3). If patient confirmation is received, the system may add the patient to the HCP's roster (step 444). These steps may permit a HCP whom a patient visits for the first time (e.g., a referral) to gain access to the patient's EMR. If a match is found (patient is on HCP roster) or patient has been added to HCP roster, e.g., in step 444, the patient's EMR may be opened (step 450).
  • a HCP (e.g., after determining that a patient has or may have a disease) selects a "create ADM" option.
  • the HCP submits a dataset.
  • the data is entered in an ADM template.
  • the submitted dataset is checked to determine whether it meets predetermined criteria. If such criteria are met, feedback is optionally provided accordingly to the HCP (step 490), and the dataset is added to the patient's EMR as a new ADM (step 492).
  • the HCP's account data may be updated to reflect addition of the ADM (step 494). If such criteria are met, feedback is optionally provided accordingly to the HCP (step 496).
  • the system may then receive a modified dataset or additional data (step 498), which may be checked for compliance with ADM criteria (step 480).
  • Figure 5 shows a flow chart of a process in accordance with some embodiments.
  • the HCP submits a proposed ADM dataset, which may be submitted at least in part by entering information into an ADM template.
  • the system checks the submitted information. For example, the dataset may be checked to determine whether it contains at least a tentative conventional disease diagnosis. If predetermined criteria are met, an ADM may be created, which may be assigned a status of "tentative" (step 520). If predetermined criteria are not met, feedback may be provided accordingly (step 512). A modified dataset may then be received (step 514) and checked (step 510) which process may continue until a dataset is accepted. A dataset containing a tentative diagnosis may be checked to determine whether it contains a proposed definitive conventional diagnosis (step
  • the proposed definitive conventional diagnosis may be checked to determine whether it should be confirmed (step524). For example, the system may check whether appropriate diagnostic tests have been performed and/or may analyze results thereof that have been entered (e.g., entered in step 500). If the proposed definitive diagnosis is confirmed, the status of the ADM may be updated to "definitive" (step 526). Feedback may accordingly be provided to the HCP, e.g., indicating that the diagnosis is confirmed (step 528). If the proposed definitive diagnosis is not confirmed (e.g., if appropriate diagnostic tests have not been performed, and/or if results thereof are not consistent with the diagnosis or suggest an alternative diagnosis), feedback may be provided (step 528).
  • step 530 Further health information (e.g., diagnostic test results) may be received (step 530), optionally at least in part in response to feedback provided in step (528).
  • a process of additional feedback and submission of health information may occur. It should be understood that the process may occur during a single session or over multiple sessions, and that health information may be submitted from a variety of sources. Additional information may also or alternately be received in step 530 after a diagnosis is confirmed. At any point the system may check whether information sufficient to confirm a proposed definitive diagnosis has been received. Thus, step 532 represents a loop back to step 524, which may occur multiple times. Further information entered may be added to an ADM (step 550) and/or to Patient Data (step 560). Such information may be subject to checking by the system prior to addition.
  • the system may check whether the dataset contains a molecular diagnosis (step 540). If the dataset does not contain a molecular diagnosis, feedback may be provided, such as a suggestion to perform a diagnostic test appropriate to obtain a molecular diagnosis (step 528). If a molecular diagnosis either matches (e.g., is consistent with) or fails to match (e.g., is inconsistent with) a proposed definitive diagnosis, appropriate feedback may be provided (step 528). Additional information may be received, and another determination of whether a molecular diagnosis matches a proposed definitive diagnosis may be performed (step 540). Steps of Fig. 5 may be repeated multiple times, e.g., for different diseases of a patient.
  • Feedback e.g., represented in step 528 (or any other step comprising providing feedback or as described herein) may comprise any of multiple different types or content of feedback depending at least in part on, e.g., preceding step(s) of the process or information previously submitted or received.
  • Figure 6 shows a flow chart of a process in accordance with some embodiments.
  • Login information is received from a subscriber (or possible subscriber) (step 600). Login information is checked against a database that stores a list of subscribers and login information thereof (step 610). If login information does not match, an error message may be issued (step 620). The system may terminate login attempts after a predetermined number of failed attempts (e.g., three). If login is successful, the system may receive a query from the subscriber (step 630). The system may process the query (step 640). Processing may include any of a wide variety of types of processing steps, which may depend, e.g., at least in part on the nature or complexity of the query, the data required to address the query, etc.
  • a query may comprise a request to retrieve an ADM having a particular identifying number, or may comprise a more complex query that may entail the system, for example, accessing multiple ADMs which may be identified by searching on one or more input terms, extracting one or more specified data elements therefrom, manipulating said data elements, e.g., combining or analyzing said data elements, performing one or more mathematical computations (e.g., generating a statistic such as a mean, standard deviation, confidence interval, p-value), performing one or more statistical tests, generating a requested display format or report, outcome analysis, etc.
  • One of ordinary skill in the art would be aware of numerous types of queries or analysis that may be performed on health information.
  • step 650 the database is accessed, e.g., to identify and/or retrieve data to respond to the query.
  • Step 650 may include one or more steps of manipulating or analyzing data retrieved from the database.
  • a response to the query is returned in step 660.
  • a subscriber may log off (step 670) or may submit an additional query which may be received by the system (step 680).
  • An additional query may, for example, be based at least in part on results of a previous query.
  • step 680 contributor account data is updated, based at least in part on data accessed in step 650. For example, if an ADM to which a subscriber contributed was accessed, the contributor's account data may be updated.
  • an incentive is issued to a contributor (e.g., at some later time point), the amount or timing of which may depend at least in part on content of the contributor's account information.
  • Processes as shown in Figures 3, 4, 5, and 6, and descriptions thereof, are exemplary and should not be construed as limiting. Any one or more steps may be omitted, added, or modified in various embodiments.
  • a step may comprise multiple sub-steps, which may not be depicted, or multiple steps may be combined. Certain steps may occur concurrently, in parallel, or in a different order than depicted in some embodiments. For example, updating a databases and providing feedback may occur substantially at the same time, or in either order, in various embodiments.
  • any one or more steps may be implemented in hardware, software, or a combination thereof. It should be understood that any step(s) may incorporate or be augmented based on any applicable description herein. It should be understood that any one or more steps, or substep(s) thereof, may be executed on one or more processors, which may be part of one or more computers or networks.
  • Feedback may comprise, e.g., an indication that a dataset was accepted or rejected, a reason why a dataset was accepted or rejected (e.g., an indication of a deficiency in said dataset or a failure to meet a predetermined criteria), a suggestion, a set of options, or modifying an ADM template, in various embodiments.
  • a suggestion may comprise, for an example, a suggested diagnostic test to confirm a diagnosis, an alternative diagnostic test, a suggested treatment, an alternative treatment, etc.
  • a database comprising EMRs is provided, said database being usable by HCPs for health care purposes and usable in addition for at least one non-health care purpose (e.g., a research purpose).
  • health information is provided at least in part in modules comprising de-identified health information.
  • a HCP may access such module(s), e.g., in the context of providing health care to a patient.
  • An individual who is not an HCP of the patient may access or retrieve data from said module(s), e.g., for research purpose(s).
  • database updates, feedback, or response may be performed or provided in a timely manner.
  • an average time for providing feedback or response to a HCP or updating an EMR or ADM may be selected so as to not substantially interfere with or delay normal workflow of the HCP.
  • an average response or update time may be selected to be below a
  • a predetermined value may be equal to or less than 1, 2, 5, 10, 15, 20, 30, 40, 45, 50, or 60 seconds for, e.g., at least some classes of actions .
  • an alert pertaining at least in part to time anticipated to be required for response or update may be provided, said alert comprising, e.g., an estimated time, an indication that a response or update may take more than a predetermined time, an option to abort an update or query, etc.
  • database accesses, updates, or queries are at least in part prioritized.
  • Prioritization may take into account, e.g., factors such as the user (e.g., whether the user is a contributor or subscriber), the nature of the action, prior response times to the user or during a session, etc. For example, an action performed in response to a contributor, e.g., a HCP, may be assigned a higher average priority than an action performed by a non-contributor.
  • the disclosure may provide an application for an electronic device, wherein the application is operative to interface with a computer that maintains user account data as described above ("user account application").
  • the user account application provides the user with access to at least a portion of his or her user account data.
  • the user account application provides the user with access to at least a portion of his or her share account data held in the share database (described above).
  • the application informs the user (e.g., upon request of the user) of the number of shares owned by or earned by the user and/or the value of said shares or current share price (e.g., if the company is a public company).
  • the user account application may display the information in any suitable format.
  • the share data may be displayed as a graph.
  • the user account application allows the user to purchase and sell shares in the business entity and, e.g., track the share price over time.
  • only users (or non-user share holders) who own or have the possibility of owning shares may be provided with the share account application.
  • the user account application may not permit the user to change the content of the user account database (although features may be provided that allow the user to change certain content such as UserlD or password).
  • the user account application may not provide access to certain content of the user account database.
  • the user account database may include information assembled by the business entity regarding the user's usage of the EMR system. In some embodiments at least some such information may not be accessible to the user.
  • the electronic device may comprise any suitable type of electronic device.
  • the electronic device may comprise a portable electronic device that a user may hold in his or her hand, such as a portable digital assistant (PDA), also referred to as a portable data assistant, a smartphone, a tablet computer, etc.
  • PDA portable digital assistant
  • the electronic device may be a larger portable electronic device, such as a laptop computer.
  • PDAs are small, e.g., hand-held, computers, that are frequently used for tasks such as maintaining a calendar, list of contacts (e.g., email addresses), and other information.
  • PDAs may contain application programs such as word processing programs, web browsers, PDF viewers, etc.
  • a "smartphone” may be an electronic device that combines the functions of a wireless phone and a PDA within a single unit.
  • a tablet computer may be a computer that is may be somewhat larger than a mobile phone or personal digital assistant, comprises a flat touch screen, and is primarily operated by touching the screen. It may use an onscreen virtual keyboard.
  • a portable electronic device may weigh under about 1 - 2 pounds, e.g., between about 3 ounces and about 1.5 pounds.
  • a smartphone or PDA may weigh between about 3 ounces and about 6 ounces and height and width dimensions in the range of less than about 7 x 5 inches and depth less than about 0.5 - 1.0 inch.
  • Exemplary portable electronic devices include, e.g., a PDA such as an iTouch (Apple, Inc.), a smartphone such as an iPhone (Apple, Inc.) or Galaxy phone (Samsung), or a tablet computer such as the iPad (Apple, Inc.).
  • a portable electronic device may include components that may be found in such devices, e.g., control circuitry, storage/memory, input/output circuitry, communications circuitry, processing circuitry, etc. In some embodiments, one or more of such components of the device may be combined or omitted. In some embodiments, the portable electronic device may include other components such as, for example, a proximity sensor, a power supply such as a battery, a display, a positioning system, a camera, an accelerometer, an ambient light sensor, other sensors, an input mechanism, etc.) or multiple instances of one or more such components. In many embodiments, the portable electronic device may possess wireless connectivity. For example, the device may have Bluetooth, Wi-Fi wireless network connectivity, and/or the ability to connect to wireless Wide Area Networks, such as those provided by cellular telecommunications companies.
  • the disclosure may provide an application for a portable electronic device, wherein the application is operative to interface with a computer that maintains the EMR database.
  • the application may consist of a single application or may comprise multiple applications that provide different functions. For purposes of
  • the EMR application provides a user with full functionality of the EMR system.
  • a contributor may create, view, update, or otherwise use EMRs or ADMs of his or her patients, enter orders, or perform other activities (e.g., data analysis activities such as those described herein) in a similar or essentially identical manner as could be done using a standard notebook or desktop computer.
  • only a subset of the EMR functions may be supported, which subset may depend at least in part on the capabilities of the particular portable electronic device and/or its operating system.
  • the user may be able to view but not update EMRs in some embodiments. It will be understood that details of the applications described herein may be customized for any particular portable electronic device platform of interest.
  • a EMR application running on the portable electronic device may synchronize with corresponding application(s) running on other electronic devices used by the user so that a seamless and integrated user experience is provided.
  • a user may receive health-related offers or information through the EMR application.
  • a user may be offered an opportunity to opt out of or discontinue receiving offers or information or would receive them only upon affirmatively requesting to do so.
  • the offers or information may be tailored to a particular user. For example, a user may perform a search on the Internet for a particular disease or may look up the disease in an information resource provided by the EMR system.
  • the EMR application may provide offers associated with the researched disease.
  • the EMR application may access a database of clinical trials and search for trials that are recruiting subjects who have the disease. The EMR application may notify the user regarding such clinical trials or may inform the user of recent research studies relating to the disease.
  • the EMR application may comprise or interface with one or more additional health-related applications for an electronic device, e.g., a portable electronic device.
  • Such application may be, for example, a medication tracking application, an exercise tracking application (e.g., a pedometer application), a weight tracking application, a calorie counting application, a heart or blood pressure monitoring application, etc.
  • the present invention may be included in an article of manufacture (e.g., one or more computer program products) comprising, for instance, computer useable media.
  • the media has embodied therein, for instance, computer readable program code means for providing and facilitating the mechanisms of the present invention.
  • the article of manufacture may be included as part of a computer system or sold separately.
  • the EMR database may be implemented using any suitable database management system (DBMS).
  • DBMS database management system
  • RDBMS relational database management system
  • Various RDBMS software packages are available, e.g., from
  • Microsoft e.g., Microsoft SQL Server
  • Oracle e.g., MySQL
  • Informix e.g., IBM
  • IBM e.g., IBM
  • Non-SQL based DBMSs e.g., object database management systems, may be used in various embodiments of the invention. It should be understood that the data may be stored in multiple distinct databases, which may be stored in different locations. Data may be stored and retrieved using standard approaches. It will be understood that data may be stored in the
  • the EMR database may contain references, e.g., pointers, to the data itself, which data may be stored within the EMR system or externally.
  • a EMR for a particular patient may contain a reference to a medical image, which medical image may be stored in a medical image database.
  • the content of the EMR database is digitally watermarked.
  • a computer system of use in the present invention may be a general-purpose computer system that is programmable using a high-level computer programming language.
  • a computer system may be
  • a computer system includes a processor, which may be a commercially available processor in various embodiments.
  • a processor usually executes an operating system which may be, for example, a Windows operating system (Microsoft), MAC OS (Apple),
  • Linux available from various sources, UNIX available from various sources, etc. Many other operating systems may be used. It will be understood that portable electronic devices may use different operating systems from those running on larger devices, e.g., iOS (Apple),
  • Android Open Handset Alliance
  • a processor and operating system together provide a computer platform for which application programs in high-level programming languages are written. It should be understood that the invention is not limited to a particular computer system platform, processor, operating system, or network. It would be apparent to those skilled in the art that the present invention could be implemented using any of a wide variety of programming languages or computer systems. It should be appreciated that the invention is not limited to any particular architecture, network, or communication protocol.
  • Various embodiments of the invention may be implemented as programmed or non-programmed elements, or any combination thereof.
  • Various embodiments of the present invention may be programmed using an object-oriented programming language, such as Java or C++. Other object-oriented programming languages may also be used. Functional, scripting, and/or logical programming languages may be used.
  • One or more elements of the invention or aspects thereof may include one or more application programming interfaces (APIs).
  • APIs application programming interfaces
  • APIs may, for example, facilitate communication between existing electronic medical record systems and a system of the present invention.
  • One or more elements of the invention or aspects thereof may be implemented as or using a "Web service" (which term refers to a software system designed to support interoperable machine-to-machine interaction over a network).
  • Web service which term refers to a software system designed to support interoperable machine-to-machine interaction over a network.
  • One or more elements of the invention or aspects thereof may be implemented using a document description language or environment (e.g., a markup language such as XML or HTML).
  • a markup language such as XML or HTML
  • the invention may modify or develop a domain-specific markup language for carrying out at least some functions of the invention.
  • such language may incorporate tags for items of medical data such as images (e.g., X-rays, CT scans, MRI scans, PET scans, etc.), EKGs, EEGs, or other types of health information.
  • a computer system may include various standard components such as one or more peripheral devices, e.g., one or more input devices (e.g., keyboard, mouse, etc.), one or more output devices (e.g., a display), data storage/memory component(s) (e.g., random access memory, read only memory), communications circuitry, etc.
  • peripheral devices e.g., one or more input devices (e.g., keyboard, mouse, etc.), one or more output devices (e.g., a display), data storage/memory component(s) (e.g., random access memory, read only memory), communications circuitry, etc.
  • data storage/memory component(s) e.g., random access memory, read only memory
  • communications circuitry e.g., etc.
  • HCPs or patients may often interact with the EMR system using standard personal computers in their place of work or home.
  • One or more components of an inventive system may be distributed across one or more computer systems, one or more of which may be coupled to a communications network.
  • various embodiments of the invention or components thereof may be distributed among one or more computer systems configured to provide a service (e.g., servers) to one or more client computers, or to perform a task as part of a distributed system.
  • various embodiments of the invention or components thereof may be performed on a client-server system that includes components distributed among one or more server systems that perform various functions according to various embodiments of the invention.
  • These components may communicate over one or more communication networks using a communication protocol. It would be appreciated that the business entity may or may not own the computer system or components thereof. In some embodiments at least some functions of the system may be outsourced.
  • cloud computing and/or cloud storage may be used at least in part.
  • EMRs are at least in part stored at a site where medical information is generated or entered ("local storage"), e.g., at a health care organization.
  • local storage e.g., at a health care organization.
  • multiple copies of EMRs are stored.
  • at least one copy may be stored by the business entity (e.g., on computer-readable medium owned or controlled by the business entity) and at least one copy may be stored locally and accessible by the business entity. Synchronization may be provided so that all copies remain the same or equivalent at most or essentially all times.
  • References to a "network” or “communication network”, unless otherwise indicated or specified, may include one or more intranets or the Internet.
  • the cloud computing environment 1000 may include one or more resource providers 1050a, 1050b, 1050c (collectively, 1050).
  • Each resource provider 1050 may include computing resources.
  • computing resources may include any hardware and/or software used to process data.
  • computing resources may include hardware and/or software capable of executing algorithms, computer programs, and/or computer applications.
  • exemplary computing resources may include application servers and/or databases with storage and retrieval capabilities.
  • Each resource provider 1050 may be connected to any other resource provider 1050 in the cloud computing environment 1000.
  • the resource providers 1050 may be connected over a computer network 1100.
  • Each resource provider 1050 may be connected to one or more computing device 1 150a, 1150b, 1150c (collectively, 1150), over a computer network 1 100.
  • the cloud computing environment 1000 may include a resource manager 1200.
  • the resource manager 1200 may be connected to the resource providers 1050 and the computing devices 1150 over the computer network 1100. In some implementations, the resource manager 1200 may facilitate the provision of computing resources by one or more resource providers 1050 to one or more computing devices 1 150.
  • the resource manager 1200 may be connected to the resource providers 1050 and the computing devices 1150 over the computer network 1100. In some implementations, the resource manager 1200 may facilitate the provision of computing resources by one or more resource providers 1050 to one or more computing devices 1 150.
  • the 1200 may receive a request for a computing resource from a computing device 1 150.
  • the resource manager 1200 may identify one or more resource providers 1050 capable of providing the computing resource requested by the computing device 1 150.
  • the resource manager 1200 may select a resource provider 1050 to provide the computing resource.
  • the resource manager 1200 may facilitate a connection between the resource provider 1050 and the computing device 1 150.
  • the resource manager 1200 may establish a connection between a resource provider 1050 and a computing device 1150.
  • the resource manager 1200 may redirect a computing device 1 150 to a resource provider 1050 with the requested computing resource.
  • all or substantially all health information in an EMR and/or in the EMR database may be stored on computer-readable media within the jurisdiction and/or within the geographical borders (optionally including ocean territory) of a selected country or union.
  • at least all or substantially all personally identifiable health information in an EMR and/or in the EMR database may be stored on computer-readable media within the jurisdiction and/or within the geographical borders (optionally including ocean territory) of a selected country or union.
  • all or substantially all health information received and stored (e.g., pertaining to a patient) may be stored on computer-readable media within the jurisdiction and/or within the geographical borders (optionally including ocean territory) of a selected country or union.
  • At least all or substantially all health information regarding a patient may be stored in a country or union in which the patient resides or in which the patient seeks health care.
  • at least all or substantially all personally identifiable health information regarding a patient may be transmitted only within a selected country or union, e.g., a country or union in which the patient resides or in which the patient seeks health care.
  • a country may be the U.S.
  • a country may be a country other than the U.S., which country may be any country in the world in various embodiments, e.g., Argentina, Australia, Belgium, Brazil, Canada, Chile, China, Egypt, France, India, Israel, Italy, Japan, Mexico, Netherlands, Norway, Pakistan, Tru, New Zealand, Philippines, Russia, South Africa, South Korea, Spain, Switzerland, Turkey, the United Kingdom.
  • a union may be the European Union.
  • a country or union may be a country or union in which the patient resides or seeks health care or in which a HCP practices or is registered to practice. In some embodiments of any aspect herein, a country or union may be a country or union in which the business entity is incorporated or its headquarters are physically located.
  • an ADM template or other element of an EMR may be generated at least in part by crowd-sourcing or using at least some crowdsourcing principles, which may comprise sourcing the generation of rules and/or code to a group of people or community (crowd) through an open call, e.g., a task may be broadcast (e.g., by posting on a web page) to an unknown group of solvers in the form of an open call for solutions.
  • the open call may be completely open or may be restricted at least in part (e.g., a solver or team may need to comprise at least one physician or medical student, in some embodiments).
  • the task(s) may include generating criteria, generating sets of predetermined options, generating any aspect of an ADM template, writing computer code for any aspect of an EMR system or
  • Broadcasting a task may comprise at least providing a task description. Broadcasting a task may comprise providing a set of guidelines (e.g., for diagnosis and/or management of a disease) and, e.g., a sample or example ADM template, and/or code therefor.
  • ADM template(s) or other task responses proposed by the crowd may be at least in part owned by the business entity, the proposer(s), or both.
  • the crowd may vote on a proposed ADM template or set of rules, criteria, or options to be adopted. Voting may be limited to HCPs, e.g., physicians.
  • Selection of a "winner” may be at the discretion of the business entity and/or may be approved by or with advice of a professional organization or board (e.g., in a relevant discipline). Prize(s) may be provided, which may, e.g., comprise a share in revenue generated through use of an adopted ADM template.
  • an ADM template or other element of an EMR may be generated at least in part by posting task(s) for bidding and awarding a contract for such task(s)to a selected bidder or bidders.
  • teams of physicians, programmers, and/or physician-programmers may be engaged or may participate
  • the cloud computing environment 1000 may include one or more resource providers 1050a, 1050b, 1050c (collectively, 1050).
  • Each resource provider 1050 may include computing resources.
  • computing resources may include any hardware and/or software used to process data.
  • computing resources may include hardware and/or software capable of executing algorithms, computer programs, and/or computer applications.
  • exemplary computing resources may include application servers and/or databases with storage and retrieval capabilities.
  • Each resource provider 1050 may be connected to any other resource provider 1050 in the cloud computing environment 1000.
  • the resource providers 1050 may be connected over a computer network
  • Each resource provider 1050 may be connected to one or more computing device
  • the cloud computing environment 1000 may include a resource manager 1200.
  • the resource manager 1200 may be connected to the resource providers 1050 and the computing devices 1150 over the computer network 1100. In some implementations, the resource manager 1200 may facilitate the provision of computing resources by one or more resource providers 1050 to one or more computing devices 1 150.
  • the resource manager 1200 may be connected to the resource providers 1050 and the computing devices 1150 over the computer network 1100. In some implementations, the resource manager 1200 may facilitate the provision of computing resources by one or more resource providers 1050 to one or more computing devices 1 150.
  • the 1200 may receive a request for a computing resource from a computing device 1 150.
  • the resource manager 1200 may identify one or more resource providers 1050 capable of providing the computing resource requested by the computing device 1 150.
  • the resource manager 1200 may select a resource provider 1050 to provide the computing resource.
  • the resource manager 1200 may facilitate a connection between the resource provider 1050 and the computing device 1150.
  • the resource manager 1200 may establish a connection between a resource provider 1050 and a computing device 1150.
  • the resource manager 1200 may redirect a computing device 1 150 to a resource provider 1050 with the requested computing resource.
  • the invention includes embodiments in which exactly one member of the group is present in, employed in, or otherwise relevant to a given product or process. It is to be understood that the invention encompasses all variations, combinations, and permutations in which one or more limitations, elements, clauses, descriptive terms, etc., from one or more of the listed claims is introduced into another claim. For example, any claim that is dependent on another claim may be modified to include one or more elements, limitations, clauses, or descriptive terms, found in any other claim that is dependent on the same base claim.
  • any of the methods disclosed herein, and methods of making the product are included within the scope of the invention, unless otherwise indicated or unless it would be evident to one of ordinary skill in the art that a contradiction or inconsistency would arise.
  • methods comprising executing computer-readable instructions to perform one or more acts or steps relating to an ADM, EMR, or database, such as accessing, retrieving, or analyzing one or more data elements therein, are provided. Any method may comprise a step of receiving a transmission, which transmission may comprise a query.
  • Any method may comprise a step of analyzing a transmission, which transmission may comprise a query. Any method may comprise a step of transmitting (e.g., following receipt of a query), which transmission may comprise a response to a query.
  • An apparatus may comprise one or more computer-readable media (e.g., memory).
  • a memory may comprise one or more non-transitory computer-readable media.
  • a memory may comprise at least a first medium and a second medium, wherein the first medium comprises a database and the second medium comprises the instructions.
  • a database, or instructions, or both, may be stored on or divided among any number of computer-readable media, in various embodiments.
  • An apparatus may comprise one or more processors.
  • An apparatus may comprise one or more computer-readable media and one or more processors.
  • a system may comprise an apparatus, which may itself comprise one or more systems or apparatuses.
  • a claim expressed at least in part in terms a system may be expressed at least in part in terms of an apparatus (or apparatuses), or vice versa.
  • a contributor or an act performed by a contributor are described, such contributor may in at least some embodiments be a designee of the contributor, and/or such act may be performed by a designee of the contributor, e.g., under direction of the contributor.
  • an incentive is provided to a contributor, such incentive may in at least some embodiments be provided to a Contibutor's designee.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Data Mining & Analysis (AREA)
  • Biomedical Technology (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Selon certains aspects, la présente invention porte sur un produit de programme informatique permettant d'assembler une base de données comprenant des dossiers médicaux électroniques (EMR). Dans certains modes de réalisation, un EMR comprend au moins un module de diagnostic actif (ADM). Dans certains modes de réalisation, la base de données est consultable en se basant sur au moins certains contenus ADM. D'autres aspects et caractéristiques de la présente invention sont décrits.
PCT/US2012/064125 2011-11-08 2012-11-08 Systèmes et procédés permettant d'assembler des dossiers médicaux électroniques WO2013070895A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/272,714 US20140244309A1 (en) 2011-11-08 2014-05-08 Systems and methods for assembling electronic medical records
US15/597,759 US20180082022A1 (en) 2011-11-08 2017-05-17 Systems and methods for assembling electronic medical records

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161557404P 2011-11-08 2011-11-08
US61/557,404 2011-11-08
US201261710296P 2012-10-05 2012-10-05
US61/710,296 2012-10-05

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/272,714 Continuation US20140244309A1 (en) 2011-11-08 2014-05-08 Systems and methods for assembling electronic medical records

Publications (1)

Publication Number Publication Date
WO2013070895A1 true WO2013070895A1 (fr) 2013-05-16

Family

ID=48290536

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/064125 WO2013070895A1 (fr) 2011-11-08 2012-11-08 Systèmes et procédés permettant d'assembler des dossiers médicaux électroniques

Country Status (2)

Country Link
US (2) US20140244309A1 (fr)
WO (1) WO2013070895A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI684109B (zh) * 2014-07-01 2020-02-01 阿聯商威孚有限公司 用於整理及展示多格式資料之電腦系統及方法
US10726098B2 (en) 2014-01-23 2020-07-28 Dror Samuel Brama Method, system and program product for transferring genetic and health data
US11101026B2 (en) 2013-05-29 2021-08-24 ZYUS Life Sciences US Ltd. Schedule-based electronic medical record modules, applications, and uses thereof
US20220189637A1 (en) * 2020-12-11 2022-06-16 Cerner Innovation, Inc. Automatic early prediction of neurodegenerative diseases

Families Citing this family (205)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949269B1 (en) * 2011-03-31 2015-02-03 Gregory J. Wolff Sponsored registry for improved coordination and communication
JP5899856B2 (ja) * 2011-11-18 2016-04-06 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
US20130346874A1 (en) * 2012-03-30 2013-12-26 Keys To Medicine, Llc User configurable electronic textbook
US20140214607A1 (en) * 2013-01-29 2014-07-31 Microsoft Corporation Global currency of credibility for crowdsourcing
US10445749B2 (en) * 2013-06-25 2019-10-15 Cerner Innovation, Inc. Universal content architecture system
US9640084B2 (en) * 2013-09-24 2017-05-02 Xerox Corporation Computer-based system and method for creating customized medical video information using crowd sourcing
WO2015176011A1 (fr) * 2014-05-15 2015-11-19 The Johns Hopkins University Procédé, système et support lisible par ordinateur pour analyse de risques de plan de traitement
US9626081B2 (en) 2014-05-19 2017-04-18 The Travelers Indemnity Company System for classification code selection
US10181051B2 (en) 2016-06-10 2019-01-15 OneTrust, LLC Data processing systems for generating and populating a data inventory for processing data access requests
US9729583B1 (en) 2016-06-10 2017-08-08 OneTrust, LLC Data processing systems and methods for performing privacy assessments and monitoring of new versions of computer code for privacy compliance
US10289867B2 (en) 2014-07-27 2019-05-14 OneTrust, LLC Data processing systems for webform crawling to map processing activities and related methods
US20160045168A1 (en) * 2014-08-12 2016-02-18 Allscripts Software, Llc Early warning score methodologies
US20160070860A1 (en) * 2014-09-08 2016-03-10 WebMD Health Corporation Structuring multi-sourced medical information into a collaborative health record
US11514031B2 (en) 2014-10-30 2022-11-29 The Travelers Indemnity Company Product navigator
US10055452B2 (en) * 2014-10-30 2018-08-21 The Travelers Indemnity Company Most likely classification code
MA41577A (fr) * 2015-01-16 2017-11-22 Pricewaterhousecoopers Llp Système et procédé d'échange de données de soins de santé
US10417607B1 (en) * 2015-05-19 2019-09-17 Amazon Technologies, Inc. Status updates during latency
US10269114B2 (en) 2015-06-12 2019-04-23 International Business Machines Corporation Methods and systems for automatically scoring diagnoses associated with clinical images
US20160378931A1 (en) * 2015-06-23 2016-12-29 PRX Control Solutions, LLC Methods and systems for comparing and matching medical treatment versus diagnosis and/or other indicators related to medical treatment and/or diagnosis
US20170277838A1 (en) * 2016-03-25 2017-09-28 Experian Health, Inc. Criteria template auto-generation and criteria auto-population
US11244367B2 (en) 2016-04-01 2022-02-08 OneTrust, LLC Data processing systems and methods for integrating privacy information management systems with data loss prevention tools or other tools for privacy design
US10706447B2 (en) 2016-04-01 2020-07-07 OneTrust, LLC Data processing systems and communication systems and methods for the efficient generation of privacy risk assessments
US9892443B2 (en) 2016-04-01 2018-02-13 OneTrust, LLC Data processing systems for modifying privacy campaign data via electronic messaging systems
US10423996B2 (en) 2016-04-01 2019-09-24 OneTrust, LLC Data processing systems and communication systems and methods for the efficient generation of privacy risk assessments
US11004125B2 (en) 2016-04-01 2021-05-11 OneTrust, LLC Data processing systems and methods for integrating privacy information management systems with data loss prevention tools or other tools for privacy design
US9898769B2 (en) 2016-04-01 2018-02-20 OneTrust, LLC Data processing systems and methods for operationalizing privacy compliance via integrated mobile applications
US9892444B2 (en) 2016-04-01 2018-02-13 OneTrust, LLC Data processing systems and communication systems and methods for the efficient generation of privacy risk assessments
US20220164840A1 (en) 2016-04-01 2022-05-26 OneTrust, LLC Data processing systems and methods for integrating privacy information management systems with data loss prevention tools or other tools for privacy design
US10176502B2 (en) 2016-04-01 2019-01-08 OneTrust, LLC Data processing systems and methods for integrating privacy information management systems with data loss prevention tools or other tools for privacy design
US10176503B2 (en) 2016-04-01 2019-01-08 OneTrust, LLC Data processing systems and methods for efficiently assessing the risk of privacy campaigns
CA3024882C (fr) * 2016-05-20 2021-03-02 Appmed Inc. Systeme et procede de surveillance et de determination de la posologie optimale chez une personne
US10509894B2 (en) 2016-06-10 2019-12-17 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US11354435B2 (en) 2016-06-10 2022-06-07 OneTrust, LLC Data processing systems for data testing to confirm data deletion and related methods
US11200341B2 (en) 2016-06-10 2021-12-14 OneTrust, LLC Consent receipt management systems and related methods
US10437412B2 (en) 2016-06-10 2019-10-08 OneTrust, LLC Consent receipt management systems and related methods
US10509920B2 (en) 2016-06-10 2019-12-17 OneTrust, LLC Data processing systems for processing data subject access requests
US11481710B2 (en) 2016-06-10 2022-10-25 OneTrust, LLC Privacy management systems and methods
US11403377B2 (en) 2016-06-10 2022-08-02 OneTrust, LLC Privacy management systems and methods
US11087260B2 (en) 2016-06-10 2021-08-10 OneTrust, LLC Data processing systems and methods for customizing privacy training
US10592692B2 (en) 2016-06-10 2020-03-17 OneTrust, LLC Data processing systems for central consent repository and related methods
US10592648B2 (en) 2016-06-10 2020-03-17 OneTrust, LLC Consent receipt management systems and related methods
US11416798B2 (en) 2016-06-10 2022-08-16 OneTrust, LLC Data processing systems and methods for providing training in a vendor procurement process
US10783256B2 (en) 2016-06-10 2020-09-22 OneTrust, LLC Data processing systems for data transfer risk identification and related methods
US11038925B2 (en) 2016-06-10 2021-06-15 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US10454973B2 (en) 2016-06-10 2019-10-22 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US10438017B2 (en) 2016-06-10 2019-10-08 OneTrust, LLC Data processing systems for processing data subject access requests
US10798133B2 (en) 2016-06-10 2020-10-06 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US10586075B2 (en) 2016-06-10 2020-03-10 OneTrust, LLC Data processing systems for orphaned data identification and deletion and related methods
US11562097B2 (en) 2016-06-10 2023-01-24 OneTrust, LLC Data processing systems for central consent repository and related methods
US10181019B2 (en) 2016-06-10 2019-01-15 OneTrust, LLC Data processing systems and communications systems and methods for integrating privacy compliance systems with software development and agile tools for privacy design
US10944725B2 (en) 2016-06-10 2021-03-09 OneTrust, LLC Data processing systems and methods for using a data model to select a target data asset in a data migration
US10803200B2 (en) 2016-06-10 2020-10-13 OneTrust, LLC Data processing systems for processing and managing data subject access in a distributed environment
US11301796B2 (en) 2016-06-10 2022-04-12 OneTrust, LLC Data processing systems and methods for customizing privacy training
US10318761B2 (en) 2016-06-10 2019-06-11 OneTrust, LLC Data processing systems and methods for auditing data request compliance
US11144622B2 (en) 2016-06-10 2021-10-12 OneTrust, LLC Privacy management systems and methods
US10853501B2 (en) 2016-06-10 2020-12-01 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US10275614B2 (en) 2016-06-10 2019-04-30 OneTrust, LLC Data processing systems for generating and populating a data inventory
US11475136B2 (en) 2016-06-10 2022-10-18 OneTrust, LLC Data processing systems for data transfer risk identification and related methods
US11222142B2 (en) 2016-06-10 2022-01-11 OneTrust, LLC Data processing systems for validating authorization for personal data collection, storage, and processing
US10997315B2 (en) 2016-06-10 2021-05-04 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11416589B2 (en) 2016-06-10 2022-08-16 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US11392720B2 (en) 2016-06-10 2022-07-19 OneTrust, LLC Data processing systems for verification of consent and notice processing and related methods
US10565161B2 (en) 2016-06-10 2020-02-18 OneTrust, LLC Data processing systems for processing data subject access requests
US10510031B2 (en) 2016-06-10 2019-12-17 OneTrust, LLC Data processing systems for identifying, assessing, and remediating data processing risks using data modeling techniques
US10685140B2 (en) 2016-06-10 2020-06-16 OneTrust, LLC Consent receipt management systems and related methods
US11138299B2 (en) 2016-06-10 2021-10-05 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US10706131B2 (en) 2016-06-10 2020-07-07 OneTrust, LLC Data processing systems and methods for efficiently assessing the risk of privacy campaigns
US11134086B2 (en) 2016-06-10 2021-09-28 OneTrust, LLC Consent conversion optimization systems and related methods
US11100444B2 (en) 2016-06-10 2021-08-24 OneTrust, LLC Data processing systems and methods for providing training in a vendor procurement process
US11146566B2 (en) 2016-06-10 2021-10-12 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US10885485B2 (en) 2016-06-10 2021-01-05 OneTrust, LLC Privacy management systems and methods
US10614247B2 (en) 2016-06-10 2020-04-07 OneTrust, LLC Data processing systems for automated classification of personal information from documents and related methods
US10169609B1 (en) 2016-06-10 2019-01-01 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11023842B2 (en) 2016-06-10 2021-06-01 OneTrust, LLC Data processing systems and methods for bundled privacy policies
US10572686B2 (en) 2016-06-10 2020-02-25 OneTrust, LLC Consent receipt management systems and related methods
US10282692B2 (en) 2016-06-10 2019-05-07 OneTrust, LLC Data processing systems for identifying, assessing, and remediating data processing risks using data modeling techniques
US10848523B2 (en) 2016-06-10 2020-11-24 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US10467432B2 (en) 2016-06-10 2019-11-05 OneTrust, LLC Data processing systems for use in automatically generating, populating, and submitting data subject access requests
US11418492B2 (en) 2016-06-10 2022-08-16 OneTrust, LLC Data processing systems and methods for using a data model to select a target data asset in a data migration
US10452864B2 (en) 2016-06-10 2019-10-22 OneTrust, LLC Data processing systems for webform crawling to map processing activities and related methods
US10706176B2 (en) 2016-06-10 2020-07-07 OneTrust, LLC Data-processing consent refresh, re-prompt, and recapture systems and related methods
US10204154B2 (en) 2016-06-10 2019-02-12 OneTrust, LLC Data processing systems for generating and populating a data inventory
US11222309B2 (en) 2016-06-10 2022-01-11 OneTrust, LLC Data processing systems for generating and populating a data inventory
US11461500B2 (en) 2016-06-10 2022-10-04 OneTrust, LLC Data processing systems for cookie compliance testing with website scanning and related methods
US10706174B2 (en) 2016-06-10 2020-07-07 OneTrust, LLC Data processing systems for prioritizing data subject access requests for fulfillment and related methods
US11366909B2 (en) 2016-06-10 2022-06-21 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US11151233B2 (en) 2016-06-10 2021-10-19 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US11238390B2 (en) 2016-06-10 2022-02-01 OneTrust, LLC Privacy management systems and methods
US10565236B1 (en) 2016-06-10 2020-02-18 OneTrust, LLC Data processing systems for generating and populating a data inventory
US11277448B2 (en) 2016-06-10 2022-03-15 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US11354434B2 (en) 2016-06-10 2022-06-07 OneTrust, LLC Data processing systems for verification of consent and notice processing and related methods
US11328092B2 (en) 2016-06-10 2022-05-10 OneTrust, LLC Data processing systems for processing and managing data subject access in a distributed environment
US10346637B2 (en) 2016-06-10 2019-07-09 OneTrust, LLC Data processing systems for the identification and deletion of personal data in computer systems
US10909488B2 (en) 2016-06-10 2021-02-02 OneTrust, LLC Data processing systems for assessing readiness for responding to privacy-related incidents
US10430740B2 (en) 2016-06-10 2019-10-01 One Trust, LLC Data processing systems for calculating and communicating cost of fulfilling data subject access requests and related methods
US10565397B1 (en) 2016-06-10 2020-02-18 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11210420B2 (en) 2016-06-10 2021-12-28 OneTrust, LLC Data subject access request processing systems and related methods
US10949170B2 (en) 2016-06-10 2021-03-16 OneTrust, LLC Data processing systems for integration of consumer feedback with data subject access requests and related methods
US10678945B2 (en) 2016-06-10 2020-06-09 OneTrust, LLC Consent receipt management systems and related methods
US10769301B2 (en) 2016-06-10 2020-09-08 OneTrust, LLC Data processing systems for webform crawling to map processing activities and related methods
US10713387B2 (en) 2016-06-10 2020-07-14 OneTrust, LLC Consent conversion optimization systems and related methods
US10282700B2 (en) 2016-06-10 2019-05-07 OneTrust, LLC Data processing systems for generating and populating a data inventory
US11157600B2 (en) 2016-06-10 2021-10-26 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US11636171B2 (en) 2016-06-10 2023-04-25 OneTrust, LLC Data processing user interface monitoring systems and related methods
US10997318B2 (en) 2016-06-10 2021-05-04 OneTrust, LLC Data processing systems for generating and populating a data inventory for processing data access requests
US11544667B2 (en) 2016-06-10 2023-01-03 OneTrust, LLC Data processing systems for generating and populating a data inventory
US10796260B2 (en) 2016-06-10 2020-10-06 OneTrust, LLC Privacy management systems and methods
US11138242B2 (en) 2016-06-10 2021-10-05 OneTrust, LLC Data processing systems and methods for automatically detecting and documenting privacy-related aspects of computer software
US10762236B2 (en) 2016-06-10 2020-09-01 OneTrust, LLC Data processing user interface monitoring systems and related methods
US10284604B2 (en) 2016-06-10 2019-05-07 OneTrust, LLC Data processing and scanning systems for generating and populating a data inventory
US11074367B2 (en) 2016-06-10 2021-07-27 OneTrust, LLC Data processing systems for identity validation for consumer rights requests and related methods
US10740487B2 (en) 2016-06-10 2020-08-11 OneTrust, LLC Data processing systems and methods for populating and maintaining a centralized database of personal data
US11057356B2 (en) 2016-06-10 2021-07-06 OneTrust, LLC Automated data processing systems and methods for automatically processing data subject access requests using a chatbot
US11188862B2 (en) 2016-06-10 2021-11-30 OneTrust, LLC Privacy management systems and methods
US10242228B2 (en) 2016-06-10 2019-03-26 OneTrust, LLC Data processing systems for measuring privacy maturity within an organization
US11727141B2 (en) 2016-06-10 2023-08-15 OneTrust, LLC Data processing systems and methods for synching privacy-related user consent across multiple computing devices
US10346638B2 (en) 2016-06-10 2019-07-09 OneTrust, LLC Data processing systems for identifying and modifying processes that are subject to data subject access requests
US10289870B2 (en) 2016-06-10 2019-05-14 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11625502B2 (en) 2016-06-10 2023-04-11 OneTrust, LLC Data processing systems for identifying and modifying processes that are subject to data subject access requests
US10353673B2 (en) 2016-06-10 2019-07-16 OneTrust, LLC Data processing systems for integration of consumer feedback with data subject access requests and related methods
US10416966B2 (en) 2016-06-10 2019-09-17 OneTrust, LLC Data processing systems for identity validation of data subject access requests and related methods
US10878127B2 (en) 2016-06-10 2020-12-29 OneTrust, LLC Data subject access request processing systems and related methods
US11227247B2 (en) 2016-06-10 2022-01-18 OneTrust, LLC Data processing systems and methods for bundled privacy policies
US10496846B1 (en) 2016-06-10 2019-12-03 OneTrust, LLC Data processing and communications systems and methods for the efficient implementation of privacy by design
US10873606B2 (en) 2016-06-10 2020-12-22 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US10282559B2 (en) 2016-06-10 2019-05-07 OneTrust, LLC Data processing systems for identifying, assessing, and remediating data processing risks using data modeling techniques
US10949565B2 (en) 2016-06-10 2021-03-16 OneTrust, LLC Data processing systems for generating and populating a data inventory
US10839102B2 (en) 2016-06-10 2020-11-17 OneTrust, LLC Data processing systems for identifying and modifying processes that are subject to data subject access requests
US11188615B2 (en) 2016-06-10 2021-11-30 OneTrust, LLC Data processing consent capture systems and related methods
US10452866B2 (en) 2016-06-10 2019-10-22 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US10503926B2 (en) 2016-06-10 2019-12-10 OneTrust, LLC Consent receipt management systems and related methods
US11222139B2 (en) 2016-06-10 2022-01-11 OneTrust, LLC Data processing systems and methods for automatic discovery and assessment of mobile software development kits
US10585968B2 (en) 2016-06-10 2020-03-10 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US10776514B2 (en) 2016-06-10 2020-09-15 OneTrust, LLC Data processing systems for the identification and deletion of personal data in computer systems
US10289866B2 (en) * 2016-06-10 2019-05-14 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US10776517B2 (en) 2016-06-10 2020-09-15 OneTrust, LLC Data processing systems for calculating and communicating cost of fulfilling data subject access requests and related methods
US10235534B2 (en) 2016-06-10 2019-03-19 OneTrust, LLC Data processing systems for prioritizing data subject access requests for fulfillment and related methods
US10708305B2 (en) 2016-06-10 2020-07-07 OneTrust, LLC Automated data processing systems and methods for automatically processing requests for privacy-related information
US10642870B2 (en) 2016-06-10 2020-05-05 OneTrust, LLC Data processing systems and methods for automatically detecting and documenting privacy-related aspects of computer software
US10496803B2 (en) 2016-06-10 2019-12-03 OneTrust, LLC Data processing systems and methods for efficiently assessing the risk of privacy campaigns
US10896394B2 (en) 2016-06-10 2021-01-19 OneTrust, LLC Privacy management systems and methods
US10706379B2 (en) 2016-06-10 2020-07-07 OneTrust, LLC Data processing systems for automatic preparation for remediation and related methods
US11586700B2 (en) 2016-06-10 2023-02-21 OneTrust, LLC Data processing systems and methods for automatically blocking the use of tracking tools
US10440062B2 (en) 2016-06-10 2019-10-08 OneTrust, LLC Consent receipt management systems and related methods
US11651104B2 (en) 2016-06-10 2023-05-16 OneTrust, LLC Consent receipt management systems and related methods
US11651106B2 (en) 2016-06-10 2023-05-16 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11416109B2 (en) 2016-06-10 2022-08-16 OneTrust, LLC Automated data processing systems and methods for automatically processing data subject access requests using a chatbot
US11438386B2 (en) 2016-06-10 2022-09-06 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US11341447B2 (en) 2016-06-10 2022-05-24 OneTrust, LLC Privacy management systems and methods
US11294939B2 (en) 2016-06-10 2022-04-05 OneTrust, LLC Data processing systems and methods for automatically detecting and documenting privacy-related aspects of computer software
US11295316B2 (en) 2016-06-10 2022-04-05 OneTrust, LLC Data processing systems for identity validation for consumer rights requests and related methods
US10909265B2 (en) 2016-06-10 2021-02-02 OneTrust, LLC Application privacy scanning systems and related methods
US10726158B2 (en) 2016-06-10 2020-07-28 OneTrust, LLC Consent receipt management and automated process blocking systems and related methods
US11336697B2 (en) 2016-06-10 2022-05-17 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US11343284B2 (en) 2016-06-10 2022-05-24 OneTrust, LLC Data processing systems and methods for performing privacy assessments and monitoring of new versions of computer code for privacy compliance
US11416590B2 (en) 2016-06-10 2022-08-16 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US10606916B2 (en) 2016-06-10 2020-03-31 OneTrust, LLC Data processing user interface monitoring systems and related methods
US11025675B2 (en) 2016-06-10 2021-06-01 OneTrust, LLC Data processing systems and methods for performing privacy assessments and monitoring of new versions of computer code for privacy compliance
US11675929B2 (en) 2016-06-10 2023-06-13 OneTrust, LLC Data processing consent sharing systems and related methods
US11228620B2 (en) 2016-06-10 2022-01-18 OneTrust, LLC Data processing systems for data-transfer risk identification, cross-border visualization generation, and related methods
US10846433B2 (en) 2016-06-10 2020-11-24 OneTrust, LLC Data processing consent management systems and related methods
US10776518B2 (en) 2016-06-10 2020-09-15 OneTrust, LLC Consent receipt management systems and related methods
US11366786B2 (en) 2016-06-10 2022-06-21 OneTrust, LLC Data processing systems for processing data subject access requests
US11520928B2 (en) 2016-06-10 2022-12-06 OneTrust, LLC Data processing systems for generating personal data receipts and related methods
US10607028B2 (en) 2016-06-10 2020-03-31 OneTrust, LLC Data processing systems for data testing to confirm data deletion and related methods
WO2017222997A1 (fr) * 2016-06-20 2017-12-28 Magic Leap, Inc. Système d'affichage en réalité augmentée pour l'évaluation et la modification de troubles neurologiques, notamment des troubles du traitement de l'information visuelle et des troubles de la perception visuelle
US10013577B1 (en) 2017-06-16 2018-07-03 OneTrust, LLC Data processing systems for identifying whether cookies contain personally identifying information
US10726391B1 (en) * 2017-11-30 2020-07-28 United Services Automobile Association (Usaa) Customer content personalization
US10832808B2 (en) 2017-12-13 2020-11-10 International Business Machines Corporation Automated selection, arrangement, and processing of key images
US11495332B2 (en) 2017-12-28 2022-11-08 International Business Machines Corporation Automated prediction and answering of medical professional questions directed to patient based on EMR
US11031109B2 (en) 2017-12-28 2021-06-08 International Business Machines Corporation Contextual EMR based dashboard graphical user interface elements
US10950354B1 (en) * 2018-03-02 2021-03-16 Allscripts Software, Llc Computing system for pharmacogenomics
US11189364B1 (en) * 2018-03-07 2021-11-30 Iqvia Inc. Computing platform for establishing referrals
JP6420513B1 (ja) * 2018-03-19 2018-11-07 雅晴 古川 情報管理装置
US10770171B2 (en) * 2018-04-12 2020-09-08 International Business Machines Corporation Augmenting datasets using de-identified data and selected authorized records
US11093640B2 (en) 2018-04-12 2021-08-17 International Business Machines Corporation Augmenting datasets with selected de-identified data records
US11836454B2 (en) * 2018-05-02 2023-12-05 Language Scientific, Inc. Systems and methods for producing reliable translation in near real-time
US10978180B1 (en) 2018-07-30 2021-04-13 Iqvia Inc. Enabling data flow in an electronic referral network
US11144675B2 (en) 2018-09-07 2021-10-12 OneTrust, LLC Data processing systems and methods for automatically protecting sensitive data within privacy management systems
US11544409B2 (en) 2018-09-07 2023-01-03 OneTrust, LLC Data processing systems and methods for automatically protecting sensitive data within privacy management systems
US10803202B2 (en) 2018-09-07 2020-10-13 OneTrust, LLC Data processing systems for orphaned data identification and deletion and related methods
CN109545369A (zh) * 2018-10-27 2019-03-29 平安医疗健康管理股份有限公司 基于数据处理的糖尿病资质认证方法、设备及服务器
KR101989474B1 (ko) * 2018-11-23 2019-06-14 (주)레몬헬스케어 클라우드 기반의 전자처방 전송 시스템 및 방법
CA3137168A1 (fr) * 2019-04-17 2020-10-22 Tempus Labs Procede et systeme d'intelligence artificielle collaborative
JP7291535B2 (ja) * 2019-05-17 2023-06-15 ユニ・チャーム株式会社 提供装置、提供方法、提供プログラム及び提供システム
WO2022011142A1 (fr) 2020-07-08 2022-01-13 OneTrust, LLC Systèmes et procédés pour la découverte de données ciblées
EP4189569A1 (fr) 2020-07-28 2023-06-07 OneTrust LLC Systèmes et procédés permettant de bloquer automatiquement l'utilisation d'outils de suivi
US20230289376A1 (en) 2020-08-06 2023-09-14 OneTrust, LLC Data processing systems and methods for automatically redacting unstructured data from a data subject access request
US11436373B2 (en) 2020-09-15 2022-09-06 OneTrust, LLC Data processing systems and methods for detecting tools for the automatic blocking of consent requests
US11526624B2 (en) 2020-09-21 2022-12-13 OneTrust, LLC Data processing systems and methods for automatically detecting target data transfers and target data processing
US11782956B2 (en) 2020-10-23 2023-10-10 Privacy Analytics Inc. System and method for intermediary mapping and de-identification of non-standard datasets
EP4241173A1 (fr) 2020-11-06 2023-09-13 OneTrust LLC Systèmes et procédés d'identification d'activités de traitement de données sur la base de résultats de découverte de données
WO2022159901A1 (fr) 2021-01-25 2022-07-28 OneTrust, LLC Systèmes et procédés de découverte, de classification et d'indexation de données dans un système informatique natif
WO2022170047A1 (fr) 2021-02-04 2022-08-11 OneTrust, LLC Gestion d'attributs personnalisés pour des objets de domaine définis dans des microservices
WO2022170254A1 (fr) 2021-02-08 2022-08-11 OneTrust, LLC Systèmes de traitement de données et procédés permettant de rendre anonymes des échantillons de données dans une analyse de classification
US20240098109A1 (en) 2021-02-10 2024-03-21 OneTrust, LLC Systems and methods for mitigating risks of third-party computing system functionality integration into a first-party computing system
US11775348B2 (en) 2021-02-17 2023-10-03 OneTrust, LLC Managing custom workflows for domain objects defined within microservices
WO2022178219A1 (fr) 2021-02-18 2022-08-25 OneTrust, LLC Édition sélective de contenu multimédia
EP4305539A1 (fr) 2021-03-08 2024-01-17 OneTrust, LLC Systèmes de découverte et d'analyse de transfert de données et procédés associés
US11550854B2 (en) 2021-03-15 2023-01-10 Unitedhealth Group Incorporated Dynamic delivery of modified user interaction electronic document data objects based at least in part on defined trigger events
US11824937B2 (en) 2021-04-04 2023-11-21 Rissana, LLC System and method for handling the connection of user accounts to other entities
US11562078B2 (en) 2021-04-16 2023-01-24 OneTrust, LLC Assessing and managing computational risk involved with integrating third party computing functionality within a computing system
DE102021207046A1 (de) * 2021-07-05 2023-01-05 Siemens Healthcare Gmbh Upgraden oder Updaten einer Software-Anwendung
US11620142B1 (en) 2022-06-03 2023-04-04 OneTrust, LLC Generating and customizing user interfaces for demonstrating functions of interactive user environments
JP2024011594A (ja) * 2022-07-15 2024-01-25 株式会社サンクスネット 健康医療情報一元管理システム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090287837A1 (en) * 2000-07-06 2009-11-19 David Paul Felsher Information record infrastructure, system and method

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149756B1 (en) * 2000-05-08 2006-12-12 Medoctor, Inc. System and method for determining the probable existence of disease
US6684276B2 (en) * 2001-03-28 2004-01-27 Thomas M. Walker Patient encounter electronic medical record system, method, and computer product
CN1639721A (zh) * 2002-04-04 2005-07-13 佳能株式会社 协作诊断系统
US8606593B1 (en) * 2009-02-25 2013-12-10 Greenway Medical Technologies. Inc. System and method for analyzing, collecting and tracking patient data across a vast patient population
US20080040151A1 (en) * 2005-02-01 2008-02-14 Moore James F Uses of managed health care data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090287837A1 (en) * 2000-07-06 2009-11-19 David Paul Felsher Information record infrastructure, system and method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANDREW TROELSEN.: "Pro C# 2008 and the .NET 3.5 Platform", PRO C# 2008 AND THE .NET 3.5 PLATFORM, 2007, pages 1172 - 1174, 1231-1236 *
MICHAEL J. YOUNG ET AL., MICROSOFT® OFFICE SYSTEM INSIDE OUT-2003 EDITION., 2004, pages 1102, 1103, 1191, 1192 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11101026B2 (en) 2013-05-29 2021-08-24 ZYUS Life Sciences US Ltd. Schedule-based electronic medical record modules, applications, and uses thereof
US10726098B2 (en) 2014-01-23 2020-07-28 Dror Samuel Brama Method, system and program product for transferring genetic and health data
TWI684109B (zh) * 2014-07-01 2020-02-01 阿聯商威孚有限公司 用於整理及展示多格式資料之電腦系統及方法
US20220189637A1 (en) * 2020-12-11 2022-06-16 Cerner Innovation, Inc. Automatic early prediction of neurodegenerative diseases

Also Published As

Publication number Publication date
US20180082022A1 (en) 2018-03-22
US20140244309A1 (en) 2014-08-28

Similar Documents

Publication Publication Date Title
US20180082022A1 (en) Systems and methods for assembling electronic medical records
US20190244683A1 (en) Systems and methods for using electronic medical records in conjunction with patient apps
US11580090B2 (en) Community data aggregation with automated followup
US8301462B2 (en) Systems and methods for disease management algorithm integration
US11101026B2 (en) Schedule-based electronic medical record modules, applications, and uses thereof
US20090076855A1 (en) Apparatus, method and system for web-based health care marketplace portal
US20160314280A1 (en) Identification of Candidates for Clinical Trials
US20140316810A1 (en) Integrated health management system
US20140100874A1 (en) Method for displaying linked family health history on a computing device
Jung et al. Barriers and facilitators to implementation of nationwide electronic health records in the Russian Far East: A qualitative analysis
Luk The impact of digital health on traditional healthcare systems and doctor-patient relationships: the case study of Singapore
Gracy et al. Content barriers to pediatric uptake of electronic health records
Woo et al. The current status of breakthrough devices designation in the United States and innovative medical devices designation in Korea for digital health software
National Academies of Sciences, Engineering, and Medicine Improving cancer diagnosis and care: clinical application of computational methods in precision oncology: proceedings of a workshop
Patel et al. A novel cross-disciplinary multi-institute approach to translational cancer research: lessons learned from Pennsylvania Cancer Alliance Bioinformatics Consortium (PCABC)
Gabriel Data Privacy and Ethical Issues in Collecting Health Care Data Using Artificial Intelligence Among Health Workers
Connecting for Health Personal Health Working Group The personal health working Group
Vu et al. Shared decision making in acute pain management in patients with opioid use disorder: a scoping review
Dixon et al. Health information exchange and Interoperability
Verma et al. Digital Assistant in the Pharmaceutical Field for Advancing Healthcare Systems
Alsahafi Studies of EHR implementation and operation in different countries with particular reference to Saudi Arabia
Van Garderen et al. Text automation tool to improve pharmacist productivity and work capacity in a digital hospital: a pilot study
Knockel et al. Medication-related problems and interventions identified and addressed by pharmacists conducting enhanced medication therapy management services
Zorko Kodelja et al. Slovenian Civil Registration and Unique Identification Number System for Universal Health Coverage
Downard et al. Pharmacists' use of electronic health records: Silent leaders no more

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12848176

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12848176

Country of ref document: EP

Kind code of ref document: A1