Patent Application
20140257840
The present disclosure relates in general to data processing and, in particular, to facilitating communication between medical care providers, patients, and third party service and product suppliers.
Until recently, pharmaceutical companies, medical device manufacturers, and other medical suppliers marketed their products directly to physicians, hospitals, and other care providers. These marketing efforts often included cash payments, free meals, trips, tickets to sporting events, and other gifts to care providers. According to Pew Charitable Trusts, in 2012 the pharmaceutical companies alone spent more than $15 billion on direct-to-physician marketing and promotions.
On Aug. 1, 2013, The Physician Payments Sunshine Act (Sunshine Act) came into effect in the United States. The goal of this law is to improve patient care and lower the cost of healthcare by requiring manufacturers of pharmaceutical and biological drugs, medical devices, and medical supplies to report when they transfer goods that are worth over $10 to physicians or teaching hospitals. The Sunshine Act increases transparency in physician-industry relationships to reduce the potential for conflicts of interest that could affect patient care. Although the Sunshine Act does not dictate how pharmaceutical, device, and medical supply companies spend their marketing dollars, many of the previous marketing practices are likely to be modified or discontinued. For example, the Sunshine Act is expected to effectively redirect or eliminate 60-80% of current marketing expenditures in the pharmaceutical industry.
The present disclosure recognizes that medical service, product and device companies need to find new ways to market and educate the public about their offerings. In addition, physicians and patients need to find new ways to get information on the products and services they need.
In one or more embodiments, the basic need for effective communication in the new regulatory environment is met through one or more techniques that can be used to improve quality of care, improve the information available to patients, and increase compliance with medical standards.
In one aspect, communication between medical providers, patients and remote data sources is facilitated so that quality of care can be improved. The remote data sources can include, but are not limited to the following: medical service providers; medical device manufacturers; medical product and drug companies; government agencies; standards bodies; insurance companies; educational institutions; patient support groups; medical journals and databases; and in-house patient records, standards of care, quality measurements and other digitized data owned by the practice or institution. In one embodiment, this communication facility is implemented in a medical information handling system, such as an Electronic Health Records (EHR) system, that care providers use to manage their patients.
In another aspect, quality of care can be improved by bringing together data from disparate sources during patient/care provider interactions. For example, during a consultation, a doctor may enter a new diagnosis for a patient into a medical information handling system. Upon entry, the system can retrieve and display data from the practice's standards of care database, from the patient's insurance company about eligibility and coverage amounts, and from government agencies about quality measures and outcomes using different treatments. Having this data available immediately allows the doctor and patient to have an informed discussion about the best course of action. In addition, automatically aggregating this information at the time it is needed (i.e., in real time) saves both doctor and patient time, reduces the need for follow-up consultations, improves data reliability, and, in general, makes the delivery of medical services more efficient. Points in time at which remote or external data are integrated into a medical information handling system are referred to herein as injection points.
In yet another aspect, digital advertising is employed to facilitate communication between medical suppliers and care providers. As noted above, government regulations and/or ethics standards can reduce or eliminate the ability of medical suppliers to persuade care providers to use their products with direct marketing incentives. In one embodiment, a medical information handling system supports the placement of advertisements at specific injection points in an application. One benefit of introducing an advertising model into medical information handling systems, such as EHR systems, is that the cost of such software to care providers can be reduced or eliminated. Medical information handling systems—and EHR systems in particular—are expensive and can be a heavy burden on small medical practices, independent practitioners, and practices and institutions in underserved areas. The disclosed use of advertisements in a medical information handling system enables new funding models that require less upfront investment.
According to one particular embodiment, one injection point is when a care provider enters a prescription for a drug for a patient into the medical information handling system. The medical information handling system consults the patient's medical record, information about one or more medical problems, and information about the drug or medical device. The medical information handling system can also consult a library of promotional information supplied by pharmaceutical companies and/or medical device companies to determine if an advertisement should be injected into an on-screen presentation at the injection point.
In yet another aspect, the medical information handling system presents a presentation including contextual social recommendations. An example might be as follows: “Your colleague, Dr. John Smith, recently prescribed Prilosec OTC® to treat a similar patient's heartburn. Would you like to learn more?” Another example might be as follows: “Dr. John Jones is one of the top physicians in this network, and he prescribes Prilosec OTC® for heartburn. Learn more here!” (Prilosec OTC® is a registered trademark of AstraZeneca.)
In yet another aspect, if a care provider or patient desires additional information, a selectable element in the presentation can be selected to invoke an informative promotional presentation by the medical information handling system, for example, featuring detailed information and videos provided by a pharmaceutical and/or medical device company, as well as testimonials on the drug from care providers and/or patients. If a care provider is interested in a drug or medical device after reviewing the promotional materials, the care provider can initiate contact with a sales representative, request samples, and/or prescribe the drug and/or medical device by making the appropriate selection within the presentation of the medical information handling system. In embodiment, multiple modalities of contact with a sales representative can be supported through the medical information handling system. For example, the care provider can request an in-person appointment, engage in an online chat, or participate in an online video conference by appropriate inputs in the presentation of the medical information handling system.
With reference now to the figures and with particular reference to
In the depicted embodiment, medical information handling system 102 includes one or more processors 104 (typically comprising one or more integrated circuits) that process data and program code, for example, to manage, access, manipulate, modify, store and present data and/or software in data processing environment 100. Medical information handling system 102 also includes input/output (I/O) devices 106, such as ports, displays, user input devices and attached devices, etc., which receive inputs and provide outputs of the processing performed by medical information handling system 102 and/or other resource(s) in data processing environment 100. Medical information handling system 102 additionally includes local data storage 108, which may include one or more volatile or non-volatile storage devices, including memories, solid state drives, optical and/or magnetic disk drives, tape drives, etc. Local data storage 108 may store, for example, program code (including software, firmware or a combination thereof) that when executed by processor(s) 104 causes medical information handling system 200 to implement at least some of the functionality described herein. In the illustrated exemplary embodiment, medical information handling system 102 includes one or more network interfaces 110 that permit medical information handling system 102 to communicate with one or more information, presentation, and/or computing resources via cabling and/or one or more wired or wireless, public or private, local or wide area networks (including the Internet).
The program code stored within local data storage 108 includes system software 112, which can include one or more operating systems and may further include a virtual machine monitor (VMM) or other platform virtualization software. System software 112 provides an execution context for one or more middleware and/or application programs, such as medical application 114 and injection engine 116. Medical application 114 can include or form a part of any medical software system, including but not limited to a medical practice management system, pharmaceutical management system, clinical decision system, medical analytics system, radiology management system, laboratory management system, disease management system, Electronic Medical Record (EMR) system, Electric Health Record (EHR) system, or a Personal Health Record (PHR) system.
In the present application, an EMR refers to a patient's digital medical record roughly corresponding to the paper charts conventionally used by care providers in medical offices, clinics, and hospitals. EMRs contain notes and information collected by and for the care providers in that office, clinic, or hospital and are mostly used by care providers for diagnosis and treatment. EMRs enable care providers to track data over time, identify patients for preventive visits and screenings, monitor patients, and improve health care quality.
EHRs include clinical data collected in providers' offices, but provide a broader view of a patient's care because they contain information from and are accessible to multiple clinicians involved in the patient's care. EHRs can also be used to share information with other health care providers and institutions, such as laboratories, specialists, hospitals, and residential care facilities.
PHRs contain the same types of information as EHRs—diagnoses, medications, immunizations, family medical histories, and provider contact information—but are designed to be setup, accessed, and managed by patients rather than care providers. Patients can use PHRs to maintain and manage their health information in a private, secure, and confidential environment.
End users, such as care providers and/or patients, can interact with medical application 114 through any of a variety of client devices 120, such as terminals, laptop or desktop computer systems, smart phones, tablets, mobile devices, etc. Client devices 120 preferably include a display in which medical application 114 (and optionally a locally executing browser or app) presents a graphical user interface through which a care provider or patient can request and/or receive information relevant to a patient, drug, medical device and/or medical therapy.
Injection engine 116, which preferably executes in the context of medical application 114, injects relevant information in presentations of medical application 114 at various injection points. To inject the relevant information, injection engine 116 may (1) gather data from a first set of data sources, which can be (but are not required to be) local to medical information handling system 102 (2) gather data from a second set of data sources, which can be (but are not required to be) external to or remote from medical information handling system 102, (3) based on the gathered data, determine and format information for presentation via one or more client devices 120, and (4) inject the information into a presentation of medical application 114 on client devices 120. Examples of data sources in the first set of data sources include EMR, EHR and PHR databases 121-123, standards of care database 124, promotions database 126, and/or optionally one or more other databases 128 that a medical practice or institution subscribes to, owns, manages, or rents. Examples of data sources in the second set of data sources include, but are not limited to, databases of standards bodies 130, educational institutions 132, government agencies 134, pharmaceutical companies 136, medical device manufacturers 138, insurance companies 140, patient support and/or advocacy groups 142, remote health sensors 144 (e.g., a patient's cardiac monitor, glucose monitor, sphygmomanometer or activity sensor(s)), social media database(s) 146, and public health database(s) 148.
Communication exchanges between injection engine 116 and data sources in the first and second sets of data sources may use publicly available communication protocols, or alternatively, may use predetermined customized protocols. In various implementations, the communication exchange between injection engine 116 and data sources in the second set of data sources can be free of charge, or alternatively, may require some form of payment from one party to the other. For example, injection engine 116 and/or the entity operating medical information handling system 102 may require payment for injection of advertisements and/or other information from the first and/or the second set of data sources. Alternatively or additionally, the operator of the medical information handling system 102 may be required to make payment to access information from data sources that require paid subscriptions.
Those skilled in the data processing arts will appreciate that the arrangement of software and hardware components depicted in
Referring now to
Management data 202 includes an injector registration data structure 204, such as a table. Injector registration data structure 204 associates injection points in medical application 114 with injectors registered at those injection points, where “injection points” are defined as the locations in the program code of medical application 114 where program code and/or data from the second set of data sources can be integrated into a presentation of medical application 114 and “injectors” are defined as the program code and/or data injected at these injection points.
The information in injector registration data structure 204 can be read by injection logic 200 at runtime to determine what program code and/or data should be injected at any injection point during execution of medical application 114. In some embodiments, management data 202 can also be used to statically or dynamically modify injection point processing, to collect runtime statistics on injection execution, or to perform any other management functions related to injection. Data structures supporting these ancillary management functions are not explicitly depicted in
In the depicted embodiment, injection logic 200 employs a Model-View-Controller design pattern and accordingly includes a model component 210, a view component 212, and a controller component 214. Model component 210, view component 212 and controller component 214 communicate through a channel 216. In at least one embodiment, channel 216 can include one or more software mechanisms for communication, including but not limited to, direct method calls, asynchronous events, message queues, and streams.
Model component 210 manages the data used by or generated by injection engine 116. Within model component 210, an injector undergoing execution is identified with a unique name expressed as its injector ID 220. In addition, the input parameters, intermediate results and temporary data structures used during injector execution form an execution context 222. Any output generated during injector execution is buffered in an adapter output data structure 224.
View component 212 of injection logic 200 manages the final formatting of data returned from local or remote sources by controller component 214. View component 212 receives raw result data and formats the raw result data for rendering on client devices 120. View component 212 also prioritizes information when more than one data source has returned information relevant to a request. To perform its tasks, view component 212 uses data in execution context 222 as well as other data stored in model component 210.
Controller component 214 communicates with data sources in the first and second sets of data sources, as shown, for example, in
Those skilled in the art will appreciate that many alternative approaches can be utilized to implement injectors and their constituent subcomponents. In some implementations, the strict separation of model, view and controller components can be relaxed to simplify coding or to improve performance. In other implementations, the Model-View-Controller design pattern does not have to be used at all: As long as injectors can (1) be associated with injection points, (2) communicate with data sources, and (3) return their results to the medical information handling system 102, any injector design will suffice.
With reference now to
Returning to block 304, in response to an affirmative determination, then injection engine 116 gathers all context parameters required by the injection point and passes those context parameters to model component 210 for storage in execution context 222 (block 320). Controller component 214 then executes each of its adapters to obtain data from a respective data source among the second set of data sources utilizing the associated communication protocol (block 322). Each adapter's output is stored in adapter output database 224 of model components 210. As the adapter(s) complete data retrieval, view component 212 formats the retrieved data to obtain a desired layout 226 (block 324). Depending on the embodiment, the layout 226 determined by view component 212 is returned synchronously or asynchronously to medical application 114 for presentation via client devices 120. As further illustrated at block 328, injection engine 116 may optionally further account for the access to the data by the adapter and/or the presentation of the data via medical application 114 and client devices 120. The accounting may include, for example, incrementing a count of times data has been presented from a particular data source within an accounting time period (e.g., day, week, month, etc), updating a record of a quantity of data accessed from a given data source within an accounting time period, initiating an electronic financial transaction (e.g., wire transfer or ACH payment), etc. From block 326, the process then returns to block 306, which has been described.
Referring now to
As illustrated, exemplary graphical user interface 400 of client device 120 includes a navigation toolbar 402 that can be utilized to navigate within and between records, for example, within and between records in EMR database 121 or EHR database 122. Adjacent navigation toolbar 402 is a record summary 404 providing summary information regarding a currently selected record, such as the patient name, date of birth (DOB), and gender. Graphical user interface 400 additionally includes a textual title 406 (in this case “New Prescription”) indicating the general classification of information to be presented to and/or input by a care provider via graphical user interface 400. In the illustrated example, the creation of a new prescription in the patient's EMR or EHR requires entry of one or more complaints in an input box 408 including one or more checkboxes, as well as selection of a prescribed drug and/or medical device through an input box 410, which in this example includes a series of radio buttons allowing the care provider to select one or more drugs and/or medical devices to be prescribed.
In the illustrated example, graphical user interface 400 further includes one or more messages 412, 414, and/or 416 injected by injection engine 116 in accordance with the process of
Based on the content of the one or more messages 412-416 injected into graphical user interface 400, a care provider may elect to update the patient's record, for example, by creating a new prescription through selection of button 418, or alternatively, may elect to cancel the update to the patient's record, for example, by navigating back to a prior screen utilizing toolbar 402.
Referring now to
Referring now to
Referring now to
With reference now to
In the foregoing description, various embodiments have been described in which messages, including promotional messages, are injected into a medical application. Although these messages have heretofore been described with reference to a particular component of an exemplary medical application (e.g., prescription entry into a patient's EMR or EHR) it should be appreciated that the described engagement with medical care providers can also be applied to any other feature set of medical application, including without limitation patient scheduling, patient portal, care provider notes, etc. Further, the information placed within the messages may vary, and in various embodiments may include special offers (discounts, rebates, coupon cards, etc.), information related to insurance coverage, best practices, quality metrics, social media endorsements, industry-wide or governmental statistics, etc. Further, when the engagement includes promotions or advertisements, the form of advertisement may vary and in various embodiments can include, without limitation, electronically requested samples, digital communication with drug and device representatives, rich media advertisements, traditional banner advertisements, advertisements targeted by patient information (e.g., medical history, demographics, etc.) and/or care provider information (e.g., prior responses to advertisements, demographics, length in practice, prescription patterns, etc.), and/or selective presentation of advertisements based on user permissions or roles (e.g., doctor, nurse practitioner, medical office administrator, clerical staff, insurance claims staff, etc.).
Turning now to
In both messages 1312a and 1312b, a link (“Info”) is provided that enables a care provider to selectively obtain additional information or engage with a representative of a drug or device manufacturer or distributor. For example, if a user of a client device 120 selects the link in message 1312a (or in some embodiments, message 1312a itself) utilizing cursor 1314 or another selection modality, injection engine 116 and medical application 114 cause message 1312a to be expanded to provide user access to additional information and resources regarding the subject of message 1312a. In the example shown in
In response to user selection of button 1408 on the user's client device 120, injection engine 116 and medical application 114 cause an option menu 1500 to be presented in graphical user interface 1300. Option menu 1500 can include options that invite email communication, hard copy communication, instant messaging communication, video chat communication (e.g., Facetime®), or scheduling of an online or live presentation with the representative identified by representative profile information 1406. In at least some embodiments, injection engine 116 injects real-time content retrieved from a data source into the graphical presentation of communication options, such as an online status indication 1502 indicating whether the representative of the featured medication is currently online and thus available for a live textual or video chat. In response to selection of one of the options in option menu 1500, medical application 114 executes functionality to facilitate the desired engagement between the care provider and the representative.
Referring now to
In the depicted example, Visit digest window 1608 provides multiple modalities for entry of the patient's chief complaint. For example, the care provider can enter the chief complaint by searching for the patient's symptom(s) in text search box 1610. Alternatively, the care provider can select the patient's chief complaint from among multiple displayed options, in this case presented utilizing radio buttons. These options include one or more complaints listed as Favorites 1612, which the care provider (or medical application 114) has previously designated as common complaints for this patient, for a group of patients (e.g., an age group) including this patient, or for all patients and are accordingly to be presented as options for selection. The options further include one or more Suggestions 1614 injected by injection engine 116 based on data retrieved from data sources in the first and/or second set of data sources. In the depicted example, these options include option 1616, which injection engine 116 dynamically injects based on data retrieved from EMR database 121 and/or EHR database 122 indicating that “chest congestion” was a prevalent complaint in the care provider's medical practice over the last week. It should be noted that injection engine 116 is configured to explicitly include in option 1616 the reasoning behind the inclusion of option 1616 in Suggestions 1614. In the illustrated example, Suggestions 1614 further include option 1618 (“runny nose”) and option 1620 (“chills”), which injection engine 116 injects based upon data retrieved from one or more data sources in the second group of data sources (e.g., government agencies 134 (possibly including a weather and/or allergy reporting service), public health database 148, and/or educational institutions 132). Again, injection engine 116 advantageously provides an explanatory rationale for the inclusion of these options, for example, to permit the care provider to assess the applicability of these options to the patient's case.
As has been described, in some embodiments
While the present invention has been particularly shown as described with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. For example, although embodiments have been described with respect to various systems and methods, those skilled in the art will appreciate that the described functionality can also be realized as a program product including program code (e.g., program instructions, commands, scripts, etc.) that, when executed by a processor of a data processing system (e.g., a computer, tablet, smartphone, etc.), direct the data processing system to perform the functions described herein. Such program code can further be employed to configure an otherwise general-purpose data processing system to serve as a special-purpose data processing system. In the program product, the program code is stored on a storage device (e.g., volatile and/or non-volatile memory, magnetic and/or optical disk, etc.), and the program product consequently comprises an article of manufacture. As an article of manufacture, the program product and the storage device are specifically defined to exclude transmission media per se and transitory propagating signals per se.
| Number | Date | Country | |
|---|---|---|---|
| 61774303 | Mar 2013 | US |
