Pugh Matrix for Service Selection(1)

8/2/2019 Pugh Matrix for Service Selection(1)

1/46

Instructions for Using Pugh Matrix Template

1. Enter the Project Title, Date of Analysis, and Team Name at the top of the Matrix.2. Enter the Key Criteria for which the Design Concepts will be compared.3. The Blue Column (Column C) is for the Datum (often the Current) Design Concept.4. Enter the alternate Design Concept Names across Row 10.5. Rate the Design Concepts against the Baseline for each of the Key Criteria using the foll

++ Concept is Much Better Than the Baseline Concept+ Concept is Better Than the Baseline Concepts 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

to accept a long dash instead of a double dash and the user shouldNote that at if the ++ and -- symbols are entered without using a ' character, Exc 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 Pu


2/46

wing scale:

will prompt the userccept this change).

el will generate an error message.

h Matrix.


3/46

Date of Analysis: 4/5/2005

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

M P I / C o n s u m e r

/

P r o v

i d e r D

i r e c t o r y

R o

l e - B a s e

d Q u e r y

A c c e s s

( R B Q A )

T e r m

i n o

l o g y

L o c a

t o r

R e c o r d

R e

t r i e v a

l /

D o c u m

e n

t

E x c h a n g e

1 Business case D

2 Interest from potentialsubmitters.

A

3 Level of effort/complexity:

T

4 Granularity/scope: U

5 Applicability toimplementations of existing specifications:

M

6 Leverage potential:

7 Maturity level of relatedstandards:

8 Required level of adaptability

9 Complexity of scaling

10Relevance/relation toEHR functional model

11

Potential for reusability:generalizability,prototypical nature of service, ability to serve asa model

Key Criteria for Comparison

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

HL7/OMG Services Specification Project Team: HL7/OMG Health


4/46

12 Broad internationalrelevance:

13 Collaborativedevelopment appropriate:

14 Main requirement andsolution types:

15 High level of MDAexploitation possible:

16 Cohesion/coupling:

17 Shared or mediatedmodel?

18

User need: Sponsorship,importance to participant,consistency/alignment

with "day job"

19

20

21

Selection Option Research Notes

Criteria Concept 1Business case: demand for the service, clear niche/role/purpose in the marketplace. (Supports national and inte

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 initia

Pros:

Cons:


5/46

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

Pros:

Cons:

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

Pros:

Cons:

Criteria Concept 6 Leverage potential: Potential for seeding downstream service development, or for bootstrapping a more comple

Pros:

Cons:

Criteria Concept 7 Maturity level of related standards: While targeted services may have a reasonable business model to be applie

Pros:

Cons:

Criteria Concept 8 Required level of adaptability -fixed vs. extensible set of functionality, data/information separated from functionali

Pros:

Cons:

Criteria Concept 9 Complexity of scaling: Consider the complexity implications by answering questions such as the following: As th

Pros:

Cons:

Criteria Concept 10

Relevance/relation to EHR functional model

Pros:

Cons:

Criteria Concept 11Potential for reusability: generalizability, prototypical nature of service, ability to serve as a model


6/46

Pros:

Cons:

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

Pros:

Cons:

Criteria Concept 13 Collaborative development appropriate: For example, infrastructure-type services that are widely required are be

Pros:

Cons:

Criteria Concept 14 Main requirement and solution types: -information-, computation-, process (coordination) or user-oriented (e.g. p

Pros:

Cons:

Criteria Concept 15 High level of MDA exploitation possible: It may be desirable to minimize the manual intervention required to gene

Pros:

Cons:

Criteria Concept 16 Cohesion/coupling: use of references vs. "pass-by-value", invocation style, service availability requirements, intr

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:


7/46


8/46


9/46


10/46


11/46


12/46


13/46

0 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 0

H S S - 6

H S S - 7

H S S - 8

H S S - 9

han Datum Concept, (s) = Concept is the Same once

are Domain Task Force


14/46

rnational healthcare interoperability initiatives)

l Services Project


15/46

ality to be useful and - Clean interface: Ability to separate/differentiate the service from existing prod

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

effort with a simpler "toe in the water"

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

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

service scales or extends across organization or regional boundaries, does complexity increase? Can


16/46

international-specific encoding (i.e. Unicode, Java localization, C++ localization, etc.) These improvem

st developed jointly resulting in more robust specifications.

rtal) services? selection of main approach, perhaps different types should be selected for first candidat

rate platform specific implementations, e.g. by limiting platform-specific dependencies. Tools to suppor

vs. inter-organizational integration, number of participants, state management. Also related to "shared


17/46


18/46


19/46


20/46


21/46


22/46


23/46


24/46


25/46

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

ical implementations of a given service (i.e. Security standards). If those standards have not matured to

he service scale and interoperate from local to regional to national and still share a common requestor i


26/46

ents have matured into many tooling products and will assist in generating international variants of the n

s)

the automated generation of PIMs may not be available for certain model structures or more complex

or mediated" and "adaptability" questions.


27/46


28/46


29/46


30/46


31/46


32/46


33/46


34/46


35/46

the point of having legitimate tooling available for a successful implementation then this may or may no

mplementation? Are provisioning services or federation services for target aggregation required as the


36/46

ecessary MDA models. Those services that will have heavy international variation in their implementati

odel elements.


37/46


38/46


39/46


40/46


41/46


42/46


43/46


44/46


45/46

t be a good selection.

ervice is scaled across organizations?


46/46

ns may benefit more from these capabilities.

Pugh Matrix for Service Selection(1)

Documents

Transcript of Pugh Matrix for Service Selection(1)