A key feature of all connectivity solutions is a database that includes all of the patients associated with the system's medical devices. This is called a "patient census" or ADT (admission, transfer and discharge), much like the way a hospital's ADT system manages patient demographics for the hospital information system or EMR. Also referred to as patient management data, these data often include: patient name and ID number (permanent medical record number, episode of care number, or both), current assigned location of the patient, and the device associated with the patient. Depending on the application, these data can also include more operational or clinical things like assigned caregivers, admitting and/or attending physician, admitting diagnosis and service unit. It is also possible that this operational or clinical data may be stored in a different file, separate from patient management.
Some workflows or systems queue up patient information prior to arrival or application of the medical device, while others capture or generate patient demographics when the medical device is first applied to the patient. In any event, the connectivity solution must capture patient demographics that are sufficient to ensure correct patient identification and possibly additional information that relates to the use of the medical device (e.g., body surface area - or the data to calculate it, weight, etc.) Common methods to capture patient demographics are an ADT interface and a method of manual data entry. In some cases, it may be practical to capture patient demographics at the same time the medical device is associated with a patient.
This workflow is being tackled first in this series of blog posts because it is a foundation used by most connectivity workflows. Patient management workflow should be one of the last set of requirements completed because it must support all the workflows to be included in the product. What follows, in no particular order, are a number of issues and considerations that fall under the patient management category.
Examples of manual artifacts of patient management are the marker boards seen on the walls of nursing units, cath labs, surgical suites, ICUs and elsewhere. There they track the basic operational data that's key to successfully completing their mission. Besides the obvious (patient name, location, scheduling or sequence data, clinicians and staff assigned to the patient) there is often information hinting at communications outside the immediate area. Pager or phone numbers for support departments like clinical engineering, radiology or respiratory therapy, on call physicians and others are often tracked on marker boards. If it's on a marker board in the clinical area that's the target for medical device connectivity, it's a safe bet it should be in your requirements. And once it's in your system, you can replace that unattractive, illegible, and often out of date marker board.
The ADT system as a source for patient demographics is somewhat problematic. Interfacing to ADT systems is not a trivial task; an HL7 ADT interface must be built into the connectivity solution, and each ADT interface must be configured at installation - this is not a "plug and play" interface. Another challenge is the fact that ADT data is dependent on users to update patient locations. Consequently, ADT data pertaining to the department/unit and bed currently assigned to a patient may be out of sync. The reasons for this lack of timely and accurate update are many, and difficult to overcome. As a result, many medical device systems include the ability to manually enter and edit patient information in their own system, separate from the ADT system.
Some might be tempted to simply acquire patient data via the reading of bar codes on patient wrist bands - and this approach may be perfectly adequate for some applications. Hospitals encode various data fields into their patient wrist band bar codes. One must ensure required information is likely to be present, and have a backup plan should critical information not be available via the bar code. Having the customer change their bar codes is only practical if you can reliably get them to actually change their bar codes. Due to how other applications read the bar codes, there may be considerable resistance to changing bar codes.
Without an ADT interface, the product developer is forcing users to manually enter patient management data - a new task they likely did not have to do before "automating" their medical device workflow. Yet, as noted above, data quality issues may preclude relying exclusively on ATD systems for patient management data. Often, the solution is to implement both an ADT interface and a user interface that allows users to enter or edit patient management data manually when necessary.
Repeated readmissions of patients are becoming increasingly important to providers as risk is pushed off to providers to ensure that discharged patients are not readmitted for the same problems. These patients typically have one or more chronic diseases where their condition degrades after an admission and they are readmitted for a clinical "tune up" and then sent back home. Often referred to as "frequent flyers", CMS and other payors are not reimbursing providers for these frequent flyer patients when their readmission is within a specific time frame. Depending on whether the connectivity application is geared towards acute care of inpatients, disease management post discharge, or both, the management of past patient encounters data may be a desired feature. Some or all of this data may be designed to reside in the patient management database and related workflow.
Trackbacks/Pingbacks