Technology Advisory Group Meeting
August 23, 2013 2-3:30

Name	Organization	
Kertis Tomlins (KT)	Orion Health 	
Larry Garber	Atrius Health	
Rick Mohnk	UMass Memorial Medical Center	
Adrian Gropper	HealthURL Consulting	
Sarah Moore	Tufts Medical Center	
Pamela May	Partners Healthcare	
Kris Williams	MassHealth	
John Kelly	EOHHS	
David Bowditch	EOHHS	
Anurag Lal	EOHHS	
Manu Tandon	EOHHS	
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	

Review of Materials and Discussion
Project Updates
•	Phase 1-Transaction and Deployment Update; as of July 2013 (Slide 2)  
o	As of the end of July, 5 organizations are in production, another 8 are in testing and 4 organizations are “on the bubble.” 93k transactions were sent over the HIway in July, putting total transactions above 1.3 million. 
•	Comment:  Reliant/VNA Care Network has tested the Local Area Network Devices (LAND), it works great. They have also tested the LAND converter box, which converts incoming CDAs to HL72.5.1 transcription, and that is also working well. The organization is planning to go live by September.
•	Phase 2 Overall Timeline (Slide 3)
o	The group reviewed the Phase 2 timeline.  The Public Health nodes are quickly coming online. Right now all of the needed reporting capabilities for Meaningful Use Stage II (MU) Public Health measures are in production; Immunization and Reportable Labs. Syndromic Surveillance nodes are in testing. The Phase 2 Requirements Gathering and Validation and the Phase 2 Preliminary Design have been completed. Phase 2, release 2, timing may be pushed back, with some Phase 2 services available in November. 

Mass Hway Phase 2- Reactions to the near and final design 
•	Search, Query, Response Availability (Slide 5)
o	Phase 2 discussion today will center on the Master Person Index (MPI), Relationship Listing Service (RLS) and consent as they have been designed for the phase 2 go live. 
o	Phase 2 services are optional, they are meant to help the market out and make it easier for organizations to do query and retrieve. Some may decide to stay with Phase 1 services and not go to Phase 2 based on system capabilities and preferences. 
o	The data requestor is the one using the services directly. The data holding entity has the responsibility of validating the request and deciding how to respond using the services directly. It is important to note that the responses always go back to the user; the response could happen over the HIway, but will not be available in the portal, the HIway is acting as an enabler. 
o	The coming slides show screenshots of the Mass HIway Provider Portal – this will be one way to access the phase 2 services. Mass HIway Webmail users will always be using the portal while others may start with the Provider Portal initially and then access the services through their EHR once their EHR vendor is able to consume the phase 2 web services. 
•	RLS and Query-Retrieve Available Either Through HIway Portal or Integrated in EHR (Slide 6)
o	The right side of the diagram describes the 4 ways that people may query for and retrieve.
1.	Manual Retrieve: Using the portal to find the record, and then retrieve records manually via fax, phone etc.
2.	Cross-entity viewing: The idea here is to leverage something that is working well in the market today, like the Magic Button, and to improve upon it.  The RLS logic will help a provider find information quickly by only enabling cross-entity view with organizations that have information for a given patient.  (note: assuming cross-entity view capabilities and legal agreements are in place between data requesting organization and data holding organization)
3.	“Push-Push”: Using the Phase 1 “pipe” to do a push of a request, and then the response push using the same services. This is similar to an email record request, only more secure.
4.	“Query Response”: This service would enable a request and allow for an automated response from the data holder provided that proper information is included in the request. 
o	All of these capabilities are essentially independent. The record search could use the portal or have it integrated in the EHR via the web service. This is separate from the record request which can be generated through the portal or could be natively generated from the EHR, whether or not you go through the RLS.  The response back does not come through the Provider Portal; it can be facilitated via the HIway in the same way a direct message would be sent, but it would not be viewed in the Provider Portal. 
o	Depending on how the response comes back, the HIway may or may not be able to track the response. This was intentional; if you imagine it the other way around, where everything went through the HIway, it would allow for more control from the center, but it needs to be flexible to the market moving forward. The design team is interested in what the Advisory Group thinks about that decision. 
•	Overview of HIway Query-Retrieve Use Patterns (Slide 7) (skipped)
•	Login-Details (Slide 8 & 9)
o	The user is logging into a Provider Portal launched with a web browser. It allows for access controls based on username and password. These may or may not be tied to the user’s direct address; the idea is that they would be separate independent credentials. There are future features that would allow for a single sign on and launches from within the EHR pending vendor capabilities. 
o	The data collected is only the username and password.
•	Landing Page-Details (Slide 10 & 11)
o	This where you land when you first enter the portal. There are two distinct services: Patient search (MPI/RLS) and the Medical Record Request (MMR). 
o	The data includes user information and informational content; there is no PHI at this point. 
•	Demographics Search and Search Results- Details (Slide 12 & 13)
o	The user is searching the MPI using patient demographic information using  a combination of the Medical Record Number (MRN) and identifier type (organization that issued that MRN) patient name, gender, DOB, address, email, and/or phone number.  
o	Only “direct hits” will be returned, preventing any record fishing.  Policy decisions for minimum data required for returning the patient name is pending. 
•	Question: For physicians working at different hospitals and practices, would all of their entity relationships be known to the system so that they could look at patients from multiple locations
•	Answer: There will be a different login per entity. Patient relationships are at the entity level so when you log on as a member of an entity you will be allowed to see the patients with a consented relationship with your entity. 
•	Patient Summary (RLS)-Details (Slide 14 & 15)
o	Selecting the patient that has been found through the search will expose the relationship listing service. For this particular patient, the RLS displays the 4 different locations where the patient was seen. There is context included: the date that the last ADT was sent and the number of encounters that have been recorded in the RLS for that entity. 
o	If a patient sees someone and does not consent to publish the relationship, the entity will not be shown. 
•	Relationship Selection-Details (Slide 16 & 17)
o	Selecting an entity from the RLS will display general information about the entity and available query options. These may include cross-entity viewer (aka “Magic Button”), Medical Record Request, or information about how to contact the organization to facilitate the records transfer by fax, email etc…
•	Question: You talked about the fact that there would be no information released into the portal, but isn’t that what is happening with the cross entity viewer?
•	Answer: It is a separate browser that gets triggered; the portal is just presenting the credentials and making the request to the source system. It is not in the portal, it is just depicted that way on the slide. There is no data or content managed by the portal; simply sending the request on the behalf of the clinicians. 
•	Cross Entity Viewer-Details (Slide 18 & 19)
o	Selecting the Cross Entity Viewer enables request for a cross entity view from the Provider Portal. For example, BID and Atrius currently have “Magic Button” capabilities and all of the necessary contractual agreements nailed down. This functionality is going to come in and support that functionality. It will pass along a request including patient demographic information, authorized entity name and certificate, and data requester name (credentials used to log in to the portal). The HIway is brokering the connection and can audit that a request occurred.
•	Question: If the “Magic Button” functionality already exists, does it need to be to the point where they have already achieved EHR to EHR Magic Button integration, or can it be a matter of an organization speaking to another and asking for viewing capabilities.
•	Answer: The assumption now is to start with improving those relationships that already exist and to take a fairly narrow role in the management of that. The state is interested in pushing most of the responsibility on the information trading pairs.
•	 It is up to the data holder to evaluate the request and decide how to respond based on the credentials being presented to it. 
•	Medical Record Request-Details (Slide 20  & 21)
o	The request will include the data requester authentication credentials providing authentication assuredness and patient identifying information from the HIway. The Provider Portal will have no visibility into the response transaction. Responsibility falls on the data holder to do validation checks, manually or automatically. 
•	Question: If you send a record from MGH to BID, there will be a different MRN at each location. If MGH does not know the BID MRN, they will send their transaction to BID with their own medical record number. Wouldn’t it be great if part of this included the BID MRN?
•	Answer: If you are an MGH provider using the portal, you can see that the patient has records at BID. When you submit the request, it will be seen with their (BIDs) MRN.
•	Follow up question: When they (BID) reply, will this then include the requesters MRN?
•	Answer: No at this time it would not, the reply would include BID’s MRN, the date requesters MRN will not be shared. 
•	Follow up question: If you know the MRN, why not send it back for easier incorporation into both systems?
•	Answer: Yes, this information is in the MPI so it would not be technically difficult to send. We will take this suggestion back to the design team.
o	Question: In what sense is the HIway certifying the requestor? In other words if the actual transaction from the record holder to the requester is being done via Direct versus single sign on, in what sense is the HIway liable, or acting as the identity provider for the requester? It is not clear how that gets factored into the Direct standard Meaningful Use sense. 
•	Answer: What the HIway is saying is that if there is a request coming through the HIway infrastructure the receiver of the request will receive a credential verifying who they are on the HIway. The HIway has procedures in place that support the ability of the receiver to trust that information. 
o	Follow up question: Whether you are using the Magic Button or this method, is the HIway acting as a single sign on authority? 
•	Answer: No, not at this point, there is no true federation or reconciliation of record identity on one side or the other.
o	Follow up question: Is the Magic Button putting up password verification when you click it?	
•	Answer: Based on a table built in the HIway, someone who has an account on the portal, and that account has been tied to an organization, and they have a Direct ID tied to the organization, the HIway is passing that credential or request on. It is up to the institution how they want to trust that credential. 
o	Comment: The fact that we are not being explicit about this issue does not make it easy going down the line; in other words everything described thus far sounds reasonable i.e. Atrius can decide to accept the credentials from the HIway, while Reliant may not. It is effectively what we are doing- a single sign on. 
•	Response: In terms of functionally, the design team is trying to decrease the barriers. It is an “SSO-like” situation without the HIway taking full responsibility for credentialing decisions.
o	Comment: This raises the question about using standards or not (e.g. OpenID Connect). It would be a shame for us to create a proprietary mechanism to do this functionality because it makes the security analysis and utility of what we are doing nationwide a lot lower. This is a time to consider that as part of the procurement; otherwise there is a huge security and privacy analysis.
•	Response: We do not want to set anything proprietary up. The design team has been considering and is open to all of the standards, but are looking at which are developed enough to more forward, while keeping in mind where the federal standards are heading. Hopefully by the time where we need to put something concrete in there will be standards in place. 
o	There is nothing that is happening now that cannot be modified moving forward.

Question to the group: From what you have seen today, do you see high utility here? Will this be useful to people?
o	Question: Beforehand, can you explain how this will look on the record holder side? Is this coming directly into the EHR, does someone need to monitor the portal? 
•	Answer: The idea is that there will be a set of options, you can natively generate the request on your own and the portal is really just facilitating the request according to a particular patient. In the query response, the web portal would be your ability to trigger the generation of a standard based request; helpful if your EHR cannot do this on its own. Some of these details need to be fully explored.
o	Follow up question: How will the holder know about the request? 
•	If you are a webmail user, you could really just get a direct message that may require a manual response. What the design team has looked at is the HL7 FHIR (Fast Healthcare Interoperability Resources) transaction standards which are both human and machine readable. This would be sent to the organization, providing them the option to process it manually or automatically. 
o	Comment: Jumping to FHIR skips a step that we have considered as part of Blue Button Plus. It would be nice to consider this in the process. 
•	Response: On the high end you have machines that can handle automation, on the low end you have two organizations with direct webmail accounts using FHIR, which allows for the option to manually process a request. The advantage to FHIR is that it allows for flexibility based on the end users capabilities. 
o	Question: If the record holder cannot support FHIR, would they just receive a direct message? Does the portal know to do this?
•	Answer: This is not a manual process right now. A lot of this will be based on the requester; at the very least someone can manually process the request. 
o	Comment: The only record holders who can take advantage of this are only those with sophisticated systems. You make it more attractive if the system or user already knows what the capabilities are for that receiving organization. In other words, build some functionality in that would indicate the capabilities.
o	Question: What kind of viewer will the receiver need to have to view human readable content?
•	Answer: There is a component in the header of the request that is human readable. 
o	Comment: Just like in other parts of the provider directory, we keep certain attributes about a provider/organization; we could add this field to the “provider profile” at the organization level that indicates how they would like to receive records on the HIway. At the very least, it would be nice to know; OK I need to send it this way. It could be as simple as asking preference when enrolling providers.
•	Response: Orion is already brokering the relationship between the data requestor and data holder and may be able to match the request format with the capability of the data holder. 
o	Question: Why pick FHIR? No one is using it? Why are we not using CDA architecture which a lot of people are using today?
•	One reason is that organizationally, Orion feels it will catch on over time, but from a technical prospective you can send a human and machine readable content in a very standardized format. It has set up a schema of information that makes sense when you are trying to engage in a request for records, and it acknowledges that there are varying EHR capabilities. 
o	The design team has noted this feedback and will discuss whether the CDA format is more appropriate. Nothing is set in stone, the design is very flexible. 
Next Steps
•	Next steps (Slide 23)
•	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 – September 20, 2:00-3:30
-	Conference call (866) 951-1151 x. 8234356
•	HIT Council – September 9th,  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