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

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
• Considered
3

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

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 public
most 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 Documentation
12

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 value
13

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

17. Dziękuję za uwagę!
dpz.m.zawisza@lodzkie.pl
17