Limits...
Analysis of Clinical Record Data for Anticoagulation Management within an EHR System.

Austin T, Kalra D, Lea NC, Patterson DL, Ingram D - Open Med Inform J (2009)

Bottom Line: Each node is capable of incorporating a rich set of context properties, but in reality it was found that many properties were not used at all, and some infrequently (e.g. only around 0.5% of Record Components had ever been revised).This work has shown how little of the resulting model is actually needed to represent useful and usable clinical data.A wider range of such evaluations, looking at different kinds of existing clinical system, is needed to balance the theoretical requirements gathering processes, in order to result in EHR information models of an ideal level of complexity.

View Article: PubMed Central - PubMed

Affiliation: Centre for Health Informatics and Multiprofessional Education (CHIME), University College London (UCL), UK.

ABSTRACT

Objectives: This paper reports an evaluation of the properties of a generic electronic health record information model that were actually required and used when importing an existing clinical application into a generic EHR repository.

Method: A generic EHR repository and system were developed as part of the EU Projects Synapses and SynEx. A Web application to support the management of anticoagulation therapy was developed to interface to the EHR system, and deployed within a north London hospital with five years of cumulative clinical data from the previous existing anticoagulation management application. This offered the opportunity to critique those parts of the generic EHR that were actually needed to represent the legacy data.

Results: The anticoagulation records from 3,226 patients were imported and represented using over 900,000 Record Components (i.e. each patient's record contained on average 289 nodes), of which around two thirds were Element Items (i.e. value-containing leaf nodes), the remainder being container nodes (i.e. headings and sub-headings). Each node is capable of incorporating a rich set of context properties, but in reality it was found that many properties were not used at all, and some infrequently (e.g. only around 0.5% of Record Components had ever been revised).

Conclusions: The process of developing generic EHR information models, arising from research and embodied within new-generation interoperability standards and specifications, has been strongly driven by requirements. These requirements have been gathered primarily by collecting use cases and examples from clinical communities, and been added to successive generations of these models. A priority setting approach has not to date been pursued - all requirements have been received and almost invariably met. This work has shown how little of the resulting model is actually needed to represent useful and usable clinical data. A wider range of such evaluations, looking at different kinds of existing clinical system, is needed to balance the theoretical requirements gathering processes, in order to result in EHR information models of an ideal level of complexity.

No MeSH data available.


Breakdown of RecordComponent type.
© Copyright Policy - open-access
Related In: Results  -  Collection

License
getmorefigures.php?uid=PMC2737130&req=5

Figure 5: Breakdown of RecordComponent type.

Mentions: The five years of data comprised 932,606 RecordComponents in the system in total and of these, 638,199 were ElementItems. More information is shown in Fig. (5). It is not possible to plot the change in these data sets over time since the preceding system did not capture the date of recording. Fig. (6) shows the way in which the ElementItem content is broken down by its value’s data type. Slightly more than two thirds of the ElementItems (435,936 out of 638,199) were a type of Numeric quantity. There were very similar amounts of date-related and textual information.


Analysis of Clinical Record Data for Anticoagulation Management within an EHR System.

Austin T, Kalra D, Lea NC, Patterson DL, Ingram D - Open Med Inform J (2009)

Breakdown of RecordComponent type.
© Copyright Policy - open-access
Related In: Results  -  Collection

License
Show All Figures
getmorefigures.php?uid=PMC2737130&req=5

Figure 5: Breakdown of RecordComponent type.
Mentions: The five years of data comprised 932,606 RecordComponents in the system in total and of these, 638,199 were ElementItems. More information is shown in Fig. (5). It is not possible to plot the change in these data sets over time since the preceding system did not capture the date of recording. Fig. (6) shows the way in which the ElementItem content is broken down by its value’s data type. Slightly more than two thirds of the ElementItems (435,936 out of 638,199) were a type of Numeric quantity. There were very similar amounts of date-related and textual information.

Bottom Line: Each node is capable of incorporating a rich set of context properties, but in reality it was found that many properties were not used at all, and some infrequently (e.g. only around 0.5% of Record Components had ever been revised).This work has shown how little of the resulting model is actually needed to represent useful and usable clinical data.A wider range of such evaluations, looking at different kinds of existing clinical system, is needed to balance the theoretical requirements gathering processes, in order to result in EHR information models of an ideal level of complexity.

View Article: PubMed Central - PubMed

Affiliation: Centre for Health Informatics and Multiprofessional Education (CHIME), University College London (UCL), UK.

ABSTRACT

Objectives: This paper reports an evaluation of the properties of a generic electronic health record information model that were actually required and used when importing an existing clinical application into a generic EHR repository.

Method: A generic EHR repository and system were developed as part of the EU Projects Synapses and SynEx. A Web application to support the management of anticoagulation therapy was developed to interface to the EHR system, and deployed within a north London hospital with five years of cumulative clinical data from the previous existing anticoagulation management application. This offered the opportunity to critique those parts of the generic EHR that were actually needed to represent the legacy data.

Results: The anticoagulation records from 3,226 patients were imported and represented using over 900,000 Record Components (i.e. each patient's record contained on average 289 nodes), of which around two thirds were Element Items (i.e. value-containing leaf nodes), the remainder being container nodes (i.e. headings and sub-headings). Each node is capable of incorporating a rich set of context properties, but in reality it was found that many properties were not used at all, and some infrequently (e.g. only around 0.5% of Record Components had ever been revised).

Conclusions: The process of developing generic EHR information models, arising from research and embodied within new-generation interoperability standards and specifications, has been strongly driven by requirements. These requirements have been gathered primarily by collecting use cases and examples from clinical communities, and been added to successive generations of these models. A priority setting approach has not to date been pursued - all requirements have been received and almost invariably met. This work has shown how little of the resulting model is actually needed to represent useful and usable clinical data. A wider range of such evaluations, looking at different kinds of existing clinical system, is needed to balance the theoretical requirements gathering processes, in order to result in EHR information models of an ideal level of complexity.

No MeSH data available.