OMG HL7 Additional technical criteria for services selection

From: 
    Neeley, Marc (STL) 
      [SMTP:]   

  

    To: 
    ; 
        

  

    Cc: 
      

  

    

  

    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?