User talk:Drussler

From IHE Wiki
Jump to navigation Jump to search



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."

<Feel free to add a second use case scenario demonstrating how it “should” work. Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>


4. Standards & Systems

Applications that could include an 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 an IHE Aggregator/Analyzer Actor

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 integrationn profile that provides minimal impact to IHE, to existing actors within IHE, and provides the needed functionality in supporting the quality domain seems optimal.