Friday, November 30, 2007
My eHealth 2007 presentation
http://www.e-healthconference.com/_ehealth2007web/pdf_presentations/wed_use_of_ehr_cripps.pdf
HL7 message development in Canada
The pan-Canadian working groups are often too far ahead of usage to be that helpful. The model currently is that representatives from each province come together and try to figure out what would need to be messaged in a Canadian standard. In a way, it's a requirements-driven process, but without the prototypes and usage that accompany systems development, it doesn't seem to yield the right results.
A better approach would be to wait for a province that has a burning need to exchange medical information to come forward, and for CHI to plant key resources on the project team who do real work towards the project goal. CHI could then be sure that decisions weren't made on the project that would limit the applicability of messages to other provinces. The advantage of tying message development into a project of course is that the project has a deliverable: the software.
With a hard deliverable at the end, a phased approach with early prototypes, in which complex issues, including messaging, are tackled early, will yield a product that is at least adequate for initial system-system communication in one provincial setting, and will form a good basis for such communication in other provinces.
What CHI needs to do is manage standards in such a way that the initial production is tied to a project, and roll out standards in alpha, beta, and final form, and in such a way that momentum is gained through iterative, cumulative releases.
The outcome of a project must of necessity include artifacts that the developers understand and that testers have created to test the system. As other projects pick up that material and need to change it, the cycle of standards maintenance can begin.
Here in Canada, rather than wait for several jurisdictions to propose changes to the standards, changes have been thrust upon the provinces whether there is need for them or not. In other words, it's often too early to know whether a standard is deficient or not until it's tried and tested in a couple of places.
It simply is not prudent to attempt to create an all-singing all-dancing solution to anything in a big bang approach. Carefully staged, iterative prototypes are the right approach to creating technical solutions to complex problems.
Invest a little, learn some lessons, invest some more, reach a small beach-head; invest again and learn more; establish a base camp; and so on, up the mountain.
A better approach would be to wait for a province that has a burning need to exchange medical information to come forward, and for CHI to plant key resources on the project team who do real work towards the project goal. CHI could then be sure that decisions weren't made on the project that would limit the applicability of messages to other provinces. The advantage of tying message development into a project of course is that the project has a deliverable: the software.
With a hard deliverable at the end, a phased approach with early prototypes, in which complex issues, including messaging, are tackled early, will yield a product that is at least adequate for initial system-system communication in one provincial setting, and will form a good basis for such communication in other provinces.
What CHI needs to do is manage standards in such a way that the initial production is tied to a project, and roll out standards in alpha, beta, and final form, and in such a way that momentum is gained through iterative, cumulative releases.
The outcome of a project must of necessity include artifacts that the developers understand and that testers have created to test the system. As other projects pick up that material and need to change it, the cycle of standards maintenance can begin.
Here in Canada, rather than wait for several jurisdictions to propose changes to the standards, changes have been thrust upon the provinces whether there is need for them or not. In other words, it's often too early to know whether a standard is deficient or not until it's tried and tested in a couple of places.
It simply is not prudent to attempt to create an all-singing all-dancing solution to anything in a big bang approach. Carefully staged, iterative prototypes are the right approach to creating technical solutions to complex problems.
Invest a little, learn some lessons, invest some more, reach a small beach-head; invest again and learn more; establish a base camp; and so on, up the mountain.
Subscribe to:
Posts (Atom)