[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OMG HL7 Additional technical criteria for services selection
From: | Neeley, Marc (STL) [SMTP:marc.neeley@express-scripts.com] | ||
To: | servicesbof@lists.hl7.org; healthcare@omg.org | ||
Cc: | greenes@harvard.edu | ||
Subject: | Additional technical criteria for services selection | ||
All, Marc Neeley <<ServicesSelectionCriteriaWithTech.doc>> The list of proposed criteria are identified below: 1. Business case:
demand for the service, clear niche/role/purpose in the
marketplace. 2. User need:
sponsorship, importance to participant, 3. Clean interface: Ability
to separate/differentiate the service from 4. Leverage potential:
Potential for seeding downstream service 5. Granularity/scope: Appropriate level of definition to be able to grasp functionality, yet encompass enough functionality to be useful 6. Level of effort/complexity: Feasibility, success potential, ability to be completed within the time frame of the initial Services Project 7. Relevance/relation to EHR functional model 8. Potential for reusability:
generalizability, prototypical nature of Technical Criteria Candidates: Applicability to implementations of existing specifications: Some services have enjoyed a healthier adoption and implementation history and thus have reasonable familiarity within the technical community. Maturity level of related standards: While targeted services may have a reasonable business model to be applied to, there may be fluctuating or incomplete technical standards that would likely be needed for the technical implementations of a given service (i.e. Security standards). If those standards have not matured to the point of having legitimate tooling available for a successful implementation then this may or may not be a good selection. Broad international relevance: There have been major technical improvements in reducing the burden of handling international-specific encoding (i.e. Unicode, Java localization, C++ localization, etc.) These improvements have matured into many tooling products and will assist in generating international variants of the necessary MDA models. Those services that will have heavy international variation in their implementations may benefit more from these capabilities. High level of MDA exploitation possible: It may be desirable to minimize the manual intervention required to generate platform specific implementations, e.g. by limiting platform-specific dependencies. Tools to support the automated generation of PIMs may not be available for certain model structures or more complex model elements. Collaborative development appropriate: For example, infrastructure-type services that are widely required are best developed jointly resulting in more robust specifications. Complexity of scaling: Consider the complexity implications by answering questions such as the following: As the service scales or extends across organization or regional boundaries, does complexity increase? Can the service scale and interoperate from local to regional to national and still share a common requestor implementation? Are provisioning services or federation services for target aggregation required as the service is scaled across organizations? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]