Notes from the Content Workgroup

Notes from the Content Workgroup Date: March 31, 2010 Time: 1pm-2pm Attendants: Arien Malec, Honora Burnett, Richard Elmore, Steven Waldren, Anand Shroff, David McCallie, Greg Turner, David Kibbe, Vinod Muralidhar, Laurance Stuntz, Girish Kumar Navani, Vasu Manjrekar, Vidit Saxena, Saurabh Singh, Robert Lynes, Peter DeVault, Vassil Peytchev, John Moehrke, Marc Donner, Janet Traub, Vince Lewis, Didi Davis, David Kantz, Pam Waters, Thomas Davidson, Martin Prahl, Tim Crowmell & Omar Bouhaddou Location: Switzer, 1107

Action Items o Arien will get self describing/non self describing discussion and send to group o Honora/Arien will post all framing issues on the Wiki o Group members will review framing questions on Wiki (all framing questions highlighted in blue below) o Group members will post 2-3 discussion topics/proposals to discuss as a group on the “Discussion” page of the Wiki

Walking through the Goals of Content Workgroup

Framing issue #1: Tradeoffs between simple packaging (e.g., multipart MIME) and sophisticated metadata (e.g., XDS metadata)

 A referral message is sent with structured information and with narrative text

o HL7 or CDA message type is self describing vs. Non self describing information

o Arien will get the self describing/ non self describing discussion and send to the group

 Message with multiple parts. Are all of these parts related? If so, do we have a best practice about how these are handled?

o IE all of the parts of this message are related to one

o Question from other User Story Workgroup: isn’t there a referral coordinator who can send out a batch set to the referred physician?

Framing issue #2: Content responsibilities of sender and receiver

 In the real/internet world, the receiver is responsible

 Healthcare world there are two ways of thinking about this o 1) This should be understood at both sides

. Fail as close as possible to the sender

o 2) Follow internet/real word rules that senders are responsible for understanding what receivers can obtain

Framing issue #3: Exploration of minimal interface needs for receivers accepting transactions

 What is the implied behavior of the receiver?

 Receiver errors appropriately

Framing issue #4: Enabling (but not requiring) content translation as a value-added service

 HIO’s that do content translation

Question/Comment from David McCallie Are there hidden assumptions here? We shouldn’t assume just one channel between sender/receiver.

 Do these questions have to be answered as either or? Or do different channels have different expectations that would be made available via different channels

o What is the minimal that can be supported?

Question/Comment from David McCallie: Important not to simply focus on provider-to-provider, but to also focus on provider-to consumer or provider-provider without EHR

 One address may be designed to accept complex content and another wouldn’t

 Multiple channels that can be expected to accept different things

 Strong desire to include patient as an addressable end point

Question/Comment from Greg Turner: How do we identify the packaging necessary for multiple channels?

 One key issue for this group is to think about the sender or receiver

 What is the minimal standard for sender/receiver and is there optionality

Question/Comment from Vinod Muralidhar: Will REST/SOAP be handled here?

 Independent of content pay loading

 Group that is first looking at that is Robust HIE

 Edge spec and node to node spec Question/Comment from Vinod Muralidhar: Shouldn’t we be looking at requirements?

 Do we need data to route it and retrieve information – use these questions to define what we need from that point.

 What can senders send, and what can receivers receive?

Question/Comment from Vasu Manjrekar: Our minimum threshold identified here in this workgroup is tied closely with user stories. It is our responsibility to identify the minmum threshold from sender and/or receiver and then build on levels of sophistication.

 And then building on levels of sophistication

 Also focus on the end user experience

 Closely tied to User Stories

Question/Comment from Vince Lewis: It is important to couple with other workgroups

Question/Comment from Didi Davis: Important to normalize terminology across the groups

 ID Actors and transactions

Question/Comment from Thomas Davidson: Who is taking notes and how will decisions be made?

 Notes will be on the Wiki

 Decisional model is consensus based

 WGs will think through issues, bring to consensus at the IG level

Three Questions/Comments from Vassil Peytchev:  Important to acknowledge that provider-to-provider communications need to take into account that there might be intermediaries as well

 Question to address this: Non-HER using physicians and patient access, will we define web- portal for end users or are we assuming that the receiver going to do a “push” transaction

o Yes, there has been this discussion

o What are the minimal capabilities of the receiver, and what does that imply about minimal packaging standards?

 Consider the intersection of Content Packaging with PKI group, because something that seems simple on the content packaging level might be prohibitive when we address it from a privacy & security standing

Question/Comment from David Kibbe: Agree with David McCallie  Need multiple levels of capability here

 Idea of enabling organizations is a critical one

 Real consumers are physicians in small medical practices and patients. Some of these consumer’s choice of enabling service providers are going to be very unsophisticated (i.e. GoogleHealth, or HealthValut).

 If physician’s group they need to do it through EHR module

 Make sure that when we talk about minimal receiving capabilities we understand what this is! Small practices!

Tensions:

 Tension between what you can do when you have access to Metadata and what a receiver can assume to receive in minimum state

 Tension between Expressive power and implementation complexity

Question/Comment from David McCallie: The question is what are the minimum capabilities needed by the receiver.

Question/Comment from Greg Turner : In experience from NHIN Collaborative, channels to support both simple and complicated

Question/Comment from Vinod: We need to keep in mind that content needs to can be sent to patients, providers, public health and health quality organizations

Question/Comment from Vince Lewis: Keep it simple but also acknowledge it needs also might need to be complicated

Question/Comment from Steven Waldren: Important to identify a layered approach.  If we used multi-part mime AND defined an optional type (x- xdssubset) for XSD submission set, you get the complex yet you retain the simple. I would hate to see vendors and communities to develop another mechanism for "simple exchange."  Meta-data for one is data for another.

Question/Comment from Steven Waldren: Consider the notion of what other constructs are needed to support the creation and standardization of the complex meta-data.  For example, you mentioned patient as part of the meta-data, would a central EMPI be required? or a standard demographic data set?

Next Steps:

 Arien/Honora: We will set up all of these framing questions in the Wiki  WG: Look at framing questions, and then people will review the framing questions, come up with discussion topics/proposals to discuss as a group – get to us as prior to the group and then we will set up the next group meeting – framed as discussion items in the Wiki

 Leader: David McCallie to be leader