Resource Evaluation Criteria
General Requirements
| 1.1 | Operating Systems supported | What operating systems are supported? |
| 1.2 | Databases supported | What database systems are supported? Is at least one Open Source database supported? |
| 1.3 | Data import/export | Is data import/export supported? What APIs or functions exist for this purpose? |
| 1.4 | Archiving requirements | Is the system capable of archiving for the number of years required by legislation? |
| 1.5 | Speed | The software should meet requirements with regard to speed of access and response time. It should also comply with volume transaction handling requirements. |
| 1.6 | Number of concurrent users supported | Does the application support the required number of users? Concurrent users are users that are logged on to the system at the same time. Does the licence agreement allow installation on any number of computers |
| 1.7 | System configuration | How much maintenance is required by the system. Are system admin processed such as database backup and archiving processes manual? |
| 1.8 | Alternate languiages | Is there support for multiple languages and how easy is this to configure? |
| 1.9 | Licensing | Is the software Open Source? Is the type of Open Source license acceptable? |
Admin and Security
| 2.1 | Compliance with HIPAA Security Rule | Does the software meet relevant regulatory compliance? |
| 2.2 | Passwords with customizable rules | Does the software support complex passwords and customizable rules around password length/change rules, etc.? |
| 2.3 | Individual and group security settings | Does the software use role based access control, with both individual and group settings? |
| 2.4 | DICOM 95 compliant audit trail | Does the software produce a DICOM 95 compliant audit trail? |
| 2.5 | Ease of customization | Does the software supply administration functionality in an easy to use format? |
Community and Support
| 3.1 | Activity of community/customer base | Does this software have an active user community, or a substantial customer base? |
| 3.2 | Backing for Open Source development | If Open Source, is development backed by a reputable company, or is it free-lance? |
| 3.3 | Number of upgrades/year | How often is the software updated? Is there a committment to provide bug fixes and patches? Are new features being added? |
| 3.4 | Stability | Assess the stability of the organization providing the product. How long have they been in business? How long have they been selling this type of software? When was this application first developed? How many local and international clients do they have for the application? |
| 3.5 | Upgrade path | For entry level packages, how accessible is the upgrade path? Can the advanced version be plugged into the architecture without significant rework? |
| 3.6 | Support available? | Is there support available for this software? A forum? Email support? Sufficient documentation? Service levels available? |
Cost Comparison
| 4.1 | Cost of Software | Is there a cost associated with this software? Is there a free version and an upgrade version? |
| 4.2 | Cost of Hardware (?) | |
| 4.3 | Effort of Implementation | How difficult is the implementation of this software? |
| 4.4 | Effort of Integration | How easy is the software to integrate? How much effort will be required to introduce this package into the HSPC architecture? |
| 4.5 | Effort for Customization | How easy is the software to customize? How much effort will there be to make this "fit for use" in HSPC? |
| 4.6 | Adopt/Adapt/Own | Are the three efforts above low enough that we can simply adopt the solution as is? If not, can we do some adaptation, and provide the adaptation back to the community? Will we have to assume ownership of the solution? |