1

EU-US eHealth/Health IT Cooperation InitiativeInteroperability of EHR

Work Group

November 20, 2013

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

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.

3

Agenda

Topic Time Allotted General Announcements 5 minutesDiscuss 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 Tables 5 minutesNext Steps/Questions 5 minutes

4

Meeting Times – NOTE TIME CHANGE NEXT WEEK

5

Washington, DC

10:00am (ET)London

3:00pm/15:00 (GMT)Germany

4:00pm/16:00 (CET)Athens

5:00pm/17:00 (EET)

Interoperability of EHR Work Group

meets everyWednesday

• NOTE: Due to the Federal U.S. holiday (Thanksgiving Day), we will re-schedule our Thursday, November 28th webinar for Monday, November 25th from 10:00am - 11:00am (ET)/3:00pm - 4:00pm (GMT)/4:00pm - 5:00pm (CET)/ 5:00pm - 6:00pm (EET).

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

6

Note: Please check the meeting schedule weekly to get the most up-to-date meeting information

Update on Cross Initiative Work… Data Access Framework

7

• 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 DAF: http://wiki.siframework.org/Data+Access+Framework+HomepageTo Join IHE: http://www.ihe.net/Join_IHE_Application/

IHE/S&I Joint DAF Technical Workgroup will launch on Monday November 25, 2013 at 10:00AM ESTIHE/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 495Meeting Password: meeting-------------------------------------------------------To join this meeting-------------------------------------------------------1. Go to https://himss.webex.com/himss/j.php?J=921745495&PW=NYjU3ODhkOGM12. Enter the meeting password: meeting3. 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

Join the EU-US eHealth/Health ITCooperation Initiative

9

• 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

Submit Your Bio• Submitted biographies are now posted on the

Wikipage http://wiki.siframework.org/Interoperability+of+EHR+Work+Group#Work Group Members

10

Archived Meeting Materials

11

• 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.

Preparing for Meetings

12

• 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.

– 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)

Use Case Development Timeline

13

Date Inputs Discussion Outputs11/13/1

3Updated scope based on comments Comments that need further discussion 

Finalize ScopeDiscuss Assumptions, Actors, and Roles

Assumptions, Actors, and Roles to be posted for commentsData exchange diagrams and tables and pre and post conditions to be posted for comments

11/20/13

Updated Assumptions, Actors, and Roles based on commentsUpdated data exchange diagrams/tables and pre and post conditionsComments 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 commentsComments that need further discussionDraft data element tables

Review and finalize Data exchange diagrams Data exchange tables Pre and Post ConditionsReview and update draft data element tables

Finalized Data exchange diagrams Data exchange tables Pre and Post ConditionsDraft data element tables to be posted for comments

12/04/13

Updated data element tables based on commentsComments that need further discussion 

Review and finalize data element tables

Finalized 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

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

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.

15

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=jprobshttp://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.

16

Language Translation: In and Out-of-Scope

17

Language to:

Language from:

English Spanish

German French Italian Dutch Swedish

English Y Y N N

Spanish Y

German Y

French

Italian

Dutch N

Swedish N

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

18

Actors & Roles

19

Type of Actor: Name of Actor: In scope Out of Scope

Person Patient X

Person Provider X

System EHR X

System PHR X

System National Contact Point

X

Actors & Roles

20

Type of Actor:

Name of Actor:

Comments on Actors & Roles:

Person Patient Patients 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.

Person Provider Providers should have optional fine grained control on what can be done where it does not conflict with patients’ fine grained control.

System EHR To 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.

System PHRNote: 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?

System National 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

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.

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

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!

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

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

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.

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

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

Use Case Development Timeline

30

Date Inputs Discussion Outputs11/13/1

3Updated scope based on comments Comments that need further discussion 

Finalize ScopeDiscuss Assumptions, Actors, and Roles

Assumptions, Actors, and Roles to be posted for commentsData exchange diagrams and tables and pre and post conditions to be posted for comments

11/20/13

Updated Assumptions, Actors, and Roles based on commentsUpdated data exchange diagrams/tables and pre and post conditionsComments 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 commentsComments that need further discussionDraft data element tables

Review and finalize Data exchange diagrams Data exchange tables Pre and Post ConditionsReview and update draft data element tables

Finalized Data exchange diagrams Data exchange tables Pre and Post ConditionsDraft data element tables to be posted for comments

12/04/13

Updated data element tables based on commentsComments that need further discussion 

Review and finalize data element tables

Finalized 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

Next Steps

31

• Prepare for our next meeting• Continue submitting your bios• NOTE: Interoperability of EHR Work Group will

meet next Monday November 25th from 10:00am - 11:00am (ET)/4:00pm - 5:00 pm (CEST)

Interoperability Support Leads

32

• US Point of Contacts– Mera Choi: Mera.Choi@hhs.gov– Jamie Parker: jamie.parker@esacinc.com– Gayathri Jayawardena, 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

Questions

33

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

34