Technology Advisory Group Meeting
September 20, 2013 2-3:30 PM 

Name	Organization	
Mark  Taricco	UMass Memorial Medical Center	
Keith Worthley	BIDMC	
Chris Diguette	Atrius Health	
Larry Garber	Atrius Health	
Claudia Boldman	EOHHS	
Century Shah	EOHHS	
David Bowditch	EOHHS 	
Sarah Moore	Tufts Medical Center	
Bill Young	Berkshire Health Systems	
Atia Amin	Network Health	
Pamela May	Partners Healthcare	
Matthew Moss	South Shore Hospital	
KT Tomlins	Guest – Orion Health	
Support Staff	Massachusetts eHealth Collaborative	
Micky Tripathi	Massachusetts eHealth Collaborative	
Mark Belanger	Massachusetts eHealth Collaborative	
Jennifer Monahan	Massachusetts eHealth Collaborative	
*Note: the majority of the Advisory Group attended the meeting but full attendance was not taken.
Review of Materials and Discussion
Project Updates
•	Mass HIway Phase 1- Transaction and Deployment Update (as of Aug 2013) (Slide 2)  
o	The group reviewed the Phase 1 updates.  There are 28 organizations in production, 13 live and 41 total organizations on the HIway. Major clients slated for testing in September/October include Holyoke, PVIX/Baystate and Atrius, Reliant, VNA Care Network. 
o	A list of 11 vendors requesting to connect to the HIway as a Health Information Service Provider (HISP) was provided. 
o	In August 97,058 transactions were exchanged. To date, over 1.5 million transactions have been transmitted through the Mass HIway.
•	Phase 2 Overall Timeline (Slide 3)
o	Many of the Public Health Nodes are now live or in testing. The preliminary approach to the phase 2 Design is complete, but the Design team is still open to feedback, and the go-live for phase 2 is slated for October 2013- March 2014. A “Platinum Spike” event is in the works. Similar to the “Golden Spike” a few different trading partners will demonstrate the phase 2 technology. Right now it is slated for November pending the governor’s availability.  
•	Current consent position is that phase 2 will require 2 separate patient permissions- RLS publish/view and Query (Slide 5)
o	The consent policy for phase 2 will touch on two new points: Sending demographic data to someone new (the HIway) where data is being persisted and information can be viewed, and the ability to query using the provider portal. Today we will focus on the technology behind the proposed policies. 
•	The first consent determines data available to RLS and the entities that are permitted to access that information (Slide 6)
o	The consent to publish/view information helps to determine the data in the RLS and it also serves as a technical control for access to that data. This is a closed community; the organization must have a consented relationship with the patient to access patient information. 
o	The only data persisted is the demographic information listed in the first paragraph of slide 6. 
•	Discussion: Options for transmitting consent to publish to and view RLS from member to the HIway (Slide 7) 
o	When this process was started there was a hope that EHR vendors would have the capability to collect a binary flag and somehow get that information to the HIway. The Design team has been looking closely at ADT messages and is trying to figure out the easiest way for the consent information to be sent to the HIway. There are a few options on the table: 
1	Include a Yes/No indicator in each ADT message sent, utilizing a pre-defined “Z segment.” 
2	Transmit a separate consent transaction; e.g. a provider could send a Direct message via standard message structure.
3	Route the ADT message to a separate Direct address conveying the consent preference; “consent.yes@direct.rls.masshiway.net for example. Messages would go to two different “mail boxes;” one for “yes,” one for “no.”
4	Noted by Larry Garber, include the flag in the Consent Segment (CON) which will provide details about a specific consent by a patient
o	Comment: There should be other criteria for success, other than relying on the EHR vendor. In MA the consent will be more complicated with HIV for example. Another success factor might be coming up with a methodology that would work for future consenting. A single binary flag, using the CON segment, which is part of HL7.1, provides the flexibility and supports future needs. 
o	Comment: Overall, there should there be a preference for keeping the consent in the same message so multiple messages will not have to be linked or reconciled. 
o	Comment: CON is the standard segment for ADT.
o	Question: The second method seems troublesome because it requires a separate transaction?
•	Answer: This is one of the draw backs and complexities of the second method; there would be some timing issues as well. Building logic around sending them separately will be a challenge.
o	Question: Wouldn’t this have the same issues as the third option? 
•	Answer: With the third option, anything coming into the “Yes” mailbox, we assume the consent has been collected; there would be no actual binary flag sent; it is just based on the delivery location of the ADT.
o	Comment: In the initial design, we intended to have this information included in the ADT message, once we saw that this is not currently utilized in the ADT message, organizations would be required to change their ADT message format.
o	Comment: With the third option where we have the mail boxes, if something comes into the “no” box the general consensus is that we do not have the consent; we would be processing those to know if the provider has previously submitted “yes” and would process that “no” for the purpose of revoking the consent.  
o	Comment: One of the things we are hoping to get from providers is information on whether they are currently working on collecting and storing consent options within their EHR, and if they have that already in a place, where can it be transmitted and associated with the ADT transactions.
o	Comment: Tufts is starting to do this with their EHR vendor, and their recommendation was to put it in the PID Segment. 
o	Comment: There is currently a configuration in Epic that will allow the CON to be inserted based on a document list. 
o	Comment: Ideally the consent indicator would be included somewhere in the ADT message that is received. The Design team feels that option number one may be the easiest way to process the consent. 
o	Question: In the last meeting we talked about being flexible with a whole bunch of things coming in. What if two organizations are using different segments?
•	Answer: Thinking about preparedness for the future, Orion wants to come up with a single agreed to format and process that can be standardized. In other words, get ADTs and consent transactions in the same way from all organizations. Orion would like to avoid having to do custom work for organizations; it will be easier to replicate as providers are on boarded. 
o	Question: Does the CON allow for multiple and different kinds of consents? 
•	Answer: Yes. Initially we would be collecting the single consent assertion, down the road you could see multiple consents being available and the process built out using the CON segment. 
o	Question: Is the CON segment designed to be part of the ADT transaction?
•	Answer: Yes, they would only be part of ADT messages. 
o	Comment: It sounds like we are probably heading down the road with option one, replacing the Z segment with the CON segment. The ADT would include the consent assertion with any transaction.
o	Question: At Tufts, the vendor is limiting us to a zero or one for collecting consent; there is no flexibility beyond that. Also, we were sending the date in the message, not sure if that is important in this context but there is often back log which would change the date. 
•	Answer: This may be more of a policy choice if the date is included; at this point in the design we were looking only at the date the transaction was received. Certainly the date the patient signed the consent form is possible.
o	Comment: Orion will go down the path of option one, leveraging the CON segment, they will map it out and see what it would look like and draft some design suggestions.  
o	Question: So for providers that do not have an EHR and are just using the web, is it just a check box that they have for consent?
•	Answer: For providers that cannot send ADT message, Orion is hoping that they have the ability to send a CSV file which contains demographic information that you would see in the PID segment. One of the things Orion is doing over the next few weeks is looking at the process of a daily batch file with ADTs, it could be sent in a provider Direct account. 
o	Comment: In terms of the batch idea, if an organization is dealing with Emergency Room work, where we need to get consent relatively fast, waiting for an overnight batch will not work. This may be fine for those that can only do batch, it just may not work for others who need the data in real time.
o	Comment: Orion has the ability to process the transaction as it comes in; a single ADT record could be sent to a Direct account.  
•	Discussion: Establishing RLS relationship for entities that wish to view RLS without contributing patient information (Slide 8)
o	At the last HIT Council meeting, there was discussion around information givers and takers and the need for the system to address that. There are multiple times when a provider will need to be a taker of the data, and not necessarily be a giver. The current thinking is that in the first release only givers and takers will view the RLS. The Design team knows they need to address the takers soon after. Some organizations may lack the necessary technology to send patient demographic information and/or deal with sensitive conditions. An organizations name may be disclosing Protected Health Information (PHI). For example a substance abuse treatment center. 
•	Discussion: Establishing Patient- Payer Relationship (Slide 9)
o	At the Legal & Policy Advisory Group meeting the group was supportive of some kind of payer involvement, but realize that this needs to be explored more. If payers are included, there needs to be a way for the payer to establish a relationship with the patient; payers would not be able to see everyone in the RLS. Right now there is a small group of payer technical leaders exploring the current options. Steve Fox from Blue Cross has volunteered to help us flush out any of the privacy and security issues. There are two things to focus on; make sure this is technically possible and the necessary policies are in place. 
o	Question: In terms of privacy and security, is there a growing consensus not to involve the payers? 
•	Answer: We have not seen  that, the Legal & Policy Workgroup is open to the idea; recognizing that there will be some people that are uncomfortable with this. 
o	Comment: It would be beneficial to pin down some use cases that would help explain how the data will be used; an education piece for consumers.  
Comment: Some of the use cases are already underway. For example, quality measurements and clinical data exchange for authorizations.
o	Question: Is it part of the idea to have patients consent to provider to provider exchange, and then have insurance be a separate agreement?
•	Answer: Some EHR’s can only handle one consent right now. 
o	Question: If my health plan is paying for my care at whatever location I am at, don’t they already know this information via the claims data? What is the concern if this information is already available?
•	Answer: It is more about the timing of the information, the HIE would allow the data to be delivered earlier. The patients should be informed that this information is available already, but the HIE can improve care management if the data is sent in real time. 
o	Comment: A payer should also only be looking at the time period that they have a relationship with the patient which is another challenge.
o	Comment: A patient may say consent to the insurance company viewing the RLS, but patient concern would be around the ability to view a Continuity of Care document. Family history and social history information does not need to be exposed to the payer. 
o	Comment: Also, it is important to note that cash payments should not be released per the HIPAA Omnibus. 
o	Comment: If this is the direction we are heading, it would be important to show the PCP relationship; since the patient is already going to have the payers telling them intimately each time they have an encounter, they might as well let the PCP know when the CCD has changed. 

•	The second consent indicates patient authorization for a query initiated through the Mass HIway (Slide 10)
o	Anyone that uses the Mass HIway to query, needs to assert consent; Meaningful Use Stage 3 is heading in this direction. The message that goes out should have an indication in the query message that patient authorization is in place. There are a lot of ways to do this technically; the Design team does not want to throw up more hurdles for providers, they want to make sure everyone knows that when they use the HIway it is only when they have patient consent. Pushing the query button is saying “Yes, I have patient consent.” 
o	Question: Is the idea that there would be a check box or another type of message for the provider to confirm that consent has been gathered?
•	Answer: Right now there is nothing that the provider needs to click, or reminder notifications. 
o	Comment: There needs to be some education around this, but at the moment there is not an explicit pop-up or check box for the consent. The provider will only be able to find the patient if they have asserted consent; if there is no ADT consent assertion they would not be able to pull up the patient and view the RLS.
o	Question: Does consent message need to be sent each time you make a query?
•	Answer: Yes.
o	Comment: Clicking on the extra button does not make anything more valid. Any entity involved with the HIway must sign a Participation Agreement (PA) in order to participate; the PA explains the consent requirements. Every action you do is because you have already agreed to follow the rules outlined in the PA; a policy control. 
o	Comment: Also, within the portal, everything is audited; every click view and transaction is logged per user. 
o	EOHHS will likely get the final say on this, however we will let them know that Technical Advisory Group prefers option one. 
•	Background: RLS and Query- Retrieve Available Either Through HIway Portal or Integrated in EHR (Slide 11)
o	Starting on the right, phase 2, like phase 1, is designed to meet the market where it is, understanding that there is a lot of difference in maturity between providers. The design team has designed this to be as open and flexible as possible with the four query retrieve methods listed on the right of the slide: 
•	Background: Overview of HIway Query-Retrieve Use Patterns (Slide 12)
o	Patient consent is gathered in order for the patients name show up on the RLS and that there is a relationship established when you contribute information. There is a technical control in place; you can only view patients which have a relationship with your organization. If there is no ADT message sent, the patient is invisible to the user on the RLS.

Next Steps
•	Reactions to be taken into account by phase 2 design team, many of whom were on the call today.
•	Meeting notes synthesized and provided back to Advisory Group for final comments.
•	Presentation materials and notes to be posted to EOHHS website. 
•	Next Advisory Group Meeting – October 18, 2:00-3:30
-	Conference call (866) 951-1151 x. 8234356
•	HIT Council – October 7,  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