Department of Medical Informatics and Clinical Epidemiology
Oregon Health & Science University
The problem list has become in the central feature in health information systems (HIS). An accurate, complete, and up-‐to-‐date problem list improves quality of care, allows the development and implementation of clinical decision support systems (CDSS), and enables the development of health care programs, as well as research studies. An accurate problem list also facilitates the administrative and billing processes in health systems. This problem-‐oriented health record had a disparate acceptance in the medical community, but in the informatics era, the problem-‐oriented electronic health record allows physicians and developers to create and maintain a structured, coded problem list in a computer system and resolved an important part of the problem of access to patient´s health information. The categorization of the problems in the problem list allows system to easily identify what problems are present and what are resolved conditions. While the advantages of a problem list are known and have been published in numerous studies, physicians do not always keep the problem list accurate, complete and updated. When physicians were interviewed about why they do not use and maintain the problem list, they reported problems in different contexts. Even some of the problems because physicians do not use the problem list have been enumerated in studies like the Wright's and others, there are not enough information about strategies to improve the granularity (level of detail) of the problem list. Granularity is one of the main features to improve the accuracy of the list. In health information systems, like ours, at Hospital Italiano de Buenos Aires, where the problem list is the backbone of the system, granularity of the problem list is a key point for better health
care quality. All our clinical decision support systems, health care programs, and also, research support systems and administrative task are based mainly in the patients' problem list. An accurate problem list, with and adequate level of granularity, allow us to optimize the development of these tools and improving the quality of health care. The main objective of this project was to measure the level of detail of the problems in the problem list testing clinical cases in two different interfaces. Two interfaces for inputting problems into the problem list were used. Current HIBA’s EHR problems list interface, which provides the actual interface for problem entry into the problem list and a new prototyped interface. This last one adds new options to the process, allowing users to increase the detail level (granularity) of the problem. This study was performed at Hospital Italiano de Buenos Aires, in Argentina. Twenty physicians participates in the test. Three clinical cases validated by medical practitioners, containing all the necessary information and controlled vocabulary with no ambiguities was used. The order in which clinical case was present was randomized. There was not time limit to perform the task. Granularity was defined based on sensitivity of documentation, compared with what was defined for each case presented to subjects. Sensitivity for each case-‐strategy pair was calculated as the level of detail identified by the subject that is present in the case, divided by the total number of detail level in this case. In general sensitivity for all the three case was 59,83% with a range 47 to 80%. 56% (47 to 80%) using interface 1 and 64% (53 to 80%) using interface 2. No statistical differences between two interfaces (p< 0,518). Specific data for each particular case can be found in the paper.
The key point in this paper is what level of granularity is really necessary, and this will depend on the circumstances, contexts and ways in which each hospital uses their list of problems. More study to address this problematic will be necessary.
School of Medicine
Otero, Carlos Martin, "Improving the granularity of the electronic health record problem list" (2014). Scholar Archive. 3532.