Stichting HL7 Nederland - PowerPoint - PowerPoint by O2d7Z3y2


									   The Medication Supply Registry
      Project & Demonstration
        in The Netherlands
           A co-production by
NICTIZ – HL7 the Netherlands – IT industry
              Tom de Jong
               HL7 the Netherlands
               What is NICTIZ?
• Not-for-profit organisation
• Founded by healthcare stakeholders:
  –   Ministry of Healthcare
  –   Organization of IT Vendors in HC
  –   Dutch HC Insurers Organisation
  –   Organisation of HC Providers
  –   Patient representation groups
• Funding by Ministry of Health
  (for a 5-year ‘trial’ period)
      Current developments in
         Dutch healthcare
• Shift from administration and billing
  processes to clinical care itself.
• Very little central coordination in the
  creation and application of standards
• Restructuring of healthcare (mergers).
• Shift from intra-institutional to
  inter-institutional cooperation and a
  resulting need to share information
  throughout the ‘chain of care’.
                 Care regions

                                                      Harderwijk           Ribw

            MFE   Lelystad

                                 Mental hospital

               One solution:
              Service Centres
             (e.g. in a hospital)


Dependance                  GP



                GP centre



                                                                                  Centrum voor
                                      Mental hospital

Dependance                       GP




                                                                                                        GP centre

                     GP centre
Regional Care

• One big EHR database with
  healthcare info for 16 million people
• Leave data at the source, but register
  a reference to it in a central repository
  (‘Act Registry’ in HL7 speak)
• A hybrid solution?
           Features of the Care
         Information Broker (ZIM)
• Data itself it not copied in the registry
• Interested parties use a pull mechanism (query) instead of
  a proliferation of notification messages between systems.
• Advantages
   – Always the most recent data from the ‘virtual’ DB
   – No risk of inconsistencies due to duplication
   – No exponential growth in # of interactions
• Drawbacks
   – All interactions have to be standardised, which results in demands
     to vendors, providers, etc.
   – The ZIM itself will have to be built and maintained by either a
     central authority or a third party vendor
      Care Information Broker
• Maintaining the Act Registry:
  – Process updates from HC systems
  – Process queries from HC systems
• Identification, Authentication
  (infrastructure & safe data transport are a
• Authorisation
• Logging
Virtual data warehouse
Linking ZIMs together…

              AUF   AB        MI         I&A          ZR         PR
              AUT    ZIR                  ZIM          UZI        ZIN

  Regionaal                                     VWI
                                   SCH                     ZIM
                     LOG                        I&A

                     AUF           GP
  Lokaal                                               GBZ
                         ZS        ZA           PD

• ZIN: Care Identification Number
• UZI: Unique Care Provider ID
• UZOVI: Unique Care Insurer ID
                     The first
                ‘ZIM-based’ project
• Obtain ‘proof of concept’ for:
   – Query and response for Medication Supply,
     based on HL7 version 3 models and messages
   – Use of an Act Registry (Care Information Broker)
     to share medication supply information transparently
• Demo at Dutch Medical IT Conference:
   – Representative selection of IT vendors
   – Implementation of abovementioned concepts
   – Near-complete, realistic and ‘live’ operation of V3
     interfaces within infrastructure of conference network
• Some limitations were agreed upon:
   –   No authentication, authorisation etc.
   –   XML based on ‘simple’ TCP/IP protocol
   –   All unique identifiers are assumed to be in place
   –   Single vendor selected for implementation of Act Registry
               Act Registry

• Notification (upload) of a
  medication supply to the
  Act Registry

• Two versions:
  – Light version
  – Extended version
                 R-MIM Act Registry
                              1st participation is
                                  the patient.

                                                     A common element
                                                       is used for the

                                                          A common
    Information                                       element (CMET)
concerning the ‘Act’                                    is used for the
    that is being                                       care provider.
‘uploaded’ to the Act
      Registry           2nd participation is the
                          care provider that is
                            the source of the
                           medication supply
R-MIM Act Registry
CMET R_PatientLite

           Zorg Identificatie nummer

                     Patiënt naam
CMET R_AssignedEntity

    Unique Care Provider ID (UZI)

                      Care provider can be a person or an organisation
          Interaction scheme
              Act Registry
                                     Add Act to Registry

MFMT_AR100001NL: Act                                                     MFMT_AR100002NL: Act
Re ference Notification
                                                                         Re ference Notification
Info rme r – Active Only                                                 Tracker – Active Only

                       MFMT_IN100010NL Act Reference Reg is try Entry C rea te d

                              MCCI_IN000002 Accept Acknowledg ement

• Application roles –
        – Sender: Act Reference Notification Informer
        – Receiver: Act Reference Notification Tracker
• Set of related messages

  Act Reference Lite Registry Entry Created (MFMT_IN100050NL)

Sending Role          Act Reference Lite Notification Informer   MFMT_AR100007NL

Receiving Role        Act Reference Lite Notification Tracker    MFMT_AR100008NL

Trigger Event         Activate Act Reference Lite                MFMT_TE100050NL

Message Type          Act Reference Lite – Add                   MFMT_MT100300NL

Wrapper Type          Registry Act Wrapper                       MFMI_RM700700
             Query and response
              Medication Supply
• What should the query result set be?
  – All medication supplies/dispenses (definition?)
    for/to a specific patient (within a certain interval).
  – Both a specific pharmacy and the Act Registry (as
    an information broker for a group of pharmacies
    and care providers) can be queried.
• Query implementation based on the generic
  query framework from HL7 version 3
  – First (successful) practical application?
• Query response has similar (same?) payload
  as unsolicited Medication Supply message
            The Medication Supply
                 Message (I)
• Challenge: the Medication Information section of the
  V3 ballot was ‘frozen’; its status was unclear.
• Dutch work was based on parallel work in the UK
  (Hugh Glover et al), which was shared with us.
• Modified D-MIM (domain model) and message
  definition for Act Registry Upload and Medication
  Supply Query were developed within the task force.
• Feedback of results in the international standard is
  in progress and will lead to final harmonization.
• Minimal discussion with the IT vendors to ensure
  efficiency in preparing for the conference demo 
  evaluation and extension with care provider
  organizations and IT vendors will continue in 2004.
          The Medication Supply
               Message (I)
• Information contents of V3 messages were
  checked with EDIFACT message currently in
  use between Dutch community pharmacies.
• Result: first (partial) mapping of EDIFACT
  pharmacy messages to HL7 v3 models.
• Comparison and mapping to HL7 v2
  messages (used within hospitals) will follow.
• But there are even more ‘competitive’
  standards that will have to be ‘harmonized’.
           Medication supply
           Query & Response
• Query with query parameters is sent to a
  ‘query responder’

• ‘Query responder’ collects medication supplies
  that answer to query parameters and sends
  the answer to ‘querying application’

• Act Registry may be used, but the interactions
  are the same for direct communication
  between querying application (e.g. EHR) and
  query responder (i.e. source pharmacy).
         Medication Query

                                          ZIN; mandatory

Query definition
ID, status: New
                                          Medication usage interval

                                          Medication supply interval

                                          Supply ID

                   Preferred sort order
Query response
      Interaction scheme
    Query & query response

• Application role –
   – Requester: Substance Supply Event Query Placer
   – Fulfiller: Substance Supply Event Query Fulfiller
Substance Supply Event Query

Sending Role             Substance Supply Event Query Placer      QURX_AR100010
Receiving Role           Substance Supply Event Query Fulfiller   QURX_AR100020
Trigger Event            Substance Supply Event Query             QURX_TE100001
Message Type             Substance Supply Query.                  QURX_MT100401
Interaction Type         Substance Supply Event Query             QURX_IN100001
Wrapper Type             Query                                    QUQI_RM020000

Substance Supply Event Query Response
Sending Role             Substance Supply Event Query Fulfiller   PORX_AR100020
Receiving Role           Substance Supply Event Query Placer      PORX_AR100010
Trigger Event            Substance Supply Event Query Response    PORX_TE100002
Message Type             Substance Supply Query Response          PORX_MT100400
Interaction Type         Substance Supply Event Query Response    QURX_IN100002
Wrapper Type             Query response                           QUQI_RM120000
                 Project context
• Start of project May 1 (announced late April).
• Parallel paths:
   – Creation of Implementation Guide for Act Registry
     Upload and Medication Supply Query & Response.
   – Bringing together a representative group of IT vendors;
     convincing them to invest and participate in the demo.
• Implementation guide delivered first week of July.
• After that, getting the interface specialists from the
  vendors involved turned out to create an excellent
  environment for active cooperation in the project.
               The ICT vendors (I)
• Participating companies:
   – Community pharmacy systems: MicroBais, EuroNed
     (a special ‘OZIS gateway’ was developed to allow use of existing
     standards for querying the Act Registry; upload not yet possible)
   – Hospital pharmacy systems: Falcon
   – HIS/EHR vendors:
     ChipSoft, McKesson, 2Cure, Infocare
   – Act Registry was implemented by LifeLine
• Two GP systems were involved, but were allowed to send
  proprietary prescription messages to the ‘OZIS gateway’.
• Realization of interfaces between August and October:
   – HL7 Netherlands task force gave support where necessary
   – Intermediate communication was mainly handled by e-mail
• Interface realization was greatly expedited by use of XSLT
  scripts to transform from EDIFACT-XML to HL7 v3-XML.
            The IT vendors (II)
• Integral test sessions on October 29/30 at NICTIZ
  (with all participating vendors & HL7 NL present).
• Atmosphere of energetic, enthusiastic
  cooperation (‘innovation can be fun’).
• NICTIZ took care of facilities and politics,
  HL7 task force handled message implementation
• Conclusions:
  – Implementation guide (almost) ensured plug-and-play
  – Quick-and-dirty coding could be done in one day
  – Act Registry concept and message interfaces worked!
               The MIC demo
• NICTIZ had prepared all conference
  attendees as ‘patients’ (marketing instrument)
• Some ‘Murphy’s Law’ issues were corrected
  on the night before the conference started;-)
• Demo performed excellently at all vendor
  stands (visitors could follow a realistic route
  through the ‘simulated care chain’)
• Politicians and other ‘budget makers’ made
  this tour too and saw something that worked
• Great sense of enthusiasm (‘proof of concept’)
• Unique synergy between competing vendors
  (important to maintain and expand on this while it still exists)
• Breakthrough event for NICTIZ
  (important for its role as a catalyst in health IT innovation)
• Breakthrough event for HL7 NL and V3
  (important for its role as a catalyst in interface standardization)
• Follow-up projects to build on this foundation:
   – Working on a complete interface specification with all
     parties involved (care providers and IT vendors)
   – Try to move from “I’ll join if you…” to “please, can I join”
• Important 1st step towards goal of having a
  national medication record online by 2006.

To top