III Jornada Asociación Madrileña de Calidad Asistencial

Transcription

1 The EuroRec Institute Dr. Jos Devlies Fundación Alcorcón, 15 December Topics The EuroRec Institute Importance of Quality Assessment of Health IT products EuroRec approach to quality assessment Compliance testing and certification Scenarios of quality assessment EuroRec Seals: towards cross border harmonisation EHR Q TN to support the process of certification Conclusions 2 1

2 The EuroRec Institute Not for profit organisation Federation of National Centres & Associated Centres 17 active ProRec Centres Active in: Research about EHR systems and their use Product Conformance to Quality Requirements 3 Mission Statement To promote and participate in research on development, implementation ti and use of health records. To promote efficiency, effectiveness and quality of health records. To advance and secure acceptance of comprehensive patient centred health records. To promote investment in health records and health informatics. To promote European and Global cooperation improving quality and interoperability of health records. 4 2

3 Main activities Support National ProRec centres. Initiate and Participate in research projects related to the EHR. Build a context for EHR Quality Conformance Testing for care and clinical research activities. Support authorities in introducing certification of health IT. Support EHR industry improving cooperation, benchmarking and procurement of the systems. 5 Importance of Quality Assurance of Health lhit Products 3

4 Health IT has a great potential To increase efficiency of care by Reducing useless and duplicated tests and interventions; Reducing cost of processing paper documents. To increase quality of care by Availability of shared interoperable patient data; Monitoring and enabling evidence based disease management; Integrating knowledge based clinicalsurveillance and decision support. We are not addressing quality of care as such: only one small but important aspect. 7 A big quality issue Qualityof the products assuchsuch very disparate, sometimes incredibly poor, not always offering what they promise. Poor availability of interoperable content due to a lack of standards insufficient use of these standards insufficient structuring of the content of these products. Enormous issue of no usage, under usage, wrong usage of even the best applications. 8 4

5 Quality Is never obvious. Is more than Exchangeability / Connectivity. Being understandable (human). Being reusable (machine reusability = interoperability). Requires high quality content (correct, precise and comprehensive data). High quality content can only be obtained: By applications able to produce high quality content By applications able to manage that information By users handling those applications properly Requires correct interpretation of that content. 9 Exchangeability EHR B ;,g:;, sdf:, EHR A ;:=;klkjjklj Correct use of syntax standards: HL7, Nonsense content possible: Not readable Readable but not to understandable 10 5

6 Interoperability: trendy concept? So many definitions: just one of IEEE The ability of two or more systems or components to exchange information and to use the information that has been exchanged. Means more than human understandable exchangeability. Interoperability means the ability to (re)use content by different applications outside the context of origin without new / complementary encoding 11 Interoperability Quality Weight 84 kg BMI 31,7 HbA1C 6,72% Cholesterol 212 mg% Diagnosis: hypertension EHR B EHR A Correct use of syntax and semantic standards Content: readable and understandable If correctly coded: translatable and machine interpretable Still not a guarantee for quality Still possible. 12 6

7 Exchangeable garbage is still garbage 13 EHR system Quality Requirements Connectivity & EHR B Interoperability Functionality Evolution Weight 84 kg BMI 31,7 HbA1C 6,72% Cholesterol 212 mg% Diagnosis: hypertension EHR A Reliability & Accountability Product quality 14 7

8 Connectivity & Interoperability To share patient information To connect devices and optimise input To support and manage clinical processes To integrate knowledge Quality Assurance, Certification and Interoperability of EHR systems 15 Functional quality The primary administrative and billing related functions (if required) are prerequisites. The system needs to provide all the functionality required by its user group: e prescription, patient safety monitoring, disease and prevention management, data sharing, decision support, care documentation,. The system needs to comply with national, regional or local requirements. Implementation has to be user friendly and configurable within predefined limits. Quality Assurance, Certification and Interoperability of EHR systems 16 8

9 Evolution Requirements are not eternal. Systems needs to be adaptable to new requirements. Authorities (public / private) needs procedures / means to enforce evolution. Quality Assurance, Certification and Interoperability of EHR systems 17 Reliability and Accountability Version management: eachchangechange is a new version Authorship: data entry and content responsibility Access traceability Audit logs for user / system interaction Confidentiality management Quality Assurance, Certification and Interoperability of EHR systems 18 9

10 EHR Product Quality Performance Correctly functioning Use and user friendly Configurable 19 Appropriate Use Weight 84 kg BMI 31,7 HbA1C 6,72% Cholesterol 212 mg% Diagnosis: hypertension EHR B EHR A EHR User Very few studies about the effective use of EHR application meaningful use : important step to quality Measuring will be an issue Appropriate use of the application Correct registration Correct clinical structuring Using standards Appropriate use of functions To interpret content To monitor care Less than 25% of functionality used 20 10

11 EuroRec approach to quality assessment of systems and their use We have a problem To express what we expect an application has to do. To document in a reliable way the functions of an application to optimise procurement of applications. To translate political and social functional needs in product requirements. To verify that these requirements are met To measure the appropriate use of the systems

12 We need a language To describe functionality. To describe requirements. To translate those requirements in product specifications. To redact test criteria and procedures to validate applications against these specifications. 23 EuroRec created A repository of functional descriptive statements Over statements A subset translated in 19 languages Extended to specialised areas as e.g. requirements for EHR systems as source for clinical trials data EuroRec does not define what s required Suggesting professional profiles. Leaving it to the authorities to decide what s important slightly different in each country (healthcare still national competence). Also less than best practice needs to be described

13 The EuroRec Repository III Jornada Asociación Madrileña de Calidad Asistencial 25 Countries of origin Belgium ( ) CCHIT (USA) HL7 Alberta (Canada) Ireland (GP IT) France (LAP) Denmark Meaningful use (USA) Clinical research (eclinical Forum) Austria (Lab functions) III Jornada Asociación Madrileña de Calidad Asistencial 26 13

14 Repository Statistics 27 Medicinal decision support related 28 14

15 HL 7 criteria 30 15

16 31 A set in Spanish: generic data attributes GS GS GS GS GS GS GS GS GS GS GS GS GS GS Cada versión de un ítem de salud tiene la fecha y la hora en que fue introducido en el sistema Cada versión de un ítem de salud tiene identificado un usuario responsable de su introducción efectiva. Cada actualización de un ítem de salud produce una nueva versión de dicho ítem. El sistema permite recoger la razón de la retirada o de la discontinuidad de un item sanitario. Cada versión de un ítem de salud tiene registrado su estado de actividad (p. ej., actual o activo, inactivo, histórico o pasado, completado, interrumpido, archivado). El sistema permite especificar para cada cambio de status del item sanitario la razón de ello. El borrado de un ítem de salud produce una nueva versión del mismo con el estado borrado. Cada versión de un ítem de salud tiene a una persona responsable de su contenido. Dicho responsable puede ser un usuario o una tercera parte. Cada cambio en el status de un item sanitario provoca una nueva versión de ese item sanitario. Cada cambio en el status de un item sanitario provoca una nueva versión de ese item sanitario. Para cada ítem de salud, el sistema puede presentar un histórico completo de sus versiones. El sistema permite precisar que una entrada de texto libre sea aceptada por ese item sanitaruio. El sistema permite precisar que se requieren datos estructurados para ese item sanitario. Un item sanitario puede ser la ausencia de una condición para un paciente dado

17 EuroRec created Tools to select statements for Test criteria for quality labelling Product procurement Product documentation A set of services to assist interested parties A validation service against cross-border subsets of quality requirements (EuroRec Seal) 33 EuroRec Use Tools III Jornada Asociación Madrileña de Calidad Asistencial 34 17

18 EuroRec Repository Use Flow Certifier EuroRec Baskets Documenter Composer Procurer EuroRec Repository Of Statements Certification Documentation Procurement Test Criteria Sets Scripter Test Scenarios Test Procedures 35 EuroRec Use Tools III Jornada Asociación Madrileña de Calidad Asistencial Compliance Testing and Certification 18

19 Importance of Compliance Testing The only way to be sure that a system: behaves as documented and expected by the (future) user accelerating adoption of EHR; can be used in order to obtain (content related) quality; complies with regulatory requirements regarding Functionality. Security. Interoperability. 37 Certificate >< Compliance Label HITCH project (INRIA, ETSI, MEDCOM, IHE, OFFIS, EuroRec) How to merge functional and interoperability testing. Compliance Label: An organisation tests a product on its conformance to a set of predefined requirements. Requirements based on an agreement between parties. Certificate: Certifier is entitled to do so on the basis of legal / regulatory rules 38 19

20 Scenarios and Stakeholders in Certification & Labelling Road to certification / labelling First step is always a political or a management decision. Two main roads: National or Regional highway Certification = initiated / organised by an authority Labelling = organised privately (e.g. professional organisation) Market driven road EuroRec offers services for both roadmaps 40 20

21 Highway to certification An organisation (professional organisation) or an authority decides to issue quality requirements for EHR systems. Defines / select interactively with users and providers a basket of descriptive functional statements. Documents the selected statements in a sufficient way to enable product development / upgrade. Issues a tender or contract to an organisation to Write test scenarios To validate applications against those criteria The authority grants the labels : certificate or conformance label. 41 EuroRec Seal acrossborder and market driven approach 21

22 EuroRec Seals How do you realise cross-border harmonisation of applications, able to produce similar quality? EuroRec approach: stepwise, based on more generic functional requirements. EuroRec issued two Seals Seal Level 1 : 20 mainly generic statements Seal Level 2 : 50 criteria also addressing security and confidentiality management. cfm Available in all the languages 43 Number Index Index Title Composition of the seal 12 A00 EHR Data Entry related 9 A02 EHR Content related 8 A03 EHR Structuring Data 22 A04 EHR Display 1 A05 EHR Data Exchange Services and Record Interfaces 14 A09 EHR Generic Data Properties 7 A10 Medication Management 3 A11 Clinical Statements Management 3 A14 Shared Care 2 A15 Clinical Decision Support: alerts, reminders 7 A22 Demographic Services 1 A32 Laboratory Services 4 A6 Health Information System management 23 A7 Privacy and Accountability Services 6 A8 Technical Security Services 44 22

23 Getting a Seal At the request of an application supplier. Tested by a local partner, considering local / national requirements. Alternative: linked to an extended national certification Comprehensive test documentation. Seal granted at European Level. Evolution: certification of modules. A possible way to progress: an authority requires a Seal for any public tender. 45 United Kingdom Austria Spain Belgium Slovenia Bulgaria EHR Q TN Project Slovakia Serbia Romania Portugal Croatia Cyprus Czech Republic Denmark 28 partners 24 countries Poland Norway Netherlands Germany France Estonia Luxembourg Italy Ireland Hungary Greece 23

24 EHR Q TN Thematic Network project To promote quality labelling and certification Main actions: > 70 workshop Development and Translation of Repository EHR Market Overview Roadmap to Certification 47 Who wins from certification? Patient: quite obviously: safer/better care Health authorities: Enabling / guaranteeing that better care Possible to enforce a strategy: how do you otherwise get a wish on the market / available at the point of care Care Professionals as users: Guarantee that a system fulfils it s promises Suppliers / industry: Unambiguous specification of market national requirements Market clearing possible on quality issues 48 24

25 Is labelling enough to guarantee quality? Having good systems is an important first step. This includes the function of sharing / exchanging patient information. Getting them used properly is another issue Education and training in structuring clinical content and reasoning using terminologies and coding schemes appropriately using their own application maintaining and updating the content of the patient records Stimulating the effective use Enforcing the use of EHR systems does not work Let the market do his job takes an eternity Incentives. => meaningful use in the USA, EHR bonus for the users Good quality of care is obviously more than good quality of the IT systems used: they are increasingly interdependent 49 Conclusions Health IT has enormous potentiality but at the same time a quality problem Interoperability will only be realised through product harmonisation Authorities should take their responsibility Quality of Health IT application should be an issue Research budgets should be limited to quality labelled EHR applications Effective use of quality labelled products should be stimulated (and measured) Industry and Users should be involved in the process

26 51 Quality Assessment for Clinical Research 26

27 Integrating Clinical Trials Criteria Cooperation with eclinical Forum They defined a set of Global Clinical Research User Requirements. 35 user requirements Endorsed by HL7 Comparable to our GPR ecf made a proposal for new GPR statements III Jornada Asociación Madrileña de Calidad Asistencial 53 Examples of EHRCR statements III Jornada Asociación Madrileña de Calidad Asistencial 54 27

28 Steps towards compliance A new B index (care setting) was added to the Repository in order to identify the specific setting of clinical research (B23). Mapping done between the EHRCR criteria and existing GPR. Indexing of GPR. Link FGS to the EHRCR (where applicable) and index the FGS. (B23) Create new FGS where needed d Create new GPR where needed Link FGS to the GPRs III Jornada Asociación Madrileña de Calidad Asistencial 55 EHRCR EuroRec Results 25 new GPR 26 GPR with as index B23 41 new FGS 71 FGS with an index B23 Mapping table..\..\..\..\repository\ehrcr input\mapping of EHRCR URs_for EuroRec Review Updated xls III Jornada Asociación Madrileña de Calidad Asistencial 56 28

29 New GPR III Jornada Asociación Madrileña de Calidad Asistencial 57 29