1. Statement of the Technical Field
The inventive arrangements relate to data processing systems, and more particularly to systems and methods for providing interoperability between a plurality of different data processing systems (e.g., healthcare systems).
2. Description of the Related Art
There are many conventional data processing systems known in the art. These conventional data processing systems are diverse systems that are often unable to work together, i.e., they are not interoperable. The term “interoperable”, as used herein, refers to syntactic interoperability and semantic interoperability. The phrase “syntactic interoperability” refers to the ability of two or more computing systems to communicate and exchange information. Syntactic interoperability is achieved using specified data formats and communication protocols. In general, eXtensible Markup Language (XML) standards and Structured Query Language (SQL) standards provide syntactic interoperability. Syntactic interoperability is necessary for semantic interoperability. The phrase “semantic interoperability” refers to the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of two or more computing systems.
In the healthcare industry, a plurality of healthcare computing systems have been produced for facilitating the electronic creation and management of health records and medical records by healthcare providers and organizations. These healthcare computing systems include first systems which employ Electronic Health Record (EHR) software applications and/or Electronic Medical Record (EMR) software applications which implement the same standards. The healthcare computing systems also include second systems which employ EHR software applications and/or EMR software applications which implement different standards. The first systems are interoperable, i.e., they are able to (a) exchange information therebetween and (b) use the exchanged information in a meaningful and accurate way so as to produce useful results. In contrast, the second systems are not interoperable, i.e., they may be able to exchange information, but are unable to use the exchanged information in a meaningful way.
The information exchange of the second systems is often achieved using a Portable Document Format (PDF) printer. The PDF printer is a software application that translates a document from a first format to a PDF open standard format. A document in the PDF open standard format is referred to herein as a PDF document. The PDF document may be communicated from a source computing system to a destination computer system over a network using the PDF printer. In this scenario, the PDF document is accessible by a PDF viewer running on the destination computer system. However, the structure of the PDF document is not in a format that is compatible with the EHR software application and/or the EMR software application running on the destination computing system. As such, the source and destination computer systems are not semantically interoperable.
Many conventional interface systems have been created for facilitating interoperability of computing systems employing EHR/EMR software applications which implement different standards. These interface systems are expensive to obtain. Also, each interface system typically provides an interface between a certain number of different EHR software applications and/or EMR software applications. There are hundreds of different types of EHR software applications and EMR software applications. Accordingly, a large number of interface systems are needed to facilitate the interoperability of the hundreds of diverse EHR/EMR software applications. Consequently, the multiple interface solution is impractical, costly and resource intensive.
Embodiments of the present invention concern implementing systems and methods for providing interoperability between a plurality of computing systems employing software applications implementing a plurality of different standards. The present invention can be used in any computer-based application in which there is a print option or capability. This will become more evident as the discussion progresses.
The computing systems can include, but are not limited to, healthcare systems employing Electronic Health Record (EHR) software applications and/or Electronic Medical Record (EMR) software applications. EHR/EMR software applications are well known in the art, and therefore will not be described herein. Such healthcare systems include, but are not limited to, healthcare provider systems, web servers and health care administration systems.
The method embodiments generally involve generating, at a first computing system (e.g., a healthcare provider system), an electronic document having a first data structure. The electronic document can include, but is not limited to, a health related document (e.g., a summary of care document), a MICROSOFT® Word document, a MICROSOFT® Excel document, or a PDF document. After the electronic document is created, the user of the first computing system performs user software interactions to “print” at least a portion of the electronic document or a “current view”. As should be understood, the “current view” is not an electronic document in the traditional sense, but is able to be submitted as an electronic document. The “printing” is generally performed for communicating data contained in the electronic document or “current view” to a second computing system (e.g., a healthcare provider system, a web server or a health care administration system). Notably, the data has a data structure and associated metadata that is compatible with the second computing system. In effect, the second computing system is able to automatically interpret the data in a meaningful and accurate way. Consequently, the first and second computing systems are syntactically and semantically interoperable.
According to aspects of the present invention, the “printing” is achieved using a virtual printer that is accessible via a menu command (e.g., File>Print>Preexisting Printers from which to choose). The phrase “virtual printer”, as used herein, refers to a piece of computer software whose user interface and Application Programming Interface (API) resemble that of a printer driver, but which is not connected with a physical computer printer. The virtual printer can be configured by the user of the first computing system. As such, the virtual printer is generally operative to: receive a first user input selecting the second computing system that is to receive data contained in the electronic document or “current view”; automatically select one or more templates from a plurality of pre-defined templates based on the first user input; receive a second user input selecting one of the templates; automatically complete the template using at least a portion of the data contained in the electronic document or “current view” in response to the second user input; automatically obtain pre-defined metadata specifying at least a meaning of information contained in the template and an intended use of the information; receive user-specified metadata; and facilitate the communication of the pre-defined metadata, user-specified metadata and completed template to the second computing system. It should be understood, that in the “current view” scenario, the template may be a “fill-in-the-blank” document in which an image of the “current view” may be inserted. Since the data is in an image format, it may be desirable to the user to specify more metadata as compared to the amount of metadata specified thereby in the “electronic document” scenario.
Embodiments will be described with reference to the following drawing figures, in which like numerals represent like items throughout the figures, and in which:
The present invention is described with reference to the attached figures. The figures are not drawn to scale and they are provided merely to illustrate the instant invention. Several aspects of the invention are described below with reference to example applications for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One having ordinary skill in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details or with other methods. In other instances, well-known structures or operation are not shown in detail to avoid obscuring the invention. The present invention is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and/or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the present invention.
The word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is if, X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances.
The present invention concerns computing systems employing software applications that implement different standards. More particularly, the present invention provides systems and methods for facilitating the interoperability between said computing systems. The interoperability is generally achieved through context awareness. The term “context”, as used herein refers to, a set of rules of inter-relationship between software applications implementing different standards. Context related to software application behavior can be structured into a plurality of categories, such as a location category and an infrastructure category (resources for computation, communication, task performance, etc . . .). The infrastructure category includes, but is not limited to, the following sub-categories: means of creation of an electronic document; time of creation of the electronic document; date of creation of the electronic document; standards implemented by the means of creation; purpose of electronic document; meaning of information contained in the electronic document; and how the information should be used.
The phrase “context awareness”, as used herein refers to, any information that can be used to characterize the situation of an entity, where an entity can be a computational object. See Dey, A. K. & Abowd, G. D., (1999), Towards a better understanding of context and context-awareness, GUV Technical Report GIT-GVU-99-22, College of Computing, Georgia Institute of Technology. Accordingly, context-awareness or context-aware computing is ‘the use of context to provide task-relevant information and/or services to a user, wherever they may be’. Id. Three (3) important context-awareness behaviors that a software application might exhibit are: (1) the presentation of information and services to a user; (2) the automatic execution of a service; and (3) the tagging of context to information for later retrieval. Id. The present invention advantageously implements these three (3) context-awareness behaviors.
In this regard, it should be understood that method embodiments of the present invention generally involve: generating information having a data structure that complies with standards employed by a software application installed on a destination computing system; deriving a context for the information that is sufficient to facilitate a meaningful use of the information at the destination computing system; communicating the information and context to the destination computing system; and using the information at the destination computing systems in a meaningful way based on the context.
The above described method is achieved using configurable interoperability software installed on a source computing system. The interoperability software can be loaded on the source computing system as a system driver. The system driver can be available to any application with a print capability. The interoperability software facilitates the display of a graphical user interface to a user of the source computing system. The graphical user interface allows the user to: select an interoperability template from a plurality of pre-defined interoperability templates; and initiate an automated process. The interoperability templates allow a user to change the data structure of information that is to be sent to the destination computing system. The automated process involves: completing the selected interoperability template using unstructured information contained in a document created by the user using a software application installed on the source computing system; generating metadata for the completed interoperability template; and communicating the metadata and completed interoperability template to the destination computing system. Notably, the metadata includes information specifying the context. In this regard, the metadata specifies a means of creation of the interoperability template, time of creation thereof, date of creation thereof, standards implemented thereby, purpose thereof, meaning of information contained therein, and how the information should be used. The interoperability template has a data structure which complies with a data structure defined by a standard implemented by a software application installed on the destination computing system.
The present invention will be described below in relation to healthcare systems. However, the present invention is not limited in this regard. For example, the present invention is applicable in any situation where there is a need for facilitating interoperability between two or more systems and software applications implementing different standards.
One such situation occurs when a determination needs to be made by a government agency. For example, a medical disability determination needs to be made in relation to a particular person. This determination is typically made by a Social Security Administration (SSA). In this regard, the SSA needs access to health information for the person. This health information is typically provided to the SSA in paper form (e.g., physical medical records and physical health records) from a plurality of sources (e.g., patients, doctors, hospitals, pharmacies, etc . . .). As a result of the paper-based process, the medical disability determination often takes months to make by the SSA. Consequently, the SSA has a backlog of medical disability matters. Such a backlog is undesirable.
The present invention provides a means for automating the SSA's medical disability determination process. More particularly, the present invention facilitates the ability to generate electronic documents having data structures compatible with software applications installed on SSA's computing system, derive contexts for the electronic documents, and submit the electronic documents to the SSA. The context includes a sufficient amount of information for facilitating a meaningful use of the information at the SSA's computing system(s). As a result of the automated process, the amount of time needed to make a medical disability determination is decreased.
Referring now to
As shown in
Each of the HPSs 112, 124, 130, 136 is generally configured for facilitating the recording and management of electronic health information by healthcare providers (e.g., doctors) and healthcare organizations (e.g., hospitals, medical insurance agencies, government healthcare agencies, etc. . .). In this regard, each of the HPSs 112, 124, 130, 136 has an Electronic Medical Record (EMR) software application 118, 128, 134, 138 installed thereon. EMR software applications are well known in the art, and therefore will not be described herein in detail. Still, it should be noted that any known EMR software application can be used with the present invention without limitation. Such known EMR software applications include, but are not limited to, EMR software applications which are available from: AdvancedMD Software Inc. of Delaware; Allscripts, LLC of Chicago, Ill.; Aprima Medical Software, Inc. of Carrollton, Tex.; and/or Integritas, Inc. of Monterey, Calif.
The EMR software applications 118, 128, 134, 138 generally facilitate the creation of computerized medical records by healthcare providers (e.g., doctors, nurses and administrators of healthcare facilities). The EMR software applications 118, 128, 134, 138 also allow for the storage, retrieval and manipulation of the computerized medical records. The EMR software applications 118, 128, 134, 138 are further operative to monitor clinical events, by analyzing patient data from an electronic health record to predict, detect and potentially prevent adverse events. The electronic health records will be described below.
Each of the HPSs 112, 124, 130 also has an Electronic Health Record (EHR) software application installed thereon. EHR software applications are well known in the art, and therefore will not be described herein in detail. Still, it should be noted that any known EHR software application can be used with the present invention without limitation. Such known EHR software applications include, but are not limited to, EHR software applications which are available from: AdvancedMD Software Inc. of Delaware; Allscripts, LLC of Chicago, Ill.; Aprima Medical Software, Inc. of Carrollton, Tex.; and Integritas, Inc. of Monterey, Calif.
The EHR software applications facilitate the creation of electronic heath records and the sharing of the electronic heath records across the health internet 102. The electronic health records can include, but are not limited to, discharge orders, transfer orders, pharmacy orders, radiology results, laboratory results, provider notes and any other records from ancillary services. Accordingly, the data contained in the electronic health records includes demographics, medical history, medication and allergies, immunization status, laboratory test results, radiology images and/or billing information.
As shown in
Notably, there are numerous types of EHR/EMR software applications. The HPSs 112, 124, 130, 136 and web server 182 may employ the same or different types of EHR/EMR software applications. For example, the HPS 112 employs EHR/EMR software 116, 118 of a first type (e.g., EHR/EMR software implementing an HL7 standard). The HPS 124 employs EHR/EMR software 126, 128 of a second type (e.g., EHR/EMR software implementing a standard other than an HL7 standard). The HPS 130 employs EHR/EMR software 132, 134 of a third type (e.g., EHR/EMR software which implements a first proprietary standard that does not comply with any other non-proprietary healthcare standard). The HPS 136 and web server 182 collectively employ EHR/EMR software 184, 138 of a fourth type (e.g., EHR/EMR software which implements a second proprietary standard that does not comply with any other proprietary healthcare standard). In this scenario, the different types of EHR/EMR software are not interoperable, i.e., they can not automatically interpret information generated and output from one another in a meaningful manner so as to produce useful results as defined by users thereof.
In order to facilitate the interoperability of EHR/EMR software applications that implement different standards, each of the HPSs 112, 124, 130, 136 is provided with Interoperability Software (IS) 117. The IS 117 implements method embodiments of the present invention. The method embodiments will be described in detail below in relation to
Referring now to
The HPS 112 may include more or less components than those shown in
As shown in
The processor 202 perform actions involving access to and use of memory 210, which may be a Random Access Memory (RAM) and/or a Read Only Memory (ROM). The processor 202 may include, but is not limited to, microprocessors, ASICs and other hardware. The processor 202 is programmed for facilitating the interoperability of different EHR/EMR software applications. In this regard, it should be understood that the processor 202 can access data files 260 stored in memory 210. The data files 260 include, but are not limited to, electronic health records, electronic medical records, document templates and interoperability templates. The templates will be described below. The processor 202 can also access and run device drivers 258, an operating system 256 and various software applications installed on the HPS 112. The software applications can include, but are not limited to, the EMR software application 118, the EHR software application 116, a web browser application (not shown), graphical user interface software programs (not shown), the IS 117 and/or other software applications 254.
The EHR/EMR software applications 116, 118 are operative to enable: the opening of an application window; the selection of a document template with a menu command (e.g., File>New>Preexisting Document Templates from which to choose); the completion of the selected document template; the storage of the completed document template; and the editing of the stored document template. The document templates can include, but are not limited to, consultation templates, summary of care (C32) document templates, emergency of care (C28) document templates, prescription templates, hospital discharge template, a referral template, a referral results template, a population health alert template and bill templates. Each of the document templates is a “fill-in-the-blank” document that is completed through an user-software interactive process. The user-software interactive process involves receiving user inputs for inputting data into entries of the document templates. The EHR/EMR software applications 116, 118 are also operative to enable the printing of document templates. In this regard, the EHR/EMR software applications 116, 118 include a menu that enables the selection of a physical computer printer and/or a virtual printer with a menu command (e.g., File>Print>Preexisting Printers from which to choose). The phrase “virtual printer”, as used herein, refers to a piece of computer software whose user interface and Application Programming Interface (API) resemble that of a printer driver, but which is not connected with a physical computer printer. Printer drivers are well known in the art, and therefore will not be described herein.
The IS 117 is operative to facilitate the interoperability of two or more different types of EHS/EMS software applications (i.e., software applications that implement different standards). In this regard, the IS 117 is operative to enable: the selection of a “document submission” printer with a menu command that is accessible via an application window (e.g., File>Print>Document Submission); and the customization of operations of the “document submission” printer via a Graphical User Interface (GUI). The GUI is accessible via a command (e.g., File>Print>Document Submission>Properties). The properties include, but are not limited to, destination properties, template properties, metadata properties and link properties. The destination properties include, but are not limited to, destination name, destination location and destination address. The template properties include, but are not limited to, interoperability templates and information contained in the interoperability templates. The metadata properties include, but are not limited to, pre-defined metadata for interoperability templates and user-defined metadata for interoperability templates. The link properties include, but are not limited to, link availability and link quality.
The interoperability templates include pre-defined templates that are compatible with a plurality of different EHR/EMR software applications. In this regard, data is structured within the interoperability templates in accordance with the data abstraction model employed by a destination computing system. Data abstraction models are well known in the art, and therefore will not be described herein. However, it should be understood that data abstraction models generally define data structures and rules for allowing the handling of data bits in a meaningful way.
According to embodiments of the present invention, each of the interoperability templates is a “fill-in-the-blank” document that is completed through an automated process. The automated process generally involves automatically retrieving information from a document (e.g., a summary of care document) that was completed or edited by a user of the HPS 112, and automatically inserting the information in the proper entries of a user-selected interoperability template. The automated process also involves automatically generating metadata for the completed interoperability template. In some embodiments, the metadata includes only pre-defined metadata. In other embodiments, the metadata includes pre-defined metadata and user-defined metadata. In either scenario, the metadata includes a sufficient amount of information for facilitating the meaningful use of information contained in an exchanged interoperability template at a destination computing system (e.g., the HPSs 124, 130, 136, the HCA system 160 and/or the web server 182 of
In general, the pre-defined metadata includes, but is not limited to, information specifying the means of creation of a completed interoperability template; time of creation of the completed interoperability template; date of creation of the completed interoperability template; standards implemented by the means of creation; purpose of the completed interoperability template; meaning of information contained in the completed interoperability template; and how the information should be used. The user-defined metadata includes, but is not limited to, additional information that a user of the HPSs 112 wants to provide to an intended recipient. The additional information can include, but is not limited to, information that is not contained in the corresponding interoperability template. Such additional information includes, but is not limited to, demographics, billing information, information relating to physical and biological characteristics of a patient (e.g., a drug allergy, a medical condition, a blood type, an age), information relating to a relative, and information relating to a fetus (e.g., blood type).
After the completion of the interoperability template and the generation of the metadata, the IS 117 performs actions for communicating the same to one or more external devices (e.g., the HPSs 124, 130, 136, the HCA system 160 and/or the web server 182 of
An exemplary architecture of the IS 117 is provided in
Referring again to
As evident from the above discussion, the healthcare system 100 implements one or more method embodiments of the present invention. The method embodiments of the present invention can be used in systems employing a plurality of diverse software applications. Exemplary method embodiments of the present invention will now be described in relation to
Referring now to
In a next step 408, the source computing system receives user inputs for creating or editing an electronic document. Processes for creating and editing electronic documents are well known in the art. However, an exemplary process for creating a document will be described in relation to
Referring again to
After step 414, the method continues with steps 416-420. Steps 416-420 will be described in relation to
In a next step 418, the source computing system receives a user input selecting an identifier 804 for a “Document Submission” printer from a list of printers 806 of the “Print” GUI 802. After selecting identifier 804, the user clicks on a properties virtual button 902 for accessing a GUI which allows the user to customize properties of the “Document Submission” printer. As should be understood, the clicking on a virtual button is typically achieved using an electronic device (e.g., a mouse of a computer).
In response to the selection of the “properties” virtual button 902, a “Document Submission” GUI is displayed to the user. A schematic illustration of an exemplary “Document Submission” GUI 1002 is provided in
After the “Document Submission” GUI is displayed to the user, the source computing system receives user inputs specifying a name and/or a location of a desired recipient, as shown by step 424. These user inputs can be achieved by inputting text information in text entry boxes (e.g., text entry boxes 1012, 1014 of
In response to the user-software interaction of step 426, the method continues with step 428 of
Upon completing step 428, the method 400 continues with step 430. In step 430, the address identifiers are displayed to the user. A schematic illustration of exemplary address identifiers 1102 being displayed in the “Destination” GUI tab 1004 of the “Document Submission” GUI 1002 is provided in
Referring again to
After a user has selected an address identifier, a decision is made in step 434 as to whether a communications link between the source computing system (e.g., HPS 112 of
If a communications link is not available [434:N0], then step 436 is performed where information is displayed to the user indicating that the communication link to the desired destination is not available. This information can be displayed to the user via the “Links” GUI tab 1010 of the “Document Submission” GUI 1002. A schematic illustration of an exemplary “Links” GUI tab 1010 is provided in
If a communications link is available [434:YES], then step 438 is performed where information is displayed to the user indicating that the communication link to the desired destination is available. This information can be displayed to the user via the “Links” GUI tab 1010 of the “Document Submission” GUI 1002 as shown in
In step 440, the source computing system selects one or more interoperability templates from a plurality of pre-defined interoperability templates based on the address identifier selected by the user in previous step 432. The selection can be achieved by: requesting information from the service registry about the destination computing system associated with the address identifier selected by the user; receiving said information from the service registry; and using the information to select interoperability templates that are compatible with one or more software applications installed on the destination computing system. The information can include information indicating the type of software applications that are installed on the destination computing system. For example, the information indicates that the destination computing system (e.g., HPS 124 of
After selecting one or more pre-defined interoperability templates, identifiers for the selected interoperability templates are displayed to the user of the source computing system, as shown by step 442. The identifiers can be displayed to the user via the “Template” GUI tab of the “Document Submission” GUI. A schematic illustration of exemplary identifiers 1302 displayed in the Template” GUI tab 1006 of the “Document Submission” GUI 1002 is provided in
In a next step 444, the source computing system receives a user input selecting an identifier from the displayed identifiers. The identifier can be selected by moving a cursor of a mouse over the identifier and depressing a button on the mouse. As shown in
In response to the user-software interaction of step 444, the method 400 continues with steps 446 and 448. In step 446, a first list of information is obtained by the source computing system. The first list of information can be obtained from a memory (e.g., memory 210 of
In step 448, a second list of information is obtained by the source computing system. The second list of information can be obtained from a memory (e.g., memory 210 of
Upon completing step 448, step 450 is performed. In step 450, the first and second lists are displayed to the user. The lists can be displayed to the user via the “Metadata” GUI tab of the “Document Submission” GUI. A schematic illustration of exemplary first and second lists 1402, 1404 displayed in the “Metadata” GUI tab 1008 of the “Document Submission” GUI 1002 is provided in
Referring again to
As shown in
In a next step 456, the completed interoperability template and associated metadata are communicated to the destination computing system (e.g., HPS 124 of
At the destination computing system, steps 458-462 are performed. Step 458 involves executing a software application at the destination computing system. The software application can include, but is not limited to, an EHR software application (e.g., an application 116, 126, 132, 184 of
Subsequent to step 460, step 462 is performed where the software application automatically interprets the information of the interoperability template. The information is interpreted meaningfully and accurately in order to produce useful results. Thereafter, step 464 is performed where the method 400 ends or other processing is performed.
All of the apparatus, methods and algorithms disclosed and claimed herein can be made and executed without undue experimentation in light of the present disclosure. While the invention has been described in terms of preferred embodiments, it will be apparent to those of skill in the art that variations may be applied to the apparatus, methods and sequence of steps of the method without departing from the concept, spirit and scope of the invention. More specifically, it will be apparent that certain components may be added to, combined with, or substituted for the components described herein while the same or similar results would be achieved. All such similar substitutes and modifications apparent to those skilled in the art are deemed to be within the spirit, scope and concept of the invention as defined.