Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Moving from V2 to V3 – Consequences of the RIM RIMBAA Presentation November 14, 2011 1."— Presentation transcript:

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

2 Agenda History of IBMs 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

3 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 History of IBMs Drug System

4 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 History of IBMs Drug System

5 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 History of IBMs Drug System

6 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 History of IBMs Drug System

7 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 History of IBMs Drug System

8 Final System Architecture 8 History of IBMs Drug System Business Functionality Database Web Viewer Viewer Support Messaging HL7

9 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 History of IBMs Drug System

10 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 History of IBMs Drug System

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

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

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

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

15 Re-Architect Our Application 15 Make It Use V3

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

17 Sample of pan-Canadian RMIM 17 Make It Use V3

18 Our RIM-based Data Model 18 Make It Use V3

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

20 Lessons Learned Dont use Schemas Dont map Vocabularies Adding the RIM to your application is a good thing! 20 Lessons Learned

21 Dont Use Schemas (Youve 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 Lessons Learned

22 To use RIM and v3 Vocab, Dont 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 Lessons Learned

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

24 Questions & Discussion? 24

Download ppt "Moving from V2 to V3 – Consequences of the RIM RIMBAA Presentation November 14, 2011 1."

Similar presentations

Ads by Google