REGISTER  |  SIGN IN
United States Patent Application20030074248
Kind CodeA1
Braud, Kristopher P. ; et al.April 17, 2003
Method and system for assimilating data from disparate, ancillary systems onto an enterprise system
Abstract
The present invention provides a means for an enterprise, such as a health care facility, to receive messages from any one of a plurality of disparate, ancillary vendor applications, convert the vendor information to an enterprise usable form and then store the enterprise information on an enterprise database. The enterprise keeps vendor specific rules for converting each vendor's information to enterprise information. Additionally, relational enterprise rules are applied to the enterprise data stored in a enterprise database, so as disparate vendor information is converted to enterprise data, the relationships between that converted enterprise data are checked with the enterprise data stored in the enterprise database. Enterprise data can also be directly entered into the enterprise database from enterprise system clients, the relationships between that enterprise data are also checked with the enterprise data stored in the enterprise database.
Inventors:Braud; Kristopher P. (Baton Rouge, LA), Hastings; David  (Baton Rouge, LA), Ragan; Danny J.  (Denham Springs, LA)
Correspondence Name and Address:Jones, Day, Reavis & Pogue 2727 North Harwood Street P.O. Box 660623
Rudolph J. Buchel, Jr.
Dallas
TX
75266-0623
US
Series Code:822013
Filed:March 31, 2001
U.S. Current Class:705/9
U.S. Class at Publication:705/9
Intern'l Class:G06F 017/60
Claims

What is claimed is:
1. A data processing system implemented method for accomplishing an enterprise event based on a unified collection of information realized from a plurality of disparate, ancillary systems comprising: catching a message, wherein the message was generated by a disparate, ancillary system using a set of content rules and the message conforms to a message standard; opening the message; identifying the disparate, ancillary system based on the message; accessing content conversion rules based on the identity of the disparate, ancillary system; converting content from the message to enterprise information using the content conversion rules; retrieving enterprise relationship rules based on the enterprise information; checking the enterprise information for a relationship with enterprise data based on the relationship rules; and scheduling an enterprise event based on a relationship between the enterprise information converted from the message and the-enterprise data stored on the enterprise database.

2. The method recited above in claim 1 further comprising: storing the enterprise information in the enterprise database.

3. The method recited above in claim 1, wherein the enterprise is a health care facility.

4. The method recited above in claim 1 further comprising: receiving an enterprise request for access to data in the enterprise database; identifying the portion of enterprise data from information from the enterprise request; identifying the requestor from the enterprise request; retrieving enterprise relationship rules based on the identity of the requester; identifying at least one user with a privilege to the identified portion of enterprise data; and granting the requester access to the identified portion of enterprise data based on the requester being identified as a user with the privilege to the identified portion of enterprise data.

5. The method recited above in claim 4, prior to granting the requester access to the identified portion of enterprise data the method further comprising: comparing the identity of at least one user with a privilege to the identified portion with the identity of the requestor; and returning a warning response to the requestor based on the outcome of the comparison.

6. The method recited above in claim 2 further comprising: detecting an error in a portion of enterprise data maintained on the enterprise database; identifying a source disparate, ancillary system, wherein the source disparate, ancillary system is a source for the portion of enterprise data; locating the portion of enterprise data in the source disparate, ancillary system; and accessing the source disparate, ancillary system for the portion of enterprise data.

7. The method recited above in claim 6 further comprising: overwriting the portion of enterprise data maintained on the enterprise database with the portion of enterprise data from the source disparate, ancillary system.

8. The method recited above in claim 1, wherein the enterprise event is an enterprise service, scheduling the enterprise event further comprises: identifying a recipient for the enterprise service from the enterprise information.

9. The method recited above in claim 8, wherein scheduling the enterprise event further comprises: identifying an enterprise department responsible for administering the performance of enterprise services to the recipient based on the identity of the recipient for the enterprise service and the enterprise data.

10. The method recited above in claim 8, wherein scheduling the enterprise event further comprises: identifying an enterprise service person responsible for performance the enterprise service based on the identity of the recipient the enterprise service and the enterprise data.

11. The method recited above in claim 8, wherein scheduling the enterprise event further comprises: identifying an enterprise service person responsible for performance the enterprise service and an enterprise department responsible for administering the performance of enterprise services to the recipient based on the identity of the recipient the enterprise service and the enterprise data.

12. The method recited above in claim 9, wherein scheduling the enterprise event further comprises: establishing a scheduling time for performance of the enterprise service; and notifying the enterprise department responsible for administering the performance of enterprise services to the recipient of the scheduling time.

13. The method recited above in claim 10, wherein scheduling the enterprise event further comprises: establishing a scheduling time for performance of the enterprise service; and notifying the service person responsible for performance the enterprise service of the scheduling time.

14. The method recited above in claim 11, wherein scheduling the enterprise event further comprises: establishing a scheduling time for performance of the enterprise service; and notifying the enterprise service person responsible for performance the enterprise service and the enterprise department responsible for administering the performance of enterprise services to the recipient of the scheduling time.

15. The method recited above in claim 14, wherein notifying further comprises: updating an enterprise web page with the scheduling time for performance of the enterprise service.

16. The method recited above in claim 15, wherein notifying further comprises: accessing notification information for enterprise service person from the enterprise data; selecting a transmission medium based on notification criteria in the notification information; and trnasmitting a message using the transmission medium based on the notification information.

17. The method recited above in claim 16, wherein the transmission medium is a telephone, the notification information includes a telephone number, and the message is an oral notification.

18. The method recited above in claim 16, wherein the transmission medium is a pager, the notification information includes a pager telephone number, and the message is a text notification.

19. The method recited above in claim 15, wherein scheduling the enterprise event further comprises: receiving an acknowledgment from the enterprise service person that the scheduling time for performance of the enterprise service has been received by the enterprise service person.

20. The method recited above in claim 19, wherein scheduling the enterprise event further comprises: notifying the enterprise department responsible for administering the performance of enterprise services to the recipient that the enterprise service person responsible for administering acknowledges the scheduling time for performance of the enterprise service.

21. The method recited above in claim 1, wherein the enterprise event is an enterprise function, scheduling the enterprise event further comprises: identifying an enterprise user responsible for executing the enterprise function from the enterprise information.

22. The method recited above in claim 21, wherein scheduling the enterprise event further comprises: retrieving enterprise relationship rules based on the identity of the enterprise user; identifying at least one user with a privilege to the enterprise function; and granting the enterprise user access to the enterprise function based on the enterprise user being identified as a user with the privilege to the enterprise function.

23. The method recited above in claim 22 wherein scheduling the enterprise event further comprises: updating an enterprise web page with at least a portion of the enterprise information a tool to perform the enterprise function.

24. The method recited above in claim 23 wherein the at least a portion of the enterprise information is a document and the tool to perform the enterprise function is an electronic signature tool.

25. The method recited above in claim 24 wherein the tool to perform the enterprise function further includes a document editing feature.

26. The method recited above in claim 25 wherein the editing feature of the tool to perform the enterprise function requires a separate privilege.

27. The method recited above in claim 22 wherein the enterprise user is one of a physician, an intern and a resident and the enterprise is a health care facility.

28. The method recited above in claim 24 wherein scheduling the enterprise event further comprises: receiving an acknowledgment from the enterprise user that document has been electronically signed by the enterprise user.

29. The method recited above in claim 25 wherein scheduling the enterprise event further comprises: receiving an acknowledgment from the enterprise user that document has been electronically edited and electronically signed by the enterprise user.

30. The method recited above in claim 24 wherein scheduling the enterprise event further comprises: faxing a copy of the signed document to a destination based on the enterprise data.

31. A data processing system for accomplishing an enterprise event based on a unified collection of information realized from a plurality of disparate, ancillary systems comprising: means for catching a message, wherein the message was generated by a disparate, ancillary system using a set of content rules and the message conforms to a message standard; means for opening the message; means for identifying the disparate, ancillary system based on the message; accessing content conversion rules based on the identity of the disparate, ancillary system; means for converting content from the message to enterprise information using the content conversion rules; means for retrieving enterprise relationship rules based on the enterprise information; means for checking the enterprise information for a relationship with enterprise data based on the relationship rules; and means for scheduling an enterprise event based on a relationship between the enterprise information converted from the message and the enterprise data stored on the enterprise database.

32. The system recited above in claim 31 further comprising: means for storing the enterprise information in the enterprise database.

33. The system recited above in claim 31, wherein the enterprise is a health care facility.

34. The system recited above in claim 31 further comprising: means for receiving an enterprise request for access to data in the enterprise database; means for identifying the portion of enterprise data from information from the enterprise request; means for identifying the requestor from the enterprise request; means for retrieving enterprise relationship rules based on the identity of the requester; means for identifying at least one user with a privilege to the identified portion of enterprise data; and means for granting the requestor access to the identified portion of enterprise data based on the requester being identified as a user with the privilege to the identified portion of enterprise data.

35. The system recited above in claim 34 further comprising: means for comparing the identity of at least one user with a privilege to the identified portion with the identity of the requestor; and means for returning a warning response to the requestor based on the outcome of the comparison.

36. The system recited above in claim 32 further comprising: means for detecting an error in a portion of enterprise data maintained on the enterprise database; means for identifying a source disparate, ancillary system, wherein the source disparate, ancillary system is a source for the portion of enterprise data; means for locating the portion of enterprise data in the source disparate, ancillary system; and means for accessing the source disparate, ancillary system for the portion of enterprise data.

37. The system recited above in claim 36 further comprising: means for overwriting the portion of enterprise data maintained on the enterprise database with the portion of enterprise data from the source disparate, ancillary system.

38. The system recited above in claim 31, wherein the enterprise event is an enterprise service, the means for scheduling the enterprise event further comprises: means for identifying a recipient for the enterprise service from the enterprise information.

39. The system recited above in claim 38, wherein the means for scheduling the enterprise event further comprises: means for identifying an enterprise department responsible for administering the performance of enterprise services to the recipient based on the identity of the recipient for the enterprise service and the enterprise data.

40. The system recited above in claim 38, wherein the means for scheduling the enterprise event further comprises: means for identifying an enterprise service person responsible for performance the enterprise service based on the identity of the recipient the enterprise service and the enterprise data.

41. The system recited above in claim 38, wherein the means for scheduling the enterprise event further comprises: means for identifying an enterprise service person responsible for performance the enterprise service based on the identity of the recipient the enterprise service and the enterprise data; and means for identifying an enterprise department responsible for administering the performance of enterprise services to the recipient based on the identity of the recipient the enterprise service and the enterprise data.

42. The system recited above in claim 39, wherein the means for scheduling the enterprise event further comprises: means for establishing a scheduling time for performance of the enterprise service; and means for notifying the enterprise department responsible for administering the performance of enterprise services to the recipient of the scheduling time.

43. The system recited above in claim 40, wherein the means for scheduling the enterprise event further comprises: means for establishing a scheduling time for performance of the enterprise service; and means for notifying the service person responsible for performance the enterprise service of the scheduling time.

44. The system recited above in claim 41, wherein the means for scheduling the enterprise event further comprises: means for establishing a scheduling time for performance of the enterprise service; and means for notifying the enterprise service person responsible for performance the enterprise service and the enterprise department responsible for administering the performance of enterprise services to the recipient of the scheduling time.

45. The system recited above in claim 44, wherein the means for notifying further comprises: means for updating an enterprise web page with the scheduling time for performance of the enterprise service.

46. The system recited above in claim 45, wherein the means for notifying further comprises: means for accessing notification information for enterprise service person from the enterprise data; means for selecting a transmission medium based on notification criteria in the notification information; and means for trnasmitting a message using the transmission medium based on the notification information.

47. The system recited above in claim 46, wherein the transmission medium is a telephone, the notification information includes a telephone number, and the message is an oral notification.

48. The system recited above in claim 46, wherein the transmission medium is a pager, the notification information includes a pager telephone number, and the message is a text notification.

49. The system recited above in claim 45, wherein the means for scheduling the enterprise event further comprises: means for receiving an acknowledgment from the enterprise service person that the scheduling time for performance of the enterprise service has been received by the enterprise service person.

50. The system recited above in claim 49, wherein the means for scheduling the enterprise event further comprises: means for notifying the enterprise department responsible for administering the performance of enterprise services to the recipient that the enterprise service person responsible for administering acknowledges the scheduling time for performance of the enterprise service.

51. The system recited above in claim 31, wherein the enterprise event is an enterprise function, the means for scheduling the enterprise event further comprises: means for identifying an enterprise user responsible for executing the enterprise function from the enterprise information.

52. The system recited above in claim 41, wherein the means for scheduling the enterprise event further comprises: means for retrieving enterprise relationship rules based on the identity of the enterprise user; means for identifying at least one user with a privilege to the enterprise function; and means for granting the enterprise user access to the enterprise function based on the enterprise user being identified as a user with the privilege to the enterprise function.

53. The system recited above in claim 52 wherein the means for scheduling the enterprise event further comprises: means for updating an enterprise web page with at least a portion of the enterprise information a tool to perform the enterprise function.

54. The system recited above in claim 53 wherein the at least a portion of the enterprise information is a document and the tool to perform the enterprise function is an electronic signature tool.

55. The system recited above in claim 54 wherein the tool to perform the enterprise function further includes a document editing feature.

56. The system recited above in claim 55 wherein the editing feature of the tool to perform the enterprise function requires a separate privilege.

57. The system recited above in claim 52 wherein the enterprise user is one of a physician, an intern and a resident and the enterprise is a health care facility.

58. The system recited above in claim 54 wherein the means for scheduling the enterprise event further comprises: means for receiving an acknowledgment from the enterprise user that document has been electronically signed by the enterprise user.

59. The system recited above in claim 55 wherein the means for scheduling the enterprise event further comprises: means for receiving an acknowledgment from the enterprise user that document has been electronically edited and electronically signed by the enterprise user.

60. The system recited above in claim 54 wherein the means for scheduling the enterprise event further comprises: means for faxing a copy of the signed document to a destination based on the enterprise data.

61. A computer readable storage medium storing program instructions for execution on a data processing system which when executed cause the data processing system to perform a method for accomplishing an enterprise event based on a unified collection of information realized from a plurality of disparate, ancillary systems, the method comprising: catching a message, wherein the message was generated by a disparate, ancillary system using a set of content rules and the message conforms to a message standard; opening the message; identifying the disparate, ancillary system based on the message; accessing content conversion rules based on the identity of the disparate, ancillary system; converting content from the message to enterprise information using the content conversion rules; retrieving enterprise relationship rules based on the enterprise information; checking the enterprise information for a relationship with enterprise data based on the relationship rules; and scheduling an enterprise event based on a relationship between the enterprise information converted from the message and the enterprise data stored on the enterprise database.

62. The system recited above in claim 61 further comprising: storing the enterprise information in the enterprise database.

63. The system recited above in claim 61, wherein the enterprise is a health care facility.

64. The system recited above in claim 61 further comprising: receiving an enterprise request for access to data in the enterprise database; identifying the portion of enterprise data from information from the enterprise request; identifying the requester from the enterprise request; retrieving enterprise relationship rules based on the identity of the requester; identifying at least one user with a privilege to the identified portion of enterprise data; and granting the requester access to the identified portion of enterprise data based on the requester being identified as a user with the privilege to the identified portion of enterprise data.

65. The system recited above in claim 64 further comprising: comparing the identity of at least one user with a privilege to the identified portion with the identity of the requester; and returning a warning response to the requester based on the outcome of the comparison.

66. The system recited above in claim 62 further comprising: detecting an error in a portion of enterprise data maintained on the enterprise database; identifying a source disparate, ancillary system, wherein the source disparate, ancillary system is a source for the portion of enterprise data; locating the portion of enterprise data in the source disparate, ancillary system; and accessing the source disparate, ancillary system for the portion of enterprise data.

67. The system recited above in claim 66 further comprising: overwriting the portion of enterprise data maintained on the enterprise database with the portion of enterprise data from the source disparate, ancillary system.

68. The system recited above in claim 61, wherein the enterprise event is an enterprise service, scheduling the enterprise event further comprises: identifying a recipient for the enterprise service from the enterprise information.

69. The system recited above in claim 68, wherein scheduling the enterprise event further comprises: identifying an enterprise department responsible for administering the performance of enterprise services to the recipient based on the identity of the recipient for the enterprise service and the enterprise data.

70. The system recited above in claim 68, wherein scheduling the enterprise event further comprises: identifying an enterprise service person responsible for performance the enterprise service based on the identity of the recipient the enterprise service and the enterprise data.

71. The system recited above in claim 68, wherein for scheduling the enterprise event further comprises: identifying an enterprise service person responsible for performance the enterprise service based on the identity of the recipient the enterprise service and the enterprise data; and identifying an enterprise department responsible for administering the performance of enterprise services to the recipient based on the identity of the recipient the enterprise service and the enterprise data.

72. The system recited above in claim 69, wherein scheduling the enterprise event further comprises: establishing a scheduling time for performance of the enterprise service; and notifying the enterprise department responsible for administering the performance of enterprise services to the recipient of the scheduling time.

73. The system recited above in claim 70, wherein scheduling the enterprise event further comprises: establishing a scheduling time for performance of the enterprise service; and notifying the service person responsible for performance the enterprise service of the scheduling time.

74. The system recited above in claim 71, wherein scheduling the enterprise event further comprises: establishing a scheduling time for performance of the enterprise service; and notifying the enterprise service person responsible for performance the enterprise service and the enterprise department responsible for administering the performance of enterprise services to the recipient of the scheduling time.

75. The system recited above in claim 74, wherein notifying further comprises: updating an enterprise web page with the scheduling time for performance of the enterprise service.

76. The system recited above in claim 75, wherein notifying further comprises: accessing notification information for enterprise service person from the enterprise data; selecting a transmission medium based on notification criteria in the notification information; and transmitting a message using the transmission medium based on the notification information.

77. The system recited above in claim 76, wherein the transmission medium is a telephone, the notification information includes a telephone number, and the message is an oral notification.

78. The system recited above in claim 76, wherein the transmission medium is a pager, the notification information includes a pager telephone number, and the message is a text notification.

79. The system recited above in claim 75, wherein scheduling the enterprise event further comprises: receiving an acknowledgment from the enterprise service person that the scheduling time for performance of the enterprise service has been received by the enterprise service person.

80. The system recited above in claim 79, wherein scheduling the enterprise event further comprises: notifying the enterprise department responsible for administering the performance of enterprise services to the recipient that the enterprise service person responsible for administering acknowledges the scheduling time for performance of the enterprise service.

81. The system recited above in claim 61, wherein the enterprise event is an enterprise function, scheduling the enterprise event further comprises: identifying an enterprise user responsible for executing the enterprise function from the enterprise information.

82. The system recited above in claim 81, wherein scheduling the enterprise event further comprises: retrieving enterprise relationship rules based on the identity of the enterprise user; identifying at least one user with a privilege to the enterprise function; and granting the enterprise user access to the enterprise function based on the enterprise user being identified as a user with the privilege to the enterprise function.

83. The system recited above in claim 82 wherein scheduling the enterprise event further comprises: updating an enterprise web page with at least a portion of the enterprise information a tool to perform the enterprise function.

84. The system recited above in claim 83 wherein the at least a portion of the enterprise information is a document and the tool to perform the enterprise function is an electronic signature tool.

85. The system recited above in claim 84 wherein the tool to perform the enterprise function further includes a document editing feature.

86. The system recited above in claim 85 wherein the editing feature of the tool to perform the enterprise function requires a separate privilege.

87. The system recited above in claim 82 wherein the enterprise user is one of a physician, an intern and a resident and the enterprise is a health care facility.

88. The system recited above in claim 84 wherein scheduling the enterprise event further comprises: receiving an acknowledgment from the enterprise user that document has been electronically signed by the enterprise user.

89. The system recited above in claim 85 wherein scheduling the enterprise event further comprises: receiving an acknowledgment from the enterprise user that document has been electronically edited and electronically signed by the enterprise user.

90. The system recited above in claim 84 wherein scheduling the enterprise event further comprises: faxing a copy of the signed document to a destination based on the enterprise data.

91. A health care information service layer comprising: a message conversion rules memory for storing vendor specific rules for converting vendor specific message format to health care level format; an automated interface gateway (AIG) catcher, said AIG catcher comprising a logical port for receiving vendor specific messages, a logical communications port for communicating, a logical memory connection for operationally connecting to the message conversion rules memory and executable logic for opening a vendor specific message generated by a vendor specific application running on a remote system, extracting information contained in a vendor specific message, identifying a remote system based on information in a vendor specific message, communicating with said message conversion rules memory via said logical memory connection and for retrieving vendor specific rules based on an identity of a remote system, converting information contained in a vendor specific message from vendor specific message format using vendor specific rules, and communicating converted health care level information via said logical communications port; an health care level memory for storing health care level relationship rules and for storing health care level information; an health care level server, said health care level server comprising a logical port for receiving health care system level messages, a logical memory connection for operationally connecting to the health care level memory and executable logic for opening a health care level message, extracting health care level information contained in a health care level message, communicating with said health care level memory via said logical memory connection and for retrieving health care level relationship rules, checking health care level information for a relationship with other health care level data based on the health care level relationship rules, scheduling health care level event based on a relationship between health care level information from a health care level message and health care level information from said health care level memory and communicating health care level messages via said logical communications port; and a web server operationally connected to said enterprise server, said web server containing executable logic for receiving health care level messages, converting health care level messages to information packets of a mark up language and communicating information packets to a remote web client.

92. The health care information service layer recited above in claim 91
wherein said health care level memory further comprises: a health care level privilege database containing privilege rules for accessing health care level information.

93. The health care information service layer recited above in claim 91
wherein said health care level memory further comprises: a vendor database access database containing rules for accessing a remote system's vendor database.

94. The health care information service layer recited above in claim 91
wherein said health care level memory further comprises: a health care level function containing an electronic signature tool.

95. The health care information service layer recited above in claim 91
wherein said health care level memory further comprises: a health care level function containing an automatic faxing tool.

96. The health care information service layer recited above in claim 91
wherein said health care level memory further comprises: a health care level function containing an notification tool for notifying health care level users of the occurrence of a health care level event.
Description


BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates generally to information services systems and more particularly to assimilating and accessing data stored in disparate, ancillary systems. Still more particularly, the recent invention relates to the distribution and administration of medical services by presenting and/or accessing information at an enterprise level, which has been entered and stored in an ancillary system level. Still further, the present invention relates to intercepting communications between disparate systems wherein the communication is performed at an applications level.

[0003] 2. Description of Related Art

[0004] A commercial enterprise, or enterprise, may be defined as a unit of economic organization or activity, especially a business organization for undertaking a project, especially a difficult, complicated or risky project. An enterprise may evolve in response to a need, which has been unfulfilled. Thus, the underlying goal of any enterprise is to successfully complete a common project or task. However, many commercial enterprises are compilations of enterprise departments that evolve to fulfill sub-tasks of the enterprise's primary task. These enterprise departments may originate autonomously from the enterprise to provide a solution for a task or instead, a department may be created internally by the enterprise for more effectively focusing on a particular sub-task. Independent enterprise departments may be acquired by an enterprise to supplement the enterprise's innate capacity. When properly integrated, the roles of individual enterprise departments are largely unrelated and dissimilar to other enterprise departments. The individual enterprise departments are supported by functional disparate systems.

[0005] One of ordinary skill in the art will understand that each of these enterprise departments may evolve its own particular infrastructure and culture. Individual enterprise departments most probably establish their own Information Systems Service (ISS) infrastructures based solely on their own information processing needs and budget constraints and without regard to the ISS needs of other enterprise departments. A department institutes its own information priori that shape its information system requirements. Individual enterprise departments establish relationships with hardware and software vendors based on that priori and set IS personal standards based on the vendor's products. As the role of the department changes within the enterprises, the department's vendors adjust their products accordingly, thus allowing the department to maintain or increase its market share in comparison to similar, but competing enterprise departments. Over the course of time, a department's vendor supplied applications become unique from other enterprise department's vendor supplied applications as each application provides ancillary functionality to all other department applications within the enterprise. In practice, the disparate, ancillary character of enterprise department applications and database structures is often beneficial to the enterprise because each department's applications are allowed to focus on the department's information priori with minimal interference from the enterprise of other department's information priori.

[0006] On the other hand, however, the information product of one department might be needed by another department for that department to expedite its enterprise sub-tasks. Therefore, a department needing another department's information product must either train its IS personnel on that department's applications or rely on that department to respond on request for its information product. Since enterprise departments relied on diverse vendor applications predicated on dissimilar information priori, information structures laced the coherence necessary for straightforward data exchange.

[0007] Problems, other than at the system level, also developed in the prior art. Enterprise department information products have an additional disadvantage of being system level data images. An enterprise level perspective of an information solution is difficult to achieve because it would be necessary for an enterprise user to understand the data images from all disparate, ancillary system's products that service the enterprise. Finding an enterprise level information solution is problematical because most enterprises rely on their enterprise departments for IS solutions thus, rarely does an enterprise establish an enterprise level information priori.

[0008] Aside from problems associated with hierarchical information levels, enterprise users needing to access system level data and functionality must be competent with a variety of disparate, ancillary applications. Any user needing data from a system must be competent with that system in order to utilize the disparate system interfaces for drilling down into individual department data structures. Many enterprise IS personnel are not overly proficient with a variety of disparate, ancillary applications and non-IS enterprise users are even less competent. Therefore, it is often left to the individual enterprise department to provide the necessary skilled IS personnel to interface with enterprise users needing system level data and functionality. Reliance on individual enterprise departments to access their disparate, ancillary systems for responding to enterprise user requests may result in a lag between the enterprise level query and a system level response from a department, as well as increasing the likelihood of a miscommunication between the enterprise user and a department's IS specialist. Maintaining a duplicative force of department IS personnel in each disparate, ancillary system to respond to enterprise users also increases the IS overhead for the disparate enterprise departments.

[0009] With respect to the health care services industry, the prior art attempts to solve many of the aforementioned shortcomings by eliminating the disparate, ancillary applications and application databases and utilizing an enterprise level application and application level database. By adopting an enterprise information priori, enterprise departments were forced to gradually migrate their ancillary applications toward the enterprise standard and gradually disband their legacy applications.

[0010] Of general background interest to the present invention are the following references. U.S. Pat. No. 5,867,821 issued to Ballantyne, et al. on Feb. 2, 1999 titled, "Method And Apparatus For Electronically Accessing And Distributing Personal Health Care Information And Services In Hospitals And Homes". This reference describes a distribution and administration system that is interconnected to a master library (ML). The master library stores data in a digital compressed format through a local medical information network. The patient/medical personnel interact with this medical information network through a patient's individual electronic patient care station (PCS) that is interconnected to the master library PCS and receives the requested service or data from the master library. The requested data is then displayed either on the associated television set or video monitor or through wireless/IR communications to a peripheral personal data assistant (pen based computer technology). The data for text, audio and video information is all compressed digitally to facilitate distribution and only decompressed at the final stage before viewing/interaction.

[0011] In another example, U.S. Pat. No. 5,748,907 issued to Crane on May 5, 1998 titled, "Medical Facility And Business: Automatic Interactive Dynamic Real-Time Management" utilizes an Interactive Dynamic Real-Time Management System including a microprocessor adapted to sense the automatic interaction of real-time inputs. These real-time inputs relate to the method of controlling the position, flow of patients, employees, invoicing, appointment scheduling, and financial costs. With this automatic interactive management system, it also controls time, space and tasks routinely of a medical clinic or other types of businesses. A memory stores historical data related to the interaction of the real-time inputs and the microprocessor compares sensed real-time information with historical data to determine changes in unknown operating parameters. All information from real-time dynamic interacting, automatic, semiautomatic and manual inputs are fed into a master processor where the information is automatically sent to patients, employees, and other businesses in the network.

[0012] U.S. Pat. No. 6,055,506 issued to Frasca, Jr. on Apr. 25, 2000
titled, "Outpatient Care Data System" utilizes a plurality of metropolitan-area data systems operatively connected to a regional data system. Each of the metropolitan area data systems is located at a different metropolitan location and is dedicated to the transmission, storage and retrieval of outpatient data relating to the care of outpatients and is provided with a regional data system located at a regional location. Each metropolitan area data system may be provided with an electronic nursing station located within a hospital and first and second types of outpatient systems operatively coupled to the electronic nursing station on a real-time basis. A data storage system is located at a hospital which stores outpatient data in the form of a plurality of medical records for a plurality of outpatients associated with the outpatient care data system. For each outpatient, these medical records include an identification of the outpatient and data relating to the medical history of the outpatient.

[0013] In still another example of the prior art, U.S. Pat. No. 5,724,580
issued to Levin, et al. on Mar. 3, 1998 titled, "System And Method Of Generating Prognosis And Therapy Reports For Coronary Health Management" describes a system and method for automatically formulating an alpha-numeric comprehensive management and prognosis report at a centralized data management center for a patient at a remote location. Levin, et al. describes converting information regarding the condition of the patient into data, transferring the data to the centralized data management center and receiving the data. Then, generating the comprehensive management and prognosis report based on analysis of the data. A storage means is also provided at the centralized data management center for maintaining a record of the data received by and transmitted from the centralized data management center in a relational data base format.

[0014] In still another example, U.S. Pat. No. 5,301,105 issued to Cummings, Jr. on Apr. 5, 1994 tilted, "All Care Health Management System" describes a fully integrated and comprehensive health care system. That health care system includes integrated interconnection and interaction of the patient, health care provider, bank or other financial institution, insurance company, utilization reviewer and employer so as to include within a single system each of the essential participants to provide patients with complete and comprehensive pre-treatment, treatment and post-treatment health care and predetermined financial support therefor. A processing system(s) contains substantial memory storage capacity and the system employs such memory storage capacity to record a number of important bodies of data and other information. These data bodies may either be a part of the memory of the processing system or may be in other data banks that are accessible to the processing system.

[0015] Finally, U.S. Pat. No. 6,112,183 issued to Swanson, et al. on Aug. 29, 2000 titled, "Method And Apparatus For Processing Health Care Transactions Through A Common Interface In A Distributed Computing Environment" describes an apparatus and method for processing health care transactions through a common interface in a distributed computing environment using specialized remote procedure calls. The distributed computing environment includes a user interface tier for collecting user inputs and presenting transaction outputs, a data access tier for data storage and retrieval of health care transaction information, a transaction logic tier for applying a predetermined set of transaction procedures to user inputs and health care transaction information resulting in transaction output, an electronic network connecting the user interface tier, data access tier and transaction logic tier to each other and a communication interface for exchanging health care transaction information among the tiers. The communication interface includes an interface definition language generating transaction-specific communication codes whereby data is exchanged through a common interface structure regardless of the origin of the data.

SUMMARY OF THE INVENTION

[0016] The present invention provides a means for an enterprise, such as a health care facility, to receive messages from any one of a plurality of disparate, ancillary vendor applications, convert the vendor information to an enterprise usable form and then store the enterprise information on an enterprise database. The enterprise keeps vendor specific rules for converting each vendor's information to enterprise information. Additionally, relational enterprise rules are applied to the enterprise data stored in a enterprise database so as disparate vendor information is converted to enterprise data, the relationships between that converted enterprise data are checked with the enterprise data stored in the enterprise database. Enterprise data can also be directly entered into the enterprise database from enterprise system clients. The relationships between that enterprise data are also checked with the enterprise data stored in the enterprise database.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as an exemplary mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0018] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals indicate similar elements and in which:

[0019] FIG. 1 is a diagram of an exemplary HL7 message;

[0020] FIG. 2 is a network diagram showing several disparate, ancillary systems depicted as Admissions, Discharge and Transfers (ADT), Radiology, Medical Records/Transcriptions, Pharmacy and Laboratory;

[0021] FIG. 3 is a flowchart depicting a process by which a disparate, ancillary system generates a message in response to a trigger event;

[0022] FIG. 4 is a diagram of an enterprise network, which utilizes an automated interface gateway for routing level seven (such as HL7) event triggered messages;

[0023] FIG. 5 is a diagram of an enterprise system which includes a plurality of disparate, ancillary systems for executing enterprise level message transactions in accordance with an exemplary embodiment of the present invention;

[0024] FIG. 6 is an illustration of patient census information for Dr. Ralph Shyner, from the example used above;

[0025] FIG. 7 is an illustration of lab results displayed on Dr. Shyner's web page as a result of the doctor selecting the "Laboratory Results" command in menu box 616 of FIG. 6 in accordance with an exemplary embodiment of the present invention;

[0026] FIG. 8 is a flowchart depicting a process employed by the Automated Interface Gateway (AIG) catcher for converting system level messages consisting of vendor-specific, system level segment and segment data fields into enterprise level message data in accordance with an exemplary embodiment of the present invention

[0027] FIGS. 9A to 9C depict flowcharts, which depict message transaction processing performed by the enterprise server in accordance with an exemplary embodiment of the present invention;

[0028] FIG. 10, a flowchart depicting an exemplary process for privilege checking, is shown that may be performed by an enterprise application in accordance with an exemplary embodiment of the present invention;

[0029] FIG. 11, a flowchart depicting the process by which an enterprise application processes a transaction request, is illustrated in accordance with an exemplary embodiment of the present invention;

[0030] FIG. 12 is a flowchart depicting a process for manually creating a request query to a disparate, ancillary system for system level event data that corresponds to corrupted enterprise data on the enterprise database in accordance with an exemplary embodiment of the present invention; and

[0031] FIG. 13 is a flowchart depicting a process for restoring enterprise data on the enterprise database from one or more of the disparate, ancillary systems' databases in accordance with an exemplary embodiment of the present invention.

[0032] Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.

DETAILED DESCRIPTION OF THE INVENTION

[0033] Migrating to an enterprise level system from a plurality of disparate, ancillary systems is an expensive and time consuming undertaking for an enterprise. Many enterprises refuse to move from antiquated legacy systems to more modem, user friendly managed desktops such as network computing (NC), or the like, until the Total Cost of Ownership (TCO) for maintenance and upkeep on the legacy system exceeds that of TCO for implementing the more modern network. In the case of disparate, ancillary system applications, the TCO factors are even less appealing to the enterprise because oftentimes, the ancillary applications are state of the art, though not enterprise friendly. Additionally, instituting enterprise level infrastructures, including master libraries and data stores, is a daunting task for an enterprise because department IS specialists must be retrained for the enterprise technology. In an effort to alleviate many of the shortcomings described above, standardized message protocols have been promulgated for the transfer of messages between individual disparate, ancillary systems, rather than wholesale migration to enterprise level systems. By adopting standardized messaging protocols and without resorting to expensive enterprise-wide solutions, disparate, ancillary system applications can communicate more effectively and thus, alleviate at least a portion of the limitation of the prior art.

[0034] Many of these standardized message protocols utilize the seventh, or top layer, of the protocol stacks known as the Application Layer. Application Layer Seven is the top layer of the many protocol stacks, including the OSI (Open System Interconnection) and TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suites. Generally, an application layer is software that provides the starting point for a communications session. Software programs in the application layer initiate communications between entities, such as applications.

[0035] Some of the most widely known application protocols in the TCP/IP suite are FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), Telnet, DNS (Domain Name System) and WINS (Windows Internet Name System). Other, more special purpose application level protocols also exist. These include the IN (Intelligent Network) and AIN (Advanced Intelligent Network) protocols of the SS7 (Signaling System 7) protocol used in publicly switched telephone systems and the HL7 (Health Level Seven) protocol used in the healthcare industry. With the exception of certain of the TCP/IP's own application protocols, the language and format used in a user's client/server program are not known to a transport or communications protocol and instead, they are known only to the receiving programs that must parse the incoming request to find out what the client is asking for. In many instances, data from the programs at the top layer of a protocol suite are "handed down" to the lower layers in a protocol stack for actual transport processing. Conversely, the data is then "handed up" the protocol stack to the appropriate application in the receiving machine.

[0036] With respect to the TCP/IP protocol suite, a program identifies the application it wishes to communicate with by that application's socket (also referred to as a socket address or socket number), which is a combination of (1) the server's IP address and (2) the application's port. If, using the TCP/IP protocol for example, an application does not know the IP address of the destination application, but knows the server by name, the application uses a Domain Name System server (DNS server) to turn the name into the IP address. The port is a logical number assigned to every application. For FTP, SMTP, HTTP and other common applications, there are agreed-upon numbers known as "well-known ports." For example, HTTP applications (world wide web) are on port 80 therefore, a web server is located by its IP address and port 80. An organization's internal client/server applications are given arbitrary ports for its own purposes.

[0037] Generally, protocols are standardized by industry members (application developers, OEMs (Original Equipment Manufacturer) and interested parties, together herein referred to as "vendors"). These vendors form a common interest standards organization that works for harmonizing rules for using the subject protocol. The primary purpose of a standards organization is to attempt to adopt metrics and rules for the use of hardware or software. The rules are sometimes referred to as the specification and using a specification adopted by a standards body is referred to as a dejure use (as opposed to defacto use where the specification is informally adopted by its wide acceptance and use without formal sanctioning). Exemplary standards bodies include ANSI, (American National Standards Institute) and ISO, (The International Organization for Standardization). Rules for application level protocols include language and format standards needed to establish a session. Applications that follow the particular rules established by a standards body are considered compliant with the standard they follow. In the case of an applications layer protocol, it is expected that two compliant applications would be able to establish a communications session because the language and format of the session has been harmonized in advance by the standards body for the application level protocol.

[0038] In practice however, the rules set forth by a standards body can be rather loose and may take the form of guidelines rather than rigid rules. Usually loose standards are an outcome of competing marketplace interests, where each vendor jealously supports protocol rules compatible with its own product rather than supporting rules that favor another vendor's products. In its infancy, the standards body often attempted to pacify competing interests within the standards body by adopting looser rules which did not give any individual or group of vendors a strategic advantage in the marketplace. Rather than alienating any major players in the body by adopting standardization rules similar to a competing vendor's product, the standards body also gave individual vendors more discretion to use their own proprietary protocol variants.

[0039] Lax, flexible or conflicting standardization rules may result in applications that are compliant with the standard and yet, unable to decipher each other's message structures and/or data definitions. In the case of application layer protocols, the resulting inadequacies may be as severe as the inability of compliant applications to establish a session or as minor as an application not being able to decipher proprietary segments of a message sent from another application.

[0040] With regard to the discussion herewithin, a level seven message will be understood by artisans as the atomic unit of data transferred between disparate system applications. Every message is structured as a group of segments in a defined sequence. Most messages are triggered by real world events and every message type defines the purpose of the message. For example, a patient being admitted to a health care enterprise triggers an ADT Message type A01. Below, Table I is a nonexhaustive list containing exemplary HL7 message types and descriptions of the message.

1TABLE I (HL7 Message Types) Message Description ACK General acknowledgment message ADR ADT response ADT ADT message DOC Document response PIN Patient insurance information R0R Pharmacy/treatment order response RAR Pharmacy/treatment administration information RAS Pharmacy/treatment administration message RDO Pharmacy/treatment order message RDR Pharmacy/treatment dispense information RDS Pharmacy/treatment dispense message SQM Schedule query message SQR Schedule query response SRM Schedule request message SRR Scheduled request response SUR Summary product experience report TBR Tabular data response

[0041] The ADT type A01 message is from Patient Administration (ADT) triggered by an event (A01) concerning a patient being admitted. The patient admission trigger event causes the ADT application to broadcast the ADT type A01 message to a predefined set of application socket addresses. The message body contains pertinent data describing the event. For the purposes of the description of the present invention, the exemplary discussions will refer to the HL7 messaging protocol adopted by the healthcare industry. The use of the HL7 standard is not meant to limit the scope or use of the present invention and, as ordinary artisans will readily realize, the present invention may be implemented in a variety of protocols adopted by various business enterprises without departing from the scope or intent of the present invention.

[0042] HL 7 messages are composed of uniquely identified segments and each uniquely identified message segment is a logical grouping of segment fields. Below, Table II is a nonexhaustive list containing exemplary HL7
segment types and corresponding segment descriptions.

2TABLE II (HL7 Segment Types) Segment Description ACC Accident segment ADD Addendum segment AIG Appointment information - general resource segment AIL Appointment information - location resource segment AIP Appointment information - personnel resource segment AIS Appointment information - service segment AL1 Patient allergy information segment APR Appointment preferences segment ARQ Appointment request segment AUT Authorization information segment BLG Billing segment ERR Error segment EVN Event type segment FAC Facility segment FHS File header segment FT1 Financial transaction segment LCC Location charge code segment LCH Location characteristic segment LDP Location department segment LOC Location identification segment LRL Location relationship segment MFI Master file identification segment MSA Message acknowledgment segment MSH Message header segment PID Patient identification segment RXA Pharmacy/treatment administration segment RXC Pharmacy/treatment component order segment RXD Pharmacy/treatment dispense segment RXE Pharmacy/treatment encoded order segment RXG Pharmacy/treatment give segment RXO Pharmacy/treatment order segment RXR Pharmacy/treatment route segment

[0043] Every segment field is associated with a particular data element type and that association depends on the type of unique segment containing the segment field. Below, Table III is a nonexhaustive list containing exemplary HL7 data element types and corresponding specification for the data elements.

3TABLE III (HL7 Data Element Types) Element Type/Description Item# Seg Seq# Len DT Rep Table Accident Code 00528 ACC 2 60 CE 0050
Accident Date/Time 00527 ACC 1 26 TS Accident Death Indicator 00814 ACC 6 12 ID 0136
Accident Job Related Indicator 00813 ACC 5 1 ID 0136
Accident Location 00529 ACC 3 25 ST Account ID 00236 BLG 3 100 CX Account Status 00171 PV1 41 2 IS 0117
Acknowledgment Code 00018 MSA 1 2
ID 0008
Admission Type 00134 PV1 4 2 IS 0007
Admit Date/Time 00174 PV1 44 26 TS Admit Reason 00183 PV2 3 60 CE Admit Source 00144 PV1 14 3 IS 0023
Admitting Doctor 00147 PV1 17
60 XCN Y 0010
Assigned Patient Location 00133 PV1 3 80 PL Assigned Patient Location 00133 FT1 16 80 PL Attending Doctor 00137 PV1 7 60 XCN Y 0010
Billing Category 01007 PRC 14 60 CE Y 0293
Birth Order 00128 PID 25 2 NM Birth Place 00126 PID 23
60 ST Business Phone Number 00195 NK1 6 40 XTN Y Consulting Doctor 00139 PV1 9 60 XCN Y 0010
Contact Address 01166 FAC 7 200
XAD Y Contact Person 01266 FAC 5 60 XCN Y Contact Person Social Security 00754 NK1 37 16 ST Number Contact Person's Address 00750 NK1 32 106 XAD Y Contact Person's Name 00748 NK1 30
48 XPN Y Contact Person's Name 00748 GT1 45 48 XPN Y Contact Person's Telephone Number 00749 NK1 31 40 XTN Y

[0044] The first column of Table III identifies a data element by ELEMENT TYPE while the remaining columns define the element's HL7 attributes. ITEM # is an HL7-specific number that uniquely identifies the data element throughout the HL7 standard. SEG is the HL7 identity of any segments that the data element will occur and SEQ defines the ordinal position of the data element within the identified HL7 segment. The column labeled LEN refers to the maximum number of characters that one occurrence of the data element may occupy within the segment. The length of a field is normative; however, in general practice, it is often negotiated on a vendor-specific basis. The column labeled DT refers to restrictions on the contents of the data field. REP defines whether a field may repeat and if so, the maximum number of repetitions permitted. The column labeled TABLE defines a HL7 table of values for a particular data element. A table defines a list of values for the entity. In this case, the data element. Tables may contain either HL7 or user defined values.

[0045] Segment types may be required or optional, depending on the message and event types. Segments are identified using a unique segment identifier code (ID). For example, an ADT message may contain Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1) segments. Segments may also be proprietary to a vendor and thus identified with segment ID codes beginning with the letter Z.

[0046] Each HL7 segment consists of a collection of segment fields, or string of characters. Certain segment fields may be required or merely optional within a particular segment depending on the segment identifier code. Segment fields are transmitted as character strings; however, some HL7 segment fields may take on the null value, which is different from an optionally deleted field. For cases where a value for the data element is transmitted, a segment field may contain a data element or might merely be a placeholder within the segment for that data element. The HL7
Standard specification contains segment attribute tables that list and describe data fields within an identified segment and characteristics of their usage. HL7 fields are defined in a comprehensive data field dictionary.

[0047] FIG. 1 is a diagram of an exemplary HL7 message 100. A HL7 message is normally generated in response to a trigger event. There are various message types defined in the HL7 message specification for various trigger events. Each message type comprises of segments which, in turn, are built up by different segment fields. The inclusion of the fields in the message segment may be Required (R), Optional (O), or Not Used (N). Below are some exemplary HL7 message types, along with segment descriptions for each message.

[0048] 1. Message Type: ACK (General Acknowledgement Originator)--It has 3
segments:

[0049] (a) MSH--Message Header (R).

[0050] (b) MSA--Message Acknowledgement (R).

[0051] (c) ERR--Error Message

[0052] 2. Message Type: ADT (Admission, Discharge and Transfer)--It has various ADT events associated. For example,

[0053] ADT Event Code: A01

[0054] Event: ADMIT A PATIENT

[0055] Message Segments are:

[0056] (a) MSH--Message Header (R).

[0057] (b) EVN--Event Type (R).

[0058] (c) PID--Patient Identification (R).

[0059] (d) NK1--Next of Kin (R).

[0060] (e) PV1--Patient Visit (R).

[0061] (f) DG1--Diagnosis Information (O).

[0062] ADT Event Code: A02

[0063] Event: TRANSFER A PATIENT

[0064] Message Segments are:

[0065] (a) MSH--Message Header (R).

[0066] (b) EVN--Event Type (R).

[0067] (c) PID--Patient Identification (R).

[0068] (d) PV1--Patient Visit (R).

[0069] ADT Event Code: A03

[0070] Event: DISCHARGE A PATIENT

[0071] Message Segments are:

[0072] (a) MSH--Message Header (R).

[0073] (b) EVN--Event Type (R).

[0074] (c) PID--Patient Identification (R).

[0075] (d) PV1--Patient Visit (R).

[0076] The PID (Patient Identification) segment is used by all ancillary systems' applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently. Therefore, the PID segment must contain non-ambiguous information values that are easily understood across disparate systems. Below is an exemplary table containing segment attributes for a PID segment.

4TABLE IV (PID Segment Attributes) Seq Len DT Opt Rep Table Item# Element Type 1 4 SI O 00104 Set ID - PID 2 20 CX B 00105 Patient ID 3 20 CX R Y 00106
Patient Identifier List 4 20 CX B Y 00107 Alternate Patient ID - PID 5 48 XPN R Y 00108 Patient Name 6 48 XPN O Y 00109
Mother's Maiden Name 7 26 TS O 00110 Date/Time of Birth 8
1 IS O 0001 00111 Sex 9 48 XPN O Y 00112 Patient Alias 10
80 CE O Y 0005 00113 Race 11 106 XAD O Y 00114 Patient Address 12 4 IS B 0289 00115 County Code 13 40 XTN O Y 00116 Phone Number - Home 14 40 XTN O Y 00117 Phone Number - Business 15 60 CE O 0296 00118 Primary Language 16 80 CE O 0002 00119
Marital Status 17 80 CE O 0006 00120 Religion 18 20 CX O 00121 Patient Account Number 19 16 ST B 00122 SSN Number - Patient 20 25 DLN O 00123 Driver's License Number - Patient 21 20 CX O Y 00124 Mother's Identifier 22 80 CE O Y 0189 00125
Ethnic Group 23 60 ST O 00126 Birth Place 24 1 ID O 0136
00127 Multiple Birth Indicator 25 2 NM O 00128 Birth Order 26 80 CE O Y 0171 00129 Citizenship 27 60 CE O 0172 00130
Veterans Military Status 28 80 CE O 0212 00739 Nationality 29 26 TS O 00740 Patient Death Date and Time 30 1
ID O 0136 00741 Patient Death Indicator

[0077] The PID Segment Attribute Table IV is similar to Table III (HL7
Data Element Types) described above with the additional column labeled OPT that defines whether or not a particular field is required (R), optional (O), conditional in a segment (C), not used with a trigger event (X) or left in for backward compatibility for other HL7 versions (B). Using the above-described HL7 rules, any disparate application can generate an HL7 message. Below is an example of an HL7 admit/visit notification transaction triggered from an A01 event (admitted patient).

5
MSH.vertline.{circumflex over ( )}.about..backslash.&.ver- tline.ADT1.vertline.SWR.vertline.LABADT.vertline.SWR.vertline.198808181126- .vertline.SECURITY.vertline. ADT{circumflex over ( )}A01.vertline.MSG00001.vertline.P.vertline.2.3.1.vertline.<cr> EVN.vertline.A01.vertline.200101030803.vertline..vertline.<cr> PID.vertline.1.vertline..vertline.PATID1234{circumflex over ( )}5{circumflex over ( )}M11{circumflex over ( )}ADT1{circumflex over ( )}MR{circumflex over ( )}SWR.about.123456789{circumflex over ( )}{circumflex over ( )}{circumflex over ( )}USSSA{circumflex over ( )} SS.vertline..vertline.JOHNSON{circumflex over ( )}DARRELL{circumflex over ( )}A.vertline..vertline.19610615.vertline.M.vertline..vertline.C.ve- rtline.1200 N ELM STREET{circumflex over ( )}{circumflex over ( )}GREENSBORO{circumflex over ( )}NC{circumflex over ( )}27401-1020.vertline.GL.vertline.(919)379-1212.vertline.(919) 271-3434.vertline..vertline.S.vertline..vertline. PATID12345001{circumflex over ( )}2{circumflex over ( )}M10{circumflex over ( )}ADT1{circumflex over ( )}AN{circumflex over ( )}A.vertline.123456789.vertline.987654{circumflex over ( )}NC.vertline.<cr> NK1.vertline.1.vertline.JONES{circumflex over ( )}BARBARA{circumflex over ( )}K.vertline.WI{circumflex over ( )}WIFE.vertline..vertline..vertline..vertline.NK{circumflex over ( )}NEXT OF KIN<cr> PV1.vertline.1.vertline.I.vertline.7050{circumfle- x over ( )}7113{circumflex over ( )}01.vertline..vertline..vertline..vertl- ine.101010{circumflex over ( )}SHYNER{circumflex over ( )}RALPH{circumflex over ( )}J..vertline..vertline..vertline.SUR.vertline..vertline..vertline- ..vertline.ADM.vertline. A0.vertline.<cr>

[0078] Patient Darrel A. Johnson was admitted on Jan. 03, 2001 at 08:03
a.m. by doctor Ralph J. Shyner (#101010) for surgery (SUR). He has been assigned to room 7113, bed 01 on nursing unit 7050. The message was sent from system ADT1 at the SWR site to system LABADT, also at the SWR site, on the same date as the admission took place, but three minutes after the admit.

[0079] Returning to FIG. 1, HL7 message 100 is composed of at least two parts, TCP/IP routing header 102 and HL7 message 104. The structure of TCP/IP routing header 102 is well known and will not be discussed further except to note that TCP/IP routing header 102 contains routing information necessary to transmit message 100 from a source application to a destination application. The sources and destination are both identified in packet 100's header.

[0080] HL7 message 104, on the other hand, is defined by rules set forth in the HL7 specification and those rules must be observed for a message generated by one disparate, ancillary system to be understood by a second disparate, ancillary system. In general, HL7 message 104 is comprised of a series of uniquely identified message segments which serve a purpose according to the message type, segments 104A-104N and 104Z are shown in FIG. 1. Segments 104A-104N contain information arranged and formatted in accordance with HL7 segment attribute rules. Each of the N segments contains a predetermined number for segment fields for holding a sequence of HL7 defined data elements.

[0081] Proprietary segment 104Z differs from HL7 defined segments 104A-104N in that the data element values contained within segment 104Z may be vendor-specific. This data may be defined and implemented by individual application vendors without regard to the HL7 specification. Often, vendors will utilize proprietary segments when the standardized definitions are ambiguous or significant errors have been encountered by attempting to follow message protocol standards. As discussed above, proprietary segment 104Z is uniquely identified as such and may be disregarded by disparate systems which are not privy to the vendor's proprietary segment specification.

[0082] Within each of the segments 104A-104N and 104Z, are a series of defined data elements. Segment 104A is shown as having M number of HL7
defined data elements in fields 105A-105M. Each of the fields 105A-105M is delimited by field separator 106 (although not shown in FIG. 1 segment boundaries are also delimited by segment terminators). Each data element occupies a predefined segment field that is defined by field delimiters. Therefore, by utilizing the HL7 definition for a particular segment type, the segment field associated with a particular data element may be found in HL7 message 100 using a three-step process. First, it identifies the message type and derives the segment and element types for that message. Next, it identifies a segment containing the value of a data element. Finally, it finds the segment field that holds the data element by counting delimiters.

[0083] Proprietary segment 104P may also be comprised of a series of data items separated by delimiters. FIG. 1 depicts proprietary segment 104Z as having words 107A-107P, each word separated with the segment by delimiters 106. However, in contrast with HL7 defined segments 104A-104N, proprietary segment 104Z may consist of P vender-defined proprietary words 107A-107P that are arranged within proprietary segment 104Z according to a vendor-defined specification. Therefore, even if the element type definitions of data element 107A-107P comply with the HL7
protocol, accessing the values for these elements in a message is nearly impossible without using the vendor's specification that defines the segment fields that hold each data element.

[0084] Generally, it is expected that each of the segments 104A-104N contain uniquely defined data elements, arranged in a predetermined sequence. Therefore, in any HL7 compliant message, it should be possible to identify where the segment data element resides without reading every data element in each segment. Thus, a receiving application can expedite the retrieval and essential data value by merely accessing the particular segment in message 100 that holds the essential data element. By merely counting field separators, the application can forgo reading any data value located in segment fields that are not essential to the message. Conversely, a sending application may omit entering data element values in any segment field that the application does not consider essential to the message. However, as alluded to above, data type definitions are often ambiguous, making the association between a particular data type and a particular data field and segment less sure and more dependent on vendor specifications.

[0085] Yet another issue is when you receive a standard HL7 revision record. As an example, the patient Darrel Johnson is moved from bed 01 on nursing unit 7050 to bed 04 in nursing unit 6050. Some vendors will send a complete HL7 revision record with all patient data including the new room and bed data. Yet another vendor will send only the "change" data elements and omit the "unchanged" elements. Since the record received for processing is, by definition, a "revision" record, one has to wonder if the omitted data elements infer that the omitted data element should be "blanked out", deleted or "nulled" in the enterprise database. Depending on the vendor, some blank data elements in the received HL7 revision record should be ignored and the enterprise database should retain any previous data elements. In yet another vendor's revision record processing, the blank data field will signify that the original data entry person(s) intended to "remove" ambiguous data from the enterprise database and should therefore be processed in the enterprise database accordingly. Here, applying the vendor supplied processing rules to incoming HL7 records becomes very important to the integrity of the enterprise database.

[0086] Fundamental to the success of any standard messaging protocol is the ability for disparate, ancillary systems to understand message content generated by and received from other systems. Messaging protocols must standardize data elements and attribute definitions by providing unambiguous definitions for every data element and attribute. Definitions that are too broad breed confusion in a message body as vendors will invariably use different entry fields for identical data values. When implementing a messaging protocol, care must be taken to avoid confusion between vendors of disparate, ancillary system applications. Initially, vendors must agree to a standardized protocol. Once the protocol has been decided, an auxiliary specification must be established between vendors that specify additional trigger events and message types that identify optional values to be used within the protocol's specification and clarifies perceived ambiguities between vendors.

[0087] With regard to prior art medical ISS technologies, individual medical departments contracted for, and implemented their own ISS solutions without regard to the needs of the enterprise as a whole or the needs of other departments within the enterprise. ISS integration and compatibility was not a concern. Data entry, information storage and data retrieval was performed by the individual departments. However, an individual user had to be authorized on the disparate, ancillary application systems and use application interfaces from the individual applications. The individual applications did not interface with each other unless the applications were products by the same vendor.

[0088] The result, for whatever reason, is an industry supported by multiple vendors, each sponsoring its own ancillary system applications, which are incorporated in an enterprise's ISS. From an enterprise level perspective, most ISS assimilation appears to be on an ad hoc basis. More importantly, due to the ad hoc assimilation and structuring of ISS systems, it is impossible for a user to get a coherent view of enterprise level data from the ancillary systems. A user needing data, most generally, must be authorized by an ancillary department and then access the disparate, ancillary system that is responsible for acquiring that particular data for that department. With such a system in place, it is virtually impossible for a user to understand enterprise relationships between the data stored in disparate, ancillary systems. Still more exacerbating, a user must gain a certain amount of proficiency in every system in order to effectively drill down into an ancillary database to needed data. It is utterly impossible for a non-ISS user, such as a manager, engineer, nurse, doctor, specialist, etc., to gain that level of proficiency in the normal course of business.

[0089] After several departments obtain their needed ISS systems, those departments soon realize the need to communicate with each other. If, by chance, the vendor applications are compatible or compliant with a standard, the disparate, ancillary application may communicate. If, as is more likely, the disparate vendor applications are not compatible or not compliant or the standards are weak, then the disparate applications may not communicate in a meaningful way.

[0090] Communication between ancillary systems may take a number of forms, but for the purpose herein, the communications process occurs as depicted in FIG. 2. FIG. 2 shows several disparate, ancillary systems depicted as Admissions, Discharge and Transfers (ADT) 202, Radiology 204, Medical records/transcriptions 206, Pharmacy 208 and Laboratory 210. The depicted systems are merely illustrative of the disparate, ancillary systems that may be present within a health care enterprise and one of ordinary skill in the art would readily realize that other systems may be present in combination or in place of the exemplary systems. Each of the respective disparate, ancillary systems utilize servers 202A, 204A, 206A, 208A and 210A for processing information to and from their respective terminals 202C, 204C, 206C, 208C and 210C and storage units 202B, 204B, 206B, 208B and 210B. It is expected that any one users 202D, 204D, 206D, 208D and 210D initiate a trigger event by communicating with their respective servers 202A, 204A, 206A, 208A and 210A via respective terminals 202C, 204C, 206C, 208C and 210C.

[0091] The occurrence of the real world event triggers a message, in this case a HL7 compliant message, being sent. Message transactions are represented by arrows to and from each of the disparate, ancillary systems 202, 204, 206, 208 and 210 which are functionally connected to one another over a network such as a Local Area Network (LAN) or possibly a Wide Area Network (WAN). As discussed above, a trigger event causes information associated with the event to be sent to one or more ancillary systems. Many types of HL7 messages are generated in response to a trigger event. As such, the transaction is termed an "unsolicited update". Ancillary applications that need event information from a trigger event must listen for a message containing the unsolicited update information values.

[0092] The process by which a disparate, ancillary system handles message generation using a standardizing messaging protocol in response to a trigger event is depicted in FIG. 3. Initially, each of disparate, ancillary systems 202, 204, 206, 208 and 210 are in a ready state waiting for the occurrence of a trigger event (step 302). Once a trigger event is detected, the event is immediately identified and the event information is processed and stored locally in accordance with vendor-specific rules (step 304). Next, the disparate, ancillary system processing the event determines whether to generate a HL7 compliant message with the event information (step 306). If a message is not to be generated, the system returns to the ready state and the process returns to step 302. If a compliant message is to be sent to another ancillary system, then the application processing the event information must first identify the appropriate HL7 message type by the event type (step 308). Once the message type has been identified, the event processing application identifies all disparate, ancillary systems that are to be sent the message. The systems are identified by their applications' socket addresses (step 310). Here, the event processing application usually looks up the recipient socket numbers associated with an event type. Of course, it is the responsibility of ancillary systems that need event information to provide the ancillary application that processes that event information with their socket address. Next, the message must be formatted in accordance with the HL7 messaging specification (of course, any messaging protocol might be equally applicable) thus, the messaging specification must be accessed (step 312).

[0093] It should now be understood that even though a standardized messaging specification has been implemented across disparate, ancillary systems in an enterprise, an auxiliary specification is often necessary to handle ambiguities, harmonize definitions and specify options, usually between at least two disparate vendor applications. Therefore, after the messaging specification has been accessed, the event processing application then accesses an auxiliary (or its proprietary) messaging specification (step 314). While the auxiliary messaging specification may be a vendor-specific specification intended for use only with vendor supplied systems, it is more likely that the proprietary messaging specification is an auxiliary specification compiled by vendors whose applications support an enterprise. Although rare, it is possible that a particular trigger event might mandate the generation of multiple messages, each message being generated in accordance with a recipient-specific specification. However, it is more likely the processing application would use a single auxiliary specification for message generation. A recipient application would then be responsible for accessing the correct proprietary specification for sending and deciphering incoming messages from the sender using the sender's specification.

[0094] One or more messages are then generated using both the standard messaging specification and the propriety specification (step 316). The messages are transmitted to the recipient applications' socket addresses (step 318). The processing application may or may not receive an ACK (acknowledgment) message from the recipients. If a recipient application is so configured, it may acknowledge the message by sending an ACK message to the processing application and even provide an error log in a message error segment. Therefore, a processing application may retain instances of transmitted messages in case one or more of the messages must be retransmitted. Therefore, the processing application determines whether or not to expect an ACK message from a recipient (step 320). If an ACK message is not expected, the ancillary system concludes processing of the current trigger event and the process returns to step 302 where the event processing system returns to the ready state. However, if the processing application identifies a recipient application that is configured to acknowledge the event message, the process monitors the time since transmission of the event message (step 322). If the processing application receives an ACK message within a preset time period, the process ends. If not, the process reverts to step 318 where another instance of the message is retransmitted to the recipient application and the time period restarts. The event processing application cannot end the current messaging process until the acknowledgement has been received from the recipient system (at least not without several attempts to communicate with the recipient). If a predetermined number of messages have been sent to the recipient without an acknowledgement, it must be assumed that the recipient system is not listening or cannot respond. In that case, the process ends without an acknowledgment and the process returns to step 302 with the processing system returning to the ready state.

[0095] With respect to the description above, as an ancillary application receives a triggering event, that application sends an unsolicited message to one or more system based socket numbers associated with the event type. If an ancillary system is listening at that socket, it will pick up the message and attempt to process it. However, a considerable number of problems may occur between ancillary systems that are attempting to communicate event information. For example, a recipient application might not be listening or may fail to understand the data in the message. Alternatively, the socket number used by the event processing application may not define a valid destination application. Because the event processing application may know the recipient application by a socket number only, the event processing application assumes that the recipient receives every event message. Still, other problems occur when the recipient application attempts to process the message in a manner that is inconsistent with the processing application's messaging specification.

[0096] The prior art has attempted to solve many of these problems by employing a myriad of intrusive solutions. Most solutions were based on the premise that no assumption could be made about the design or architecture of either the sending or receiving application. Thus, the easiest solution required that vendors communicate with each other and define rules for handling ambiguities, harmonizing definitions, specifying options and reassigning conflicting port numbers used to link incoming data to the correct applications. These solutions required each vendor to keep abreast of its competitor's technology by relying on disclosures from the competition.

[0097] A second tact was to strengthen the standards. To that end, messaging standards were introduced which required that an original mode acknowledgment be returned whenever an unsolicited update was received. By requiring each ancillary application to respond to an event message with an acknowledgment message, the burden of "listening" was more evenly divided between sending applications and receiving applications. A sending application could no longer "send and forget" an event message but instead, was required to retransmit the event message if an acknowledgment was not forthcoming from the recipient system. On the other hand, recipient systems were relieved of the consequences of the network faults occurring between their socket and the sender system. Utilization of the acknowledgment message also relieved a recipient of the responsibility of listening. Transitory lapses in listening were tolerated because the sending system was required to retransmit event messages that were not acknowledged by a recipient system. Other improvements were also employed to ensure that the recipient understood the information contained in an event message. Standards bodies attempted to harmonize definitions and remove ambiguities wherever a consensus of members agreed. Rules that were previously optional were made mandatory. New, more generic open standard text languages were implemented including XML (extensible Markup Language). Often, however, the standard's strengthening and harmonization efforts were no more successful than previous efforts that produced weak, guideline-like standards rules.

[0098] A third effort came by way of relieving individual vendors of the responsibility for the monitoring of each other's application system changes. The introduction of the Automated Interface Gateway (AIG pronounced "egg") to intercept and reroute messages between ancillary system applications was directed to that end. AIGs, or interface engines, are generally data integration tools that allow information in the form of messages, records, or transactions to be exchanged, routed, and translated between dissimilar systems and applications. The Integrator and Cloverleaf are examples of interface engines and available from Healthcare.com, Inc., 15301 Dallas Parkway, Dallas, Tex. 75248-4605.

[0099] FIG. 4 is a functional diagram of an enterprise network which utilizes an automated interface gateway for routing level seven event triggered messages. FIG. 4 depicts enterprise network 400 that comprises several disparate, ancillary systems each functionally connected to an Automated Interface Gateway (AIG). Admissions, Discharge and Transfers (ADT) 402, Radiology 404, Medical records/transcriptions 406, Pharmacy 408 and Laboratory 410 are identical to disparate, ancillary systems depicted above with respect to FIG. 2. Again, the depicted systems are merely illustrative of disparate, ancillary systems which may be present within a health care enterprise and one of ordinary skill in the art would readily realize that other systems may be present in combination or in place of the exemplary systems. As discussed with respect to FIG. 2
above, each of the respective disparate, ancillary systems utilize servers 402A, 404A, 406A, 408A and 410A for processing information to and from their respective terminals 402C, 404C, 406C, 408C and 410C and storage units 402B, 404B, 406B, 408B and 410B. However, unlike the disparate, ancillary systems depicted in FIG. 2, whenever any one of servers 402A, 404A, 406A, 408A and 410A generate a HL7 compliant message, the message is directed AIG 412 rather than sending the message to a recipient system based on the event type. Message transactions are represented by arrows to and from each of the disparate, ancillary systems 402, 404, 406, 408, 410 and AIG 412.

[0100] Including addressability, utilizing an AIG for routing messages between systems has several immediate benefits over system-to-system messaging. When an enterprise configures an AIG in its network, all event messages are initially addressed to the AIG socket rather than to the individual ancillary applications. Thus, an event processing application is freed from maintaining a correspondence table of application socket addresses and event types. Any message generated as result of an event is transmitted to the AIG. The AIG also handles responses, such as ACK messages, thereby freeing resources in the event processing application for other tasks immediately after the AIG receives the event message. Also, with an AIG in place, the event processing application need only send a single event message in response to any trigger event, thereby freeing even more system resources.

[0101] By maintaining a comprehensive list of message/event type correspondence tables for all application sockets registered in the enterprise, AIG 412 relives individual vendor applications from the burden of maintaining an extensive list of event (message) type socket addresses. Regardless of the event type, the processing application merely routes the event message to the AIG. Upon receipt by AIG 412, the event processing application (sending system) is identified and the message address layer (TCP/IP layer) is stripped away. AIG 412 then identifies the message and event types from the message header segment (MSH) and the event type segment (EVN), respectively. Using the message/event type information, AIG 412 looks up corresponding recipient application socket addresses using a message/event type socket address correspondence table stored in AIG database 412B. The original HL7 event message body is then repackaged in event messages with the respective recipient application socket addresses. The repackaged event messages are then sent to the respective recipient applications over enterprise network 400. After the event messages are sent, AIG 412 assumes the responsibility for retransmitting any undelivered HL7 event messages to any recipient applications not responding with an ACK message within a preset time period.

[0102] The description above provides a greatly simplified view of the workings of a messaging interface engine. It is understood, however, that every vendor relies on the AIG for routing event messages to and from its ancillary applications in an enterprise. In order to assure receiving critical event messages, each vendor is therefore behooved to expeditiously update the AIG database with internal vendor specification changes, updated socket addresses, etc. However, even though the AIG greatly increases messaging reliability between disparate, ancillary systems in an enterprise, many of the shortcomings inherent in the prior art still exist. For instance, ambiguities, optional parameters and outright contradictions in the HL7 specification still necessitate each vendor maintaining auxiliary specifications for all other vendor applications in the enterprise. Even in enterprises where event data is freely and accurately transmitted between ancillary applications, the event data is still stored and maintained at a system level. An enterprise level view of data stored in the respective ancillary databases is impossible because each database maintains only a system level image of its data. Attempts to piece together an enterprise level answer from the ancillary system's present enterprise network 400 is extremely difficult because each ancillary system maintains separate database rules for structuring, storing and interfacing its respective data. Enterprise users not only have to be familiar with the specific data elements stored in disparate system's database, but the user also must maintain the proficiency necessary on that system's interface to drill down into a particular database and acquire the data.

[0103] In response to many of the additional shortcomings of the prior art, the enterprise network was further modified to restructure system level HL7 message data to an enterprise standard. Event data processed at a system level can, therefore, be stored and retrieved in an enterprise database. While the prior art teaches storing and retrieving event data to and from a master enterprise database heretofore, the preferred method was to migrate each of the disparate, ancillary applications to an enterprise application and disband the ancillary systems altogether. Individual enterprise departments gave up their ancillary systems for an enterprise system. Department ISS personnel, who once specialized on the ancillary system applications and databases, are absorbed, as needed, into an enterprise ISS. While the wholesale migration of system level applications and databases to an enterprise solution may provide the most expedient path to enterprise level IS answers, the path is fraught with expense and disruption for the enterprise.

[0104] An alternative to migrating to a system wide enterprise solution is to layer an enterprise level solution over the existing system level application structure. The AIG interface provides a ready port for connecting to an enterprise level database for storing event data that is organized based on enterprise level information priori rather than the individual system level information structures. Event messages broadcast from the AIG may be transmitted, simultaneously, to a system/enterprise interface engine. This interface engine converts HL7 compliant messages to an enterprise message capable of being processed by an enterprise server. The enterprise server then, among other functions, warehouses the event data, that was converted from HL7 messages, in an enterprise database. The functionality of the individual ancillary system applications remains unmodified and each ancillary system continues to process event information and stores the information locally as described above. With this improvement, the enterprise server processes transactions directly from the enterprise user. Additionally, event information is available to the enterprise server from an enterprise level data stored in the enterprise database. Thus, it is no longer necessary for the enterprise user to drill down into ancillary databases using ancillary system tools.

[0105] Briefly, the message/event type socket address correspondence table stored in AIG database is updated with an additional socket address for the system/enterprise interface engine, known as the AIG catcher. The AIG catcher receives and opens HL7 event messages from the AIG and accesses the message body. Each data value in the message body is then mapped to a corresponding enterprise value in an enterprise message body. Once an HL7
message's event data is converted from its original, vendor-specific variant of the HL7 protocol into enterprise structured data, the enterprise message is passed to an enterprise server, where it is processed and written into an enterprise database. Rather than being system specific, as are the ancillary system databases, the enterprise database is enterprise specific. Therefore, in addition to processing any requested transactions, whenever an enterprise message arrives at the enterprise server, the server can autonomously process a variety of additional enterprise transactions related to either the message data or the requested transaction. Processing these related transactions might require that the enterprise server retrieve additional enterprise data from the enterprise database. Access to enterprise level data stored in the enterprise database is further provided to authorized web appliances connected to a web server that is also connected to the enterprise server.

[0106] Heretofore, the prior art disparate, ancillary systems were fashioned such that each system's applications relied only on its own internal data. Other than event data received in an HL7 message from another system, applications could not establish functional relationships with data in another application's database. In accordance with an exemplary embodiment of the present invention, the enterprise server establishes functional relationships between seemly disparate event elements. These functional relationships could not be recognized by prior art systems as they processed event data at a system level.

[0107] An example of a functional relationship heretofore unrecognized by the prior art involves the occurrence of a trigger event, such as a medical practitioner prescribing a course of respiratory therapy for the patient on an ancillary system, the Medical Records system. Normally, in a prior art enterprise, the physician's order is transcribed by Medical Records' personnel and then the patient's whereabouts are determined by accessing the ADT database. A hard copy of the physician's order is then routed to the nurses' station responsible for monitoring the patient's hospital room. Once the hard copy is received at the nurses' station, a nurse looks up the name and notification information for the respiratory care therapist responsible for the patient's room. The nurse attempts to contact the therapist, usually by telephonic paging. Eventually, the therapist gets the message and attempts to confirm with the nurse by telephone. Scheduling a therapist may take several iterations of paging attempts and return telephone calls. The physician's order also triggers an HL7 message for Patient Billing, ADT, etc. In contrast to the prior art and in accordance with the present invention, a physician's scheduling order for a course of respiratory therapy is received by the enterprise server as an enterprise message, e.g. a request for service. The enterprise application accesses patient information, respiratory therapy duty roster and therapist notification information from the enterprise database. Next, prior to actually processing the physician's service order transaction, the server application locates the patient's assigned floor, room and bed and identifies the therapist and nurses' station assigned to cover the patient's room and bed. The enterprise application notifies both the appropriate therapist and nurses' station of the pending order and only then does the enterprise application process the physician's service order transaction. The physician's service order transaction is supplemented with information acquired by processing the related transactions, such as the patient's location, therapist identity and nurses' station.

[0108] With respect to FIG. 5, a diagram of an enterprise system, including a plurality of disparate, ancillary systems, is depicted for processing enterprise message transactions in accordance with an exemplary embodiment of the present invention. An enterprise message, in accordance with an exemplary embodiment of the present invention, is compliant with proprietary enterprise messaging standards with respect to an enterprise messaging standard or specification. These standards are derived by the enterprise in furtherance of a defined enterprise information priori. In one exemplary embodiment, the enterprise messaging specification is similar, and in fact, based on the HL7 framework. In other embodiments, the enterprise messaging specification is based on a vendor's messaging framework of an existing enterprise system. Using this second messaging framework positions the enterprise for deferred, but eventual, migration of each of the disparate, ancillary systems to an enterprise system.

[0109] Although and in accordance with the depiction shown in FIG. 5, the network elements are shown as physical network elements. In practice, certain network elements are actually logical sub-components of other physical network elements. For example, AIG catcher 520 is depicted as a unique physical structure with its own storage, vendor specific mapping tables 522, that is separate and apart from enterprise server 530. However, in practice, the functionality of AIG catcher 520 is contained within enterprise server 530 and the information on vendor specific mapping tables 522 is actually stored on enterprise database 532. It is possible to configure enterprise system 500 in accordance with either embodiment however, the present invention will be described as each network element being a separate physical element. Logical network elements that, in practice, are not configured as separate network elements are show in dashed lines while physical elements are shown as solid lines.

[0110] At the center of the enterprise system is enterprise server 530
which supports an enterprise application. Enterprise server 530 may be, for example, an IBM RISC/System 6000 system, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system or alternatively could include an Intel based Symmetric MultiProcessing (SMP) server such as available from Dell Computer Corporation, One Dell Way, Round Rock, Tex. 78682 and Compaq Computer Corp., 20555 SH 249, Houston, Tex. 77070, etc. running Microsoft Windows NT operating system (Windows NT a trademark of and available from Microsoft Corporation, One Microsoft Way, Redmond, Wash. 98052); an Intel based SMP server (any vendor) running LINUX, etc.; or SparkStations, etc. (SparkStations is a trademark of and available from Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, Calif. 94303). In practice, current code is only supported on Windows NT servers but, the ordinarily skilled artisan could readily duplicate this, write their own code, to be supported and run on any platform for processing data and requests to and from enterprise database 532. Enterprise server 530 receives enterprise messages from any one of a number of sources including web server 540, AIG catcher and under certain circumstances, any one of disparate, ancillary systems 502 to 510. Ancillary systems 502
to 510 correspond to systems 402 to 410 described above with respect to FIG. 4 and may include, for example, ADT, Radiology, Medical Records and Transcriptions, Pharmacy, and Laboratory Systems, etc.

[0111] Enterprise server 530 may be a symmetric multiprocessor (SMP) system including a plurality of processors connected to a system bus or alternatively, a single processor system may be employed. Also connected to system bus is local and memory controller/cache, which provides an interface to the local memory. An I/O bus bridge is connected to the system bus and provides an interface to the I/O bus. Peripheral component interconnect (PCI) bus bridge connected to the I/O bus provides an interface to the PCI bus and a number of modems may be connected to the PCI bus. Communications links to network computers, including web server 540 and AIG catcher 520 may be provided through a modem, but more likely, using one of a plurality of network adapters connected to the PCI local bus or the I/O bus. Those of ordinary skill in the art will appreciate that the hardware described above is exemplary and may vary from server to server based, among other factors, on enterprise needs. For example, other peripheral devices, such as optical disk drives and the like, may also be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention. Enterprise server 530 may be, for example, an IBM RISC/System 6000 system, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system.

[0112] Enterprise server 530, as depicted in FIG. 5, functions as a database server. Enterprise server 530 processes database storage and retrieval requests from enterprise clients by utilizing an enterprise database management system (DBMS) and for managing information in enterprise database 532. Exemplary DBMSs include Sybase (a trademark of and available from Sybase Inc., 6475 Christie Avenue, Emeryville, Calif. 94608) and Oracle (a trademark of and available from Oracle Corporation, 500 Oracle Parkway, Redwood City, Calif. 94065) for applications on NT/UNIX platforms and also Microsoft SQL Server for NT operating systems (both trademarks and available from Microsoft Corporation). Upon requests from the enterprise clients, such as web clients 544A-544N, Enterprise server 530 searches enterprise database 532 for selected records and passes them back to the requestor over the network. The implementation of enterprise server 530 allows enterprise data to be requested, modified and imaged at an enterprise level rather than at a sub-enterprise or system level as was common in the prior art. Therefore, rather than the user being forced to access system level information at each one of the separate ancillary systems 502 to 510, an enterprise user may, instead, access enterprise level information contained within enterprise database 532 through enterprise server 530 via, for example, web server 540.

[0113] Web server 540 makes world wide web services on the Internet available to enterprise server 530. Web server 530 includes hardware and operating systems similar to that described above with respect to enterprise server 530, but also includes web server software, TCP/IP protocols and the web site content