Your SlideShare is downloading. ×
Projekt EHR-Qtn. Ewaluacja kryteriów EuroRec Seal 2010-2011 - Marcin Zawisza
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Projekt EHR-Qtn. Ewaluacja kryteriów EuroRec Seal 2010-2011 - Marcin Zawisza

114
views

Published on

Published in: Health & Medicine

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
114
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Konferencja29 listopada 2012 r. Projekt EHR-QTN Ewaluacja kryteriów EuroRec Seal 2010-2011 Marcin Zawisza, Urząd Marszałkowski w Łodzi1
  • 2. Podstawowe założenia 1. Patients are too important to just suppose that EHR systems are trustworthy. 2. Patient data should not be locked into one system or application. 3. Patients essential data should be made available anywhere anytime to health professionals authorised to access them. 4. Patient has the right to request confidentiality of some data to be handled while taking full responsibility for that option. 5. Patients’ data accesses should be audit-trailed.2
  • 3. Aktualna certyfikacja w Europie • Existing “national” certification • Foreseen within 1-2 years • Considered3
  • 4. A recent Norwegian statement is an important one andbased on a large experience in certifying “messages”(certifying all kind of standards based data exchange).The Norwegian Ministry of Health and CareServices stated that “EHR Quality will be difficult toreach unless certification of the EHR systems ismade mandatory”.4
  • 5. Weryfikacja - Walidacja 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 !5
  • 6. 5 obszarów dla jakości i weryfikacji rozwiązań EHR 1. Data exchange facilities (incl. IOP) 2. Functional (incl. some aspects of IOP) 3. Administrative and billing facilities 4. Use related measurements and validation 5. Software development quality (out of scope, not specific for EHR systems) => Different expertise , different organisations6
  • 7. Powody certyfikacji rozwiązań EHR 1. Assure compliance to national rules and standards. 2. Increase quality of the products through coherent and pre-tested functionality. 3. Leverage exchange of health (care) related data and interoperability of systems. 4. Improve patient safety in care. 5. Have a reliable data source for secondary use.7
  • 8. Krajowa certyfikacja Consortium listed the top 5 enablers for a country wide certification: 1. Stimulate the use of certified EHR systems by creating incentives (€). 2. Create a legal framework enabling to define quality criteria for the EHR. 3. Initiate a cooperative platform involving all stakeholders to define domain / profession specific quality criteria for the different EHR settings (GP, secondary care, …). 4. Stimulate the use of certified EHR systems by offering services (e.g. simplification of administrative procedures). 5. Initiate a cooperative platform involving all stakeholders to define overall quality criteria for the EHR.8
  • 9. Różne modele organizacyjne Certification procedure Attestation granted Third party assessment by a CAB being a publicmost suitable procedure authority or an organisation granted power by a Certificate public authority either by law or by regulation. Third party assessment by a CAB on requirements issued by an organisation not empowered by law or Quality label by regulation. Self-assessment with an external audit. Conformity No “attestation” but a assessment is done by the supplier and documented Quality Mark on the to a third party, being a public entity, a professional product is allowed organisation or an industry federation. Self-assessment by vendor who performed testing on his own products and affirms that they conform Declaration of quality to a given set of requirements. 9
  • 10. Główne ryzyka  Lack of any decision to go for quality labelling and certification.  Insufficient resources to invest in certification bodies, CABs and in favouring the use of certified EHR systems.  Market fragmentation due to national / regional healthcare delivery systems, regulations and the multi-professional and multi-lingual European reality => limited resources.  Nationally defined functional and data exchange related criteria to be avoided, when possible.  Actual cross-border health-IT is dominated by solution provider for “technical” departments and services. Insufficient to guarantee quality expressed in reliability, trustworthiness and appropriateness of the content.10
  • 11. Rekomendacje z projektu  Legal and regulatory framework (Create and harmonise the legal and regulatory framework stimulating national or regional authorities to enforce the use of quality labelled and certified applications.Clarify the role of Directive 2007/47/EC regarding software development aspects, EHR functional aspects and Data-Exchange related issues.)  Involvement of stakeholders (Certification bodies should be accredited and compliant to international standards, more precisely ISO 17020. Favour cooperation between all service providers active in different areas of quality labelling and certification of EHR systems: administrative data exchange, clinical data exchange and system functionality.Create an advisory platform involving all stakeholders to agree on content and feasibility of requirements.)  Technical Framework (It is highly recommended to strengthen the European scale pioneering initiatives (EuroRec / I.H.E) in order to keep certification on the agenda. Invest in maintenance and expansion of the actual descriptive statements and profiles towards more completeness and towards including more “domain- or profession- specific sets”. Address the issue of personnel shortage in health informatics in general and more specifically in health informatics quality assessment.)11
  • 12. Rekomendacje dot. procesu certyfikacji • Discretion and Confidentiality • Impartiality Independence • Openness • Distinct roles involved organisations • Initial Documentation Documentation of • Rules of Evaluation the process • Testing Documentation12
  • 13. Ryzyka • Involvement of all stakeholders Content to be • Distinguish generic and domain specific validated / tested • Consider national / regional variants • Precise unambiguously the version of the SW Limitations of • Limit the validity to intended user group(s) Certificate or Label • Limit validity to region or country (if applic.) • Pay attention to effective use to realise full Effective Use added value13
  • 14. SEAL 1 1. Each version of a health item has a date and time of registration. 2. Each version of a health item has a user responsible for the effective data entry identified. 3. Each update of a health item results in a new version of that health item. 4. Each version of a health item has a status of activity, e.g. active or current, inactive, history or past, completed, discontinued, archived. 5. Deletion of a health item results in a new version of that health item with a status "deleted". 6. Each version of a health item has a person responsible for the content of that version. The person responsible for the content can be a user or a third party. 7. A complete history of the versions of a health item can be presented. 8. Each version of a health item has a date of validity. 9. The system enables the user to designate individual health items as confidential. 10. The system makes confidential information only accessible by appropriately authorised users. 11. Each health item is uniquely and persistently associated with an identified patient. 12. The system enables to assign different access rights to a health item (read, write,...) considering the degree of confidentiality. 13. All patient data can be accessed directly from the patient record. 14. Each patient and its EHR is uniquely and persistently identified within the system. 15. The system takes the access rights into account when granting access to health items, considering the role of the care provider towards the patient. 16. The system offers to all the users nationally approved coding lists to assist the structured and coded registration of health items. 17. Data entry is only done once. Entered health items are available everywhere required. 18. The pick lists and reference tables offered by the system are the same for all the users of the same application. 19. The system does not display deleted health items, audit logs excepted. 20. The system does not include deleted health items in clinical documentation or export, for audit purposes excepted.14
  • 15. SEAL 2 1. The system enables to link a role to a user. 2. The system shall include the information necessary to identify each patient, including the first name, surname, gender and date of birth. 3. The system enables the capture of all patient demographic data necessary to meet legislative and regulatory requirements. 4. The system displays all current health problems associated with a patient. 5. Each version of a health item has a date and time of data entry. 6. Each version of a health item identifies the actor who has actually entered the data. 7. Each update of a health item results in a new version of that health item. 8. The system supports the use of clinical coding systems, where appropriate, for data entry of health items. 9. The system presents a current medication list associated with a patient. 10. The system presents a medication history associated with a patient. 11. The current medication list can be printed. 12. The system support the use of a catalogue of medicinal products. 13. Each version of a health item has a status of activity, e.g. active or current, inactive, history or past, completed, discontinued, archived. 14. The system presents a list of the allergens with an active status. 15. Deletion of a health item results in a new version of that health item with a status "deleted". 16. Each version of a health item has a person responsible for the content of that version. The person responsible for the content can be a user or a third party. 17. Each change of status of a health issue results in a new version of that health issue. 18. A complete history of the versions of a health item can be displayed. 19. The system enables to document a patient contact. 20. The system is able to present all the documentation associated to a contact for that patient. 21. The system is able to present a list of the individual results for a discrete lab test for an individual patient. 22. Each version of a health item has a date of validity. 23. The system supports concurrent use. 24. The system enables the user to designate individual health items as confidential. 25. The system makes confidential information only accessible by appropriately authorised users.15
  • 16. SEAL 2 26. The system enables the implementation of a privilege and access management policy. 27. The audit trail contains the registration of users logging in or out. 28. The audit trail contains the registration of security administration events. 29. Audit trails cannot be changed after recording. 30. The system enables a user to change his password. 31. Security service issues and operation of the system are well documented. 32. Each health item is uniquely and persistently associated with an identified patient. 33. The system enables to assign different access rights to a health item (read, write,...) considering the degree of confidentiality. 34. All patient data can be accessed directly from the patient record. 35. The system distinguishes administrators, privileged users and common users. Administrators assign privileges and/or access rights to privileged and common users. Privileged users assign privileges and/or access rights to common users. 36. The system is available in the languages required by the regulatory authorities. 37. Each patient and his EHR are uniquely and persistently identified within the system. 38. The system is able to make a distinction between patients with same name, first name, gender and date of birth. 39. The system takes the access rights into account when granting access to health items, considering the role of the care provider towards the patient. 40. The system supports to all the users nationally approved coding lists to assist the structured and coded registration of health items. 41. Data entry is only done once. Entered health items are available everywhere required. 42. The system displays patient identification data (name, first name, age and sex) on each data entry interface. 43. The system displays, when prescribing a medicinal product, known allergies of the patient, if it does not alert the user for a specific allergen. 44. The system enables the user to modify patients administrative data. 45. The system distinguishes actual or active medication items from past medication items when including and displaying medication items in lists or in a journal. 46. The system enables the user to modify health items, if legally admitted. 47. The system has a timeout function, terminating a session after a configurable period of inactivity. 48. The system has a consistent way to present clinical alerts, e.g. red colour for abnormally and/or high lab results. 49. The system does not include deleted health items in clinical documentation or export, for audit purposes excepted. 50. A medication list presents at least the following elements: identification of the medicinal product (package), starting date, date of the latest prescription, dosing instructions (structured or as a textual expression)16
  • 17. Dziękuję za uwagę! dpz.m.zawisza@lodzkie.pl17

×