EU-US eHealth/Health IT Cooperation Initiative Interoperability of EHR Work Group

1. EU-US eHealth/Health IT Cooperation InitiativeInteroperability of EHR Work Group November 13, 2013

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.

4. Agenda

5. Meeting Times Washington, DC 10:00am (ET) • Due to the federal U.S. holiday (Thanksgiving Day), we will re-schedule our Thursday, November 28th webinar for Monday, November 25thfrom 10:00am - 11:00am (ET)/3:00pm - 4:00pm (GMT)/4:00pm - 5:00pm (CET)/ 5:00pm - 6:00pm (EET). Interoperability of EHR Work Group meets everyWednesday London 3:00pm/15:00 (GMT) Germany 4:00pm/16:00 (CET) Athens 5:00pm/17:00 (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 Note: Please check the meeting schedule weekly to get the most up-to-date meeting information

7. Join the EU-US eHealth/Health ITCooperation Initiative • 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+Up

8. Submit Your Bio • Submitted biographies are now posted on the Wikipagehttp://wiki.siframework.org/Interoperability+of+EHR+Work+Group#Work Group Members

9. Archived Meeting Materials • 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.

10. Preparing for Meetings • 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 wikipagefor the latest interoperability meeting materials and recordings 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)

11. Use Case Development Timeline

12. Use Case Discussion • Today’s discussion: • Scoping including Comments • Goals for today: • What if any text should be translated? • Should codes with existing translation include the translation? • If text is translated, what languages should be covered? • Can we assume that the EU will adopt the same standards for internal data sharing as they will for EU to US data sharing? • Are activities that involve paper copies out of scope? • Are scenarios with someone acting on behalf of a patient out of scope? • Are radiology images out of scope? • Are consents in scope? • Is break the glass in scope? • Assumptions • Actors & Roles

13. Scoping • Review Comments received on wiki • Address specific areas of scoping: • Language translation • Areas of translation • Geographic • Additional items

14. Language Translation: In and Out-of-Scope Question: Should Language Translation be in or out of scope? • Barry Robson - We really don’t have time to discuss fully these on the calls, which is probably just as well as many of the items could be a 45 minute seminar. We should put patient safety before fears of IT-based liability, and help avoid medical errors. They drive litigation anyway, and medical errors could be costing even just the US $1 trillion a year in cost.(http://www.healthdatamanagement.com/news/medical-errors-economic-cost-study-hospitals-45134-1.html). I presume the above question relates to natural language textual comment that cannot be placed into canonical form, i.e. into well -defined attributes or fields governed by a crisp ontology. Incidentally, though, I think there are safety merits in having a brief summary of essentials in natural language even if the canonical form covers everything. I am not 100% sure what the “note:” in the question means, but if it means in practice that English is translated on receipt, that is a lot more prone to error and ambiguity under emergency conditions than pre-translating it into short summaries of key features in the transmitted artifact, in a few basic languages. Moreover, translation software can be standardized at the transmitting end that constructs the transmission artifact, but translation is harder to control at the receiving end; in the latter case, one can imagine the experiment of sending the same artifact to multiple sites with their own different translation software and finding that text content is translated in multiple different ways with differences in meaning even when it is translation into the same language, which would be worrying. It is pleasing that transmitting in several languages does not prohibit the receiving-end humans or software from doing their own translations, for those who wish to take that route, and in fact the two modes can provide a safety check on each other. Transmitting several natural language translations does have the disadvantage of possible conflicts between their interpretations, although translation only at the receiving end really has essentially the same problems but hides them. In summary, leaving translation only as the responsibility of the receiver seems to be to present a greater number of problems, whilst having the sender system translate does not prohibit receiver-end translation as an alternative or parallel approach

15. Language Translation: In and Out-of-Scope Question: Should Language Translation be in or out of scope? (continued) • David Tao - I think it should be tried starting with something small like Chief Complaint (see below). The question is confusing, because it asks if it should be in or out of scope, but the parentheses makes it sound like the answer is already known to be "no." In conjunction with limited languages, perhaps the idea of "co-presenting" for this one elementwould not be too difficult. The tool/source for any translation should be clearly identified (e.g., Google Translate, human translator, etc.).

16. Language Translation: In and Out-of-Scope Question: If in scope, should we start with a sample set of 2 or 3 languages? For instance, we could pick one universal language (ex: English) and another language to demonstrate translation both ways? (Note: the intent was to suggest that we limit the scope to 1-2 languages). • Barry Robson – This question effectively implies “make English the Universal English”, at least for our purposes. It isn’t 100% universal right now. I understand, of course, that what is meant is this: if we have to choose one natural language for the EU and US, then English is an excellent choice. However, as promised I am looking into Kodaxil as a formally rigorous universal second language. I am not its inventor and have no personal bias here, but the general idea of some kind of a universal second natural-like language with a crisp ontology and semantic form following Semantic Web ideas, and that a computer can process well into natural language, seems to me to be a good idea...if it works. That I will know soon. • David Tao– Yes, starting with a small set would be a good idea, and it should be based on the languages that would provide the most benefit (a combination of which countries have the most travelers to/from US AND which countries are least likely to understand English)

17. Data on Visitors Between Countries • David Tao – Number of patients benefited. http://travel.yahoo.com/p-interests-29848550 indicates that thleadingEuropean non-English-speaking countries visited from the USA are France, Italy, Germany and Spain. So translation from French, Italian, German, and Spanish to Englishappear to be higher priorities. (Not sure whether UK-USA English needs "translation?")In the other direction, the non-English-speaking EU countries generating the most visits to the USA are Germany, France, Italy, Spain, Sweden, Netherlands, Switzerland (source: http://travel.trade.gov/view/m-2012-I-001/index.html) • David Tao – A modifying factor is whether the translation is necessary and helpful. If nearly everyone (or at least most healthcare providers) already understand English in a EU country, the priority for translation might be lower. For example, don't most Germans speak English? Of course, there are other considerations such as technical feasibility, availability of tools and resources, etc. I assume that something as ubiquitous as "Google Translate" is not precise enough to be solely used for translation. (Je suppose quequelque chose aussiomniprésentque «Google Translate» n'est pas assez précis pour êtreuniquementutilisé pour la traduction.)

18. Language Translation: In and Out-of-Scope

19. Areas of Translation: In and Out-of-Scope • Question: If in scope, should translation be limited to specific areas of clinical content? Are there other areas of clinical content that must be added to this list? • chief complaint • reason for visit • hospital course (Note: should this be excluded since we have excluded inpatient care?) • discharge summary • patient instructions • history of present illness • Barry Robson - I think that all these examples can be covered by a canonical form as an ontology using attributes or fields, though the lower items on the list will take more work. We should always strive for that if we can. Then the superficial natural language of the attributes or fields is really irrelevant and “under the hood”, since receiving software will merely place the data items in the appropriate slots. To be clear here, recall that early computer languages like Algol often had their keywords like “if” or “for” translated into corresponding French words for French programmers. However, the complied code would execute the same, either way. We have, of course, a lot more key words to worry about in our case, but that’s what the standard code, ontology, and notation initiatives are all about, and why we preoccupy ourselves with HL7, VistA, SNOMED, ICD and so on. • David Tao - I think chief complaint would be a good candidate, because it is generally just the starting point that capture in the patient's own words why they came in. Capturing the patient experience and perceptions in the patient's words is valuable in addition to the (later) medical conclusions (diagnoses, problem list, findings...). With all the "patient-centered" work going on in the US, this would be an opportunity to capture something that is not filtered through medical professionals (and medical vocabulary).

20. Geographic: In and Out-of-Scope Question: To what extent will the EU standards for EU to EU country exchanges be different from EU to US exchange? • Barry Robson - Ideally, to zero extent. The ancient Tower of Babel project was never a shining example! It does not mean that unification of healthcare IT philosophies is easy, though. Indeed, what about US to US? What exactly is the US usefully to send to or receive from Europe? That is still a bottleneck, even well after PCAST noted it. Compliance issues and interpretation of Federal regulations even differ between States of the US, and 90% of my present coding time is struggling with the problem of interconverting the Veteran’s Association MUMPS-VistA source code with HL7 etc. The EU-US eHealth project should be seen as an opportunity, also, of getting the US’s own healthcare IT house in order (I doubt that this notion has escaped US administrators!). And a European travelling in the US would then feel a little more comfortable too.

21. Additional items: In and Out-of-scope Question: Are the following additional items in scope or out of scope? • Barry Robson - All should be in scope. Authority, responsibility, workflow, privacy and encryption disaggregation, fine- grained consent, and DICOM images are all achievable, but you have to look at them as an integrated whole, considering the methods of handling each one along with the others, because they all impact each other. Our team has proofs-of-concept and doubtless others have too. There are some specific issues on thinking how work effort on this might be broken up into chunks. Authority can be an attribute, but consent on a matter should ideally be a data issue, formally a dimension of any data value, along with time stamp, and e.g. confidence interval where appropriate. Then it is fine-grained. And while disaggregation by metadata, if you take that route, was a good PCAST idea, you obviously couldn’t disaggregate or shred a DICOM image by metadata, since internally it is unstructured data, but instead you could, for security, encrypt and shred arbitrarily. • David Tao - Radiology Images might be a "low hanging fruit" in that the images themselves should be understandable without transcoding or translation. However, I wish to qualify that images by themselves would lack the "bottom line" of the radiologist's report, which should accompany them. So even though the image may not need transcoding or translation, the report would face at least the same and probably greater issues of transcoding/translation as clinical summaries, given the amount of textual content. such as "Findings," "Impression" and "Recommendations" (to name some examples from RSNA reporting templates).

22. Assumptions • The ability to comply with legal and regulatory regimes of the EU and US • The clinical content in the original languages will be transmitted without any translation • Standards within the EU will be the same as standards between the EU and US • Translation will be done by the sending system and may also be done by the receiving system

23. Actors & Roles

24. Use Case Development Timeline

25. Next Steps • Prepare for out next meeting • Continue submitting your bios • Interoperability of EHR Work Group will continue to meet every Wednesday from 10:00am - 11:00am (ET)/4:00pm - 5:00 pm (CEST) • During the week of November 25thwe will meet on Monday, November 25th from 10:00am - 11:00am (ET)/3:00pm - 4:00pm (GMT)/4:00pm - 5:00pm (CET)/ 5:00pm - 6:00pm (EET).

26. Interoperability Support Leads • US Point of Contacts • Mera Choi: Mera.Choi@hhs.gov • Jamie Parker: jamie.parker@esacinc.com • GayathriJayawardena, gayathri.jayawardena@esacinc.com • Amanda Merrill, amanda.merrill@accenturefederal.com • Emily Mitchell, emily.d.mitchell@accenturefederal.com • Mark Roche, mrochemd@gmail.com • Virginia Riehl, virginia.riehl@verizon.net • EU Point of Contacts • Benoit Abeloos, Benoit.ABELOOS@ec.europa.eu • Frank Cunningham, frank.cunningham@ec.europa.eu • Catherine Chronaki, chronaki@gmail.com

27. Questions

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