Immunization Work Group
Meeting Minutes
4
Date: Thursday, July 3, 2014
WebEx: 1-650-479-3207 & Online Meeting
Meeting Lead: Nancy Anthracite
Time: 4:00 PM EST
Access Code: 660 146 910
Facilitator/Scribe: Liz Badt/Jacquie Marian
4
Attendees:
X / Nancy Anthracite / President, CMO & Director, WorldVistAX / Keith Magoon / VA VIMM Project Manager
Dennis Peterson / VA VLER Health Project Manager
Michael Montali / VA Developer Competency Manager
X / Peter Li / OSEHRA CISSP Director, Engineering
Rob Silverman / VA Immunization SME
Mike Henderson / OSEHRA Director Open Source Product Management
X / Brian Morgan / VIMM PMO SME
Chris Rhodes / Director, Open Source VHA
X / George Lilly / VistA Expertise Network & CIO, WorldVistA
Dennis Kemp / VIMM PMO Project Manager
Cameron Schlehuber / Community volunteer, Former DBA for VistA
Randy Nickel / Director of Interfaces & Technical Services Group, Medsphere
Bill Malcom
Jay Heroux
James Proctor / VIMM PMO Agile Release Manager
Sridevi Uppalapati / VIMM PMO Support Project Manager
Helena Gilbert / VIMM PMO Technical Writer
X / Jacquie Marian / VIMM PMO Business Analyst
X / Sam Habiel / Director of Technology, VistA Expertise Network
X / Linda Hebert / VA Immunization SME
Bryan Volpp / VA Informatics SME
Patrick Redington / VA M Developer
Susan Richards / IHS Office of Information
X / Chuck Link / VA M Developer
X – Present. O – Excused absence. Blank – no report.
Discussion:
Topic: Update on Immunization Project / Presenter: Keith MagoonDiscussion:
· Chuck stated there were a few fields in the V IMMUNIZATION file that clashed, but they kept as much of IHS fields as possible.
o Nancy noticed the DIAGNOSIS fields were moved and Chuck stated yes because it conflicted with existing VA fields.
· Nancy mentioned CDC now has a funded project to include barcodes.
· Nancy stated she was hoping that Sam Habiel could make us new builds for installation.
o Sam Habiel will be on the plane and asked Nancy to send him what she would like him to work on.
· Nancy is thinking about populating with some patients and adding data to some of the files that are not populated
· Nancy asked Chuck if he has been looking at the current RPMS software.
o Chuck indicated he has not done so lately
o Chuck stated they are working to get items completed and into a patch.
o Nancy asked Chuck if she should get a new VistA instance up on that machine and put the new BI code on that; she is concerned that Chuck has looked at the old BI code and made some changes that follow the old BI code.
o Chuck stated he had started, but set it aside since the 1.0 was only for the data dictionary structure changes.
o Nancy indicated she backed up the server before she installed the 1.0 patch provided last week.
o Nancy stated she would contact Howard Hays to see if we could start having Mike Remillard on the calls, possibly next Thursday, if you are ready to look at that code.
· Chuck stated they are not ready to move forward with reviewing the BI code yet since he is still working on closing out the patch for VIMM 1.0. Finishing up the administrative items, getting DBA approval, and all the steps necessary to complete the developer checklists.
· Chuck stated he could get a copy of the Patch Description as it is right now.
o Chuck indicated Alan completed some more of the patch description and may also be done.
· Nancy asked Chuck if he is aware of the OSEHRA Work Group site and the documents posted
o Nancy stated there is a Git repository where items that are being worked on can be uploaded to.
o Nancy stated she wanted to use the RPMS code as much as possible.
o Chuck stated they have to start with the requirements for VIMM 2.0 and because these requirements are primary to VA we will need review them and set priorities. From there we can see how much of the RPMS code we can keep and try to keep as much as we can.
o Nancy thought is to look at the RPMS code and then parameterize the code that will not be utilized by VA.
· Chuck stated he did not see any issues at this time as long as it is possible.
o Nancy volunteered to look at the list of requirements and evaluate if the RPMS code does handle it.
· Chuck explained the current list of requirements need reviewed and elaborated in order to see what can or cannot be done for this release. Once we have this list, then it should not be an issue to provide for you to look through.
· Nancy stated that if you look at RPMS and see that it already fulfills a requirement wouldn’t it determine what you can or cannot do.
· Chuck felt it may not assist as much as Nancy thinks. Chuck stated we have to look at the VA first.
o Nancy asked Keith if he had already sent over the requirements.
· Keith stated he sent over the Requirements Traceability Matrix (RTM) and Requirements Specification Document (RSD)
· Keith wanted to reiterate that we have to look at what the Business needs are.
· Nancy stated that if the RPMS software you have already meets your Business needs and some additional features you would not need to rewrite the code, you could just converge the code from RPMS.
· Keith stated he is concerned after talking with IHS that the current capability they have is being replaced because it did not meet their requirement yet we are trying to install something or implement an application that IHS says does not meet their needs.
· Their current forecasting system is being replaced.
· Keith wonders why VA is not implementing what IHS is implementing to meet their needs instead of trying to adopt what did not meet IHS’s needs.
· Nancy explained there are 2 parts for immunizations. IHS did replace their forecaster with one that comes from Texas Children’s Hospital, but there is a point in the code where you go out to use the forecaster; however, there are a whole lot of other things that are done in the roll and scroll that already works very well and could be reused by the VA. So when IHS stated it does not meet their needs, it is only in that narrow sense with the forecaster.
· Sam in the previous build even identified the entry points where we could get at it.
· Nancy feels we should not throw everything out because it does not meet their needs when it is only the forecaster that does not meet their needs.
· In fact, IHS has enhanced the immunizations further and most of what you need probably will already function or come close to functioning inside VistA.
· Chuck mentioned they will be reviewing these requirements with some additional VA resources and suggested 1 member from OSEHRA be on those meetings to listen in. Nancy suggested including IHS immunization SMEs on the call and Chuck stated he was looking to have 1 person.
· Chuck wanted clarification from Nancy as to what she meant when stating use RPMS code when available. Nancy stated one of the reasons for OSEHRA’s existence is to have code convergence between the various flavors of VistA and RPMS and to bring them together to have a core system that works; it turns out that RPMS has an excellent immunization section already and it does not need to be in the same namespace as the VA. There is good reason to think we can converge this part of RPMS and VistA by combining them right now.
· Chuck then asked if she cared about the code itself or the functionality that RPMS provides and Nancy stated she cared about the code in order to maintain code convergence.
· Peter mentioned the BCMA supports both RPMS and VistA using the same code base and it would be advantageous if the Immunizations could also follow the same methodology.
· Chuck stated if the RPMS code as it sits meets the requirements outlined by VA, then he does not foresee any issues.
· Keith stated having an outside member should not be an issue as long as acquisition details are not discussed.
· Chuck asked that instructions be sent via email on how to access documents on the Work Group website.
· Sam showed GitHub, which is where he has uploaded some RPMS builds for Immunizations. Sam sent the website via Chat: https://github.com/shabiel/rpms-immunizations
· Nancy asked if there are any updates on the TRM meeting.
o Keith stated the decision was made that immunizations will put in whatever system is needed and eHMP will have to make any system that they implement interface with what immunization implements.
o ASD is heavily embedded in this now since it was brought to management level.
o
Topic: ICE / Presenter: Nancy Anthracite
Discussion:
· Nancy explained to Chuck that they have setup ICE and have done direct calls from VistA.
· George explained the ICE forecaster has to be accessed by a SOAP web service. Nancy and George wrote MUMPs code that pulls together the patient immunization information, problems, and diseases they had in the past and puts it in a format required by ICE and does a web service request in SOAP format and then when the result comes back we have a packet. We parse the packet and put it in a format where it could easily be interpreted in the MUMPs code.
o Since these the packets are so large, George wrote a web service that goes in and runs it for us. You just provide the DFN of the patient and it will return the MUMPs array that represents the results from the forecaster.
o Return XML array contains the patient’s date of birth, gender, patient ID, feedback to us what we told them about the diseases the patient has had, and then they have an interpretation that they are immune to. For each of the vaccinations the patient has already had, it feeds back to us what the vaccinations were and the dates and what the vaccination’s CVX number is. A hard-coded map was put in between the VistA immunization and CVX codes because we do not have the CVX codes in VistA right now. What group that CVX is part of and if you click on that it will display the XML of what vaccines are included in that group. Feedbacks the dose number that was supplied and whether it is accepted or not. Sends back the proposal (forecasting) of what is due now or needed to be done in the future; they do not send back the CVX code for the vaccine, but the number of the vaccine group.
o Large XML that is CCDA formatted and was processed down to a set of manageable named value pairs.
· George stated they are using the Reminders package to evaluate whether the patient had a disease that would cause immunity.
o The way the forecaster works is if the patient had Hepatitis B, you would have to send it a specific Hepatitis B ICD-9 code because there is only 1 code that works with the forecaster. That code stands for all the different codes that mean Hepatitis B. So Nancy built a taxonomy with a value
o There is a value set published by National Library of Medicine as part of the Quality Measures value sets that define all the different components that represent Hepatitis B. Value sets are things that represent a single concept. George stated he is calling these rubrics.
o Nancy built a taxonomy in the Reminders package with all of the codes that ought to be mapped to Hepatitis B and wrote a finding in the Reminders package so it can be called to evaluate that finding.
o Last 5 columns added after last meeting in order to trace back the disease documentations in VistA. Done by writing an interface to the Reminders package which passes in the patient and the reminder and it then retrieves the evaluation matrix that the Reminders package puts together; this is represented by the FIEVAL variable that George displayed and is used to process into “Findings”. IF it is in the Problem List, we needed the Onset date to send over to ICE. Rubric Code included.
o XML comes back and do lookups on the rubrics in order to match up what came back from ICE to what the source was in VistA.
o Talked to ICE people and explained the date has to accept just a year and UNKNOWN.
o VMR is what is used to send all the information over to ICE.
· George stated to Chuck that he created a URL that can be accessed behind the VA firewall.
· Nancy stated Jim is going to do work on a GUI for Immunizations in Delphi.
o Nancy stated she thought the Reminders package will get enhanced to have better Reminder Dialogs to be able to handle more of this information and process it so everything can be done in Reminder Dialog. On Friday a call with Patrick is to be held.
· Chuck asked why the Reminders package was used for all of this.
o George stated there is only 1 piece of this that uses the Reminders package and that was to determine what diseases a patient had and whether they are immune. The VPR extract is used to determine what vaccines the patient has been given before.
o Nancy stated it is already in the workflow for VA so heavily already. To support Meaningful Use that has to do with Quality Measures and reminders and PCE and all of this fits into that. Value sets are 1 of 800 that eventually will need to become taxonomies and ported into VistA, which George and Patrick have been working on that. The whole workflow already is to use Reminder Dialogs to record immunizations and allow rapid ordering of all these things. Rob wants PCE to use Reminder dialogs so everybody fits into the workflow they are used to already and because they are so powerful. Nancy feels combining these 2 is an effective way of doing it.
o Nancy stated Patrick and George have already worked out a way to update automatically the taxonomies (value sets).
o Chuck mentioned the VA’s deadline for the move of the ICD-9 to ICD-10 has been pushed out to Oct 2015.
· Nancy stated the good news is the ICD-10 and SNOMED codes are already available in the Taxonomy. We only used the ICD-9 because we are not on a version of Reminders that takes in ICD-10, but they are all available so that we can automatically import those when it comes time to put them in the Taxonomy.
· George displayed one of the value sets used (comes from National Library of Medicine) and it already has ICD-10 codes in it. If the Lexicon supported ICD-10 and if Reminders package operated to be able to support ICD-10 in Taxonomies, we would be able to put this entire value set into the Taxonomy. Whether the disease itself is recorded as ICD-9 or ICD-10, then the same reminder evaluation would work without change. So the Reminders package is shielding us from this issue of the coding system.
Topic: Open Forum / Presenter: All
Discussion:
Action Items: