> For the complete documentation index, see [llms.txt](https://wiki.medicaiddatalearningnetwork.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.medicaiddatalearningnetwork.org/advanced/creating-hospitalization-episodes-from-inpatient-claims.md). # Creating Hospitalization Episodes from Inpatient Claims {% hint style="info" icon="pen-to-square" %} Contributed by Shashi Kapadia () and Kenneth Karan () {% endhint %} ## Motivation Our research asked questions about care that patients received before and after a hospital stay. Numerous claims could comprise a hospital stay: some duplicate, some overlapping, some nested, some starting within a specified number of days of previous beginning. This could be for a variety of billing reasons, such as specific hospitals having different bills across units or time periods. This pattern can also occur because of individuals being transferred between distinct hospitals. Regardless, our goal was to establish a consistent approach to defining a “hospitalization” or “hospital stay” using episode logic.
## Approach This approach was adapted from T-MSIS TAF Methodology briefs #5011. * First, Select inpatient claims using *Identifying* *Inpatient TAF Claims* methodology specified in \ * Condense claims into episodes using the following logic: * A gap of longer than 1 days means there is a new episode. * Flags are created to check for potential transfers or discharges within the episode: * poss\_xfer: a possible transfer to any facility. The indicator is set to 1 or TRUE if there is more than one billing NPI within an episode and a discharge status code indicating transfer to any facility. These are values of ptnt\_dschrg\_stus\_cd: * Short term hospital: 01, 43, 66, 82, 85, 88, 94 * Skilled nursing facility: 03, 04, 61, 62, 64, 83, 84, 89, 90, 92 * Long term acute care hospital: 63, 91 * Psych hospital: 65, 93 * Other hospital: 05, 70, 95 * Hospice: 50, 51 * poss\_xferip: a possible transfer to another inpatient facility. The indicator is set to 1 or TRUE if there is more than one billing NPI within an episode and a discharge status code indicating transfer to another short term hospital. These are discharge status codes: * Short term hospitalization: 01, 43, 66, 82, 85, 88, 94 * poss\_dis: possible discharge and rapid (within 1 day) readmission. If the episode contains a claim where the end date is not equal to the episode end date and one of the following values of ptnt\_dschrg\_stus\_cd: * Home: 01, 06, 08, 71, 72, 81, 86 * Skilled Nursing Facility: 03, 04, 61, 62, 64, 83, 84, 89, 90, 92 * Long term acute care hospital: 63, 91 * Psych hospital: 65, 93 * Other hospital: 05, 70, 95 * Law: 21, 87 * Hospice: 50, 51 ## Key Considerations and Limitations * We intentionally meant to combine hospitalizations that included a transfer into one hospital stay and flag them with a binary variable. An alternative approach (and the one recommended in TAF brief #5011) would be to require that claims with a new billing provider identifier create a new episode. This approach would be preferred if the researcher intends to count a hospitalization with a transfer between facilities as “two” episodes. * This approach is vulnerable to scenarios where patients are discharged and re-admitted within 1 day. Though this may be rare, the intention of the above flag variables are to identify those scenarios and allow for further investigation or exclusion. * This approach is not benchmarked against an external data source. ## Sources * TAF DQ Methodology Brief #5011 p. 2. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.medicaiddatalearningnetwork.org/advanced/creating-hospitalization-episodes-from-inpatient-claims.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.