Roles played by the date dimensinAccumulating 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 dimensionNormally 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 staysThe 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 eventsIn 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 dimensinLa 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 multivalorNormalmente 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 estilo-mltiples 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 extranjera-clave-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 facturadosLa 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 complejasEn 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.