Service Line management provides the healthcare industry the ability to determine which of its diverse services are profitable and how the market share of a given service compares to competing providers. Service Lines are typically limited to a handful of well defined, mutually exclusive categories or groupings of individual services or interventions. For example, a provider may choose to categorize clinical transactions (encounters, ambulatory or hospital visits, episodes, longitudinal courses of care) into Service Lines such as Oncology, Cardiovascular and Orthopedics. Since no such Service Line designation exists in standard transactional encoding systems or taxonomies, Service Line assignment are derived based on attributes such as primary diagnosis codes, procedure codes, and other patient attributes such as age, gender or genetic characteristics, to name a few.
From a data management perspective, Service Line management presents a number of interesting challenges. To illustrate these challenges, consider a large, multi–hospital, multi-specialty, multi-care-setting health system servicing millions of patients annually as they attempt to gain a single, consistent view of Service Lines across all facilities and settings. Then consider the typical data management obstacles that arise in any one of these settings such as poor data quality, potentially caused by inconsistent coding practices or lack of validation within and across the various source systems in use. It turns out that for such a provider, the challenges are not insurmountable if the solution adheres to the proper architectural approach and design principles.
Here are some challenges to consider when implementing Service Lines within your healthcare organization:
- It’s not likely that a single set of attributes will provide the flexibility, or for that matter, the consistency across an enterprise that will be needed to define a Service Line. The approach will have to take into account that business users will almost reflexively define Service Lines on the basis of one or more complex clinical conditions, including the primary treatment modalities. For example, Oncology = DRG codes BETWEEN 140.00 and 239.99 OR Service IN (RAD, ONC) OR Physician IN (Frankenstein, Zhivago) OR …
- Service Lines will likely overlap on any given healthcare transaction, either within the Service Line or across Service Lines, as a consequence both of the inherently multi-disciplinary care that is delivered, and the traditional department or specialty alignment of critical staff. A patient that has a primary diagnosis code of lung cancer may be discharged after having a lung transplant procedure by a cardiovascular or thoracic surgeon. The patient transaction is arguably a candidate for both Service Lines, but by definition, only one Service Line may prevail, depending upon the analytic objectives and context.
- Given the often unavoidable Service Line overlap, the need to resolve conflicts within and across Service Lines exists to meet the ultimate requirement that a transaction (case, episode, etc.) is ultimately assigned to one and only one Service Line. However, there is value in capturing all Service Lines that apply to a given transaction, and specifically giving users visibility into the reality that, given current operating definitions, overlap exists. This both informs the end-user and enables him/her to take this into consideration appropriately for the analytic objectives at hand.
- Various models are possible for explicitly revealing and managing these important overlaps. For example, the reporting structure might consider a three level hierarchy that explicitly represents and manages this overlap as a multi-level model: level 1 resolves conflicts at the health system across all Service Lines; level 2 resolves conflicts between sub-categories within a Service Line; and level 3 allows overlap and may even accommodate multiple counting in well-circumscribed and special analytic contexts.
- Organizations in the early stages of measuring performance by Service Lines might be motivated to influence the definition of any given Service Line to extend its reach by attaching to transactions currently falling into the ‘Other Service Line’; or by providing a more granular view (e.g. categories and sub-categories) of existing Service Lines. To support the inevitable evolution of these definitions, Service Line definitions and specifications should be implemented as adaptable business rules, capable of being changed on a frequent basis.
To address these challenges, listed below are some technical implementation techniques you may want to consider:
- Business rules should be implemented using a data model that allows for data-driven evaluation of rules, and should never be implemented as part of static code or ETL (extract, transformation, load). Given the volume of data that will be processed, rule evaluation should be done within the database engine as a Join operation, rather than iterating record by record.
- Complexity of the business rules and the frequency with which they change could drive a decision to use an off-the-shelf business rule tool. Finding a tool that meets your implementation timeline and budget will enhance the users’ experience; typically the financial planners and analysts that will create and modify the rules. The key is to find a business rule tool that does not require rule processing to be programmatic or iterative.
- When evaluation of any business rule applies to a specific transaction, tag the transaction explicitly. While the ultimate goal of the rules is to assign one and only one Service Line, tagging as a first step allows rules to be evaluated in isolation of one another and provides visibility to the level 2 and level 3 Service Line assignments described above. A tag is equivalent to a provisional Service Line designation, although the ultimate Service Line assignment cannot occur until overlap conflict is resolved.
- With individual transactions specifically tagged, conflicts that occur can be resolved at each level of the Service Line assignment hierarchy. To achieve the desirable level 1, 2 and 3 hierarchy behavior, conflict is resolved in terms of the competing individual precedence assigned to each of the relevant business rules. For example, a simple business rule precedence scheme for level 1 may be to state that where Oncology and Cardiovascular overlap, Cardiovascular always takes precedence. Other strategies and specifications for resolving such conflicts can implemented using a consistent representation.
In summary, the key requirement for Service Line implementation is adaptability. Implementing a data-driven platform capable of evaluating the complex business rules and supporting the different behaviors of Service Line tags by explicit representation within the relevant reporting hierarchies will allow your healthcare organization to constantly evolve and gain new insights on the performance and improvement opportunities of your services lines. In the final analysis, that’s what it’s all about.