Composite Reporting
A node-to-node health information exchange architecture I've described has the added benefit of generating composite reports. These reports are comprised of information sent from multiple publisher nodes to a single subscriber node. The subscriber node takes all that information and combines it into a single integrated patient health profile report.
For example, let's say this report is a "continuity of care record" (CCR) [1] that a primary care physician (PCP) wants to use to help keep track of what's going on with the treatment a patient is receiving from several provider specialists. The PCP's node, which serves as the subscriber, would send a request for CCR data from all the patient's specialists. Upon receipt, the specialists' nodes, which serve as the publishers, retrieve the requested data from their different EHR (electronic health record) databases and send the data automatically to the PCP's node. The PCP's node then incorporates the data into a composite report tailored to the PCP's needs and preferences, and then presents it on screen for the PCP to view. The PCP's subscriber node could also be instructed to request data from the publisher node connected to the patient's PHR (personal health record) database and, upon receipt, include specificPHR data into the same CCR report as authorized by the patient.
Now, if the nodes also utilized universal translation (see the previous post), the data being sent by the subscriber nodes to the PCP's publisher node would be transformed appropriately, so the data always arrives in the right format (structure) and with the right terminologies (semantics). The result would be a useful, cohesive, and understandable CCR report containing information from disparate databases and data standards.
Application Integration
Still another way to make information useful, while avoiding data standards problems, is through application integration. This refers to an ideal way to present information residing in different software applications to support healthcare decisions.
Software vendors have been inventing different ways to display patient data that reside in disparate databases and are presented trough disparate applications.
- First, there was single sign-on (SSO) with which the user name and password are entered once. Multiple applications then display a patient's data through different windows on the computer screen. In its most basic form, SSO simply bypasses the login and user-validation screens of all but the first application accessed. The person still has to navigate through each application individually, however.
- Then came context management, which uses SSO, but goes a step further by synchronizing multiple applications. This enables a clinician to view a list all his/her patients, select one, and have multiple windows, corresponding to multiple applications, refresh automatically. This means the information presented through the windows of all the applications is related to the selected patient.
- Unified view takes context management one step further by presenting the data from different applications in a single window.
- Data integration involves synthesizing data across multiple applications and presents the data in a fully integrated manner. For example, when context management with a unified view is used to examine how a patient's medications affect his/her lab data, it simply presents one window with the lab results and another with the patient's active medications. That is, the data in each window are accessible only to the application that presents it; there is no interaction between the applications, so the data is static.
A data integration system, however, recognizes the relationship between the data in the lab results window and the data in the meds window. This means the system can provide decision support by, for example, displaying a warning that lab result A may be affected by the patient's use of medication B. This goes beyond context management with a unified view since it applies analytic intelligence to the data being displayed by different applications. These data associations, however, are transient, i.e., the logic processes used for analytics and decision support must be run each time the same data are presented since there is no way to store the associations.
- Application integration goes beyond data integration since it retains the associations between data from multiple sources by creating and storing new forms of data that can be accessed repeatedly. Using the example above, it means that an application integration system would generate and store a new piece of data indicating that the problematic lab result A may be due to the patient's use of medication B. This warning information can be retrieved at any time in the future without having to startup the medication and lab results applications, and without having to analyze their data all over again. And the warning information can even be shared with other authorized persons, such as in a CCR report.[2]
References:
[1] American Academy of Family Physicians Center for Health Information Technology: ASTM Continuity of Care Record (2007)
[2] Holland, M. (Feb 2007). Improving Clinical Workflow with Unified Data Access and Management. IDC.
3 comments:
HMMM...some intriguing thoughts.
Hi, I was just wondering if you could post up something like a picture to explain how the node to node process works again. It would be really helpful
Thanks a lot,
Thanks for you request, Michelle. Here are several links containing node-to-node architecture diagrams:
• mesh node architecture
• Node Network Using the CP Split Technology
• Node Network's Health IT Functions
Post a Comment