Download Medication Supply Registry Project and Demonstration in

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Channel coordination wikipedia , lookup

Transcript
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
Ribw
Harderwijk
MFE
Lelystad
Ermelo
Mental hospital
Amersfoort
Riagg
Almere
Riagg
One solution:
Service Centres
(e.g. in a hospital)
GP
GP
Dependance
Hospital
Pharmacy
GP centre
Ribw
MFE
Dentist
GP
Centrum voor
Revalidatie
Mental hospital
GP
Ophthamologist
GP
Dependance
Riagg
Riagg
Hospital
Hospital
Pharmacy
GP centre
Pharmacy
Laboratory
GP centre
Regional Care
Networks
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)
• 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
• 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
Virtual data warehouse
Linking ZIMs together…
AUF
AB
MI
I&A
ZR
PR
Nationaal
AUT
ZIR
SCH
Regionaal
UZI
ZIM
VWI
ZIM
SCH
LOG
AUF
I&A
GP
Lokaal
GBZ
ZS
ZA
PD
ZIN
Identification
Schemes
• 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
(CMET)
is used for the
patient.
Information
concerning the ‘Act’
that is being
‘uploaded’ to the Act
Registry
A common
element (CMET)
is used for the
care provider.
2nd participation is the
care provider that is
the source of the
medication supply
R-MIM Act Registry
(Lite)
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_ST000011NL
MFMT_AR100001NL: Act
Reference Notification
Informer – Active Only
MFMT_AR100002NL: Act
Reference Notification
Tracker – Active Only
MFMT_IN100010NL Act Reference Registry Entry Created
MCCI_IN000002 Accept Acknowledgement
• Application roles –
– Sender: Act Reference Notification Informer
– Receiver: Act Reference Notification Tracker
• Set of related messages
Interaction
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).
R-MIM
Medication Query
ZIN; mandatory
Query definition
ID, status: New
Medication usage interval
Medication supply interval
Supply ID
Preferred sort order
R-MIM
Query response
Interaction scheme
Query & query response
• Application role –
– Requester: Substance Supply Event Query Placer
– Fulfiller: Substance Supply Event Query Fulfiller
Interactions
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
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.
Questions