Instructions for Using Pugh Matrix Template

1. 2. 3. 4. 5.

Enter the Project Title, Date of Analysis, and Team Name at the top of the Matrix. Enter the Key Criteria for which the Design Concepts will be compared. The Blue Column (Column C) is for the Datum (often the Current) Design Concept. Enter the alternate Design Concept Names across Row 10. Rate the Design Concepts against the Baseline for each of the Key Criteria using the following scale: ++ Concept is Much Better Than the Baseline Concept + Concept is Better Than the Baseline Concept s Concept is the Same as the Baseline Concept Concept is Worse Than the Baseline Concept -Concept is Much Worse Than the Baseline Concept (Note that Excel will prompt the user to accept a long dash instead of a double dash and the user should accept this change). Note that at if the ++ and -- symbols are entered without using a ' character, Excel will generate an error Just click "OK" or enter these two symbls using a ' mark. EG: '++ or '--. 6. The Sums will automatically total for you at the top of the matrix. 7. Enter your Research notes in the "Design Option Research Notes" section below the Pugh Matrix.

using the following scale:

ote that Excel will prompt the user user should accept this change). haracter, Excel will generate an error message.

below the Pugh Matrix.

HL7/OMG Services Specification

Date of Analysis: 4/5/2005

Project Team: HL7/OMG Healthcare Domai

Design Concept Rating Scale: (++) = Concept is Much Better Than Datum Concept, (+) = Concept is Better Than Datum Con as Datum Concept, (--) = Concept is Much Worse Than Datum Concept, (-) = Concept is Worse Than Datum Conce

Net Process Total Sum of M. Better (++) Sum of Better (+) Sum of "Same" (s) Sum of Worse (-) Sum of M. Worse (--)

0 0 0 0 0 0 MPI / Consumer / Provider Directory

0 0 0 0 0 0 Role-Based Query Access (RBQA)

0 0 0 0 0 0 Terminology

0 0 0 0 0 0

0 0 0 0 0 0 Record Retrieval / Document Exchange

Key Criteria for Comparison

1 2 3 4 5 6 7 8 9 10

Business case Interest from potential submitters. Level of effort/complexity: Granularity/scope: Applicability to implementations of existing specifications: Leverage potential: Maturity level of related standards: Required level of adaptability Complexity of scaling Relevance/relation to EHR functional model Potential for reusability: generalizability, prototypical nature of service, ability to serve as a model

D A T U M

11

Locator

12 13 14 15 16 17

Broad international relevance: Collaborative development appropriate: Main requirement and solution types: High level of MDA exploitation possible: Cohesion/coupling: Shared or mediated model? User need: Sponsorship, importance to participant, consistency/alignment with "day job"

18

19 20 21

Selection Option Research Notes

Criteria Concept 1 Business case: demand for the service, clear niche/role/purpose in the marketplace. (Supports national and international healt Pros: Cons: Criteria Concept 2 Likelihood of gaining interest from potential submitters. Pros: Cons:

Criteria Concept 3 Level of effort/complexity: Feasibility, success potential, ability to be completed within the time frame of the initial Services Proj Pros: Cons:

Criteria Concept 4 Granularity/scope: Appropriate level of definition to be able to grasp functionality, yet encompass enough functionality to be use Pros: Cons:

Criteria Concept 5 Applicability to implementations of existing specifications: Some services have enjoyed a healthier adoption and implementation Pros: Cons:

Criteria Concept 6 Leverage potential: Potential for seeding downstream service development, or for bootstrapping a more complex effort with a s Pros: Cons:

Criteria Concept 7 Maturity level of related standards: While targeted services may have a reasonable business model to be applied to, there may Pros: Cons:

Criteria Concept 8 Required level of adaptability -fixed vs. extensible set of functionality, data/information separated from functionality (or not), me Pros: Cons:

Criteria Concept 9 Complexity of scaling: Consider the complexity implications by answering questions such as the following: As the service scale Pros: Cons: Criteria Concept 10 Relevance/relation to EHR functional model Pros: Cons: Criteria Concept 11 Potential for reusability: generalizability, prototypical nature of service, ability to serve as a model

Pros: Cons:

Criteria Concept 12 Broad international relevance: There have been major technical improvements in reducing the burden of handling internationalPros: Cons:

Criteria Concept 13 Collaborative development appropriate: For example, infrastructure-type services that are widely required are best developed jo Pros: Cons:

Criteria Concept 14 Main requirement and solution types: -information-, computation-, process (coordination) or user-oriented (e.g. portal) services? Pros: Cons:

Criteria Concept 15 High level of MDA exploitation possible: It may be desirable to minimize the manual intervention required to generate platform s Pros: Cons:

Criteria Concept 16 Cohesion/coupling: use of references vs. "pass-by-value", invocation style, service availability requirements, intra vs. inter-orga Pros: Cons: Criteria Concept 17 Shared or mediated model? For example, centralized terminology service or terminology mediation service? Pros: Cons: Criteria Concept 18 User need: sponsorship, importance to participant, consistency/alignment with "day job" Pros: Cons:

ation

MG Healthcare Domain Task Force

cept is Better Than Datum Concept, (s) = Concept is the Same Than Datum Conce

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

HSS-6

HSS-7

HSS-8

HSS-9

onal and international healthcare interoperability initiatives)

e of the initial Services Project

ough functionality to be useful and - Clean interface: Ability to separate/differentiate the service from existing products, clear responsibility

doption and implementation history and thus have reasonable familiarity within the technical community.

more complex effort with a simpler "toe in the water"

to be applied to, there may be fluctuating or incomplete technical standards that would likely be needed for the technical implementations of

m functionality (or not), meta-level or exact content definitions?

owing: As the service scales or extends across organization or regional boundaries, does complexity increase? Can the service scale and in

en of handling international-specific encoding (i.e. Unicode, Java localization, C++ localization, etc.) These improvements have matured into

quired are best developed jointly resulting in more robust specifications.

ented (e.g. portal) services? selection of main approach, perhaps different types should be selected for first candidates)

uired to generate platform specific implementations, e.g. by limiting platform-specific dependencies. Tools to support the automated generat

rements, intra vs. inter-organizational integration, number of participants, state management. Also related to "shared or mediated" and "adap

existing products, clear responsibility and cohesive functionality (these two previous criteria have been merged)

for the technical implementations of a given service (i.e. Security standards). If those standards have not matured to the point of having legi

rease? Can the service scale and interoperate from local to regional to national and still share a common requestor implementation? Are pro

se improvements have matured into many tooling products and will assist in generating international variants of the necessary MDA models.

first candidates)

ols to support the automated generation of PIMs may not be available for certain model structures or more complex model elements.

d to "shared or mediated" and "adaptability" questions.

ot matured to the point of having legitimate tooling available for a successful implementation then this may or may not be a good selection.

n requestor implementation? Are provisioning services or federation services for target aggregation required as the service is scaled across

iants of the necessary MDA models. Those services that will have heavy international variation in their implementations may benefit more fro

re complex model elements.

ay or may not be a good selection.

uired as the service is scaled across organizations?

mplementations may benefit more from these capabilities.