Moving from V2 to V3 – Consequences of the RIM

Moving from V2 to V3 – Consequences of the RIM RIMBAA Presentation November 14, 2011

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

History of IBM’s Drug System 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

History of IBM’s Drug System 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

History of IBM’s Drug System 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

History of IBM’s Drug System 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!

History of IBM’s Drug System 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!

History of IBM’s Drug System Final System Architecture HL7 Database Business Functionality Messaging Viewer Support Web Viewer

History of IBM’s Drug System 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!

History of IBM’s Drug System 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!

Longitudinal Record Services Make It Use V3 Common Services Communication Bus JURISDICTIONAL INFOSTRUCTURE Ancillary Data& Services EHR Data& Services DataWarehouse Registries Data& Services OutbreakManagement PHSReporting SharedHealth Record DrugInformation DiagnosticImaging Laboratory HealthInformation ClientRegistry ProviderRegistry BusinessRules EHRIndex MessageStructures NormalizationRules LocationRegistry TerminologyRegistry Security MgmtData Privacy Data Configuration HIAL Public HealthServices PharmacySystem RadiologyCenterPACS/RIS Lab System(LIS) Hospital, LTC,CCC, EPR PhysicianOffice EMR EHR Viewer Public Health Provider Pharmacist Radiologist Lab Clinician Physician/Provider Physician/Provider Physician/Provider POINT OF SERVICE 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.

Make It Use V3 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

Make It Use V3 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

Make It Use V3 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

Make It Use V3 Re-Architect Our Application

Make It Use V3 Keep our interface models separate HL7 Database Business Functionality Messaging Support Viewer Support Messaging Web Viewer

Make It Use V3 Sample of pan-Canadian RMIM

Make It Use V3 Our RIM-based Data Model

Make It Use V3 Keep our interface models separate • 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

Lessons Learned Lessons Learned • Don’t use Schemas • Don’t map Vocabularies • Adding the RIM to your application is a good thing!

Lessons Learned 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

Lessons Learned 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

Lessons Learned 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

Questions & Discussion? jean.duteau@gpinformatics.com

Moving from V2 to V3 – Consequences of the RIM