LRI+Architecture+Overview+and+Implications

include component="page" wikiName="siframework" page="LRI Header" This is the wiki page to discuss and document the Architecture Overview and Implications for the Lab Results Interface (LRI) Use Cases as defined by the Laboratory Results Interface S&I Framework Discovery Phase Use Case development completed March 2011.


 * Overview**

The Laboratory Results Interface Use Cases describe the sample user story that is executed when Laboratory Test Results are to be electronically reported to an Ambulatory Care Provider such as an Internal Medicine Physician, a Family Practice Physician or a Pediatrician in the US Realm. In addition, the Use Case also identifies the content that needs to be exchanged for the Laboratory Test Results to happen seamlessly using electronic health information. The goal of the Architecture and Implementation Requirements SWG is to take the Use Case and delve down into an architecture which can support the LRI Use Case as well as delineating the implementation requirements required for each component within the system.


 * Overview of the Information Flow and the System Interactions**

The following diagram is an abstract model of the interchange that helps visualize the information flow and the systems that are involved in the laboratory results interface:



As shown in the diagram, the initial part of the Laboratory workflow, namely initializing the Laboratory request and providing the specimen are out-of-scope for the LRI Initiative. The receipt of the Laboratory Requisition, which includes the Laboratory Order, Patient Information, and other critical information is required as input to the Laboratory Test Results. Additionally, the process for delivering the specimen in order to perform the test is also out-of-scope. The LRI user story identifies a "Sender", "Receiver", "Sending LRI System", "Receiving LRI System" which are minimally required for the user story to be met. The Sender must be an Ambulatory Laboratory Interface System (LIS) and Receivers must be an Ambulatory Care EHR, supporting Providers such as a Internists, a Family Practitioners or a Pediatricians. The Information that is exchanged between the Sending and the Receiving System is the initial sending of the Laboratory Test Results, and the potential follow-up interactions requesting and fulfilling a corrected/amended Laboratory Test Result. The core data elements that will be exchanged will be identified and defined by the Clinical Information Model SWG and the Implementation Guide Analysis SWG.


 * Overview of the System Architecture**

In order to implement the LRI user story in the real world, organizations need to understand the major components making up the sending and receiving systems. At the application level, Sending and Receiving Enterprises need to be able to create/receive and view the clinical content associated with the LRI. Just as important is the existence of the System infrastructure which provides such functionality as the Security and Privacy, and the transport of the clinical information from one Enterprise to another. The diagram below is a pictorial representation of the System components which need to exist in real world implementations.



Together these major components provide critical capabilities which allow the system to deliver the required functionality for real world implementations. This includes: The following section gives a short overview of the capabilities required to meet the needs of the LRI, including in some cases implementation mechanisms that might be deployed. Since the current S&I Framwork LRI Initiative focuses primarily on the application level, this phase of the development will be focused on items #1 (Sender's and Receiver's LRI System Capabilities), #2 (Core Data Elements) and #3 (Standards). In other words the LRI Initiative will be creating recommendations in terms of standards, services and policies that are related to item1 #1, #2 and #3.
 * 1) **Sender's LRI and Receiver's LRI System Capabilities**//:// What kind of capabilities need to exist minimally in a Sending or Receiving LRI System ?
 * 2) **Core Data Elements** : What are the exact data elements that need to be included in the LRI Information Packages ?
 * 3) **Standards**: What are the candidate standards that can be used for each of the above areas ?
 * 4) **Transport**: How will information be transferred between the sending and the receiving system ?
 * 5) **Security and Privacy**: What kind of security and privacy practices need to in place to protect PHI ?
 * 6) **Addressing**: How will senders, receivers, patients be identified ?
 * 7) **Patient Consent**: What kind of patient consents are required for the LRI user story to be implemented ?
 * 8) **Patient Correlation across enterprises**: When the Transition is across enterprises what kind of correlation needs to happen ?


 * Sending and Receiving System Capabilities (LRI**)

The capabilities that are essential for effectively exchanging electronic health information are shown in the LRI System Component Overview Diagram above as part of the "Sender's and Receiver's LRI Systems". For the purpose of the LRI user story, the only capabilities that will be covered will be the creating, receiving and viewing of the clinical information related to the LRI initative. The focus of the Architecture and Implementation RQ SWG will be to refine the architecture and implementation requirements related to the sending and receiving capabilities.

**Core Data Elements (LRI)**
The core data elements that are required for the LRI Initiative will be identified and further refined as part of the Clinical Information Model SWG and Implementation Guidelines Analysis SWG and the results will be incorporated into the capabilities identified above.

**Standards Selected: (LRI)**
The standards that will be selected to best implement the LRI core data elements will be chosen based on the analysis of the Standards Analysis SWG and the Implementation Guidelines Analysis SWG The candidates for implementing the core data elements are: The standards for implementing other areas such as the Transport, Security and Privacy, Patient Correlation, Patient Consent etc.. are not part of the LRI Initiative, but a brief discussion of these capabilities is included as informative content.
 * HITSP Interoperable Lab Results Specification
 * ELINCS R1

**Transport**
Transport in the above context defines the mechanisms that can be used to transfer the content electronically between the Sending and the Receiving Systems. For LRI Transport an organization can choose to implement mechanisms based on Direct specifications, IHE TF profiles, NHIN Exchange specifications etc. For the purpose of this initiative it is assumed that one of the above or equivalent mechanisms are being used to transfer content between the Sending and the Receiving Systems.

**Security and Privacy**
To ensure PHI is not disclosed inappropriately, the initiative assumes that organizations are adhering to HIPAA privacy policies and have security practices that protect the patient's information for all information exchanges. The organizations security and privacy practices when coupled with the appropriate Transport can ensure that PHI is protected from the Sender to the Receiver through all the intermediary systems involved. In addition the Auditing and other security controls that an organization has in place should be able to meet the required MU, HIPAA and NIST regulations.

**Addressing**
The addressing here refers to the activity of identifying the senders and receivers of LRI information. The addressing can be implemented based on Direct specifications, IHE TF profiles, NHIN Exchange specifications etc. For the purpose of this initiative it is assumed that one of the above or equivalent mechanisms are being used to identify senders and receivers and no new mechanisms are developed as part of this initiative.

**Patient Consent**
Organizations are assumed to have patient consent policies in place as appropriate and these existing mechanisms will be used by the senders and receivers before LRI information is exchanged between the senders and the receivers.

**Patient Correlation across Enterprises**
LRI Initiative does not require Patient correlation to exist in order for information to be exchanged between the enterprises for LRI user storu. However, Organizations can leverage any pre-existing mechanisms for correlating patients across enterprises such as the use of XCPD based standards, NHIN Exchange specifications.

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"