projekt ehr-qtn. ewaluacja kryteriów eurorec seal 2010-2011 - marcin zawisza

17
1 Projekt EHR-Q TN Ewaluacja kryteriów EuroRec Seal 2010-2011 Marcin Zawisza, Urząd Marszałkowski w Łodzi Konferencja 29 listopada 2012 r.

TRANSCRIPT

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

1

Projekt EHR-QTN

Ewaluacja kryteriów EuroRec Seal 2010-2011

Marcin Zawisza, Urząd Marszałkowski w Łodzi

Konferencja

29 listopada 2012 r.

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

2

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.

Podstawowe założenia

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

3

• Existing “national” certification

• Foreseen within 1-2 years

• Considered

Aktualna certyfikacja w Europie

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

4

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”.

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

5

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 !

Weryfikacja - Walidacja

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

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 organisations

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

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.

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

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.

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

9

Różne modele organizacyjne

Certification procedure Attestation granted

Third party assessment by a CAB being a public authority or an organisation granted power by a public authority either by law or by regulation.

Certificate

Third party assessment by a CAB on requirements issued by an organisation not empowered by law or by regulation.

Quality label

Self-assessment with an external audit. Conformity assessment is done by the supplier and documented to a third party, being a public entity, a professional organisation or an industry federation.

No “attestation” but a Quality Mark on the product is allowed

Self-assessment by vendor who performed testing on his own products and affirms that they conform to a given set of requirements.

Declaration of quality

mo

st s

uit

able

pro

ced

ure

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

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.

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

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.)

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

12

Rekomendacje dot. procesu certyfikacji

• Discretion and Confidentiality

• Impartiality

• Openness

• Distinct roles involved organisations

Independence

• Initial Documentation

• Rules of Evaluation

• Testing Documentation

Documentation of the process

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

13

Ryzyka

• Involvement of all stakeholders

• Distinguish generic and domain specific

• Consider national / regional variants

Content to be validated / tested

• Precise unambiguously the version of the SW

• Limit the validity to intended user group(s)

• Limit validity to region or country (if applic.)

Limitations of Certificate or Label

• Pay attention to effective use to realise full added value Effective Use

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

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.

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

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.

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

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 patient's 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)

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

17

Dziękuję za uwagę! [email protected]