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.


Revision breakdown.
© Copyright Policy - open-access
Related In: Results  -  Collection

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

Figure 9: Revision breakdown.

Mentions: 5,537 of the RecordComponents have their “Revised By” flag set, indicating that another version of them exists. However the capacity to record revisions has only been provided since the new Web application was created so this represents not 1 or 2 records per patient over the lifetime of their care, but over a single year. Fig. (9) shows how the revisions are broken down by SynOD class.


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)

Revision breakdown.
© Copyright Policy - open-access
Related In: Results  -  Collection

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

Figure 9: Revision breakdown.
Mentions: 5,537 of the RecordComponents have their “Revised By” flag set, indicating that another version of them exists. However the capacity to record revisions has only been provided since the new Web application was created so this represents not 1 or 2 records per patient over the lifetime of their care, but over a single year. Fig. (9) shows how the revisions are broken down by SynOD class.

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.