the medication supply registry project demonstration in the netherlands n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The Medication Supply Registry Project & Demonstration in The Netherlands PowerPoint Presentation
Download Presentation
The Medication Supply Registry Project & Demonstration in The Netherlands

Loading in 2 Seconds...

play fullscreen
1 / 35

The Medication Supply Registry Project & Demonstration in The Netherlands - PowerPoint PPT Presentation


  • 273 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Medication Supply Registry Project & Demonstration in The Netherlands' - winfred


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the medication supply registry project demonstration in the netherlands

The Medication Supply Registry Project & Demonstrationin The Netherlands

A co-production by

NICTIZ – HL7 the Netherlands – IT industry

Tom de Jong

HL7 the Netherlands

what is nictiz
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
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’.
solutions
Solutions
  • 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
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 functions
Care Information Broker functions
  • Maintaining the Act Registry:
    • Process updates from HC systems
    • Process queries from HC systems
  • Identification, Authentication(infrastructure & safe data transport are a requirement)
  • Authorisation
  • Logging
identification schemes
Identification Schemes
  • ZIN: Care Identification Number
  • UZI: Unique Care Provider ID
  • UZOVI: Unique Care Insurer ID
the first zim based project
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
Act Registry
  • Notification (upload) of a medication supply to theAct Registry
  • Two versions:
    • Light version
    • Extended version
r mim act registry
R-MIMAct Registry

1st participation is the patient.

A common element (CMET) is used for the patient.

A common element (CMET) is used for the care provider.

Information concerning the ‘Act’ that is being ‘uploaded’ to the Act Registry

2nd participation is the care provider that is the source of the medication supply

interaction scheme act registry
Interaction schemeAct Registry
  • Application roles –
    • Sender: Act Reference Notification Informer
    • Receiver: Act Reference Notification Tracker
  • Set of related messages
interaction

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

Interaction

Act Reference Lite Registry Entry Created (MFMT_IN100050NL)

query and response medication supply
Query and responseMedication 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
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 i1
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
Medication supplyQuery & 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).
r mim medication query
R-MIM Medication Query

ZIN; mandatory

Query definition

ID, status: New

Medication usage interval

Medication supply interval

Supply ID

Preferred sort order

interaction scheme query query response
Interaction scheme Query & query response
  • Application role –
    • Requester: Substance Supply Event Query Placer
    • Fulfiller: Substance Supply Event Query Fulfiller
interactions

Sending Role

Sending Role

Substance Supply Event Query Fulfiller

Substance Supply Event Query Placer

PORX_AR100020

QURX_AR100010

Receiving Role

Receiving Role

Substance Supply Event Query Placer

Substance Supply Event Query Fulfiller

PORX_AR100010

QURX_AR100020

Trigger Event

Trigger Event

Substance Supply Event Query Response

Substance Supply Event Query

PORX_TE100002

QURX_TE100001

Substance Supply Event Query

Message Type

Message Type

Substance Supply Query.

Substance Supply Query Response

QURX_MT100401

PORX_MT100400

Interaction Type

Interaction Type

Substance Supply Event Query Response

Substance Supply Event Query

QURX_IN100002

QURX_IN100001

Wrapper Type

Wrapper Type

Query

Query response

QUQI_RM020000

QUQI_RM120000

Substance Supply Event Query Response

Interactions
project context
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
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
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
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
conclusions
Conclusions
  • 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.