Blue Button Plus Push Workgroup Meeting. July 29, 2013. Meeting Etiquette. From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute . All Panelists . Remember: If you are not speaking, please keep your phone on mute
July 29, 2013
From S&I Framework to Participants:
Hi everyone: remember to keep your phone on mute
Model Privacy Notice: http://www.healthit.gov/policy-researchers-implementers/personal-health-record-phr-model-privacy-notice
Slides from previous meeting (July 15, 2013)
Comment (Ryan): For example, what we had heard at the event last week was we noticed people attaching a file to message vs. packaging it as a ZIP, including the request.txt, and not pulling the Blue Button Anchor Bundle. That is such a simple thing to do especially if you’re using the last RI. And Lastly the Triggers & Automation part how it is an open section in the IG just has three bullets, but as soon as data holders implement automation we should start putting more clarity to it. How do folks feel about using these calls on maybe a bi-weekly basis to get a pulse on how the community is doing and really being there to help the community move forward and take action to help fix things
Comment (Sean): I think it is a great idea, it has been interesting to watch, 2,3, 4x a day we’re getting reports of “Hey, I downloaded my CCDA from somebody, or I got it and I’m trying to send this through Direct” it seems like people have been building files for a long time and they aren’t importing correctly. Sometimes it is because they aren’t compliant, some cause they haven’t done V/D/T, there is an interesting back and forth, might be valuable if more of the community can see back and forth because it would accelerate fixes on all sides and it might shame some folks who are particularly egregious and have more people calling on them to fix documents they are generating. If that could be structured, the discussion of where we’re seeing patterns or issues around CCDAs that are floating around might be a neat 10 minute section every couple of weeks
Comment (Ryan): It is a great idea, it is one thing we may not have is public visibility of folks having issues. Is there a place? The Direct equivalent was a Forum where you could point people to, do we have the same for BB+ or even V/D/T alone?
Comment (Sean): I think the answer is no, it may have been something we tried, but from a defacto point of view it is so much developer to developer we get them on our business development alias, or people personally says there is not.
Comment (Josh): The only thing I know about is the Transport Testing Tool, it is an automated tool if you download transmit from vendors. There is a Google group for that tool where vendors can have that sort of discussion, but it would be great to have this in the patient facing use cases, where the people who kick off the discussion would be a patient who got their data from somewhere but it is no good.
Comment (Ryan): Is the proper forum a Google group, the folks that want to receive those type of messages can be a part of or the flip Pam and you ask the person you that want to get started.
Comment (Josh): The other option is the SIT Platform, they have been setting up resources for developers working with consolidated CDA. One of the things they’re planning to add to those resources is a question and answer style kind of a stack overflow for people asking implementation specific questions rather than just a discussion forum, it might be a useful resource as well.
Comment (Ryan): For the BB+ IG we put a stack overflow style thing on it, but it didn’t get that much love. No one posted question to it or not. I don’t know if it is because it didn’t feel like the right way…I take that back, some people have posted some questions.
Comment (Josh): Maybe we can take that as a point and we can work with Nayan and the Team so you could point them to the larger group, or show them to the larger group so you can get extra help.
Comment (Sean): Yeah that would be fantastic, as we go they become useful conversations. Those kinds of defacto uses help as well, that would be great to have a place where we could broaden discussion
Question(Chris Burrow): This is mutually important. I identify deficiencies all the time where things aren’t coded right, where codes are missing, lack of coding. I think this is very important. I would kick it back to you Ryan or Sean, if you could do whatever you wanted what would be the best technical way to make sure that everyone that produces a BB+ CDA is producing a file that is close to perfect as possible? What is the best way to do that?
Comment (Sean): Josh did some work in the beginning to say can we create a repository, the repository test documents is probably the best asset we could have in that sense.
Comment (Josh): The other thing that smart platforms is doing is working with Lantana to collect documents from not just vendors who are willing to share them publically but also privately for an analysis. Collecting a couple dozen documents to go through and find discrepancies, similarities to bring it back to HL7 and tighten down the standards. We’ll also be able to publish a document and fine-grained resources describing the things that we found.
Comment (Chris): One of the things I found as a clinician is that some of the sample records are excessively simple. I think we need get our hands on more clinically complete, and clinically relevant documents.
Comment (Sean): I certainly agree.
Comment (Ryan): Question is it possible if you see the VA XML file, is the score card checking for those things? It is very easy for us to call someone out, but if we can push the angry finger at the score card and keep using the score card it will help you get it right. If you’re still seeing folks that are still doing things wrong with there CCDA and the score card doesn’t catch those things then we need to keep adding more checks on the score card.
Comment (Chris): The XML in green text says we don’t have the codes yet, they know about it and I’m sure they’re working on it I just thought I would call it out as an example.
Comment (Ryan): I can see us when we meet every other week that it is almost us starting with big issues in the community, it is almost a 20 minutes focus on what are people doing right and wrong; mostly what are people doing wrong. At the forum Jeff said the time we’re at right now is dangerous, we’re celebrating a lot of the work that has been done, but we’re so far from being done as well too. People can say they’ve implemented BB+ and actually not have, folks can do the bare minimum and disengage. It is almost as if we need to be even more vigilant making sure people do things from going forward from this day for at least the next 6 months. Are there other things folks are seeing, any other patterns you’re noticing that could be leading us into a bad state? Bad state meaning data isn’t flowing or really bad data is flowing.
Comment (Sean): I’m not sure it meets the bar of that but it certainly is the case that automation is on nobody’s radar at all. I don’t know if it is appropriate for us to try and do something about that or not. But it is clear that automation is not happening really with anyone today and we have to decide if we want to push it or not.
Comment (Josh): I agree that automation isn’t happening and it probably can’t happen in a meaningful way on the basis of the spec that is out there today. If we did want to support that we would need more specifications in order to get there.
Comment (Sean): Maybe that could take some time offline, the more challenging part from the implementation view is when to send, and I don’t know how we’re going to provide guidance about that because you’re out of the RI. You’re inside the specific EHR if they can or cannot identify the trigger points, I would be thrilled if they send a copy of the CCDA and I would figure that out. I can’t imagine that is the blocker as much as the fact that this is per EHR design work.
Comment (Adrian): One of the things that is an interesting trigger in the Health Information Exchange is the registration event. One of the early points of automation could be send out the information when an encounter is registered. That is sort of an issue for Health Information Exchanges in almost every case.
Comment (Sean): Fair point, there might be some of those for sure.
Comment (Chris): I think this automation thing is hugely important. As long as this thing stays manual we’re kind of failing to fulfill the vision here of getting the data to flow I’m not quite sure how to go forward. Is there not a thought that we should be taking this on in our group? Should we be trying to give further guidance? Or is it like Sean said where the block is really down at the individuals EMR level?
Comment (Adrian): Well I think it would be helpful if instead of being very generic we figured how to be very specific about one or two events. Because, sure there is a lot of diversity out there, but asking for a transmission on registration and a transmission on when an order is placed in the EHR those are both fairly straightforward demarcation points. Why not just start with those two things, I think those two would cover a lot of the App developers and interested parties, HIE and everything else.
Host: If you're interested in attending the BB+ Developer Day in NY (or seeing the results of the July 12) you can find more information here: http://www.capconcorp.com/meeting/2013/BlueButton/default.asp
Host: BlueButton Push Implementation Guide Link: http://bluebuttonplus.org/
Greg Meyer: GUI installer for Java RI as well! http://api.nhindirect.org/java/site/assembly/stock-installer/3.0-SNAPSHOT/users-guide/depl-install.html
Josh Mandel: Re: sitplatform Q&A, contact is: "Bill Dyer" <firstname.lastname@example.org>
Greg Meyer: There will a demo of the sitplatform at this week's Direct connet-a-thon
Josh Mandel: NYC BB+ Forum on 7/22: (Registration Link) http://www.capconcorp.com/meeting/2013/BlueButton/default.asp