User talk:Drussler
This is a template page. CLICK HERE if you're not sure how to use it.
DO NOT MODIFY this page unless you are changing the template for all future users.
This template is for one or two page IHE workitem proposals for initial review.
<Delete everything in italics and angle brackets and replace with real text>
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 a 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 Proxy Actor Integration Profile would allow a security and privacy administrator to install an application with the Proxy Actor who 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
<Describe a short use case scenario from the user perspective. The use case should demonstrate the integration/workflow problem.>
<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
<List existing systems that are/could be involved in the problem/solution.>
<If known, list standards which might be relevant to the solution>
5. Discussion
<Include additional discussion or consider a few details which might be useful for the detailed proposal>
- <Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>
- <What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>
- <What are some of the risks or open issues to be addressed?>
<This is the brief proposal. Try to keep it to 1 or at most 2 pages>