1. EU-US eHealth/Health IT Cooperation Initiative Interoperability of EHR Work Group November 20, 2013 0

2. Meeting Etiquette Participants automatically enter the webinar in “listen only” mode. The organizer will then unmute all participants. We ask if you are not speaking to manually mute yourself NOTE: VoIP participants have the ability to “Mute” themselves by clicking on the green microphone. However, if you would like to speak, only you can unmute yourself. If you are dialing in using a telephone and NOT using the VoIP you MUST dial the audio pin in order for the organizer to unmute you – if you do not use the audio pin and just push # when prompted the Organizer cannot unmute you

3. Meeting Etiquette CONTINUED If you are calling from a telephone, please do not put your phone on hold. If you need to take a call, hang up and dial in again when you have completed your other call This meeting is being recorded Another reason to keep your phone or your VoIP on mute when not speaking Use the “Chat” or “Question” feature for questions, comments and items you would like the moderator or other panelists to know. 2

4. Agenda TopicTime Allotted General Announcements5 minutes Discuss Outstanding Scoping (including comments)25 minutes Discuss Outstanding Assumptions (including comments 10 minutes Discuss Pre and Post Conditions (including comments) 10 minutes Discuss Data Exchange Diagrams and Tables5 minutes Next Steps/Questions5 minutes 3

5. Meeting Times – NOTE TIME CHANGE NEXT WEEK 4 Washington, DC 10:00am (ET) Washington, DC 10:00am (ET) London 3:00pm/15:00 (GMT) London 3:00pm/15:00 (GMT) Germany 4:00pm/16:00 (CET) Germany 4:00pm/16:00 (CET) Athens 5:00pm/17:00 (EET) Athens 5:00pm/17:00 (EET) Interoperability of EHR Work Group meets every Wednesday NOTE: Due to the Federal U.S. holiday (Thanksgiving Day), we will re-schedule our Thursday, November 28th webinar for Monday, November 25 th from 10:00am - 11:00am (ET)/3:00pm - 4:00pm (GMT)/4:00pm - 5:00pm (CET)/ 5:00pm - 6:00pm (EET).

6. General Announcements To participate in our weekly webinars, please visit the EU-US eHealth Collaboration Wiki Homepage: http://wiki.siframework.org/EU- US+eHealth+Cooperation+Initiative http://wiki.siframework.org/EU- US+eHealth+Cooperation+Initiative 5 Note: Please check the meeting schedule weekly to get the most up-to- date meeting information

7. Update on Cross Initiative Work… Data Access Framework 6 The Data Access Framework (DAF) Local Data Access Framework defines the scenarios, requirements, system interactions, and data requirements that will provide a standardized and simplified approach to the integration of data across disparate applications within a single enterprise. While the Health IT systems provide many access paths through their pre-defined interactions between a user and the system, they are limited in their support for data queries, APIs, or services to access data sets as needed. Where Health IT systems provide data access, they likely do not use industry standard access methods. Allowing access to this data can enable a provider to further analyze the collected data to understand a patient’s overall health, the health of a provider’s collective patient population, and use the data to power innovative new applications and tools to take better care of patients and populations. DAF work is being balloted through the IHE Standards organization – IHE requested S&I reach out to all initiatives involved in data access specifically those international initiatives to encourage members to get involved ensure the standards balloted and ultimately supported by IHE are international in scope

8. Participating in the IHE/S&I Joint DAF Technical Workgroup 7 DAF: http://wiki.siframework.org/Data+Access+Framework+Homepagehttp://wiki.siframework.org/Data+Access+Framework+Homepage To Join IHE: http://www.ihe.net/Join_IHE_Application/ http://www.ihe.net/Join_IHE_Application/ IHE/S&I Joint DAF Technical Workgroup will launch on Monday November 25, 2013 at 10:00AM EST IHE/S&I Joint DAF Technical Workgroup Dial In Information: Every week on Monday at 10:00AM EST [IHE International PCC Domain] Data Access Framework (DAF) Disc. Call Meeting Number: 921 745 495 Meeting Password: meeting ------------------------------------------------------- To join this meeting ------------------------------------------------------- 1. Go to https://himss.webex.com/himss/j.php?J=921745495&PW=NYjU3ODhkOGM1https://himss.webex.com/himss/j.php?J=921745495&PW=NYjU3ODhkOGM1 2. Enter the meeting password: meeting 3. Click "Join Now". 4. Follow the instructions that appear on your screen to join the teleconference. ------------------------------------------------------- To only join the teleconference ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 Access code:921 745 495

9. Join the EU-US eHealth/Health IT Cooperation Initiative 8 We encourage all members to “sign up” for the initiative. By joining, this ensures you stay up-to-date with the work being done, communications and any initiative activities Simply complete the EU-US MOU Project Signup Form on the Wiki Page: http://wiki.siframework.org/EU- US+MOU+Roadmap+Project+Sign+U p http://wiki.siframework.org/EU- US+MOU+Roadmap+Project+Sign+U p

10. Submit Your Bio Submitted biographies are now posted on the Wikipage http://wiki.siframework.org/Interoperability+of+EHR+W ork+Group#Work Group Members http://wiki.siframework.org/Interoperability+of+EHR+W ork+Group#Work Group Members 9

11. Archived Meeting Materials 10 Visit the “Materials” tab and select “Past Meetings” from the drop down menu to access all archived meeting materials http://wiki.siframework.org/Project+Meeting+Artifacts. http://wiki.siframework.org/Project+Meeting+Artifacts

12. Preparing for Meetings 11 Given our timeline and the amount of material to cover please ensure you are up-to-date with all of the activities of the interoperability work group – Visit the “Past Meetings” section of the wikipage for the latest interoperability meeting materials and recordings http://wiki.siframework.org/Project+Meeting+Artifacts. http://wiki.siframework.org/Project+Meeting+Artifacts – If you have questions, need help or want a quick update please feel free to reach out to any member of the support team – We will have little or no time to review what was covered the week prior in order to make our deadlines and deliverables FIRST MILESTONE: Completed Use Case by December 4th (with consensus completed by December 18th)

13. Use Case Development Timeline 12 DateInputsDiscussionOutputs 11/13/13 Updated scope based on comments Comments that need further discussion Finalize Scope Discuss Assumptions, Actors, and Roles Assumptions, Actors, and Roles to be posted for comments Data exchange diagrams and tables and pre and post conditions to be posted for comments 11/20/13 Updated Assumptions, Actors, and Roles based on comments Updated data exchange diagrams/tables and pre and post conditions Comments that need further discussion Review and update  Data exchange diagrams  Data exchange tables  Pre and Post Conditions Data exchange diagrams, data exchange tables, pre and post-conditions to be posted for comments 11/25/13 Updated data exchange diagrams, data exchange tables, pre and post-conditions based on comments Comments that need further discussion Draft data element tables Review and finalize  Data exchange diagrams  Data exchange tables  Pre and Post Conditions Review and update draft data element tables Finalized  Data exchange diagrams  Data exchange tables  Pre and Post Conditions Draft data element tables to be posted for comments 12/04/13 Updated data element tables based on comments Comments that need further discussion Review and finalize data element tablesFinalized data element tables 12/11/13 Draft use case with all sections completed End to end review of draft use case Updated use case based on end to end comments and ready for consensus posting 12/18/13 Consensus comments mapped into the use case Review consensus comments and finalize use case Approved use case

14. Use Case Discussion Today’s discussion: – Outstanding Scoping Comments – Outstanding Assumptions Comments – Pre and Post Conditions including Comments – Data Exchange diagrams and tables Goals for today: – Reach consensus on outstanding scoping and assumptions comments – Review and update pre and post conditions – Review and update data exchange diagrams & tables

15. Scoping Gerard: – Add Spanish – Why Chief Complaint only when a code from SNOMED will provide the translation. Note: This was recommended in previous comments and discussed by the group. – Date/time FORMAT: We must make up our minds whether we make presentation screens interoperable (and face various formats) or resort for interoperability to one ISO format for Time and Date. – Clinical statements can be (must be) made interoperable via SNOMED. Medication using ATC codes. – Procedures need one agreed classification, Which? – Textual data: (=original) as HTML using a style sheet. Note: This was recommended in previous comments and discussed by the group. – Why NOT US->EU Note: US—> EU is in scope. We will update the wiki to reflect this. – Without knowing the system architecture it is unclear we need ‘Break the glass. When we exchange between designated trusted contact points that each handles the request and forwarding there is no use case that breaks the glass. Note: This was recommended in previous comments and discussed by the group. 14

16. Scoping Barry: – We need to consider genomic, DNA, and proteomic information. The VA recognizes and is working on that. The UK explored sampling some time ago. I know many of my own DNA features and stratification. We are rapidly approaching the $1000 genome. Pharmacogenomics and genetic risk markers for cardiovascular diseases, cancers, and immunological markers (transplants, allergies, stop signs for preventing autoimmune disease, etc.) are of particular importance. Our HL7-compliant and particularly CDA Genomic Messaging System GMS and Clinical Messaging System CLaMS describes key issues and applications (no push here; personally I favor another way of implementing it now): http://xml.coverpages.org/ni2004-10-11-a.html http://pubs.acs.org/doi/abs/10.1021/pr0341336?journalCode=jprobs http://www.freepatentsonline.com/7158892.html – In scope and out of scope here is a matter of specification level. Data mapping and ontology is a matter of special specification. General specification must however provide the format and framework that represents the definition of exchange artifacts into which specific data mapping and ontology solutions can be slotted. This implies defining an attribute metadata language or field metadata language, or both. In effect, we are approaching the time for considering not just what artifacts should carry, but how. Lack of theoretical consideration of scope and power for all that might be needed can cause future problems. 15

17. Language Translation: In and Out-of-Scope 16 Language to: Language from: EnglishSpanishGermanFrenchItalianDutchSwedish EnglishYYNN SpanishY GermanY French Italian DutchN SwedishN

18. Assumptions The ability to comply with legal and regulatory regimes of the EU and US All content in the original languages will be transmitted along with any translation Standards within the EU will be the same as standards between the EU and US Translation will be done by the receiving system and may also be done by the sending system Responsibility for translation is with the entity that receives the translation Sending and receiving systems comply with mutually agreed upon specifications Gerard: – This is a tough case because of US privacy and patriot regulations that does not fit the European privacy and political opinions. – Who is accountable for the translation? Sender or receiver? I prefer the latter. Barry: – If we go this route you will need to design an international registration system for it, and carry “Registered (number) in (country)” style information in attributes or fields or artifacts. And if you want to enforce its use intrinsically, you will need digital certificates to do it. – Note: we will re-visit this when we discuss data elements 17

19. Actors & Roles 18 Type of Actor:Name of Actor:In scopeOut of Scope PersonPatientX PersonProviderX SystemEHRX SystemPHRX SystemNational Contact Point X

20. Actors & Roles 19 Type of Actor:Name of Actor:Comments on Actors & Roles: PersonPatientPatients should have optional fine grained control on what can be done. We should in this include at patient’s option the player’s representative (e.g. parent, guardian, lawyer) and player who is a public qualified authorized human adjudicator/ ombudsman to resolve system transaction difficulties/ ambiguities in event of any transaction difficulties, and to communicate between patient and representative and provider wherever possible. PersonProviderProviders should have optional fine grained control on what can be done where it does not conflict with patients’ fine grained control. SystemEHRTo paraphrase Isaac Asimov:- 1. A healthcare IT system may not injure human beings or, through inaction, allow human beings to come to harm. 2. A healthcare IT system must obey the orders given to it by authorized human beings, except where such orders would conflict with the First Law. 3. A healthcare IT system must protect its own existence and security of its information as long as such protection does not conflict with the First or Second Law. SystemPHR Note: The support team suggests that this be changed to Patient Controlled Application to be more generic Using the Wikipedia definition, “A personal health record, or PHR, is a health record where health data and information related to the care of a patient is maintained by the patient. This stands in contrast to the more widely used electronic medical record, which is operated by institutions (such as hospitals) and contains data entered by clinicians or billing data to support insurance claims. The intention of a PHR is to provide a complete and accurate summary of an individual's medical history which is accessible online. The health data on a PHR might include patient-reported outcome data, lab results, data from devices such as wireless electronic weighing scales or collected passively from a smartphone.” In my book an EHR should be or contained in a PHR, or we should be talking about the PHR. But then there is the issue of EHR to PHR feeds (to transmit insurance data etc.), under patient control ideally, and of who stores and manages the IT of PHRs …. Note: Do you mean is PHR generic enough? SystemNational Contact Point The NCP or in-country NCPs should store and manage the IT of PHRs, and (“in my book” at least) release patient-consented DE identified safe combinations and disaggregation of PHR data for data mining for public health analysis, epidemiology, and clinical and biomedical decision support systems.

21. Pre and Post Conditions: Patient Mediated Pre-conditions: – Patient controlled application is able to send the patient summary – Provider EHR is able to receive the patient summary – The National Control Point is able to? Post-conditions: – The patient controlled application has sent the patient summary – The National Control Point has? – The provider EHR has received the patient summary and stored the data 20

22. Pre and Post Conditions: Patient Mediated Question: Should the following items all be listed as pre and post conditions? Are there any conditions that should also be included? What should be the pre and post-conditions related to the National Control Point? Gerard: In Europe designated National Contact Points set up a secure and trusted channel inside their jurisdiction and with other contact points. What is meant by “provider id able to receive” We can make NO assumptions on the receiving user system. We can make them only for the systems the National Contact Points use. Barry: Yes, yes, and gosh. That’s all a big architecture issue, and like Fermat’s last theorem, the solution is too big to fit into this margin. We need to consider direct transact and NCP-mediated transact. I don’t want to die because a server goes down. And think of the NCP like a stock-broker who can only automatically transact client stocks and shares in the manner and under the conditions as prescribed but changeable instructions by the client. 21

23. Pre and Post Conditions: Patient Facilitated Pre-conditions: – Provider 1 EHR is able to receive and process the patient request to send the patient summary – Provider 1 EHR is able to send a patient summary – The National Control Point is able to? – Provider 2 EHR is able to receive a patient summary – Provider 2 EHR is able to send a patient summary – The National Control Point is able to? – Provider 1 EHR is able to receive a patient summary Post-conditions: – Provider 1 EHR has processed the patient request – Provider 1 EHR has sent the patient summary to Provider 2 EHR – The National Control Point has? – Provider 2 EHR has received the patient summary from Provider 1 and stored the data – Provider 2 EHR has sent the patient summary to Provider 1 EHR – The National Control Point has? – Provider 1 EHR has received the patient summary from Provider 2 and stored the data 22

24. Pre and Post Conditions: Patient Facilitated Question: Should the following items all be listed as pre and post conditions? Are there any conditions that should also be included? What should be the pre and post-conditions related to the National Control Point? Barry: As above, but note that it needs a powerful language to express all options, wishes of the patient, wishes of payers, wishers or providers, compliance and law, and so on which we need to consider carefully in that context. The formalism is for example IF (condition 1) AND (((condition 2) OR (condition 3)) and…) THEN (action 1, action 2, action 3,..). Then we need to see that the conditions can be supplied and have a recognized state code, and that actions have complete, pending, exception, blocked, awaiting etc. state codes. That cannot be all worked out by Monday! 23

25. Pre and Post Conditions: Provider to Provider Pre-conditions: – Provider 1 EHR is able to receive and process a request from Provider 2 to send the patient summary – Provider 1 EHR is able to verify consent – Provider 1 EHR is able to send a patient summary – The National Control Point is able to? – Provider 2 EHR is able to receive a patient summary – Provider 2 EHR is able to send a patient summary – The National Control Point is able to? – Provider 1 EHR is able to receive a patient summary Post-conditions: – Provider 1 EHR has processed the request from Provider 2 EHR – Provider 1 EHR has sent the patient summary to Provider 2 EHR – The National Control Point has? – Provider 2 EHR has received the patient summary from Provider 1 and stored the data – Provider 2 EHR has sent the patient summary to Provider 1 EHR – The National Control Point has? – Provider 1 EHR has received the patient summary from Provider 2 and stored the data 24

26. Pre and Post Conditions: Provider to Provider Question: Should the following items all be listed as pre and post conditions? Are there any conditions that should also be included? What should be the pre and post-conditions related to the National Control Point? Barry: same comments as previous 25

27. Data Exchange Diagrams & Tables: Patient Mediated Question: Does this diagram accurately represent the Patient Mediated exchange? At what points does translation occur? Barry: A detailed breakdown of these excellent starts is too a big a task to be undertaken on any weekend, but two general points may be noted. If translations in multiple approved languages (including perhaps an unambiguous artificial pivot language ) are generated at source, then the NCP is an excellent opportunity to take on the role of validating the mutual compatibility and consistency and perhaps even necessary completeness or sufficiency, notifying the sender in event of irreconcilable problems. This could progressively extend to a sophisticated NCP “Guardian Angel” function, where there are expected scenario and case study descriptions, and means of detecting departure from them. For natural language text but also quite in general, the NCP could also be the main repository for the WANT-EXPECT-GET functionality. In this managerial WEG model base on neuroscience, each node in a network receives a WANT instruction, notes and feeds back what you actually GET from its action, learns and/or is told what to EXPECT, and seeks to reduce the WEG triangle, i.e. bring information in all three channels into convergence. 26

28. Data Exchange Diagrams & Tables: Patient Facilitated Question: Does this diagram accurately represent the Patient Mediated exchange? At what points does translation occur? Barry: same comments as previous 27

29. Data Exchange Diagrams & Tables: Provider to Provider Question: Does this diagram accurately represent the Patient Mediated exchange? At what points does translation occur? Barry: same comments as previous 28

30. Use Case Development Timeline 29 DateInputsDiscussionOutputs 11/13/13 Updated scope based on comments Comments that need further discussion Finalize Scope Discuss Assumptions, Actors, and Roles Assumptions, Actors, and Roles to be posted for comments Data exchange diagrams and tables and pre and post conditions to be posted for comments 11/20/13 Updated Assumptions, Actors, and Roles based on comments Updated data exchange diagrams/tables and pre and post conditions Comments that need further discussion Review and update  Data exchange diagrams  Data exchange tables  Pre and Post Conditions Data exchange diagrams, data exchange tables, pre and post-conditions to be posted for comments 11/25/13 Updated data exchange diagrams, data exchange tables, pre and post-conditions based on comments Comments that need further discussion Draft data element tables Review and finalize  Data exchange diagrams  Data exchange tables  Pre and Post Conditions Review and update draft data element tables Finalized  Data exchange diagrams  Data exchange tables  Pre and Post Conditions Draft data element tables to be posted for comments 12/04/13 Updated data element tables based on comments Comments that need further discussion Review and finalize data element tablesFinalized data element tables 12/11/13 Draft use case with all sections completed End to end review of draft use case Updated use case based on end to end comments and ready for consensus posting 12/18/13 Consensus comments mapped into the use case Review consensus comments and finalize use case Approved use case

31. Next Steps 30 Prepare for our next meeting Continue submitting your bios NOTE: Interoperability of EHR Work Group will meet next Monday November 25 th from 10:00am - 11:00am (ET)/4:00pm - 5:00 pm (CEST)

32. Interoperability Support Leads 31 US Point of Contacts – Mera Choi: Mera.Choi@hhs.govMera.Choi@hhs.gov – Jamie Parker: jamie.parker@esacinc.comjamie.parker@esacinc.com – Gayathri Jayawardena, gayathri.jayawardena@esacinc.comgayathri.jayawardena@esacinc.com – Amanda Merrill, amanda.merrill@accenturefederal.comamanda.merrill@accenturefederal.com – Emily Mitchell, emily.d.mitchell@accenturefederal.comemily.d.mitchell@accenturefederal.com – Mark Roche, mrochemd@gmail.commrochemd@gmail.com – Virginia Riehl, virginia.riehl@verizon.netvirginia.riehl@verizon.net EU Point of Contacts – Benoit Abeloos, Benoit.ABELOOS@ec.europa.eu Benoit.ABELOOS@ec.europa.eu – Frank Cunningham, frank.cunningham@ec.europa.eufrank.cunningham@ec.europa.eu – Catherine Chronaki, chronaki@gmail.comchronaki@gmail.com

33. Questions 32

34. Resources EU US Wiki Homepage – http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative Join the Initiative – http://wiki.siframework.org/EU-US+MOU+Roadmap+Project+Sign+Up http://wiki.siframework.org/EU-US+MOU+Roadmap+Project+Sign+Up Reference Materials – http://wiki.siframework.org/EU- US+MOU+Roadmap+Project+Reference+Materials http://wiki.siframework.org/EU- US+MOU+Roadmap+Project+Reference+Materials 33