Difference between revisions of "Challenges of Implementing VistA by Matt King"
DavidWhitten (talk | contribs) |
DavidWhitten (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | Prepared by Matt King of Clinica Adelante | + | |
| + | == Prepared by Matt King of Clinica Adelante == | ||
| + | |||
Clinica Adelante identified several key challenges with respect to the deployment of VistA in a community health center context. It is necessary to have a clear roadmap before embarking on the implementation of open source in a community health center context. Additionally, early identification of challenges and close affiliation with the WorldVistA community can help to mitigate challenges encountered along the way. Next, we discuss several challenges encountered during the deployment. | Clinica Adelante identified several key challenges with respect to the deployment of VistA in a community health center context. It is necessary to have a clear roadmap before embarking on the implementation of open source in a community health center context. Additionally, early identification of challenges and close affiliation with the WorldVistA community can help to mitigate challenges encountered along the way. Next, we discuss several challenges encountered during the deployment. | ||
| − | Project Leadership | + | '''Project Leadership''' |
Project leadership does not always have the technical skills necessary to oversee the implementation of an EHR. However, it is possible to hire a WorldVistA community liaison to oversee the implementation. Involving staff in the implementation process early is also helpful. Paradoxically, this challenge may be resolved through project buy-in and actually result in better quality processes and clinical tools. | Project leadership does not always have the technical skills necessary to oversee the implementation of an EHR. However, it is possible to hire a WorldVistA community liaison to oversee the implementation. Involving staff in the implementation process early is also helpful. Paradoxically, this challenge may be resolved through project buy-in and actually result in better quality processes and clinical tools. | ||
| − | Interfacing WorldVistA | + | '''Interfacing WorldVistA''' |
Interfacing open source software to proprietary software can be challenging for a number of reasons. My experience is only with WorldVistA EHR and thus my comments are limited to that software. WorldVistA EHR is strongly HL7 compliant. Most other health information software are as well. One would expect interfacing two HL7 compliant systems to be a trivial matter. However, this is not the case. Creating interfaces to VistA turned to be our greatest challenge. Our first challenge was because we were the first to interface WorldVistA on a GT.M platform. Several technical issues were discovered and resolved and several globals in GT.M needed to be rewritten. Next, our PMS system, although “HL7 compliant,” still did not interface well with VistA, causing an additional layer of complexity. Communication between our proprietary vendors and our WorldVistA vendors could be challenging also. Although they remained thoroughly professional, it was evident that our proprietary vendors were not eager participants in our project. Neither side trusted the other, and this could lead to finger-pointing rather than troubleshooting. This is not an isolated experience. Interfacing with the reference laboratory was actually more difficult than interfacing with the PMS. The biggest difference is the laboratory was a willing partner, and worked very hard with our vendors. | Interfacing open source software to proprietary software can be challenging for a number of reasons. My experience is only with WorldVistA EHR and thus my comments are limited to that software. WorldVistA EHR is strongly HL7 compliant. Most other health information software are as well. One would expect interfacing two HL7 compliant systems to be a trivial matter. However, this is not the case. Creating interfaces to VistA turned to be our greatest challenge. Our first challenge was because we were the first to interface WorldVistA on a GT.M platform. Several technical issues were discovered and resolved and several globals in GT.M needed to be rewritten. Next, our PMS system, although “HL7 compliant,” still did not interface well with VistA, causing an additional layer of complexity. Communication between our proprietary vendors and our WorldVistA vendors could be challenging also. Although they remained thoroughly professional, it was evident that our proprietary vendors were not eager participants in our project. Neither side trusted the other, and this could lead to finger-pointing rather than troubleshooting. This is not an isolated experience. Interfacing with the reference laboratory was actually more difficult than interfacing with the PMS. The biggest difference is the laboratory was a willing partner, and worked very hard with our vendors. | ||
| − | Technical Challenges | + | '''Technical Challenges''' |
The technical challenges for us were magnified because we were the first ones to go through the experience of deploying WorldVistA. The experience, however, is an example of how the open source community works: 1) We uncovered several bugs in WorldVistA EHR that we fixed and then sent on to both WorldVistA and the VA. These fixes were incorporated into the patch stream to benefit everyone. 2) Some problems that we could not easily fix were sent to the WorldVistA community. Programmers in the community provided the fixes. 3) Most often, there was more than one way to fix the problem and the experts viewed the ideas and selected the best, or even improved on the coding before release. 4) We used an open source HL7 engine called Mirth, to do the bulk of the interface work. The code for these interfaces is now available to others needing it without charge. 5) We also built open source web-based Java tools to help administer the interface. These are also available. Thus, the time and cost to the next health center should be lower. | The technical challenges for us were magnified because we were the first ones to go through the experience of deploying WorldVistA. The experience, however, is an example of how the open source community works: 1) We uncovered several bugs in WorldVistA EHR that we fixed and then sent on to both WorldVistA and the VA. These fixes were incorporated into the patch stream to benefit everyone. 2) Some problems that we could not easily fix were sent to the WorldVistA community. Programmers in the community provided the fixes. 3) Most often, there was more than one way to fix the problem and the experts viewed the ideas and selected the best, or even improved on the coding before release. 4) We used an open source HL7 engine called Mirth, to do the bulk of the interface work. The code for these interfaces is now available to others needing it without charge. 5) We also built open source web-based Java tools to help administer the interface. These are also available. Thus, the time and cost to the next health center should be lower. | ||
Latest revision as of 18:50, 15 March 2010
Prepared by Matt King of Clinica Adelante
Clinica Adelante identified several key challenges with respect to the deployment of VistA in a community health center context. It is necessary to have a clear roadmap before embarking on the implementation of open source in a community health center context. Additionally, early identification of challenges and close affiliation with the WorldVistA community can help to mitigate challenges encountered along the way. Next, we discuss several challenges encountered during the deployment.
Project Leadership
Project leadership does not always have the technical skills necessary to oversee the implementation of an EHR. However, it is possible to hire a WorldVistA community liaison to oversee the implementation. Involving staff in the implementation process early is also helpful. Paradoxically, this challenge may be resolved through project buy-in and actually result in better quality processes and clinical tools.
Interfacing WorldVistA
Interfacing open source software to proprietary software can be challenging for a number of reasons. My experience is only with WorldVistA EHR and thus my comments are limited to that software. WorldVistA EHR is strongly HL7 compliant. Most other health information software are as well. One would expect interfacing two HL7 compliant systems to be a trivial matter. However, this is not the case. Creating interfaces to VistA turned to be our greatest challenge. Our first challenge was because we were the first to interface WorldVistA on a GT.M platform. Several technical issues were discovered and resolved and several globals in GT.M needed to be rewritten. Next, our PMS system, although “HL7 compliant,” still did not interface well with VistA, causing an additional layer of complexity. Communication between our proprietary vendors and our WorldVistA vendors could be challenging also. Although they remained thoroughly professional, it was evident that our proprietary vendors were not eager participants in our project. Neither side trusted the other, and this could lead to finger-pointing rather than troubleshooting. This is not an isolated experience. Interfacing with the reference laboratory was actually more difficult than interfacing with the PMS. The biggest difference is the laboratory was a willing partner, and worked very hard with our vendors.
Technical Challenges
The technical challenges for us were magnified because we were the first ones to go through the experience of deploying WorldVistA. The experience, however, is an example of how the open source community works: 1) We uncovered several bugs in WorldVistA EHR that we fixed and then sent on to both WorldVistA and the VA. These fixes were incorporated into the patch stream to benefit everyone. 2) Some problems that we could not easily fix were sent to the WorldVistA community. Programmers in the community provided the fixes. 3) Most often, there was more than one way to fix the problem and the experts viewed the ideas and selected the best, or even improved on the coding before release. 4) We used an open source HL7 engine called Mirth, to do the bulk of the interface work. The code for these interfaces is now available to others needing it without charge. 5) We also built open source web-based Java tools to help administer the interface. These are also available. Thus, the time and cost to the next health center should be lower.
