Certificats of Conformance by nkk75814

VIEWS: 32 PAGES: 29

More Info
									     IST- 027065 RIDE                                                                09/12/2010




                                                     RIDE
     “A Roadmap for Interoperability of eHealth Systems in Support
           of COM 356 with Special Emphasis on Semantic
                           Interoperability”



     COORDINATION ACTION
     PRIORITY 2.4.11 Integrated biomedical information for better health”: eHealth


RIDE D.2.1.1 – Current European practices in providing
interoperability in eHealth domain: KMEHR-BIS and
BE-HEALTH (Belgium)


  Due Date:                      June 15, 2006 (Month 4+45 Days)
  Actual Submission Date:        May 4, 2006
  Project Start Date:            January 01, 2006
  Project End Date:              December 31, 2007
  Project Duration:              24 months
  Leading               Contractor METU-SRDC
  Organization:
 Document History:

 Version      Date                   Changes                                                    From      Review

 V0.1         Feb. 8, 2006           Initial version created                                    METU      All partners

 V0.2         Apr 17, 2006           Additions in several chapters                              EuroRec   All partners

 V0.3         May 3, 2006            Final version                                              METU      All partners




                 Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)

                                                            Dissemination Level

PU      Public
PP      Restricted to other programme participants (including the Commission Services)
RE      Restricted to a group specified by the consortium (including the Commission Services)                            X
CO      Confidential, only for members of the consortium (including the Commission Services)
    IST- 027065 RIDE                                                                    09/12/2010



                                                               RIDE Consortium Contacts:


No     Organisation     Street name      Post      Town/        Country    Title      Family Name    First Name     Phone No        Fax No         E-Mail
                        and number
                                         Code       City         Code
1     METU-SRDC        Inonu Bulvari     06531     Ankara       Turkey    Prof. Dr.      Dogac        Asuman        +90-312-     +90(312)21010 asuman@srdc
                                                                                                                    2105598           04        .metu.edu.tr
2         OFFIS         Escherweg 2      26121   Oldenburg     Germany      Dr.        Eichelberg      Marco        +49-441-     +49-441-9722- eichelberg@o
                                                                                                                    9722-147          102          ffis.de
3        IFOMIS           Campus         66041   Saarbrücken   Germany     Prof.         Smith         Barry       +49(0)681/30 +49(0)681/302   phismith@bu
                        Saarbrücken                                                                                  2-64777       -64772         ffalo.edu
4       EUROREC          co IDISS -      42400      Saint       France    Prof. Dr      De Moor       Georges                    +32-9-2403439 georges.demo
                        Croix-Rouge               Chamond                                                             +32-9-                   or@ugent.be
                         Française                                                                                   2403421
                       route de Platon
5         CNR          Piazzale Aldo     00100     Roma          Italy     Prof.       Rossi Mori      Angelo       +39 06 86    +39 06 86 090 angelo@itbm.
                          Moro 7                                                                                     090 250          340        rm.cnr.it
6      NTUA, ICCS       42, Patision     10682     Athens       Greece     Prof.        Mentzas       Gregoris     +3021077238 +30210772355 gmentzas@so
                           street                                                                                      95           0        ftlab.ntua.gr
7      NUIG, DERI        University       na       Galway       Ireland    Prof.         Vitvar        Tomas         +353 91        +353 91     tomas.vitvar
                           Road                                                                                      495270         495270       @deri.org
8         IHE-D        Stresemannalle    60596    Frankfurt    Germany     Prof.         Wein        Berthold B.   +49-241-559    +49-241-559   wein@radiolo
                            e 19                                                                                      559 1          558 2      gie-aachen.de
9         OLE          Hazenakkerstra B9520      Zonnegem       Belgium     Dr.         Ceusters      Werner       +32 475 486         -        werner.ceuste
                           at 20a                  (Sint-                                                              587                      rs@ecor.uni-
                                                  Lievens-                                                                                       saarland.de
                                                  Houtem)
1     INTRODUCTION ............................................................................................................................... 5
2     EXECUTIVE SUMMARY ................................................................................................................. 5
3     QUALITY LABELLING OF EHRS IN BELGIUM ........................................................................ 5
4  KMEHR-BIS: KIND MESSAGES FOR ELECTRONIC HEALTHCARE RECORD -
BELGIAN IMPLEMENTATION STANDARD........................................................................................ 8
    4.1    OVERVIEW OF THE KMEHR MESSAGE ................................................................................................ 9
    4.2    CODES..............................................................................................................................................10
    4.3    LINKS ...............................................................................................................................................11
    4.4    KMEHR SERVICES ..........................................................................................................................12
5     ONGOING RESEARCH AND DEPLOYMENT PROJECTS AND BE-HEALTH.....................13
6     APPENDIX 1: THE KMEHR FORMAT .........................................................................................14
7  APPENDIX 2: EXAMPLE, SCENARIOS 2003 FOR QUALITY LABELLING OF EHRS IN
BELGIUM (VERSION IN FRENCH) .......................................................................................................17
1    INTRODUCTION

RIDE is a roadmap project for interoperability of eHealth systems leading to recommendations
for actions and to preparatory actions at the European level. This roadmap will prepare the ground
for future actions as envisioned in the action plan of the eHealth Communication COM 356 by
coordinating various efforts on eHealth interoperability in member states and the associated
states. Since it is not realistic to expect to have a single universally accepted clinical data model
that will be adhered to all over the Europe and that the clinical practice, terminology systems and
EHR systems are all a long way from such a complete harmonization; the RIDE project will
address the interoperability of eHealth systems with special emphasis on semantic
interoperability.This document is a survey on the current practices in Belgium eHealth initiatives.

2    EXECUTIVE SUMMARY

Belgium has since long (i.e. since the 2nd European Framework Programme) been active in ICT
for Health through its participation in a vast number of European research projects in respectively
Medical Informatics, Health Telematics and eHealth. These projects have been directly or
indirectly impacting on today’s Belgian eHealth. Besides the establishment of a number of
eHealth spin-off companies, many of these European R&D projects have also resulted in the
creation of important/ strategic structures, both in Europe (CEN TC/ 251, Founding Chairman:
Prof Dr Georges De Moor) and in Belgium (the Ministerial Committee for Health Telematics
Standardisation, Moniteur 3 May, 1999; modified on 15 December,2005). This Committee started
its work by developing a specific Health Telematics “vision and strategy” which has been
published in a booklet called “Building Bridges”. Since then, this committee and its seven
working groups have drafted a series of national recommendations (adviezen/ avis) which can be
found at http://www.health-telematics.be (! a new website and address is now under
construction). This document focuses on only three but important outputs of the Belgian
endeavour:
    1. The existing Belgian system for quality labeling of electronic health records in
       ambulatory care;
    2. The standardisation of messages (in particular the KMEHR message);
    3. The ungoing deployment projects and the creation of the BeHealth platform.
The above three topics have been selected for they all are directly or indirectly related to
interoperability issues.




3    QUALITY LABELLING OF EHRS IN BELGIUM

In the past Electronic Healthcare Record systems were used to register non-critical administrative
information, where the potential for harm to the patient was low. The current information
requirements to perform accurate medical decision making increasingly justifies the use of
complex, efficient and advanced EHRs.
The potential for harm may equally lie in the system design such as failure in design logic, poor or
confusing presentation of clinical relevant information and even failure in logic. Some of these
system deficiencies are insidious and may be invisible to the healthcare professional.
These developments require a throughout quality assessment of the EHR informatics products
available on the market that are developed to store both administrative and clinical data. Quality
labelling becomes a necessity to limit the risk of harming the quality of the care delivery process.
Healthcare information in particular clinical information is often scattered over a number of
informatics systems (primary care, secondary care…).
The official Quality labelling of Electronic Healthcare Records started in Belgium in 2000. The
quality labelling of software packages for EHRs was initially developed for ambulatory care and
for software packages used by General Practitioners in their private practices. Progressively the
quality labelling of EHRs was extended to other software packages i.e. physiotherapy, dentistry
and recently nursing and pharmacy. The operation of the quality labelling/certification procedure
                                                         .
falls under the responsibility of the Ministry of Health
Quality labelling in Belgium focuses on:
       The verification of compliance to legal and ethical aspects of data protection
        when storing patient information (administrative and clinical);
       Verification of the respect of patient’s privacy when archiving confidential data;
       Providing access to reference documents, healthcare databases (drug
        information), validated means to support clinical decision making;
       Verification of the implementation of the interoperability criteria allowing the
        exchange of patient records between different software package
        implementations, without the loss of clinical information, e.g. the import from and
        export to the summary patient record, called “SumEhr”.
History: in 1999 ProRec-BE was asked to develop evaluation criteria to support the “quality label”
of GP software systems. Initially 333 criteria were identified. It was agreed that conformance
testing of these 333 criteria at once would not be feasible taking into account the reality of the
market. It would have resulted in a failure of all software packages in the market. It was decided
to set up a working group with the software vendors to define year after year the criteria to be
tested. This working group was then called the “Transfer” group.
The “Transfer” working group consisted of representatives of the EHR software industry, end-
users, independent experts appointed by the Ministry of Health, representatives of several
scientific associations. This group became later the working group “LABELLING” of the Ministerial
Committee of Health Telematics Standardisation who defines the criteria that should be tested
during next years’ benchmarking sessions. The criteria need to be regularly adapted, others need
to be made more explicit. The criteria defined 5 years ago have therefore to be reviewed every
year depending on the current evolution of technology, standardisation, coding systems,
legislation etc.
Once the criteria agreed in the above working group, subgroups start finalising the testing
scenarios. These testing scenarios are developed by experts appointed by the ministry of health.
The scenarios represent a consistent case (as close as possible to a real situation), and are
developed to a sufficient level of detail so that unambiguous benchmarking can be organised.
Every detailed step of a scenario comprises a reference to the criterion or sub-criterion that is
tested. Examples of a test scenario are given in the Annex of this chapter. The scenarios are
available in Dutch and French. The example test scenario in annex has been used for the
benchmarking session in the quality labelling exercise of 2003.
The scenarios and preparative instructions have to be made publicly available through the WEB
site of the Federal Ministry of Health minimum three months before the benchmarking sessions.
Software vendors have to subscribe to the benchmarking session days. The benchmarking
                                               th
sessions of 2006 will be organised Friday the 9 of June and Saturday the 10th of June.
End users assisted by the software vendor personnel, have to manipulate the software during the
benchmarking session. The software vendors presence is only allowed to provide technical
specifications upon request of the examinators (experts appointed by the Ministry of Health – The
examination-experts are different from the ones involved in the development of the scenarios).
The experts can only evaluate the functionality and not at all the presentation or the way the
function has been implemented. This remains the responsibility and the exclusive authority of the
software vendor.
After the benchmarking sessions a deliberation session takes place between the representatives
of the Ministry of Health and the examination experts. Until now, no software vendors are allowed
during the deliberations in spite of many requests of the software industry. The final results of the
deliberation session are due within 15 days after the testing via the WEB site of the Federal
ministry of Health.
Once the list is published, users of the successful software packages can apply for subsidies at
the Ministry of Health. Since 2000 the Belgian Health Third Party Payer (RIZIV, INAMI/ the
insurer) selected the “sponsoring” model as the only model to improve the quality of the
Electronic Healthcare Record software. Every user who is using labelled software in his daily
medical practice can apply for a yearly financial support of 743 € upon delivery of an invoice for
maintenance of his EHR software application.
No costs are involved for the software vendors. The procedure, invitation of experts (examination,
scenario development) is entirely financed by the Ministry of Health.
Every year a number of criteria are refined and adopted for the labelling procedure of that year.
These criteria are then used in the test scenarios. The basic full list of criteria is available in Dutch
and in French. The list of criteria has been structured along the following classification:
    1. General criteria: (e.g. the software should be conceived for the management of patient
        records in primary care)
        1.1. Security aspects link to the application access
        1.2. Data Availability
    2. Administrative data management
        2.1. Patient Identification
        2.2. File’s access
        2.3. File’s characteristics
        2.4. Patient’s personal characteristics
        2.5. Insurability data
        2.6. Administrative period management (e.g. hospitalisation, …)
    3. Medical data
        3.1. Nature and content
        3.2. Overview
        3.3. Codes and internal dictionaries
        3.4. Specific interfaces
            3.4.1. Drug prescription
            3.4.2. Vaccination
            3.4.3. Prevention
            3.4.4. Ergonomic aspect
    4. Data structure
        4.1. Health Care element
        4.2. Health Approach
        4.3. Contact
        4.4. Sub-contact
         4.5. Service
    5. Decision support
    6. File management support
         6.1. Schedule
         6.2. Production of document and reports
    7. Coordination, connectivity, communication
         7.1. Import of documents
         7.2. Export of standardised messages documents
         7.3. Received messages management
         7.4. Encryption
    8. Requests: data extraction
         8.1. Data extraction
         8.2. Export and de-identification of data
    9. Medical and legal aspects
    10. Electronic signature
    11. Service and continuity
         11.1. User documentation
         11.2. Technical documentation
         11.3. Contractual after sales services

Detailed scenarios have been used during benchmarking sessions to certify the different software
applications presented for labelling. The scenarios are structured along the following lines:
    1. Preparative activities
        1.1. Equipment
        1.2. Software (EHR application)
        1.3. Documents and software documentation
        1.4. Patients setup
        1.5. Lab data
        1.6. Referrals
    2. Test session
        2.1. Start
        2.2. Enter patient data
        2.3. Simple case
        2.4. Structured case
        2.5. Vaccination section
        2.6. Care planning
    3. Help, structure of the screens (display)
    4. Docs and reports (mainly official reporting to Health insurance)
    5. Selection of data
    6. Closing of a session and saving patient data.




4   KMEHR-BIS: KIND MESSAGES FOR ELECTRONIC HEALTHCARE
    RECORD - BELGIAN IMPLEMENTATION STANDARD

In Belgium a conceptual message format was developed, based on previous work of the CEN.
This theoretical model describes the different objects needed to build a message for the exchange
of a whole electronic healthcare record.
         This format has been implemented using XML syntax through the KMEHR project
(http://www.health.fgov.be/telematics/kmehr/one/) funded by the Belgian federal Ministry of
public health and assessed in collaboration with Belgian industry.
         In 2000, a working group was set up by the Belgian National Commission “Telematics
Standards in relation to the Health Sector” in order to produce a simple, minimal and practical
framework for the exchange of clinical data. The experts’ work has been based on previous
national and international work (including CEN, HL7 and GEHR works, as well as some
commercial systems). Based on the needs of many on-going projects and using existing material
as much as possible (e.g. existing codes), about 20 specific XML messages have been produced
(the Kind Messages for Electronic Healthcare Records - Belgian Implementation Standard or
KMEHR-bis).
         The Kmehr-Bis specification process has been used by the following implementation
projects:
     Development of the Patient Document Server at the CHU of Charleroi
     Development of the Flemish vaccination interactive database
     Development of the Electronic Pharmaceutical Prescription project of the EMDMI
         working group
     Development of the Referral letter of the ACTH on top of the S3 server (IRIS network
         and the Federal Ministry of Health)
     Development of the interface between PDA's and GP software (Euremis)
     Distribution of radiology images and protocols by the CHU of Charleroi (with Siemens,
         Intranet carolo, Brutele and the Walloon Region)

       Kmehr Bis does not aim to standardize all medical matters. The mission is to propose an
immediately usable XML format to exchange key medical transactions in Belgium. It follows the
activities (more particularly) of the HL7 CDA specification. In the future, it planned to convert
Kmehr format to the HL7 CDA standard using simple XSL-T.

4.1   Overview of the Kmehr message




                             Figure 1 Overview of KMEHR Message
A Kmehr message is composed of a header and at least one folder. The header describes the
sender, the recipient(s) and a few technical statuses. The folder gathers the information about one
patient. Each folder identifies the subject of care (patient) and contains at least one medical
transaction.
         The transaction gathers the information reported by one healthcare professional at a given
instance. It can be a consultation report, a laboratory result, a drug prescription, a discharge letter,
etc. The transaction has the key attributes: type, author, date and time. A transaction can not
contain another transaction. Kmehr-Bis proposes a dictionary of transactions.
         A transaction can be organized using optional headings. For example, a discharge letter
could make use of the following headings: patient history, current treatment, clinical findings,
technical findings, assessment, proposed treatment, etc. The clinical information can be placed as
free text directly within the transaction or within headings. Headings can be nested to represent
chapters and paragraphs. Kmehr-Bis proposes a dictionary of headings.
         The clinical information can be described using optional items like allergy, reason for
encounter, complaint, risk factor, medication, etc. Items can be placed directly within the
transaction or within headings. Kmehr-Bis proposes a dictionary of items. Their content can be of
various datatype's: free text, number, date or coded value. Items can be further described using a
set of elements like: severity, certainty, quantity, unit, etc.
         The following XML fragment shows the structure of a Kmehr message:

<kmehrmessage>
  <header>
  </header>
  <folder>
    <patient> ... identification of the patient ...    </patient>
    <transaction>
      <item> ... type of encounter ...        </item>
      <item> ... date of encounter ...        </item>
      <heading>
        <item> ... diagnosis ...         </item>
      </heading>
      <heading>
        <item> ... drug delivery ...         </item>
        <item> ... drug prescription ...          </item>
      </heading>
    </transaction>
  </folder>
</kmehrmessage>

      Kmehr-Bis XSD schema is available at the following URL:

http://www.chu-charleroi.be/kmehr/xsd/kmehr.xsd

        Furthermore, an example message in Kmehr format is presented in appendix.

4.2   Codes
Using Kmehr-Bis you can transfer the same information as pure free text as well as fully coded
and structured text.
        Kmehr-Bis proposes a set of dictionaries: transaction types, heading types, item types,
severity levels, administration routes. In parallel with those national codes, the structure always
supports international or local codes.
        Four levels of coding are referred in a Kmehr message:
          The first level requires that transactions are coded using the national dictionary. All
           Kmehr messages must have a coded transaction type. The rest of the information can
           remain as free text.
          The second level consists in coding headings.
          The third level consists in coding items.
          The fourth level consists in coding the content of the items.

       In the following figure, some example codes that can be referred from transaction,
heading and item elements are presented.




                                         Figure 2 Example Code
      Kmehr-Bis proposes simple reference tables to ensure a minimal normalisation of Belgian
healthcare communication. Besides the mandatory national codes, proprietary or international
codes can be used at the item content level.

4.3       Links
The concept of links is important within Kmehr-Bis to support advanced features like:
    The link to an external object (an image on a web server, another Kmehr message
       somewhere on the internet).
    The link to an internal object (an embedded multimedia object within the message itself).
       This can be used to transfer a Word or a PDF document for example.
    The order-result communication process.
    The history of versions of a same message (replacements, cancellation, ...).

The lnk element represents a link in a message. When inserting a multimedia object in the
message itself, an empty URL has to be specified and the binary data should be inserted in the lnk
as follows:

<lnk TYPE="multimedia" MEDIATYPE="application/msword" URL="">...your word file as
binary data...</lnk>

           It is also possible to specify that the object is located on a remote web server:

<lnk TYPE="multimedia" MEDIATYPE="image/jpeg" URL="http://www.s3.org/document-
number.jpg"/>
4.4   KMEHR services
With the emerging of medical web servers (hospital medical records, regional servers like the S3,
Vaccination on-line database of Kind & Gezin) in Belgium, there is a need to standardise the
exchange of data between those servers. The W3C recommends the usage of Web services for
that purpose. This is based on the SOAP (XML) specification.
        Therefore, the Kmehr-Bis specification is extended with a few request and response
elements to offer standard services on top of Belgian medical web servers.
        The following key services were identified that are expected from medical servers:

                                    Table 1Standard Services

Name of the service Description
GetTransactionList    This is a service that allows an application to interrogate a medical web
                      server, to get a list of transactions (= medical documents) that match a set
                      of criteria: the patient unique identifier associated with a free combination
                      of 0, 1 or several transaction types, 0 or 1 author, a period of time defined
                      by a begin date and/or an end date, and 0 or 1 encounter number.

                      A hospital medical server that supports that standard Kmehr service is able
                      to answer the question: "Have you a list of documents of the type
                      discharge letter, older than 01/01/2001, for patient 62031011931?" .

                      The answer to such a question is a set of transaction headers within a
                      Kmehr response element. The Kmehr header contains key information for
                      each transaction like: unique Kmehr transaction identifier, transaction
                      type, author, date, time, etc ...


GetTransactionDetail This is a service that allows an application to interrogate a medical web
                     server, to get the complete transaction (= document) that matches a
                     transaction Kmehr unique identifier. The response is a standard Kmehr
                     message encapsulated within the response element.

                      Typically, an application would interrogate the regional server with a
                      GetTransactionList. It would the display the list of transaction headers to
                      the user. The user would then make its choice. The application will then
                      call the GetTransactionDetail service to access to the full document, using
                      its unique Kmehr transaction identifier.


PutTransaction        This is a service that allows an application to put a Kmehr transaction
                      within a medical web server as a standard Kmehr message.
                      A regional medical server that supports that standard Kmehr service is
                      able to receive and store a standard kmehrmessage.


PutTransactionHeader This is a service that allows an application to declare a Kmehr transaction
                     within a medical web server, using the same transaction header element as
                     the GetTransactionList web service.
                      A hospital medical server could declare some of its transactions (=
                      medical documents) to the regional server using this web service. The
                      information contained within the transaction headers is used to index the
                      document properly and allow users to make their choice. The regional
                      server can recall the hospital's URL of the document (that is stored within
                      the lnk element) on demand.


DeleteTransaction     This is a service that allows an application to delete a Kmehr transaction
                      within a medical web server, passing its unique Kmehr transaction
                      identifier. Usually the server will hide the transaction instead of physically
                      delete it.
                      A regional medical server that supports that standard Kmehr service is
                      able to hide a transaction upon request of an authorised external
                      application.



         It is possible that the requesting party do not know the ID-PATIENT of the patient. In
that case, an empty <id S="ID-PATIENT" SV="1.0"/> element must be placed to signify
explicitly that the patient is not known. This indicates that it was not an omission. Then an
alternative id of the requestor’s choice can be added (identity card number, the patient number
within the requestor’s system), like:

        <id S="LOCAL" SL="MyPatientNumber" SV="1.0">1234567890</id>.

        IT Systems are not obliged but could do the matching of patient using this alternate id or
firstname/familyname/sex/birthdate/address.
        Hospitals like the CHU of Charleroi or CHNDRF at Charleroi are currently developing
the same interface. Other standard web services could also be specified to manage patient and
party identification: GetPatientList, GetPatientDetail, PutPatient, DeletePatient, GetHCPartyList,
GetHCPartyDetail, PutHCParty, DeleteHCParty.
        The complete information for the input/outputs of these Web services are presented at the
Kmehr services XSchema (http://www.chu-charleroi.be/kmehr/xsd/kmehrservices.xsd).

5   ONGOING RESEARCH AND DEPLOYMENT PROJECTS AND BE-
    HEALTH

Much effort is being made by the federal Ministry of Health in the area of B2B applications. As
part of the initiative of the "SFP Santé Publique" a thematic sector-related portal, called Be-
Health, has been created (23 December 2004). It aims at interconnecting applications from a
number of eHealth stakeholders, mainly social security actors, but intends to become over time an
important access point for all other users (including clinicians) as well (see: http://www.health-
telematics/behealth ).
A number of projects and activities have also been launched in parallel (acronyms: RIM2,
ELODIS, CODENTAL, KINELECTRICS, HEPI-GO, FLOW (Alfa, Beta, Gamma), BePrescript,
KMEHR Love, KMEHR Live, BeHEALTH, THESAURUS, KMEHR Lab, HEPI-Gone, HISABEL,
KMEHR+, REGISTERS).
These projects are followed up by the seven working groups (DATA, SECURITY, ARCHIVES,
BeHealth, NURSING, LABELLING, TELEMEDICINE) of the ministerial Heath Telematics
Committee (see above).



6   APPENDIX 1: THE KMEHR FORMAT

As an example to how a message is represented in KMEHR Format, assume that a doctor (Dr
Alain Juvenois) would like to send the contact report depicted in Figure 3 to another doctor (Dr
Jean-Pierre Rochet).
 Dear Dr Jean-Pierre Rochet,

 Your patient Jean Dubois came on our emergency unit on 01/10/2001.
 He presented a serious infection of the left hand caused by a tropical insect bite.
 I have performed a Tevax injection 0,5ml IM and prescribed Augmentin 3*500mg
 daily for 5 days.

 Sincerely yours,
 Dr Alain Juvenois
                                    Figure 3 Example message
The Kmehr representation of the above contact report is as follows:

<kmehrmessage
 xmlns="http://www.health.fgov.be/telematics/kmehr/schema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.health.fgov.be/telematics/kmehr/schema
 ..\xsd\kmehr.xsd">
 <header>
   <standard>
    <cd S="CD-STANDARD" SV="1.0">20021205</cd>
   </standard>
   <id S="ID-KMEHR" SV="1.0">71071801.tutorial</id>
   <date>2001-10-02</date>
   <time>06:03</time>
   <sender>
    <hcparty>
         <id S="ID-HCPARTY" SV="1.0">71071801</id>
         <cd S="CD-HCPARTY" SV="1.0">orghospital</cd>
         <name>CHU de Charleroi</name>
    </hcparty>
    <hcparty>
         <cd S="CD-HCPARTY" SV="1.0">deptemergency</cd>
    </hcparty>
    <hcparty>
         <id S="ID-HCPARTY" SV="1.0">15858523580</id>
         <cd S="CD-HCPARTY" SV="1.0">persphysician</cd>
         <firstname>Alain</firstname>
         <familyname>Juvenois</familyname>
    </hcparty>
   </sender>
   <recipient>
  <hcparty>
        <id S="ID-HCPARTY" SV="1.0">115259412004</id>
        <cd S="CD-HCPARTY" SV="1.0">persphysician</cd>
        <firstname>Jean-Pierre</firstname>
        <familyname>Rochet</familyname>
  </hcparty>
 </recipient>
</header>
<folder>
 <id S="ID-KMEHR" SV="1.0">1</id>
 <patient>
  <id S="ID-PATIENT" SV="1.0">32031011931</id>
  <id S="LOCAL" SL="ISPPC-ID-PATIENT" SV="3.4">3001234</id>
  <firstname>Jean</firstname>
  <familyname>Dubois</familyname>
  <birthdate>
        <date>1932-03-10</date>
  </birthdate>
  <sex>
        <cd S="CD-SEX" SV="1.0">male</cd>
  </sex>
  <address>
        <cd S="CD-ADDRESS" SV="1.0">home</cd>
        <country>
         <cd S="CD-COUNTRY" SV="1.0">be</cd>
        </country>
        <zip>6044</zip>
        <city>ROUX</city>
        <street>Rue du coucou</street>
        <housenumber>6</housenumber>
  </address>
 </patient>
 <transaction>
  <id S="ID-KMEHR" SV="1.0">1</id>
  <cd S="CD-TRANSACTION" SV="1.0">contact</cd>
  <date>2001-10-01</date>
  <time>15:25</time>
  <author>
        <hcparty>
         <id S="ID-HCPARTY" SV="1.0">15858523580</id>
         <cd S="CD-HCPARTY" SV="1.0">persphysician</cd>
         <firstname>Alain</firstname>
         <familyname>Juvenois</familyname>
        </hcparty>
  </author>
  <iscomplete>true</iscomplete>
  <isvalidated>true</isvalidated>
  <item>
        <id S="ID-KMEHR" SV="1.0">1</id>
        <cd S="CD-ITEM" SV="1.0">encountertype</cd>
        <content>
         <cd S="LOCAL" SL="MyADTSYstem" SV="3.4" DN="Consultation" L="fr">CONS</cd>
        </content>
  </item>
  <item>
        <id S="ID-KMEHR" SV="1.0">2</id>
     <cd S="CD-ITEM" SV="1.0">encounterdatetime</cd>
     <content>
      <date>2001-10-01</date>
     </content>
</item>
<heading>
     <id S="ID-KMEHR" SV="1.0">3</id>
     <cd S="CD-HEADING" SV="1.0">assessment</cd>
     <item>
      <id S="ID-KMEHR" SV="1.0">1</id>
      <cd S="CD-ITEM" SV="1.0">healthissue</cd>
      <content>
        <text L="en">infection due to tropical insect bite</text>
      </content>
      <severity>
        <cd S="CD-SEVERITY" SV="1.0">veryabnormal</cd>
      </severity>
      <site>
        <text L="en">left hand</text>
      </site>
     </item>
</heading>
<heading>
     <id S="ID-KMEHR" SV="1.0">4</id>
     <cd S="CD-HEADING" SV="1.0">treatment</cd>
     <item>
      <id S="ID-KMEHR" SV="1.0">1</id>
      <cd S="CD-ITEM" SV="1.0">medication</cd>
      <content>
        <medication>
         <cd S="CD-DRUG-CNK" SV="1999">0135418</cd>
         <tradename>Tevax amp 0,5ml</tradename>
         <presentation>
               <cd S="CD-DRUG-PRESENTATION" SV="V1.0">injsol</cd>
         </presentation>
         <strength>
               <decimal>0.5</decimal>
               <unit>
                <cd S="CD-UNIT" SV="1.0">ml</cd>
               </unit>
         </strength>
         <route>
               <cd S="CD-DRUG-ROUTE" SV="V1.0">intramuscular</cd>
         </route>
        </medication>
      </content>
      <lifecycle>
        <cd S="CD-LIFECYCLE" SV="1.0">administrated</cd>
      </lifecycle>
      <quantity>
        <decimal>1</decimal>
      </quantity>
     </item>
     <item>
      <id S="ID-KMEHR" SV="1.0">2</id>
      <cd S="CD-ITEM" SV="1.0">medication</cd>
          <content>
            <text L="en">prescription of Augmentin 500mg 3x1caps/day during 5 days</text>
          </content>
         </item>
    </heading>
  </transaction>
 </folder>
</kmehrmessage>




7    APPENDIX 2: EXAMPLE, SCENARIOS 2003 FOR QUALITY LABELLING
     OF EHRS IN BELGIUM (VERSION IN FRENCH)


Introduction
Les sessions de tests ont été conçues selon le principe de l' « evidence-based testing » : des
scénarios réalistes fort similaires à ce que le généraliste rencontre dans la pratique quotidienne.

Ces scénarios réalistes ont en outre été élaborés de telle façon qu'ils permettent de tester dans la
pratique un nombre important de critères essentiels de fonctionnalité "F" auxquels doit répondre
le logiciel de médecine générale. Ceci n'exclut pas qu'en passant, des critères 'T' (plutôt
techniques) soient testés.

La procédure de test et les diverses tâches à accomplir sont publiées dans l'optique d'une
préparation équivalente pour tous.

Seuls certains paramètres spécifiques seront communiqués le jour du test.

A titre de préparation aux tests mêmes, certaines étapes techniques et administratives bien
précisées doivent être réalisées avant le début de la session.

Les tests seront réalisés par des médecins utilisateurs «expérimentés» du logiciel, désignés par le
fournisseur de logiciels, éventuellement assistés par une personne du helpdesk.

Un groupe restreint (minimum deux personnes, nullement liées au logiciel testé) et dénommé
"Comité d'évaluation", désigné par le Service Public Fédéral (SPF) Santé Publique, se chargera
du déroulement des tests et en évaluera l'exécution.

L'évaluation se fera point par point, en mentionnant les scores sur la feuille de résultats. A défaut
d'unanimité des évaluateurs, il en sera pris acte.

Le dossier d'évaluation se composera du questionnaire préalablement complété, des documents et
attestations à soumettre par écrit (2.2), des documents et supports utilisés à remettre (voir
paragraphe 'clôture'), de la feuille de résultats ainsi que du formulaire « Commentaires et
Remarques ».
Ce dossier sera signé par le comité d'évaluation et remis à un agent du SPF Santé Publique,
immédiatement après la session de tests.

Remarques:

Le fait que certains actes médicaux sont repris dans ces scénarios n'indique aucunement qu'ils
sont justifiés scientifiquement ou sont des exemples de bonne pratique médicale! Nous ne testons
pas l''evidence-based medicine', nous testons les logiciels.

Les tests sont conduits selon un scénario précis (ce document). En outre, des directives précises
seront données aux évaluateurs au début du test.

Les numéros des critères testés ou en relation avec le test se trouvent groupés entre crochets [],
par test.

Préparation à la session de tests

    1. Équipement et logiciels

Pour la participation aux tests, les producteurs de logiciels sont priés de se munir d'un ordinateur
de leur choix, à écran large de préférence, afin de permettre à quatre personnes de suivre le
déroulement des opérations.

L'ordinateur sera également connecté à une imprimante et comportera un outil de stockage (par
exemple DAT, CD-writer, ZIP drive, ...) pour la fonction de sauvegarde sur support amovible. A
la fin de la séance de test, le backup sera conservé par les évaluateurs.

Sur le même ou un autre support (amovible) remis en fin de scénario, les résultats de certains tests
devront être sauvegardés sous un format lisible (c'est à dire sous un format accepté et documenté
internationalement).

Un second usage du support externe concerne la lecture de données de laboratoire, qui doivent
également être préparées d'une manière bien spécifiée.

Finalement, le support externe sera également utilisé pour l'import-export de données en format
KMEHR.

Tant le système d'exploitation que les logiciels à tester doivent être entièrement installés avant le
début du test.

Le logiciel de médecine générale devra être totalement opérationnel, mais ne pourra contenir
aucun enregistrement patient, ni autre donnée introduite par un utilisateur.

Les données des patients seront introduites au cours de la session de tests, de trois façons :
  via la sauvegarde (back-up) préparée à l'avance (2.3)
  via la « disquette labo » également préparée à l'avance (2.4)
  par voie manuelle durant la session
    2. Documents à préparer et questionnaire à compléter en préparation à la session.

Complétez les certificats et documents au formulaire XXX4 et remettez-les au début du test.

ATTENTION: LES DOCUMENTS ENVOYES LORS DE L' INSCRIPTION NE DOIVENT
PLUS ÊTRE APPORTES;.

    3. Données à préparer (plusieurs patients et quelques données administratives) afin
       de les introduire au moment du test

Ces données, données patients et autres, sont communiquées dans l' Annexe 1.

Ces données, qui seront nécessaires pour divers scénarios, devront être minutieusement
introduites dans un dossier «vierge», ne comprenant pas d'autres données de patients.

Le participant devra par la suite procéder à un back-up complet, au moyen des instruments de
sauvegarde de son logiciel (ou autres, dans ce cas: les spécifier), sur un « support externe
extractible » de son choix (par exemple disquette, CD-RW, DAT tape, ZIP drive, ...). Ce support
devra être apporté le jour du test !

 IL EST ESSENTIEL QUE SEULES LES DONNÉES NÉCESSAIRES AUX TESTS SOIENT
COMPRISES DANS LE BACK-UP. CERTAINEMENT PAS L'ENTIÈRETÉ (PROGRAMMES
ET BASES DE DONNÉES) DU LOGICIEL!!! (Voir Annexe 1 pour toutes les données à insérer
à l'avance via la procédure de sauvegarde/restauration.)

    4. « Données labo » et « fiches de renvoi » à préparer

Les candidats assureront eux-mêmes l'élaboration d'une disquette ou CD, (une « disquette labo »)
contenant les données visées à l'annexe 2. Il s'agit ici d'enregistrements de données de laboratoire,
protocoles et rapport(s) de spécialiste à généraliste.

Cette « disquette labo » sera utilisée durant la session de tests. Les données ne peuvent pas être
préalablement mises sur le disque dur.

Pour les données de laboratoire, nous vous conseillons de faire appel à votre laboratoire habituel
afin de vous aider à préparer cette disquette.

Ce support devra être apporté le jour du test !

(Voir Annexe 2 : « Disquette à produire par le producteur selon le format désiré et contenant les
données suivantes »)

    5. Disquette "KMEHR" à préparer

Les candidats assureront eux-mêmes l'élaboration d'une disquette ou CD, (une « disquette
KMEHR ») contenant les données visées à l'annexe 3. Il s'agit ici d'enregistrements de données
KMEHR, comprenant les données de l'annexe 3.

(Cfr. Annexe 3 : « messages KMEHR »)
      6. EN RÉSUMÉ:

Doivent être préparés et apportés à la session de tests :



  Ordinateur avec logiciel opérationnel, récemment installé, comprenant les thésauri CBIP,
  ICPC-2,... comme requis et tel que disponible sur le marché. Le numéro de version du software
  doit être clairement mis en évidence.
  Imprimante
  Données patients (annexe 1) préparées sur support externe

  Disquette labo » préparée sur support externe

  Disquette KMEHR» préparée sur support externe
  Questionnaire complété

REMARQUE: La partie 'administrative' doit également être remise SPF Santé Publique au
préalable.




Session de tests
T-01 Démarrage
Ouvrez le logiciel, démontrez qu'il est protégé par un mot de passe.
T-01.1 [25]

OUI       NON          ?

Affichez la liste (vierge) de patients.

T-01.2

OUI       NON          ?


T-02 Introduction de données patients
A l'aide de la procédure de restauration prévue dans le logiciel, chargez les données des patients
enregistrées sur le support externe (en préparation aux tests). Montrez la liste des patients.

T-02.1 [127]

OUI       NON          ?
Chargez la disquette labo.

T-02.2 [100][101][102][103][104][109][29][30][31][33][34][35]

OUI      NON          ?

Chargez la disquette en format KMEHR.

T-02.3 [108]

OUI      NON          ?

Montrez la 'boite d'entrée' ou 'inbox', ou devraient transiter les données entrées via la disquette
labo et la disquette KMEHR. Si pour la réception de messages par courrier électronique ou data,
des programmes largement répandus sont utilisés, on doit pouvoir montrer que ces messages sont
placés automatiquement dans la boite aux lettres du logiciel de dossier médical.

T-02.4 [109]

OUI      NON          ?

Intégrez toutes les données et les nouveaux patients dans le dossier médical.

T-02.5 [100][101][102][103][104] [73]

OUI      NON          ?

Affichage en ligne de la liste de tous les patients (comprenant toutes les nouvelles données (labo,
lettres, ...)

T-02.6 [100][101][102][103][104]

OUI      NON          ?


T-03 Cas simple
Première consultation d'un nouveau patient:

Monsieur XXX XXX, °XX-XX-XXXX, métier, ..., est le mari de madame XXX (déjà connue).

Retrouvez cette dernière, à partir du début de son nom.

T-03.1 [36][37]

OUI      NON          ?

Enregistrez le nouveau patient (tandis que le dossier de la patiente précédente reste ouvert): nom,
prénom, date de naissance.
T-03.2 [38]

OUI      NON          ?

Renouvelez le dossier médical global (DMG) de ce nouveau patient.

T-03.3 [84]

OUI      NON          ?

Prescrivez un médicament: XXX en utilisant la base de données du CBIP et en faisant en sorte
que le médicament se trouve dans le journalier et dans la rubrique "médicaments". ATTENTION:
il n'est pas permis de passer par un "copié-collé".

T-03.4 [56][57][58][59][73][83]

OUI      NON          ?

Produisez une attestation d'incapacité de travail XXX (introduire, préparer à l'impression,
visualiser et imprimer).

T-03.5 [43][92]

OUI      NON          ?




Montrez l' échéancier de ce patient

T-03.6 [84][85][86]

OUI      NON          ?

Fermez tous les dossiers.

T-04 Cas structuré
Retrouvez le patient, né XXX . Les dossiers précédents restent ouverts.

T-04.1 [36][37][38]

OUI      NON          ?

Ce patient est traité par vous pour un diabète depuis le diagnostic, posé lors d'une prise de sang
pour XXX. Vous procédez régulièrement à une mesure de tension artérielle, à une détermination
de la glycémie et à une mesure de HbA1C. Annuellement, vous déterminez sa taille et son poids,
vous demandez une analyse microscopique des urines et vous référez à un ophtalmologue. Ce
patient a subi plusieurs traitements en rapport à son diabète et aux complications dues à cette
maladie. Il a également contracté une autre maladie. Récemment, il a eu un accident de travail
(deux lésions) avec des séquelles permanentes entraînant des épisodes d'incapacité de travail
supplémentaires.

Ce patient a envoyé toutes les notes de frais relatives aux divers examens et incapacités de travail
après l'accident à l'assureur de la partie adverse. Lors d'un contrôle, il demande une liste des
examens, traitements et incapacités de travail, spécifiquement en rapport avec l'accident.

Visualisez la liste des problèmes de santé actuels du patient.

T-04.2 [46][78]

OUI      NON          ?

Visualisez seulement les résultats des examens antérieurs faits dans le contexte du diabète.

T-04.3 [51]

OUI      NON          ?

Visualisez à l'écran toutes les incapacités de travail et les éléments de soin associés.

T-04.4 [42][44][51]

OUI      NON          ?

 Visualisez les services et les résultats dus seulement à l'accident de travail et la dernière
incapacité de travail. Liez-la à l'élément de soin de l'accident, avec le code ICPC-2 approprié.

T-04.5 [51][78][80]

OUI      NON          ?

 Introduisez maintenant pour les services suivants, en contacts partiels, liés à la démarche
concernée (=service appartenant à un sous-contact): XXX et mettez-le en lien avec la démarche
XXX.

T-04.6 [78][80]

OUI      NON          ?

 Faites une nouvelle demande d'avis spécialisé en ophtalmologie pour mesure de pression et fond
d'oeil.

T-04.7 [78][80]

OUI      NON          ?
Visualisez le traitement spécifique pour la maladie XXX, pour évaluer quelle médication vous
allez prescrire.

T-04.8 [61]

OUI      NON           ?

Visualisez toutes les prescriptions, en date concernant ce patient.

T-04.9 [60]

OUI      NON           ?

Le programme rappelle certains examens XXX. L'activation de ce rappel se fait automatiquement
ou manuellement au préalable.

Planifiez et/ou rappelez les actions suivantes: XXX.

T-04.10 [68][69][73]

OUI      NON           ?

Donnez un sommaire de toutes les actions concernant le "suivi du diabète" pour ce patient.

T-04.11 [71][79]

OUI      NON           ?

Montrez que l'identification du patient est visible sur tous les écrans.

T-04.12 [72]

OUI      NON           ?


T-05 Dossier de vaccination
Patient XXX né le XXX, a reçu des vaccinations, avec un nombre de rappels planifiés.

T-05.1 [62][63][65][66]

OUI      NON           ?

Le patient compte partir en voyage et reçoit des vaccinations:

vaccin XXX aujourd'hui même avec planning de rappel par le logiciel.

T-05.2 [63]
OUI      NON          ?

Idem aujourd'hui même avec planning de rappel après XXX années.

T-05.3 [64]

OUI      NON          ?

Nouveau vaccin XXX aujourd'hui

T-05.4 [65]

OUI      NON          ?

Imprimez sa carte de vaccination (ou schéma de vaccination, état, ...)

T-05.5 [93]

OUI      NON          ?

Recherchez tous les patients qui doivent avoir un rappel de vaccin. Visualisez la liste

T-05.6 [63] [95]

OUI      NON          ?


T-06 Planification
Planifiez une consultation avec prise de sang: XXX

T-06.1 [84]

OUI      NON          ?

Planifiez une référence à un spécialiste: XXX

T-06.2 [85]

OUI      NON          ?

Planifiez un examen technique: XXX

T-06.3 [85]

OUI      NON          ?
Imprimez le PLAN D'ACTION.

T-06.4 [88]

OUI      NON          ?


T-07 Configurations d' écran et fonction d'aide
But du test : Le logiciel propose plusieurs écrans de saisie des données. Pour chacun de ces écrans
de saisie, il existe une configuration par défaut. Le logiciel permet à l'utilisateur de définir et
d'enregistrer ses propres écrans de saisie afin d'obtenir une mise en page personnalisée par
l'utilisateur, valable pour tous les patients.

Montrez l'écran par défaut du patient, comme fourni par le producteur et vérifiez la présence des
données d'identification.

T-07.1 [75]

OUI      NON          ?

Montrez COMMENT l'utilisateur peut modifier l'écran par défaut, pour définir un écran propre à
l'utilisateur, qui doit comporter au moins les allergies et le intolérances du patient.

T-07.2 [76]

OUI      NON          ?

Sauvez l'écran personnalisé.

T-07.3 [76]

OUI      NON          ?

Montrez la liste des raccourcis offerts par le logiciel et comment l'utilisateur peut les découvrir à
l'aide de la fonction d'aide du logiciel.

T-07.4 [77]

OUI      NON          ?

Montrez la fonction d'aide du logiciel.

T-07.5 [125]

OUI      NON          ?


T-08 Documents et rapports
 Préparez pour ce patient une lettre d'admission à l'hôpital (selon le modèle proposé par le
logiciel) basé sur le dossier de XXX, comprenant les éléments suivants:



  Nom, adresse, du médecin responsable, date du jour
  Données administratives du patient: nom, prénom, adresse, date de naissance, profession
  Données d'assurabilité

  Médication actuelle

  Maladies actives
  Antécédents médicaux pertinents
  Allergies et intolérances
  Facteurs de risque

Montrez la lettre, préparez l'impression.

T-08.1 [96][97]

OUI      NON           ?

Apportez une modification manuelle: XXX

T-08.2 [97]

OUI      NON           ?

Imprimez la lettre.

T-08.3 [97]

OUI      NON           ?

Exportez cette lettre en format KMEHR bis, comme "notification d'admission"

T-08.4 [108]

OUI      NON           ?

Montrez la boite aux lettres de sortie ("outbox").

T-08.5 [112]

OUI      NON           ?
 La lettre à exporter, devrait se trouver dans la 'outbox' du logiciel. Si on utilise un programme
largement diffusé pour la communication par courrier électronique, on doit pouvoir démontrer
que la lettre est déposée automatiquement dans la boite de sortie de ce programme.

T-08.6 [112]

OUI      NON          ?

 Entretemps, le patient XXX requiert un duplicata de sa prescription. Au moins un autre dossier
reste ouvert. Imprimez le document demandé.

T-08.7[59][38]

OUI      NON          ?


T-09 Sélections
Montrez la liste des patients, correspondant au critère: XXX

T-09.1 [115]

OUI      NON          ?

Exportez cette liste, pour usage selon le critère 116

T-09.2 [116]

OUI      NON          ?

Ajoutez maintenant un nouveau critère de sélection XXX.

T-09.3 [117]

OUI      NON          ?


T-10 Fermeture
Exportez toutes les données du patient XXX vers une base de données, sur média amovible (PAS
comme sauvegarde complète du programme, seulement le contenu de données!)



T-10.1 [128][129]

OUI      NON          ?
Fermez tous les dossiers.

Clôturez avec une sauvegarde de tous les dossiers de patients, utilisables pour un nouveau
démarrage (comme en T-02). Cette sauvegarde ne peut pas altérer l'original de T-02!



T-10.2 [127]

OUI      NON           ?

Remettez:
               la sauvegarde primaire
               les données exportées du patient XXX, sur un support amovible.
               Les lettres KMEHR exportées et les autres données produites (sélections,
               documents imprimés, ...)
               la sauvegarde finale.

T-10.3

OUI              NON               ?

								
To top