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.

Monday, August 13, 2007

Initiate Identity Hub

The Identity Hub can't officially store audit dates against attributes. It stores the dates against operations, and then the attributes are linked to the operations. So if you have an HL7 message arriving with different dates on different attributes, you end up having to execute a number of MemPut operations. So it CAN be done, but it's messy, and I'd be a little concerned about performance, in that instance. Of course, if you go to Update mode as well (instead of Snapshot mode) then an inbound message is likely to contain only one set of dates (business and technical) anyway so would only occasion one MemPut.

Incidentally, I don't think eDrug has a requirement for Update Mode. Current Pharmanet demographic updates to CRS are considered Snapshots, so if they don't change an address, they still have to supply it. The Update Mode requirement is probably coming from somewhere else, though.