View source for Receive & Forward Proxy Actor Proposal

__NOTOC__
"Two IHE Quality Domain Proposals on page below by Dan Russler:

1) Receive and Forward ITI-14 Proxy Actor

2) Aggregator/Analyzer Actor"


==1. Proposed Workitem: '' Receive and Forward ITI-14 Proxy Actor ''==

* Proposal Editor: ''Dan Russler''
* Editor: ''Dan Russler'' 
* Date:    N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Domain: ''Quality''

==2. The Problem==

''The introduction of the TLS dual-certificate security model in the IHE ATNA Secure Node intetration profile both ensures that the connection between two servers over the internet is secure and precludes the ability to allow two receivers of a single communication. However, there are a number of scenarios in the Quality Domain associated with the re-use of data whereby secure manipulation of transaction content or transaction direction is desirable. These scenarios are commonly associated within secure data centers where data center administrators may want to establish an ITI-14 Proxy Actor whose main function is to receive one transaction and forward that transaction to one or more recipients after optionally applying de-identification or other transform procedures on the transaction content. Specific examples include the introduction of an Aggregator/Analyzer Actor into the Affinity Domain (which requires a duplicate register document set transaction ITI-14), the need to route transmissions to alerting engines in biosurveillance or the need to de-identify privacy information within a transaction for quality reporting, clinical trial use, or other reporting requirements. This Receive and Forward ITI-14 Proxy Actor Integration Profile would allow a security and privacy administrator to install an application with the ITI-14 Proxy Actor that could act as an ITI-14 recipient, which receives all ITI-14 transactions and transforms and distributes ITI-14 transactions as needed.''


==3. Key Use Case==

''Precondition: An existing IHE affinity domain includes a central Patient Identity Manager, a central Document Registry, a central Audit Server, a central Time Server and multiple document repositories distributed among many institutions. The system administrator of the centralized data center and the privacy officer of the affinity domain wish to install a central document aggregator/analyzer for quality analysis as approved by the governing board of the affinity domain.

Activities: The privacy officer grants the system administrator two new TLS security certificates. The system administrator either installs a separate application with the ITI-14 Proxy Actor, configures the Document Registry Application to include an ITI-14 Proxy Actor, or configures the Aggregator/Analyzer actor to include an ITI-14 Proxy Actor. This new ITI-14 Proxy Actor is configured with the TLS security certificate of the original central document registry. The two new TLS security certificates are configured into the  current document registry actor and the aggregator/analyzer actor as needed (if within a separate application). Finally, the ITI-14 Proxy Actor is configured to route all ITI-14 transactions to both the central document registry actor and the central aggregator/analyzer actor as well as document transactions in the IHE ATNA Audit Server.

Alternative Flows:

1) The ITI-14 Proxy Actor is configured to filter(based on ITI-14 document metadata fields) some ITI-14 transactions out of the stream of ITI-14 transactions forwarded to the recipient(s).

2) The ITI-14 Proxy Actor is configured to remove or substitute data in ITI-14 document metadata fields with personal healthcare information that allows anonymization or pseudo-anonymization of ITI-14 metadata forwarded to the recipient(s).''

Postcondition: All document repositories in the affinity domain that generate an ITI-14 "Register Document Set" are now pointed to the ITI-14 Proxy Actor. When documents are registered by the document repository actors with the ITI-14 transaction, the transactions are routed to the document registry actor, but are also selectively routed to the Aggregator/Analyzer actor based on appropriate document types and other metadata information. In addition, the ITI-14 transactions forwarded to the recipient(s) are appropriately de-identified based on the policies and procedures of the affinity domain. The central audit server holds records of each transaction generated by the ITI-14 Proxy Actor."


==4. Standards & Systems==

''Applications that could include a Receive and Forward ITI-14 Proxy Actor are:

1) An independently installed application

2) An application that also includes an IHE Document Registry Actor

3) An application that also includes a new Aggregator/Analyzer''

''Relevant standard transactions:

1) IHE ATNA Secure Node

2) IHE ATNA Audit Trail

3) IHE Register Document Set (ITI-14)''


==5. Discussion==

''This proposal allows an addition of a new actor to IHE without disturbing any existing IHE integration profiles. This proposal also introduces a new actor to IHE without adding any new IHE transactions. Finally, this proposal describes a function that may be carried out at high volume within an affinity domain without degrading the performance of existing affinity domain actors (like a polling strategy would do). Although there are alternative models of achieving the same ends, an actor integration profile that provides minimal impact to IHE, to existing actors within IHE, and provides the needed functionality in supporting the quality domain seems optimal.''


==1. Proposed Workitem: '' Aggregator/Analyzer Actor''==

* Proposal Editor: ''Dan Russler''
* Editor: ''Dan Russler'' 
* Date:    N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Domain: ''Quality''

==2. The Problem==

''Document sharing has proven to be a highly effective model for sharing information for individual patient care. However, stored documents in multiple document repositories provide issues for the cross-population analysis of data. In accordance with the identification of the need by IHE in 2007 in the IHE Quality Technical Framework for an Aggregor/Analyzer Actor, this proposal is to implement an Aggegator/Analyzer Actor integration profile in 2008 for Connectathon testing in 2009.''


==3. Key Use Case==

''Precondition: An existing IHE affinity domain includes a central Patient Identity Manager, a central Document Registry, a central Audit Server, a central Time Server and multiple document repositories distributed among many institutions. The system administrator of the centralized data center and the privacy officer of the affinity domain wish to install a central document aggregator/analyzer for quality analysis as approved by the governing board of the affinity domain.

Activities: The privacy officer grants the system administrator a new TLS security certificate for the Aggregator/Analyzer Actor. The system administrator configures the Aggregator/Actor to receive ITI-14 Register Document Set transactions (see ITI-14 Proxy Actor for a new complementary integration profile). The Aggregator/Analyzer Actor receives ITI-14 Register Document Set transactions and uses the document location (s) within the ITI-14 transaction to generate HTTPs GET Document tranactions from the appropriate IHE Document Repository(ies) in the affinity domain. Once an IHE CDA document is retrieved, the CDA document is parsed and data from the CDA document is stored in the Analyzer data repository for analysis.

Alternative Flows:

1) The Aggregator/Analyzer Actor is configured to filter(based on ITI-14 document metadata fields) some documents, e.g. document types, out of documents retrieved from document repositories

2) The Aggregator/Analyzer Actor is configured to filter out and NOT store CDA documents that contain certain types of sensitive information based on information within the CDA document.

3) The Aggregator/Analyzer Actor is configured to remove or substitute data in CDA documents that contain personal healthcare information, which allows anonymization or pseudo-anonymization of the CDA documents ''

4) The Aggregator/Analyzer Actor is configured to remove or substitute data in data analysis fields that contain personal healthcare information, which allows anonymization or pseudo-anonymization of the analytic data''

5) The Aggregator/Analyzer Actor may respond to queries against the document collection or analytic data generated by other IHE actors

6) The Aggregator/Analyzer Actor may be configured to accept person ADT messages (create, split, merge, etc) in order to support both queries from other IHE actors and true population denominator calculations.

7) The Aggregator/Analyzer Actor may allow ETL procedures (extract, transform, and load) of data out of analytic fields and into other analytic schemas.


Postcondition: All document repositories in the affinity domain that generate an ITI-14 "Register Document Set" now are capable of providing documents to a central Aggregator/Analyzer Actor (assuming the Aggregator/Analyzer Actor is receiving all ITI-14 transactions). When documents are registered by the document repository actors with the ITI-14 transaction, the transactions are routed to the document registry actor, but are also routed to the Aggregator/Analyzer actor based on appropriate document types and other metadata information. The Aggregator/Analyzer has parsed all appropriate CDA documents and stored the appropriate data from within the CDA document in analytic fields. The Aggregator/Analyzer makes appropriate documents and analytic data available to other IHE actors. The central audit server holds records of each transaction by the Aggregator/Analyzer Actor."


==4. Standards & Systems==

''Applications that could include an Aggregator/Analyzer Actor are:

1) An independently installed application

2) An application that also includes an IHE Document Registry Actor

3) An application that also includes an IHE Document Repository

4) An application that also includes a new Receive and Forward ITI-14 Proxy Actor ''

''Relevant standard transactions:

1) IHE ATNA Secure Node

2) IHE ATNA Audit Trail

3) IHE Register Document Set (ITI-14)

4) IHE HTTPs Get Document ''


==5. Discussion==

''This proposal allows an addition of a new actor to IHE without disturbing any existing IHE integration profiles. This proposal also introduces a new actor to IHE without adding any new IHE transactions. Finally, this proposal describes a function that may be carried out at high volume within an affinity domain without degrading the performance of existing affinity domain actors (like a polling strategy would do). Although there are alternative models of achieving the same ends, an actor integration profile that provides minimal impact to IHE, to existing actors within IHE, and provides the needed functionality in supporting the quality domain seems optimal.''