Provider Advisory Group Meeting
July 16, 2013, 7-8:30am

Name	Organization	
Dirk Stanley	Cooley Dickinson Hospital	
Daniel O’Neil	Steward Health 	
Paul Oppenheimer 	Sisters of Providence Health System 	
David Smith 	MA Hospital Association  	
Support Staff	Massachusetts eHealth Collaborative	
Micky Tripathi	Massachusetts eHealth Collaborative	
Mark Belanger	Massachusetts eHealth Collaborative	
Jennifer Monahan	Massachusetts eHealth Collaborative	

Review of Materials and Discussion
Project Updates
•	Mass HIway Phase 1- Transaction and Deployment Update (Slide 2)  
o	The group reviewed the Phase 1 updates.  Phase 1 operations are going live, while synonymously working through the design and deployment of Phase 2. 
o	Currently Beth Israel Deaconess Medical Center, Network Health and Massachusetts eHealth Collaborative are in production. Holyoke Medical Center/Holyoke HIE, Tufts Medical Center, Beaumont Medical and Dr. Gregory Harris are live, having completed successful transactions. 
•	It was noted that the Department of Health and Human Services is also in production, receiving immunization data via the HIway. 
o	On the near horizon, the Last Mile Implementation Grants will start to drive movement. The grants involve approximately 51 sites. These sites will interact with the HIway to demonstrate a variety of use cases. Interfacing with the HIway will take place over the next six months. 
o	In June 106,331 transactions were exchanged. To date, over 1,255,903 Phase 1 transactions have been transmitted through the Mass HIway.
•	Phase 2 Overall Timeline (Slide 3)
o	The Phase 2 high level project schedule was reviewed. Phase 2 requirements for gathering and validating information was added to the timeline with targeted completion at the end of July. 
o	The high level design for Phase 2 was discussed last month, the team is currently in the process of working through design details, and will provide a vetted design at the beginning of August. 
Phase 2 Technical Design Under Consideration 
•	Questions to the Advisory Group (Slide 5)
o	The design team has solicited  Advisory Group perspective on the following straw-person Phase 2 design stances:
•	For a Medical Record Request, the data holder who is receiving the request is accountable for verifying the identity of the patient using demographic information and local Medical Record Number (MRN) where available before responding to the request.
•	Secondly, it should be up to the provider organizations to decide what to include in a response to a Medical Record Request. The Mass HIway should not dictate the request response content. It would be difficult to do this from the center. 
o	A high level workflow illustration of how the data request and response might work is provided on Slides 6 and 7. 
•	In steps 1 and 2 the patient has given the data holder permission to publish information to the Relationship Listing Service (RLS).  In this case if they have given consent, an Admission, Discharge, Transfer (ADT) message, or series of ADT messages, could be triggered off to the RLS which would allow that patient and that relationship to show up on the RLS (left side of diagram).
•	In steps 3 and 4 the patient is giving permission for a provider organization to view the information published on the RLS. The relationship on the RLS will not be viewable if the organization does not have an established relationship captured via ADT message).
•	In the last step, once Hospital B knows Hospital A holds the information; Hospital B can initiate a request for that patient’s record. If Hospital A has the capability to respond, they can send the information over. 
•	Framework for Query for a Patient Record (Slide 7)
o	The group reviewed the current direction of the Federal certification approach for Meaningful Use Stage 3, which is helping guide the framework for query.  
•	On the left side of the diagram, the data requester sends enough information to identify the patient. The RLS will help apply a medical record number. 
•	Federal framework considers the option for identifying what kind of information they would like. However it has yet to be seen if organizations are capable of responding this way.
•	The data holder has the flexibility to send whatever record information they feel is appropriate. 
o	Question: It only makes sense for the person holding the data to authenticate the request; is there even any other option to consider?
•	That is where the design team came down. It will also be reliant on how the Participation Agreements are written. 
•	The design team will not get into dictating the response requirements -  they felt it was best to let the market convention figure that out. The obvious other extreme is to say that this is the way the response needs to be formatted with specific data elements.
o	Question: In the absence of any other standard, we suppose it has to be up to the institution what data they want to push out, would it be more helpful to have that dictated, or would it get in the way? People may end up with all sorts of formats.
•	Answer: It would be useful to have some standard so organizations know what they can expect back. However, it was suggested that the response format be optional because of some of the constraints that exist in current EHR systems. For now the plan is to keep things flexible, however in the future as systems progress, more structure may be warranted. 
o	Question: Should there be a standardized response;  for example we all agree that there should be a lifetime record with a CCD based on current Meaningful Use data requirements. 
•	Answer: There was a strong sense that we should not do this because everyone is in a different place with their current systems. At this point we do not want to create an adoption barrier to those who cannot respond according to standards.
o	Question: What remains in the middle if there are no standards? 
•	Answer: There will be a lot of variation in the middle. MAeHC will pick this up with the Technology Advisory Group. It is reasonable to consider setting Meaningful Use data requirements as the floor to start. It could be frustrating for someone to query the system and come back with an unsatisfactory result because there is no standard data set.
o	Another area of concern is around patient matching. You may have a local system that uses a different algorithm for patient matching, while the Hiway is using Initiate with a defined algorithm, you could have the RLS say it matches, but the local system says it does not. At the end of the day, it needs to be the prerogative of the data holding entity to make the decision on the match. 
•	Questions to the Advisory Group Cont. (Slide 8)
o	There are multiple disclosure for which a patient could provide consent. How do you think patient consent will be gathered in a practice given the following possible disclosures, which can be bundled in any way:
•	Publishing patient/entity relationship to the Relationship Listing Service (RLS)
•	Viewing patient/entity relationship on the RLS
•	Requesting a patient’s medical record
•	Providing patients medical record to a requester
o	Trying to get a feel from the Provider Advisory Group of how this consent model might flush out over the next few years in a real practice, this will help inform the lawyers on the EOHHS team craft policy, but also for the technical people to understand how the workflow might be designed. 
•	There are so many things that go into an ER encounter, ambulatory visit, etc. What a patient is agreeing to needs to be very clear to the patient, it needs to be explicit and provide options without completely opting out from treatment. 
•	Adding these four pieces of all of the HIway interactions will be a challenge
•	Legal and Policy team will also be looking at this- there is trade off with the burden of explaining the choice on the other end.  Needs to be the path of least resistance: should be fast, but it also needs to be clear.
o	Comment: To hand some power back to the patient, there could be some standard language around how the data will be used; not exactly describing how the HIway works, but rather how the data will be shared. Part of the consent could be a check box on an intake form; “Would you like your records sent to your PCP, specialists etc.” The organization would make an effort to follow through with the requests. 
•	The challenge here would be the need to manage and enforce the patient designations, which need to be updated relatively timely. However, describing the end effect may be easier for patients to understand, rather than explaining the technology. 
o	The design team also asked for feedback on Emergency Department consent. The understanding is that consent in the ED is implied. 
•	The group needs a firm idea of what that might look like in real life. How does it work with HIPAA today in the paper world, usually isn’t there a difference with treatment consent, versus reaching to get more information? Should it not be considered as “automatic” or roped in with the treatment consent. 
•	Suppose that there is the patient consenting to the transfer of information, in a lot of electronic systems they have talked about a “break the glass” option. The other question is: is there anything :”behind the glass” that you could not get normally? The design team has taken the question off the table to date by making sure there is not “extra” information to be gathered. 
o	Some insight from an ED provider would be helpful. There should be a process defined around it for audit purposes. The Advisory Group will solicit feedback from ED providers at their organizations for the next meeting. 

Next steps 
•	Key points and recommendations synthesized and provided back to Advisory Group for final comments
•	Presentation materials and notes to be posted to EOHHS website
•	Next Provider Advisory Group Meeting – September 17, 7-8:30 am.  Conference call – (866) 951-1151   Room Number: 8234356. 
•	HIT Council – August 5, 2013, 3:30-5:00 One Ashburton Place, 21st Floor

HIT Council meeting schedule, presentations, and minutes may be found at http://www.mass.gov/eohhs/gov/commissions-and-initiatives/masshiway/hit-council-meetings.html