Presented at the PCS/I Conference in
Örjan Leringe
DRG System Development AB,
Grouper software has been used for more than 25 years to group hospital stays in Diagnostic Related Groups (DRG’s) for Casemix purposes.
A new kind of grouper software is evolving with radically increased flexibility and ease of use. We will in this presentation explore the design criteria for this software. We will also describe an implementation in a new DRG Management System (DMS) which fulfills these criteria.
The DRG’s themselves were constructed with the following design criteria:
For the DRG software we formulate similar design criteria
The Nordic countries are using the strictly defined NordDRG system [1]. A number of database tables define the algorithm unambiguously. This satisfies the first design criteria.
The Nordic Centre in Uppsala (NC) has the
responsibility for the development of the Nordic groupers. At NC, under the
leadership of
The construction of the DRG’s would not have taken place without computers. In defining the logic to fulfill the DRG design criteria lots of calculations had to be done. Fetter and Averill have described the initial process of recursive subdivision in groups [2]. This involved lots of simulation runs against actual patient records with cost data. One of the main designers, Averill, was not surprisingly a computer scientist.
The way of producing the grouper software has followed the general trends in software development. With one major exception: It has not been on the front-line on adapting new technologies.
The first generally used groupers were written in machine language. The HCFA grouper, now produced by CMS [3], is still maintained in IBM Assembler, a machine language from the 60’s.
The formulation of the DRG algorithm has
evolved from ad hoc methods to more formalized ones. The health authorities in
These recent approaches have another level of abstraction and thus ease of use and understandability. But they are mainly aimed at implementers of the computer programs. We advocate an approach where also other professions are part of the complete development process of the DRG’s.
Many of our conclusions come from experience of the tools used in the construction and maintenance of the NordDRG grouper. In particular we focus on the recently made enhancement called DRG Management System, DMS [4].
How do you formulate the DRG algorithm in a way understandable by people from the economic and medical professions as well as computer professionals? The obvious solution is to formulate the algorithm in a flowchart. The flowchart is in addition to being intuitive also a formal presentation. But how can we go from a flowchart to a computer program without a lot of programming with staffs of programmers. The solution is to translate the flowchart to a decision table.
It can be shown that a flowchart always can be emulated by a decision table [5]. Finally, a decision table is computable; in particular it can automatically be translated to a computer program. This means that we can go from a decision table describing the DRG algorithm to an automatically generated computer program.
The flowchart is based on information on a number of tables stored in a database. These include lists of properties of each diagnoses and procedures. These properties are used in the flowchart as actions variables – deciding which path to take in the flowchart.
The heart in the decision process is the logic table which essentially is a decision table. In order to fully understand the grouping algorithm you have to study the logic table. The flowchart gives the general path to the computed DRG but the logic table is needed for the details. But again, this does not imply need to have programming knowledge.
In the Nordic countries the ICD-10 coding for diagnoses is the chosen standard. Since there are possibilities of extensions and deviations from the standard in the different countries the DRG system has to handle this. The solution has been to establish a common set of codes with common properties. The national coding of a specific code can be the standard one but its DRG deciding properties can vary. Also there can be additional local codes with the same or different properties as other codes. The system for DRG development must take care of this situation.
The Nordic countries have for procedure coding adopted an extended version of CSP called NCSP [6]. Just like the use of ICD-10 the application in the different countries of NCSP varies. And the solution in our tools is the same. There is a mapping between the national versions and the NCSP codes.
The advantage of the approach chosen is a reasonable independence of the tools for DRG software construction and the different coding standards used.
This flexibility has been very helpful in allowing local adjustments for the different Nordic countries and they still can have cooperation with a common DRG grouper.
The design of the DRG’s is mainly a responsibility of people from the economic and medical professions.
The yearly correction to the DRG structure consists of activities like
These activities can now be performed by the people responsible directly with the tool.
Properties of diagnoses and procedures can be added, deleted or modified using a simple user interface which performs lots of consistency checks.
The logic table can also interactively be changed with all sorts of consistency checks being made while editing.
After changes have been made you can immediately test the result by grouping individual test cases or a series of test cases. This is done interactively and the results are presented with information on differences compared to previously made groupings.
There is also a utility for test coverage to ensure that a certain set of test cases cover all of the decisions rules.
In addition to the interactively performed test you can perform a batch grouping of huge sets of cases.
The DRG algorithm is a complicated logical structure. It is traditionally implemented by computer professionals in a program called a grouper. The grouper is run on a large number of cases to ensure that the algorithm fulfils the design criteria of the DRG algorithm. If this is not the case the logical structure is modified and a new version of the program is constructed and tested.
This cycle of modifications to the logic of the DRG’s and testing on actual cases is time consuming. With new tools for development this cycle can be shortened in time and the quality of the result can be increased.
We propose use of tools which make it possible also for people from the economic and medical professions to take part in the whole cycle of testing the DRG algorithm. This is made possible by the automatic generation of the grouper program. This generation is done out of tables with decision rules which is managed by a user-friendly program.
As a final remark we observe that this does not rule out the role of the computer professionals. We will still need groupers which are tailored for specific productions environments. This is solved by letting the development tool produce the final decision tables in a form suitable for construction of production quality groupers.
[1] NordDRG Users' Manual, Nordic Centre
for Classifications in Health Care, www.nordclass.uu.se
[2] Case Mix Definition by Diagnosis-Related Groups
Fetter, Shin, Freeeman, Averill, Thompson
Medical Care February 1980, vol. XVIII
[3] In 2001, HCFA was renamed the Centers for Medicare & Medicaid Services (CMS).
[4] User Manual for DRG Management System – DMS
DRG System Development AB,
[5] On the Emulation of Flowcharts by Decision Tables
Art Lew,
Communications of the ACM, December
1982, Volume 25 Number 12
[6] NCSP, Nordic Centre for Classifications
in Health Care and NOMESCO