Difference between revisions of "Relocatable Aplication Hosting in Radiology"
(New page: ==1. Proposed Workitem: Relocatable == * Proposal Editor: Chris Lindop * Editor: An Applications Development Engineer * Date: N/A (Wiki keeps history) * Version: N/A (Wiki keeps histor...) |
|||
| Line 1: | Line 1: | ||
| − | ==1. Proposed Workitem: Relocatable == | + | ==1. Proposed Workitem: Relocatable Hosted Applications in Radiology== |
* Proposal Editor: Chris Lindop | * Proposal Editor: Chris Lindop | ||
Revision as of 14:49, 13 September 2010
1. Proposed Workitem: Relocatable Hosted Applications in Radiology
- Proposal Editor: Chris Lindop
- Editor: An Applications Development Engineer
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
2. The Problem
In many Radiology environments today, there is a need to extend the functional capability of an imaging platform with capabilities provided by a seperate application. Many systems today provide hosting with proprietary API solutions. This requires an application developer to adapt their platform to each of the propriatry APIs developed by each of the hosting platform vendors. In many cases portability is inhibited by these propriatry methods.
3. Key Use Case
A Radiologist requires a new capability for prost-processing image analysis. The new capability is provided by only one application today. The application is installed easilly on the hosting platform that the Radiology uses everyday. The hosting platform and the hosted application are developed by 2 autonomous development groups. It's behaviour is seamless on the Radiologist hosting platform.
4. Standards and Systems
DICOM Supplement 118 Hosted Applications
5. Discussion
The key to making this profile effective is to define a minimum API set that would make a hosted application interoperable in any Radiology environment.