1 / 20

The EuroRec Seal 2010

The EuroRec Seal 2010. Dr. Jos Devlies, EuroRec Sarajevo, August 31 st 2009. Quality and efficiency of care depends on, beside the ability to exchange data and the professional expertise also on the use and intrinsic quality of the software “instruments”.

gerik
Download Presentation

The EuroRec Seal 2010

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. The EuroRec Seal 2010 Dr. Jos Devlies, EuroRec Sarajevo, August 31st 2009

  2. Quality and efficiency of care depends on, beside the ability to exchange data and the professional expertise also on the use and intrinsic quality of the software “instruments”. What are the main “quality” requirements for an EHR? Reliability and Trustworthiness of the application Robust Functionality (does a system do what it has to do?) Usability (user friendliness) How do you measure these quality requirements? Evaluating the output (e.g. done by IHE) Using and Testing the application => Quality assessment How does a user or procurer know that quality has been evaluated and that a system meets the criteria? => Certification Why quality labelling and certification?

  3. Not at all limited to EHR system functional specifications as such Obviously also about data sharing, data exchange and semantic interoperability Even more…the complete “health infostructure” should be subject to quality assessment : archetypes, terminologies, ontology files etc… eHealth Quality Labelling

  4. EuroRec is NOT defining what’s required in a given care environment. EuroRec offers content and tools to anyone who wants to define such requirements, e.g. for an ICU, for home care, for neonatology… No “shall” or “should”, only descriptive statements. This is an important difference with HL7. EuroRec offers tools to select customised sets of criteria. Advantage: No need to agree on what is needed. No need to define / redefine and to ballot new versions of the sets of criteria. Is it possible to define a comprehensive set of requirements applicable cross-discipline and a fortiori cross border? There is no need to do so !!! National / regional and/or regulatory “authorities” can use the tools to select what’s important for them. EuroRec is NOT suggesting that these “professional profiles” aren’t important or valuable. What’s specific to the EuroRec approach?

  5. Testing as such is another activity: a more technical “validation against well defined criteria” on the basis of use or test scenarios. Example: IHE is testing exchangeability of care related (also administrative) data, with (still) the main focus on syntactic issues. Not defining the functionality of a system… other than validating the possibility to exchange data between systems. The capacity to exchange is as such a function: one of the many functions of an EHR. The capacity to exchange obviously impacts on the functionality. Testing and Labelling

  6. Neutrality – Independence EuroRec is not defining what’s required: independent of authorities Not representing important stakeholders Other side of the picture: how to get this funded? Multilingual More a service provider: statements and tools to be used when labelling health information systems and artefacts…e.g. doing the compliance tests is (actually) not our main/first point of attention. Other differences

  7. HITCHHealthcare Interoperability Testing and Conformance Harmonisation

  8. Decomposed from National Requirements. Local aspects removed Reworded in a consistent way. Does not include “regulatory” or “good practice” options => Purely “descriptive” statement. => To be considered as a domain specific “linguistic expression”. Attributes as mandatory/optional are defined at usage level, within a given “certification basket”. Requirements => Statements

  9. HL7 Criteria

  10. EuroRec Statements

  11. Statistics EuroRec Statements

  12. Multilingual: statement 2265

  13. A common/minimal basic set of criteria selected by “experts” to be committed in order to obtain the Seal. Goals of the Seal: Not to define the “best” EHR system Not the ambition to be “complete” Additional to certification done locally where use context and local requirements can be taken into account Content of the Seal: Addressing several “generic” issues such as reliability, trustworthiness and version management, confidentiality, access control, data entry and data display. The EuroRec Seal. What? Why?

  14. Seal 2008 had 20 very elementary functional requirements, addressing generic issues related mainly to reliability and trustworthiness of the applications, independent of the care setting. Composition of Seal 2008 available on the web site. Up to 125 candidate statements (out of +1.500) were selected extending scope to data entry and display as well as to access management and authentication. Still not at all specific for particular care settings. Voting form forwarded to EHR-QTN members (25 countries, mainly ProRec centres). Form on the web… to be completed by “experts”. Seal 2008 => Seal 2010

  15. Lowest Scores • Only 1 statement with less than 2,5 (50%)

  16. Highest scores • All these statements were yet required for the Seal 2008. • These are really essential requirements.

  17. Average product quality increases each time a (new) labelling is performed based on increased requirements. Induces convergence at conceptual and structuring level without impacting diversity of applications. The more we have similar functions with the same attributes, the more convergence, the more harmonisation of the systems. Functional harmonisation (with different flavours!) is essential to realise real interoperability Data exchange is validating “output”, on top of an application. Exchangeability improves interoperability, but will not be the final solution to realise that interoperability. Impact of a (cross-border) seal

  18. Cross border exchange (main focus of actual research) is only a first step towards interoperability. Even that first step and surely further and more performing interoperability requires “harmonisation” of the systems. That will take time… and progress will be realised with small steps. The EuroRec Seal is a good first step to that interoperability through harmonisation of the applications. Conclusion 1

  19. There is no contradiction between the HL7, IHE and EuroRec activities. They are complementary. CCHIT is actually doing / coordinating the whole process of: Defining what’s required (in cooperation with…) Providing the tools and scenarios to test compliance Doing the tests Providing the certificates EuroRec remains an “independent” organisation Conclusion 2

  20. Web site: www.eurorec.org Seal 2008 composition Seal 2010 voting form Seal 2010 first results (50 candidate statements) Material on the web site…

More Related