Certification of Medication Management Systems

1
Certification of Medication Management Systems
2

• Certification whats in a name.
• Do we need certification of EHR systems or of
  some of their functions?
• Stakeholders involved in any certification.
• Why certification of Medication Management
  modules?
• Does it exist somewhere?
• The EuroRec approach regarding certification in
  general.
• Classification indexes.
• From functional descriptions to test criteria and
  certification sessions.
• Functional descriptions in product documentation
  and procurement.
• The EuroRec tools
• Demo of the EuroRec Repository
• Processing a Referenced Statement
• Indexing a Fine Grained Statement
• Composing a Good Practice Requirement
• Translation and Management tools
• The EuroRec Composer

3
Certification whats in a name

• Certification can be defined as The process of
  granting, by an authorised / accepted body, of a
  compliance attestation to a set of precised
  functional and/or quality criteria for a given
  product or service.
• More than simply a validation of a product.
• Its not the selection of the best choice. This
  can be on top, based on non certified features.
• Certification adds a third party level to the
  validation of a function or application.

4
Why certification? Is there a need? Why investing
in certification?

• EHR systems are becoming complex and clinical
• More than simply store and retrieval systems
• Increasing importance of care management
  affecting the quality of care
• Increasing importance of being communicative
  supporting continuity of care.
• Expectations are therefore day by day higher and
  higher
• Integrated decision support and workplan
  management, resulting in better or at least more
  efficient care, requires reliable systems, that
  meets their ambition.
• Health Care Professionals want systems that meet
  their expectations.
• Patients want using thrustworthy and secure
  systems to be used.
• Product documentation sometimes from confusing
  to misleading
• Some functions are not addressed in the
  documentation
• Some documentation is not detailed enough
• Obvious functions are not alway present
• Purchasers / clients / users want to know what
  they buy
• Not always possible, as client, to validate all
  the functions
• Requirements are frequently misunderstood by the
  suppliers

5
Certification requires consensus between all
stakeholders

• An authority or organisation (healthcare
  authorities / or insurers (mainly the payers))
  they take the final decision on
• what should be certified
• how and by who testing is done
• level of compliance to be reached (not all at
  once)
• Someone (mostly the insurers and/or healthcare
  authorities) creates an incentive, promoting the
  use of certified systems (essential!)
• EHR Users (individual users as well as user
  representatives and professional bodies) should
  have their say in what, when and even more how.
• EHR System Providers needs to be involved from
  the start at equal level as the authorities and
  users, influencing priorities and feasibility
  of the certification criteria as well as the
  certification procedure.
• Certification body advising on feasibility and
  the how of the testing to be done.

6
Why certification of medication management?

• Medication management includes the whole process
  of prescribing, dispensing, administration as
  well as the registration and reporting on a
  medicinal treatment.
• Medication management seems to be the first area
  of (well)-reasoned containment of therapeutic
  freedom.
• 70 to 90 of the patients contacts result in a
  prescription or an adjustment of a medicinal
  treatment.
• Medication requires an important part of the
  healthcare resources.
• Prescribing is at the same time error prone, due
  to
• increasing complexity of the domain, of the
  healthcare in general
• shift evolution of care with new products with
  limited scope/indications, narrow therapeutic
  margins
• increasing importance of the cost/benefit ratio.
• Cost of medication errors is unacceptable.
  Savings can be huge by a 20 reduction of these
  errors.

7
Does or did such a certification exist somewhere?

• Specifically addressing the medication only a
  project in France, starting in 2008.
• Integrated as one of the functions of certified
  EHR systems
• Belgium, starting in 1999, first labelling in
  2002, including medication management. Now
  extended to dentist, home nursing,
  physiotherapists
• Denmark, since 2000, in primary care limited to
  message standards and data sharing
• The Netherlands, already in the late 80s, early
  90s but stopped
• Ireland, on voluntary basis in late 90s, in
  general practice, starting again with new
  criteria in 2007.
• USA (CCHIT), first certification in 2006.
  Important funding from health institutes.
  Certification for primary care as well as
  (starting) for secundary care.
• Canada (Alberta, Ontario and British Colombia)
• United Kingdom, an accreditation process for GP
  stystems to meet NHS criteria between 1989 and
  2001. Unclear how it evolves now.
• France for the Logiciels daide à la
  prescription to start in 2008..

8
EuroRec approach and goals

• EuroRec composes a generic and comprehensive
  repository of statements describing use functions
  (entry, display, export, decision support,
  access,...), structuring and data elements of
  Electronic Health Record systems, enabling
  cross-border multi-lingual description and
  validation or certification of those systems and
  use functions.
• EuroRec develops complementary tools
• To build user-defined certification sets of test
  criteria and to perform these system
  certification sessions. EuroRec Composer,
  EuroRec Certifier and EuroRec Scriptor.
• To document unambiguously and in a standardised
  way existing EHR products or functions. EuroRec
  Composer and EuroRec Documenter.
• To produce in a standardised comparable way
  procurement documentation regarding EHR products
  or some of their functions. EuroRec Composer and
  EuroRec Procurer.

9
EuroRec Quality Criteria Repository
The central repository of validated quality
criteria to be used to harmonise European quality
labelling, procurement specification and
documentation of EHR systems.
10
Differences and issues related to test criteria
at European level

• Sets of labelling criteria / functions to be
  validated are defined nationally
• Considering local (legal / regulatory)
  requirements e.g. regarding demographics,
  mandatory attributes to e.g. bllable acts,
  reporting.
• Considering preferences or favourite
  functions of the users.
• Considering local feasability and development
  efforts required
• mostly in the definition of the criteria
• sometimes only when defining mandatory / optional
  issues
• Intended user group
• Previous certification sessions
• Using sometimes local terminology.
• Similar criteria are exceptionally formulate in
  the same way.
• Most certification criteria are formulated as a
  SHALL or SHOULD...but the shall of one country or
  environment can be a should in another
  environment.
• Procedures on the other hand are very similar
  definition of criteria, test scenarios, testing,
  evaluation, appeal and/or second session

11
From reference... to functional descriptive
statements

• Identify and if required translate the
  reference(d) statements.
• Decompose the referenced statements in granular
  elements.
• Reduce functionality to generic and
  de-localised statements.
• Rephrase / reword the content of imposing /
  commanding statements into generic and
  descriptive fine grained statements
• OR
• Select one or more applicable previously defined
  fine grained statements.
• Indexing the statements for classification and
  retrieval purposes multiple indexing on three
  different axes
• Business functions generic as well as domain
  specific functions, e.g. medication. Classes for
  retrieval purposes, e.g. medicinal decision
  support as a sub section
• Care settings restrictions on / or typical
  environments of applicability, e.g. primary care
• Component type identifying a functionality, a
  knowledge nugget, a repository...

12
1. From Reference Statements to Fine Grained
Statements selecting the Reference Statement
Reference statements frequently include multiple
functions.
Extract of the Irish 2007 criteria for General
Practitioners Reference Statement
Multi-functional Statement
13
2. From Reference Statements to Fine Grained
Statements editor and linkage and indexing FGS
Linking an existing FGS
Editor
Indexing
14
Medication Prescription related Indices in the
EuroRec Repository
15
From functional descriptions... to certification
criteria

• Fine Grained Statements are recomposed in logic
  functional clusters, generic (e.g. overall
  attributes of data elements) or domain specific
  (e.g. related to medication) gt Good Practice
  Requirements
• Main differences with the Referenced Statements
• They represent universal Good Practice (the
  ambition at least). Not Best Practice!
• Content is independent of the context of
  certification and not intended to be used as such
  in a specific certification session.
• They have a mainly documenting finality and are
  used for retrieval purposes by the EuroRec
  Composer
• They are indexed as collection.
• There are Fine Grained Statements not included in
  a GPR.
• They fall apart in the certification baskets
  (collections of FGSs) all or only part of them,
  eventually with alternative statements.

16
Statistics
17
Overview Medication Prescription related
EuroRec statements
18
EuroRec Use Tools

• EuroRec Composer
• To compose user defined, re-usable and
  exchangeable baskets of Fine Grained Statements
• EuroRec Certifier
• To format a EuroRec Basket content to obtain the
  basic layer for the certification of EHR systems.
  This is done by adding structure and attributes
  to the selected Fine Grained Statements.
• EuroRec Documentor
• To document EHR systems and their functions,
  enhancing their understanding and comparability
  by using the EuroRec statements.
• EuroRec Procuror
• To list and describe, for purchase purposes,
  required functionalities and product
  characteristics using EuroRec statements.
• EuroRec Scriptor
• To produce and link Test Scenarios to EuroRec
  Baskets for Certification, Documentation and/or
  Procurement purposes.

19
From EuroRec Baskets of Statements
EuroRec Baskets
Certification
Documentation
Procurement
Test Criteria Sets
to... Certification and Validation of Products or
Functions
Test Procedures
Test Scenarios
20
EuroRec Repository... gt Free Access on
www.eurorec.org

• Select EuroRec Services
• Select Certification Criteria
• Register for Free Access

http//www.eurorec.org/services/certificationCrite
ria.cfm?selectioncertificationactiefservices
21
Certification as a means for what?

• Certification can be defined as The process of
  granting, by an authorised / accepted body, of a
  compliance attestation to a set of precised
  functional and/or quality criteria for a given
  product or service.
• More than simply a validation of a product.
• Adds a third party level to the validation of a
  function or application.
• Certification as a means to
• harmonise (existing / legacy) systems systems
  doing the same things the same way or at least
  with the same result
• by upgrading systems rather than eliminating
  systems
• increasing interoperability as a logical result
• stimulate / favour the use of high(er) quality
  systems
• Certification can be dangerous when used as a
  means to
• interfere / disrupt market
• reduce / eliminate competition, resulting in
• less development and progress
• less responsiveness of the market to new
  requirements / expectation
• finally less or extinguishing certification and a
  scanty market

22
Lessons learned...

• Certification without an incentive to the market
  has no sense.
• Negative incentive only certified applications
  are accepted / can be used... or can be
  sponsored.
• Positive incentive gratifying users of certified
  systems.
• Dont use certification for elimination of
  systems
• Improving quality and upgrading systems should be
  progressive.
• Reduction of suppliers will come anyway, natural
  wash-out.
• No bigger danger for innovation and progress than
  a lack of competition.
• Limit your ambition, accordingly to your
  resources
• Most countries sputtered after a couple of years.
• Yearly certification is exhausting, surely when
  new requirements are not limited.
• Consider different certification levels and/or
  certification of specific functions.
• Certification is not only very resource consuming
  for the suppliers, it may avoid them to assign
  sufficient resources to (new) functions not yet
  defined as to be certified but required by the
  users.
• Be aware that users does not always understand
  why an application isnt certified. Therefore
  always foresee a recover procedure and be
  discrete on systems that did not pass a session.
• It is not at all because an application enables
  the user to do something, e.g. problem oriented
  registration, that this functionnality will be
  used.