OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ihc message

[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 
Sent: 2/10/05 2:29 PM 
Importance: Normal 

All,
   As a follow-up to the Feb OMG meeting, Don Jorgenson (Eclipse) and myself agreed to take a shot at adding technical criteria to the list previously compiled by Bob Greenes. Below is that attempt under the heading of "Technical Criteria Candidates". Bob's initial list has been added for completeness and has an example added to the Business Case criteria that my help enforce that criteria. I have also attached an equivalent document should it help in expediting the exercise. Let me know if anyone has questions to the below content.

Marc Neeley
Express Scripts

<<ServicesSelectionCriteriaWithTech.doc>>



The list of proposed criteria are identified below:

1.  Business case:  demand for the service, clear niche/role/purpose in the marketplace.
(Supports national and international healthcare interoperability initiatives)

2.  User need:  sponsorship, importance to participant,
consistency/alignment with "day job"

3.  Clean interface: Ability to separate/differentiate the service from
existing products, clear responsibility and cohesive functionality

4.  Leverage potential:  Potential for seeding downstream service
development, or for bootstrapping a more complex effort with a simpler "toe in the water"

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
service, ability to serve as a model

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]