moving from v2 to v3 – consequences of the rim rimbaa presentation november 14, 2011 1
TRANSCRIPT
gpi
gordon point informaticswww.gpinformatics.com
Moving from V2 to V3 – Consequences of the RIMRIMBAA Presentation
November 14, 2011 1
gpi
Agenda
• History of IBM’s Drug System– Building a Drug System– Creating V2 messages
• Make it use V3– Could we map V3 like we did V2?– Re-architect the application
• Lessons Learned– Schemas vs Code Generation– RIM and Vocabulary Bindings– RIM Architecture Benefits
2
gpi
Building a Drug System• In 1999, Alberta Health and Wellness contracted IBM
to build a Drug Information System (DIS).• The intent was to have Pharmacies provide real-time
data and the Physicians would browse this data using a Web Viewer
• Eventual goal would be to have the DIS purely function as a broker of information with a number of external vendor systems browsing and providing new data
3
gpi
What does the system contain?• The requirements were driven by consulting a
Working Group composed of Physicians – both general practitioners and specialists, Pharmacists, Nurses, and Hospital Administrators
• Focused on what should the Web Front end provide and how it should be provided
• Functionality included three main categories:– Prescriptions – the ordering of medications for a patient in
a community-care setting– Dispenses – the supplying of medication to a patient– Allergies
4
gpi
How was it built?• Since the requirements were driven by how the Web
Viewer would function, the data elements were derived from what needed to be displayed on the screen plus any data that was needed to derive that data
• Example: Days Left of medication was a data element– Drove Days Supply from the Dispense– Dose Per Day from the Prescription– Refills allowed from the Prescription
5
gpi
Creating V2 Messages• Once development got underway on the Web Viewer
and the business functionality and underlying data structures, the decision on how to allow for application-to-application communication was made
• HL7 V2.x Messaging was chosen as the medium using the new V2-over-XML standard
• A team was brought on to develop the V2.x specifications and the underlying application functionality
• NOTE: This is where Lloyd McKenzie got started with HL7. I apologize for playing a small role in the creation of the monster!
6
gpi
Implementing V2.x Messaging• All of the messages used existing V2.x messages but
we added a ton of Z-segments to support our needs.• The specification basically took the requirements for
data that would drive the Web Viewer and determined how we would send those over the wire.
• We had a number of stumbles – I believe that I rewrote the V2 XML parsing piece at least three times!– V2.x messaging is hard!
7
gpi
Final System Architecture
8
Business FunctionalityBusiness Functionality
DatabaseDatabase
Web ViewerWeb Viewer
Viewer SupportViewer SupportMessagingMessaging
HL7HL7
gpi
Implementing with External Vendors• Once we had the implementation complete, we
began interfacing with external vendors.• We produced V2.x schemas and sent those to the
vendors.• They started building and a lot of them experienced
the same pain that we had in implementing V2.x• We went live around 2006 with the first system-to-
system message in production!
9
gpi
What had we accomplished?• We had an architecture that was very Web Viewer
focused– The business functionality supported the Web Viewer– The data structures (and underlying database) supported
the Web Viewer– The System-To-System messages supported the Web
Viewer
• It worked!
10
gpi
Guidelines of V3 Project• In the meantime, Canada Health Infoway was
developing a V3 pan-Canadian Specification for many parts of the healthcare system, including Medication Management.
11
JURISDICTIONAL INFOSTRUCTUREAncillary Data
& ServicesRegistries Data
& ServicesEHR Data
& ServicesData
Warehouse
OutbreakManagement
PHSReporting
SharedHealth Record
DrugInformation
DiagnosticImaging
LaboratoryHealth
Information
POINT OF SERVICE
Hospital, LTC,CCC, EPR
PhysicianOffice EMR
EHR Viewer
Physician/Provider
BusinessRules
EHRIndex
MessageStructures
Normalization
Rules
Security MgmtData
Privacy Data Configuration
Physician/Provider
Physician/Provider
Lab System(LIS)
Lab Clinician
RadiologyCenter
PACS/RIS
Radiologist
PharmacySystem
Pharmacist
Public HealthServices
Public Health
Provider
Longitudinal Record Services
HIAL Communication Bus
Common Services
ClientRegistry
ProviderRegistry
LocationRegistry
TerminologyRegistry
gpi
Guidelines of V3 Project• Infoway approached IBM to adapt its Drug
Information System to use V3 messaging• There were 72 transactions in the Electronic
Prescribing domain that they wanted to be implemented
• By this time, IBM had implemented in a second jurisdiction.
• IBM decided to abandon the V2.x solution and replace it with V3 messaging
• After analyzing the transactions, 52 transactions were deemed relevant to the application
12
gpi
Can we just map V3 to our app?• Challenge in how to implement the new interface• Could we just replace the existing V2.x messaging
piece with a V3 piece?• It was determined that our existing data model had no
real relationship to the underlying RIM model of the V3 models
• The semantic difference between the V2.x messages and the V3 models were so different that this was not a feasible solution
• The new dynamic model was also an intractable mapping problem
13
gpi
Re-Architect Our Application• We analyzed all of the V3 transactions• Created a new Data model based on the data
required by the new transactions– This ended up being an implementation of a constrained
version of the RIM
• Built a new business layer based on the new V3 dynamic model
14
gpi
Re-Architect Our Application
15
gpi
Keep our interface models separate
16
Business FunctionalityBusiness Functionality
DatabaseDatabase
Web ViewerWeb Viewer
Viewer SupportViewer Support
MessagingMessaging
Messaging SupportMessaging Support
HL7HL7
gpi
Sample of pan-Canadian RMIM
17
gpi
Our RIM-based Data Model
18
gpi
Keep our interface models separate
19
• This actually led to a better architected system• Also led to a system that actually performed better!• As we added more transactions, there was no
disruption of the Web Viewer• Any changes to business functionality are done to
support just the business and not specifically for one interface or another
gpi
Lessons Learned• Don’t use Schemas• Don’t map Vocabularies• Adding the RIM to your application is a good thing!
20
gpi
Don’t Use Schemas (You’ve heard this before)
• The number of constraints in the pan-Canadian v3 messages and then in the jurisdiction specific constraints could not be conveyed via Schemas
• We used a Code Generator to read the MIFs and combined this with a set of XSL transform rules to express our constraints on the MIFs
• The model is generated automatically and is mapped by developers to the internal business model
• Hides the V3 message model from the business model
21
gpi
To use RIM and v3 Vocab, Don’t Map!• We did not see a benefit in mapping a pre-existing
data model and pre-existing terminologies to the RIM and to V3 codes
• A subsequent project, not done by IBM, took a version of the application and tried to add V3 messages without changing the Web Viewer or the existing V2.x messages– Ultimately, this project too realized that there were
changes required to the underlying business model as there was too much disconnect between the initial model and the constrained-RIM models
22
gpi
Adding RIM to models is a good thing!• By being forced to “add the RIM” our application, the
architecture actually ended up being cleaner.• Our performance was faster than the V2.x messaging • Our underlying data model was easier to understand
since there was more semantics embedded in the data model and the terminologies
23
