1 / 35

EHR-QTN Main Conclusions Recommendations

Why certification?. Brussels, March 30, 2012. 2. Reasons for Certification". eHealth and more specifically Electronic Health Record systems have an enormous potential to improve quality, accessibility and efficiency of care, provided they are:reliable, trustworthy and of sufficient quality;shara

ponce
Download Presentation

EHR-QTN Main Conclusions Recommendations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. 1 EHR-QTN Main Conclusions & Recommendations Brussels, March 30th 2012

    2. Why certification? Brussels, March 30, 2012 2

    3. Reasons for “Certification” eHealth and more specifically Electronic Health Record systems have an enormous potential to improve quality, accessibility and efficiency of care, provided they are: reliable, trustworthy and of sufficient quality; sharable and interoperable; used appropriately. Quality labelling and certification through professional third party assessment offers best chances for a comparable and reliable quality documentation of those systems. Brussels, March 30, 2012 3

    4. But there is a quality issue Myers et al*. show that adverse events related to the use of EHR systems are mainly resulting from: missing or incorrect data; data displayed for the wrong patient; chaos during system downtime; system unavailable for use. Examples of reported incidents in healthcare where a medical information system was the cause or a significant factor: http://iig.umit.at/efmi/badinformatics.htm *Myers DB, Jones SL, Sittig DF, Review of Reported Clinical Information System Adverse Events in US Food and Drug Administration Databases, Applied Clinical Informatics 2011; 2: 63–74.

    5. Some EHR quality “statements” Patients are too important to just suppose that EHR systems are trustworthy. Patient data should not be locked into one system or application. Patients essential data should be made available anywhere anytime to health professionals authorised to access them. Patient has the right to request confidentiality of some data to be handled while taking full responsibility for that option. Patients’ data accesses should be audit-trailed. Brussels, March 30, 2012 5

    6. A Norwegian statement… A recent Norwegian statement is an important one and based on a large experience in certifying “messages” (certifying all kind of standards based data exchange). The Norwegian Ministry of Health and Care Services stated that “EHR Quality will be difficult to reach unless certification of the EHR systems is made mandatory”. Brussels, March 30, 2012 6

    7. Not all EHR systems are good enough Selecting the most appropriate application from the correct vendor is a real challenge => importance of assessing the systems’ quality. Comprehensive and correct use is another important factor => Importance of training the users Importance of assessing the users Motivation for incentives for the users. Brussels, March 30, 2012 7

    8. EHR Market: some considerations Very fragmented as expected May endanger quality of applications, though never proven. Not the privilege of the suppliers: also large number of “important stakeholders”. There is no one single nor homogeneous provision of healthcare in Europe, neither within one country Each profession needs a “different” application. Using the same application in several countries does not work. There is some market “concentration” Concentration of ownership No concentration of applications, even when the same name is used in different countries Brussels, March 30, 2012 8

    9. One of the project conclusions The only approach that may work seems to be to increase harmonisation within diversity, offering more and more “similar” (not identical), functions based on the same basic functional and quality specifications. Brussels, March 30, 2012 9

    10. Brussels, March 30, 2012 10 Roadmap towards a sustainable pan-European certification of EHR systems

    11. Verification versus Validation Verification = technical correctness of the software application or component of an application. Verification attempts to answer the question “is the software built right (rightly)?” => medical device directive ? Validation = compliance of the application to the consumer’s / user’s functional expectations: is the application offering what it is expected to do? Validation attempts to answer the question “is the right software built?” => procurement and functional validation ! Brussels, March 30, 2012 11

    12. Five areas for quality labelling and certification Data exchange facilities (incl. IOP) Functionality (incl. some aspects of IOP) Administrative and billing facilities Use related measurements and validation Software development quality (out of scope, not specific for EHR systems) => Different expertise , different organisations Dublin, November 17-18 12

    13. Actual Status of Quality Labelling and Certification Brussels, March 30, 2012 13

    14. Procedure and kind of attestation  

More Related