Roles played by the date dimensin

Accumulating snapshot fact tables always involve multiple date stamps. Our
example, which is typical, has seven foreign keys pointing to date dimensin.
This a good place to reiterate several important points:
-

The foreign keys in the fact table cannot be actual date stamps because
they have to handle the not applicable case. The foreign keys should
be simple integers serving as surrogate keys.
The surrogate keys assigned in the date dimension should be assigned
consecutively in order of date. This is the only dimension where the
surrogate keys have any relationship to the underlying semantics of the
dimension. We do this so that physical partitioning of a fact table can be
accomplished by using one of the date-based foreign keys. In our
example we recommend that the treatment date key be used as the
basis for physically partitioning the fact table.
Surrogate keys corresponding to special conditions such as not
applicable, Corrupted, or Hasnt happened yet should assigned to
the top end of numeric range so that these rows are physically
partitioned together in the hot partition with the most recent data. We do
this if these rows are ones that are expected to change.
We do not join the seven date-based foreign keys to a single instance of
the date dimension table. Such a join would demand that all seven dates
were the same date. Instead, we crate seven views on the single
underlying date dimension table, and we join the fact table separately to
these seven views, just as if they were seven independent. We refer to
these seven views as roles played by the date dimension table.
The seven view definitions using the date dimension table should
cosmetically relabel the column names of each view to be
distinguishable so that query tolos directly accessing the views will
present the column names through the user interface in a way that is
inderstandable to the end user.

Although the role-playing behavior of the date dimension is very

characteristic of accumulating snapshot fact tables, other dimensions often
play roles in similar ways, such as the payer dimension in Figure 13.2. Later
in this chapter we will see how the physician dimension needs to have
several roles in complex surgical procedures depending on whether the
physician is the primary responsible physician, working in a consulting
capacity, or working in an assisting capacity.

Multivalued diagnosis dimension

Normally we choose the dimensions surrounding a fact table row by asking,
what do we know to be true in the context of the measurement? If
something has many values in the context of the measurement, we almost
always disqualify that dimension because the many-valuedness means that
the offending dimension belongs at a lower grain of measurement.

However, there are a few situations in which the many-valuedness is natural

and unavoidable, and we do want to include such a dimension in our design,
such as the case when we associated multiple customers with an account in
chapter 9. The diagnosis dimension in our health care billing fact table is
another good example. At the momento of treatment, the patient has one or
more diagnoses along with the billing row.
If there were always a mximum of three diagnoses, for instance, we might
be tempted to create three diagnosis dimensions, almost as if they were
roles. However, diagnoses dont behave like roles. Unfortunately, there are
often more tan three diagnoses, especially for elderly patients who are
hospitalized. Real medical bill-playing organizations sometimes encounter
patients with more than 50 diagnoses! Also, the diagnoses dont fi tinto
well-defined roles other than possibly admitting diagnosis and discharging
diagnosis. The role-playing dimensions we talked about in the preceding
section are categorized much more naturally and disjointly. Finalle, the
multiple-slots style of design makes for very inefficient applications because
the query doesnt know a priori which dimensional slor to constrain for a
particular diagnosis.
We handle the open-ended nature of multiple diagnoses with the design
shown in figure 13.3. We replace the diagnosis foreign key in the fact table
with a diagnosis group key. This diagnosis group key is connected by a
many-to-many join to a diagnosis group bridge table, which contains a
separate row for each diagnosis in a particular group.
If a patient has three diagnoses, then that patient is assigned a diagnosis
group with three diagnoses. We assign a numerical weighting factor to each
diagnosis in the group such that the sum of all the weighting factors in the
group is exactly 1.00. We can then use the weighting factors to allocate any
of the numeric additive facts across individual diagnoses. In this way we can
add up all billed amounts by diagnosis, and the grand total will be the
correct grand total billed amount. This kind of report would be called a
correctly weighted report.
We see that the weighting factors are simply a way to allocate the numeric
additive facts across the diagnoses. Some would suggest that we change
the grain of the fact table to be line item by diagnosis rather than just line
item. In this case we would take the weighting factors and physically
multiply them against the original numeric facts. This is done rarely, for
three reasons. First, the size of the fact table would be multiplied by the
average number of diagnoses. Second, in some fact tables we have more
than one multivalued dimension. The number of rows would get out of hand
in this situation, and we would start to question the physical significance of
an individual row. Finally, we may want to see the unallocated numbers, and
it is hard to reconstruct these if the allocations have been combined
physically with the numeric facts.

If we choose not to apply the weighting factors in a given query, we can still
summarize billed amounts by diagnosis, but in this case we get what is
called an impact report. A question such as What is the total billed amount
across all possible treatments in any way involving the diagnosis of XYZ?
would be an example of an impact report.
In Figure 13.3, an SQL view could be defined combining the fact table and
the diagnosis group bridge table so that these two tables, when combined,
would appear to data access tools as a standard fact table with a normal
diagnosis foreign key. Two views could be defined, one using the weighting
factors and one not using the weighting factors.

Finally, if the many-to-many join in Figure 13.3 causes problems for your
modeling tool that insists on proper foreign-key-to-primary-key
relationships, the equivalent design of Figure 13.4 can be used. In this case
an extra table whose primary key is diagnosis group is inserted between the
fact table and the bridgetable. Now both the fact table and the bridge table
have conventional many-to-one joins in all directions. There is no new
information in this extra table.
In the real world, a bill-paying organization would decide how to administer
the diagnosis groups. If a unique diagnosis group were created for every
out-patient treatment, the number of rows could become astronomical and
unworkable. Probably the best approach is to have a standard portfolio of
diagnosis groups that are used repeatedly. This requires that each set of
diagnoses be looked up in the master diagnosis group table. If the existing
group is found, it is used. If it is not found, then a new diagnosis group is
created.
In a hospital stay situation, however, the diagnosis group probably should
be unique to the patient because it is going to evolve over time as a type 2
slowly changing dimension (SCD). In this case we would supplement the
bridge table with two date stamps to capture begin and end dates. While
the twin date stamps complicate the update administration of the diagnosis
group bridge table, they are very useful for querying and change tracking.
They also allow us to perform time-span queries, such as identifying all
patients who presented a given diagnosis at any time between two dates.
To summarize this discussion of multivalued dimensions, we can list the
issues surrounding a multivalued dimension design:
-

In the context of the fact table measurement, the multivalued dimension

takes on a small but variable number of well-defined values.
Correctly allocated reports can be created only if weighting factors can
be agreed to.
Weighting factors can be omitted, but then only impact reports can be
generated using the multivalued dimension.

In high-volume situations such as medical bills and bank accounts, a

system of recognizing and reusing groups should be used.
In cases where the relationship represented in the bridge table changes
over time, we embellish the bridge table with begin and end dates.

Extending a billing fact table to show profitability

Figure 13.5 shows an extended set of facts that might be added to the basic
billing schema of Figure 13.2. These include the consumables cost, provider
cost, assistant cost, equipment cost, location cost, and net profit before general
and administrative (G&A) expenses, which is a calculated fact. If these
additional facts can be added to the billing schema, the power of the fact table
grows enormously. It now becomes a full-fledged profit-and-loss (P&L) view of
the health care business.
These costs are not part of the billing process and normally would not be
collected at the same time as the billing data. Each of these costs potentially
arises from a separate source system. In order to bring this data into the billing
fact table, the separately sourced data would have to be allocated down to the
billing line item. For activity-based costs such as the ones we have included in
the list, it may be worth the effort to do this allocation. All allocations are
controversial and to an extent arbitrary, but if agreement can be reached on
the set of allocations, the P&L database that results is incredibly powerful. Now
the health care organization can analyze profitability by all the dimensions!

Dimensions for billed hospital stays

The first part of this chapter described a comprehensive and flexible design for
billed health care treatments that would cover both inpatient and outpatient
bills. If an organization wished to focus exclusively on hospital stays, it would
be reasonable to tweak the dimensional structure of Figure 13.2 to provide
more hospital-specific information. Figure 13.6 shows a revised set of
dimensions specialized for hospital stays, with the new dimensions set in bold
type.
In Figure 13.6 we show two roles for provider: admitting provider and attending
provider. We show provider organizations for both roles because providers may
represent different organizations in a hospital setting.
We also have three multivalued diagnosis dimensions on each billed treatment
row. The admitting diagnosis is determined at the beginning of the hospital
stay and should be the same for every treatment row that is part of the same
hospital stay. The current diagnosis describes the state of knowledge of the
patient at the time of the treatment. The discharge diagnosis is not known until

the patient is discharged and is applied retroactively to all the rows that have
been entered as part of the hospital stay.

Complex health care events

In a hospital setting, we may want to model certain very complex events, such
as major surgical procedures. In a heart-transplant operation, whole teams of
specialists and assistants are assembled for this one event. A different heart
transplant may involve a team with a different makeup.
We can model these complex events with the design shown in Figure 13.7. We
combine the techniques of role-playing dimensions and multivalued
dimensions. We assume that a surgical procedure involves a single responsable
physician and variable numbers of attending physicians, assisting
professionals, procedures, and equipment types. We also assume that the
patient has a multivalued diagnosis before the surgery and a separate
multivalued diagnosis after the surgery.
Thus we have six multivalued dimensions, indicated by the bold type in Figure
13.7. The responsible physician, attending physician, and assisting professional
dimensions are all roles played by an overall provider dimension. The
presurgery and postsurgery multivalued diagnosis dimensions are roles played
by a single diagnosis dimension.
Since the grain of the fact table is the surgical procedure itself, it is natural to
supply a comprehensive set of facts. We show the extended set of facts that
would allow a complete P&L analysis to be done on surgical procedures,
assuming that the various costs can be allocated to each surgical event.
We leave out the weighting factors on all the multivalued dimensions in this
design. If we tried to provide weighting factors for the multivalued dimensions,
we would be implicitly supporting all the complex combinations of weighting
values, some of which would be nonsensical. It doesnt seem worth the trouble
to claim that the correctly allocated portion of the total billed amount of the
surgery conjointly assigned to each possible assistant and each possible piece
of equipment has much meaning. Our technique of placing the weighting
factors independently in each dimension is only part of the problem. A more
practical concern is that most organizations would not be willing to assign
dozens or hundreds of weighting factors.
Without the weighting factors, we nevertheless can create many useful impact
reports. For instance, what is the total value of all surgeries performed that
used a heart-lung machine? We also can ask which physicians, which assisting
professionals, and which pieces of equipment were involved in various kinds of
surgery. And finally, if we have allocated the costs to each surgery in a rational
way, we can ask which types of surgery are profitable or nonprofitable and why.

Funciones desempeadas por la fecha dimensin

La acumulacin de tablas de hechos instantnea siempre involucra mltiples
sellos de fecha. Nuestro ejemplo tiene siete claves forneas apuntando a la
fecha dimensin. Este es un buen lugar para reiterar varios puntos
importantes:
- Las claves externas de la tabla de hechos no pueden ser sellos de fecha
reales porque tienen que manejar el caso "no aplicable". Las claves externas
deben ser enteros simples que sirven como teclas sustitutas.
- Las claves suplentes asignados en la dimensin fecha deben ser asignados de
forma consecutiva en el orden de la fecha. Esta es la nica dimensin donde
las claves sustitutas tienen ninguna relacin con la semntica subyacente de la
dimensin. Hacemos esto para que la compartimentacin fsica de una tabla de
hechos se puede lograr mediante el uso de una de las claves externas basadas
en fechas. En nuestro ejemplo se recomienda que la fecha clave del
tratamiento se utiliza como base para dividir fsicamente la tabla de hechos.
- Claves suplentes correspondientes a condiciones especiales, tales como "no
aplicable", "corrupto", o "no ha sucedido todava" debe asignada al extremo
superior del rango numrico para que estas filas se dividen fsicamente juntos
en la particin caliente con los ms datos recientes. Hacemos esto si estas filas
son los que se espera que cambien.
- No unimos a las siete claves externas basadas en fechas a una sola instancia
de la tabla de dimensiones fecha. Tal unen exigira que todos los siete fechas
eran la misma fecha. En su lugar, creamos siete puntos de vista sobre la tabla

de dimensiones de fecha subyacente sola, y nos unimos a la tabla de hechos

por separado a estos siete puntos de vista, al igual que si fueran siete
independiente. Nos referimos a estos siete puntos de vista como funciones
desempeadas por la tabla de dimensiones fecha.
- Los siete definiciones de vista utilizando la tabla de dimensiones fecha debe
etiquetar cosmticamente los nombres de columna de cada fin de poder
distinguirse de manera que consulta Tolos accediendo directamente a los
puntos de vista se presentarn los nombres de columna a travs de la interfaz
de usuario de una manera que es inderstandable al usuario final.
Aunque el comportamiento de rol de la dimensin fecha es muy caracterstico
de la acumulacin de las tablas de hechos de instantnea, otras dimensiones a
menudo desempean un papel de manera similar, como la dimensin pagador
en la figura 13.2. Ms adelante en este captulo veremos cmo la dimensin
mdico necesita tener varios papeles en procedimientos quirrgicos complejos,
dependiendo de si el mdico es el mdico responsable primario, trabajando en
calidad de consultor, o trabajar en una capacidad de asistencia.
Dimensin diagnstico multivalor
Normalmente elegimos las dimensiones que rodean una fila de tabla hecho
preguntando, qu sabemos para ser verdad en el contexto de la medicin? Si
algo tiene muchos valores en el contexto de la medicin, que casi siempre
descalificar a esa dimensin porque el de muchos valuedness significa que la
dimensin infractor pertenece a un grano inferior de medicin.
Sin embargo, hay algunas situaciones en las que los muchos-valuedness Es
natural e inevitable, y que quieren incluir una dimensin tal en nuestro diseo,
como es el caso cuando nos asociamos mltiples clientes con una cuenta en el
captulo 9. La dimensin diagnstico en nuestra tabla de hechos de facturacin
atencin de la salud es otro buen ejemplo. En el Momento de tratamiento, el
paciente tiene uno o ms diagnsticos junto con la fila de facturacin.
Si siempre haba un mximo de tres diagnsticos, por ejemplo, podramos estar
tentados a crear tres dimensiones de diagnstico, casi como si fueran papeles.
Sin embargo, los diagnsticos No te comportarse como roles. Por desgracia, a
menudo hay ms bronceado tres diagnsticos, especialmente para los
pacientes de edad avanzada que estn hospitalizados. Organizaciones de
facturas de papeles mdicos reales a veces se encuentran los pacientes con
ms de 50 diagnsticos! Adems, los diagnsticos no fi papeles tinto bien
definidos que no sean posiblemente admitir diagnstico y descarga de
diagnstico. Las dimensiones de rol de las que hablamos en la seccin anterior
se clasifican mucho ms natural y no conjuntamente. Finalmente, el estilomltiples ranuras de diseo hace para aplicaciones muy ineficientes porque la
consulta no sabe que valor dimensional priori para limitar para un diagnstico
particular.
Nos encargamos de la naturaleza abierta de mltiples diagnsticos con el
diseo que se muestra en la figura 13.3. Reemplazamos la clave externa
diagnstico en la tabla de hechos con una tecla de grupo diagnstico. Esta

tecla grupo de diagnstico est conectado por un muchos-a-muchos se unen a

una mesa de bridge grupo de diagnstico, que contiene una fila separada para
cada diagnstico de un grupo particular.
Si un paciente tiene tres diagnsticos, entonces ese paciente se le asigna un
grupo de diagnstico con tres diagnsticos. Se asigna un factor de ponderacin
numrica a cada diagnstico en el grupo de tal manera que la suma de todos
los factores de ponderacin en el grupo es exactamente 1,00. A continuacin,
podemos utilizar los factores de ponderacin para asignar cualquiera de los
hechos a travs de aditivos numricos diagnsticos individuales. De esta
manera podemos sumar todas las cantidades facturadas por el diagnstico y el
total ser el importe de la factura total correcto. Este tipo de informe se
llamara un informe correctamente ponderada.
Vemos que los factores de ponderacin son simplemente una manera de
asignar los hechos aditivos numricos a travs de los diagnsticos. Algunos
podran sugerir que cambiamos el grano de la tabla de hechos para ser partida
por el diagnstico en lugar de slo artculo de lnea. En este caso tomaramos
los factores de ponderacin y fsicamente multiplicar en contra de los hechos
numricos originales. Esto se hace rara vez, por tres razones. En primer lugar,
el tamao de la tabla de hechos se multiplica por el nmero medio de
diagnsticos. En segundo lugar, en algunas tablas de hechos que tenemos ms
de una dimensin de varios valores. El nmero de filas podra ir de las manos
en esta situacin, y nos gustara empezar a cuestionar el significado fsico de
una fila individual. Por ltimo, es posible que queremos ver los nmeros
asignados, y es difcil de reconstruir estos si las asignaciones se han
combinado fsicamente con los hechos numricos.
Si no optamos por aplicar los factores de ponderacin en una determinada
consulta, todava podemos resumir cantidades facturadas por el diagnstico,
pero en este caso podemos obtener lo que se llama un informe de impacto.
Una pregunta como "Cul es el monto total facturado en todos los
tratamientos posibles en cualquier direccin, que implica el diagnstico de
XYZ?" Sera un ejemplo de un informe de impacto.
En la Figura 13.3, una vista SQL se podra definir la combinacin de la tabla de
hechos y de la mesa de bridge grupo de diagnstico de manera que estas dos
tablas, cuando se combinan, pareceran herramientas de acceso a datos como
una tabla de hechos de serie con una clave externa diagnstico normal. Dos
puntos de vista pueden ser definidos, uno utilizando los factores de
ponderacin y no utilizando los factores de ponderacin.

Por ltimo, si los muchos-a-muchos se unen en la figura 13.3 provoca

problemas para su herramienta de modelado que insiste en buen extranjeraclave-para-clave primaria-relaciones, el diseo equivalente de la figura 13.4 se
puede utilizar. En este caso se inserta una tabla extra cuya principal clave es el
diagnstico de grupo entre la tabla de hechos y la bridge table. Ahora, tanto la

tabla de hechos y de la mesa de bridge tienen uno de varios a convencional

une en todas las direcciones. No hay nueva informacin en esta tabla extra.
En el mundo real, una organizacin de pago de facturas decidira la forma de
administrar los grupos de diagnstico. Si un grupo de diagnstico nica se crea
para cada tratamiento ambulatorio, el nmero de filas podra convertirse
astronmica e inviable. Probablemente el mejor enfoque es tener una cartera
estndar de grupos de diagnstico que se utilizan repetidamente. Esto requiere
que cada conjunto de diagnsticos se buscar en la tabla del grupo diagnstico
principal. Si se encuentra el grupo existente, que se utiliza. Si no se encuentra,
a continuacin, se crea un nuevo grupo de diagnstico.
En una situacin de estancia en el hospital, sin embargo, el grupo de
diagnstico, probablemente, debe ser nico para el paciente, ya que va a
evolucionar con el tiempo como el tipo 2 que cambia lentamente dimensin
(SCD). En este caso tendramos complementar la tabla del puente con dos
sellos de fecha para capturar fechas de inicio y final. Mientras que las marcas
de fecha gemelas complican la administracin actualizacin de la mesa de
bridge grupo de diagnstico, que son muy tiles para la consulta y el
seguimiento de cambios. Tambin nos permiten realizar consultas lapso de
tiempo, tales como la identificacin de todos los pacientes que presentaron un
diagnstico dado en cualquier momento entre dos fechas.
Para resumir esta discusin de las dimensiones de varios valores, podemos
enumerar los problemas que rodean un diseo dimensin de varios valores:
- En el contexto de la tabla de la medida hecho, la dimensin multivalor toma
en una pequea pero variable nmero de valores bien definidos.
- Informes asignados correctamente slo se pueden crear si los factores de
ponderacin pueden ser acordados.
- Los factores de ponderacin se pueden omitir, pero luego slo los informes de
impacto se pueden generar utilizando la dimensin de varios valores.
- En situaciones de alto volumen, tales como facturas mdicas y cuentas
bancarias, se debe utilizar un sistema de reconocimiento y grupos reutilizacin.
- En los casos en que la relacin se representa en la tabla del puente cambia
con el tiempo, adornamos la tabla del puente con fechas de inicio y final.

Prolongacin de una tabla de hechos de facturacin para mostrar la

rentabilidad

La figura 13.5 muestra un conjunto extendido de hechos que puedan aadirse

al esquema de facturacin bsica de la figura 13.2. Estos incluyen el costo de
consumibles, costo proveedor, costo asistente, el coste del equipo, el costo
ubicacin, y el beneficio neto antes de los gastos generales y administrativos
(G & A), que es un hecho calculada. Si estos hechos adicionales se pueden
aadir al esquema de facturacin, el poder de la tabla de hechos crece
enormemente. Ahora se convierte en una de prdidas y ganancias de pleno
derecho (P & L) vista del negocio de cuidado de la salud.
Estos costes no son parte del proceso de facturacin y normalmente no seran
recogidos al mismo tiempo que los datos de facturacin. Cada uno de estos
costos potencialmente surge a partir de un sistema de origen independiente.
Con el fin de llevar estos datos en la tabla de hechos de facturacin, los datos
de origen por separado tendran que ser asignado a la lnea de facturacin.
Para los costos basados en actividades como las que hemos incluido en la lista,
puede valer la pena el esfuerzo para hacer esta asignacin. Todas las
asignaciones son controvertidos y en una medida arbitraria, pero si se alcanza
un acuerdo sobre el conjunto de asignaciones, la base de datos P & L que
resulta es increblemente poderoso. Ahora la organizacin de salud puede
analizar la rentabilidad por todas las dimensiones!

Dimensiones para estancias hospitalarias facturados

La primera parte de este captulo se describe un diseo integral y flexible para
tratamientos de cuidado de la salud facturados que cubriran ambos proyectos
de ley para pacientes hospitalizados y ambulatorios. Si una organizacin desea
centrarse exclusivamente en las estancias hospitalarias, sera razonable para
modificar la estructura tridimensional de la figura 13.2 para proporcionar ms
informacin hospitalaria especfica. La figura 13.6 muestra un conjunto
revisado de dimensiones especializada para estancias en el hospital, con las
nuevas dimensiones en letra negrita.
En la figura 13.6 se muestran dos funciones para el proveedor: proveedor de
admisin y que asisten a proveedor. Mostramos organizaciones de proveedores
para ambos papeles porque los proveedores pueden representar diferentes
organizaciones en un entorno hospitalario.
Tambin tenemos tres dimensiones de diagnstico de varios valores en cada
fila tratamiento facturado. El diagnstico de admisin se determina al
comienzo de la estancia hospitalaria y debe ser el mismo para cada fila de
tratamiento que es parte de la misma estancia en el hospital. El diagnstico
actual describe el estado de conocimiento de la paciente en el momento del
tratamiento. El diagnstico de alta no se conoce hasta que el paciente es dado
de alta y se aplica retroactivamente a todas las filas que se han introducido
como parte de la estancia en el hospital.

Eventos de atencin mdica complejas

En un hospital, podemos querer modelar ciertos eventos muy complejos, como

procedimientos quirrgicos mayores. En una operacin de trasplante de
corazn, equipos enteros de especialistas y asistentes se ensamblan para ste
evento. Un diferente trasplante de corazn puede involucrar un equipo con un
maquillaje diferente.
Podemos modelar estos eventos complejos con el diseo mostrado en la figura
13.7. Combinamos las tcnicas de las dimensiones de rol y dimensiones de
varios valores. Suponemos que un procedimiento quirrgico consiste en un solo
mdico responsable y un nmero variable de asistir a los mdicos, ayudar a los
profesionales, procedimientos y tipos de equipos. Tambin asumimos que el
paciente tiene un diagnstico de varios valores antes de la ciruga y un
diagnstico de varios valores separado despus de la ciruga.
As pues, tenemos seis dimensiones de varios valores, indicados por la negrita
en la figura 13.7. El mdico responsable, mdico de cabecera, y la asistencia a
las dimensiones profesionales son todas las funciones desempeadas por una
dimensin total de proveedores. El pre quirrgica y posquirrgica
multivaluados dimensiones diagnstico son funciones desempeadas por una
sola dimensin diagnstico.
Desde el grano de la tabla de hechos es el procedimiento quirrgico en s
mismo, es natural para abastecer a un amplio conjunto de hechos. Mostramos
el conjunto extendido de hechos que permitan un anlisis de P & L completa a
hacerse sobre los procedimientos quirrgicos, suponiendo que los distintos
costes se pueden asignar a cada evento quirrgico.
Dejamos a los factores de ponderacin de todas las dimensiones de varios
valores en este diseo. Si tratamos de proporcionar factores de ponderacin
para las dimensiones de varios valores, estaramos apoyando implcitamente
todas las complejas combinaciones de valores de ponderacin, algunos de los
cuales sera absurdo. No parece vale la pena decir que la parte asignada
correctamente del importe total facturado de la ciruga asignado
conjuntamente a cada posible asistente y cada posible pieza de equipo tiene
mucho significado. Nuestra tcnica de colocacin de los factores de
ponderacin de forma independiente en cada dimensin es slo una parte del
problema. Una preocupacin ms prctica es que la mayora de las
organizaciones no estaran dispuestos a asignar decenas o cientos de factores
de ponderacin.
Sin los factores de ponderacin, que, sin embargo, podemos crear muchos
informes de impacto tiles. Por ejemplo, cul es el valor total de todas las
cirugas realizadas que utilizaron una mquina corazn-pulmn? Tambin
podemos pedir que los mdicos que asisten a los profesionales, y que piezas
de equipo estaban involucrados en diversos tipos de ciruga. Y, por ltimo, si
hemos asignado los costos para cada ciruga de una manera racional, podemos
preguntarnos qu tipo de ciruga son rentables o no rentable y por qu.