Ian Cheong wrote: > At 9:42 pm +1000 6/7/06, David Guest wrote: >> Content-Type: multipart/signed; >> protocol="application/x-pkcs7-signature"; >> micalg=sha1; boundary="------------ms080507030901030406090108" >> >> Tim Churches wrote: >>> On teh international openhealth mailing list some months ago, there >>> was a discussion on this with respect open source health software >>> and a proposed US accreditation mechanism - see >>> http://www.mail-archive.com/[email protected]/msg00656.html >>> - if you scroll down you'll see the entire thread of messages. >>> >>> The points I made were that: >>> a) accredittaion tests should be automated, not done by humans >>> tapping a keyboard and clicking a mouse each and every time a test >>> needs to be repeated (for a new version of the software etc) ; >>> b) there should be no monopoly on who creates the test scripts; >>> c) the testing authority merely verifies the correctness of the >>> test scripts and runs them to perform the test - or, much better, it >>> trusts a signed statement from accredited independent testing >>> agencies (so that there is a competitive market for their services >>> and no govt-created monopoly). >>> >>> The main point is that application developers should be able to do >>> the leg work of creating test scripts to demonstrate compliance of >>> their products themselves, since this is were a lot of the costs >>> lie. Of course, the first step is to create a comprehensive set of >>> test specs, and to publish these. >>> >> You've been hanging around Extreme Programmers too long, Tim. :-) It >> sounds fantastic to me though. How would it work in practice. >> >> I must admit that I was thinking testing and certifying would be aimed >> more at the differing components such as the GUI, middleware and >> backend. >> > > Don't forget the GPCG and previously the RACGP had been chasing > software accreditation along with industry round and round over many > years. > > It is a non-trivial exercise. > > The best specs ever written down were the IBM GPCS functional > specifications..... nobody wanted to be accredited on that. > > ISO/IEC 15504 SPICE accreditation was explored by local software > experts under Software Engineering Australia (Qld) and deemed too > expensive in the GP setting.... project report should on the GPCG web > site....no further steps were taken. > > Certification of standards compliance could be possible, but we still > don't have all the standards functional.....still work in progress at > NeHTA. > > Not sure that there are robust accepted methods for accrediting > usability, since modern software (and many other human artefacts, > especially technological) suffer from usability problems. Not sure I follow that. Isn't that what regression testing is all about?
I was kind of hoping that modern EHR software would do things like not dissolve on the screen, would not lose data, hopefully would not crash (too often), allow for generic data extraction and importing and have an API that other applications could address. > It makes sense to me that there should be demonstrable usability, > safety, quality, etc around software. But the pathway to getting there > is not well made. > > Accreditaiton of functionality in support of practice standards had a > run at one stage and seems likely to have legs in the long term... > since we see the beginnings of it already in PIP requirements and > broadband security standards. Yes. You may have to define what you want first and then build it from scratch. If it's all too hard is Enrico just whistling in the wind? David
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
