Content Packaging WG Notes 040710

Notes from Content Packaging Workgroup
Status of Notes: DRAFT
Date: April 7, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Lin Wan, David McCallie, Greg Turner, Vinod Muralidhar, Laurance Stuntz, Vassil Peytchev, John Moehrke, Paul Saxman, Vince Lewis, Omar Bouhaddou
& Tim Crowmell
Actions

#	Date	Action	Status	Owner	Due Date
4	4/7/10	Put together Straw Man proposal around how we could use multipart MIME and XDS rubric	Complete	Arien	4/14/10
5	4/7/10	Document multipart MIME issues that XDS.a ran into – learn those lessons, add them to the comments on the Wiki page	Open	John & Vassil	4/14/10
6	4/7/10	Keep cross group synchronization	Complete	Arien	4/14/10
7	4/7/10	Create framing issues for next week’s call	Complete	David	4/14/10

Notes
Agenda and Framing

• Review of last week’s action items
• Discussion
• Next Steps

Actions Items from Last Week:

• Arien will get self describing/non self describing discussion and send to group
• Honora/Arien [David McCallie] will post all framing issues on the Wiki
• Group members will post 2-3 discussion topics/proposals to discuss as a group on the “Discussion” page of the Wiki

Discussion

Who is the intended audience? What is the impact on the systems that support this audience?

• • Does the audience include consumers and patients?
  • Does the audience include machine to machine messaging?

Comment from Lin Wan

• Patient to patient is important to include
• What is the overall goal? Are we defining standards to push everyone to adopt? Or are we making something practical?
  • We are not trying to define the payload representations themselves
  • Do we assume the two endpoints are human in the same way we do for email messaging?
  • Do we assume the two endpoints are machines?
  • Or do we want to do both?
  • Define content packaging:
    • Options for the wrapper, whether than what is inside:
• Level of metadata and content packaging provided y multipart mime is sufficient

Or

• We support one payload

Or

• We support content as supported by XDS metadata

Comment from Laurance Stuntz

• Has to support machine to machine
• Many of these clients are big hospitals or public health reporting
• Email – the target is to the machine not to the human

Comment from Vinod Muralidhar

• Think through all the entities that will need support and connection through Meaningful Use

Clarification from David McCallie

• Unattended processing of the message

Comment from Greg Turner

• Need to keep vernacular, machine to machine, but we don’t want to defeat the purpose of NHIN direct
• Don’t want too many barriers, keep the simple

Comment from Vassil Peytchev

• Abstract model calls this a “system” but doesn’t say if it is direct, or fully automated
• Original User Story as a referral has interaction
• Lab results doesn’t have human interaction on the human side

Comment from John Moehrke

• When do we have to worry about too many manual steps being required
• What extent can we test the limits … for example, it could be implemented via A, B or C to test, but it is also educational so people outside the committees can better understand
• Content types
  • Inside the discussions we’ve had in IHE we say that we’re not going to define content
  • Bucket of bits, size, and can be defined by a MIME type by a minimum metadata

Comment from Paul Saxman

• This information will come from the User Stories WG
• How this referral works will define how much machine we want in the process
• Intent of the story was to describe an example
• Human but also a computer
• Could do unattended processing
• Stories indicate by the content types a range of options
• What do we need to do to do our job completely? People need to know what to do with an HL7V2 message when it their email box.
• Do we want to constrain the use when we can guarantee end to end success, or do we want it to be more ad hoc or can there be multiple addresses available for different endpoints?
  • Yes multiple endpoints

Comment from Vince Lewis

• Acknowledge importance of email use case
• HIS-HIS use case for transfer as well

Comment from Vince Lewis

• Don’t want to override the simplicity of NHIN Direct
• Notion of incremental steps of NHIN Direct
• Incrementally we can look at human-human as well as

Clarity from David McCallie

• Consensus around consumer and human mediated are supported
• Consensus around machine-machine are supported, maybe in an incremental fashion
• Assumption of ad hoc use of these cases

Counter straw man: if this is successful, will it replace most systems we build today (ex: HL7 Lower Level protocol would go away)

• Yes, always wrap a protocol with a protocol

Minimum constraints on sending/receiving participants

• Fairly ad hoc
• Given provider or end point could have more than one address where those address serve different purposes
• Could have one address and route based on metadata
• Transport is responsible for transport, not for workflow

Message Header and/or Metadata: How should we think about what is the required minimum for header data or metadata

• Assuming that we could have header data that is associated with the message itself and then within that message we could have “attachments” or imbedded objects that have metadata associated with those topics
• How should we think about what is the required minimum for header data or metadata
• Email header
• Don’t want to alienate the REST people
• At a minimum, it has to be at least “to and from”
• Implied functionality in the User Cases
  • Receipt date
  • Message ID that can be used to correlate messages

Comment from Vassil Peytchev

• Purpose of the abstract is to see how things could map to a particular implementation – some things have been assumed that they will work fine
• Don't get into transport level headers (SOAP, SMTP, HTTP)
• Metadata, could this be handled by a specific content type – corresponding IHE, class code, format code, plus a known profile of the content

Comment from Omar Bouhaddou

• What filters are on?
• Source needs to make explicit what filters it has on the data
• Might be lower level than we want to go into at this point

• Document metadata and document metadata are the sections that we want to be focused on
• Focus on use of Multipart MIME
  • If we were to focus on that, how does that address package vs. imbedded object

Comment from Arien Malec

• If you use multipart MIME out of the box you get minimal pay load data
  • Content type for each section and identifier for each section
  • XDR Spec
    • Find XDS metadata in the route and it maps nicely to the directory tree and Multipart MIME
    • Focus on multipart MIME as the minimum, and then and we would recommend the use of XDS Metadata

Comment from Vassil Peytchev

• If you use multipart MIME you will have implementation issues
• Even email using multipart MIME it is getting too complicated and may cause interoperability problems when we get to the implementation stage
• A lot of problems
• Whatever we come up with, we need to take back to User Story and there is a need for the Metadata to contain not the packaging level, but contain the information
• Important to have sufficient metadata to create initial patient record without having to open the actual document (a must have)

• Arien: contrary some EHR systems have the ability to push something to a queue if it doesn’t know the patient
• Previous call discussed the potential that there are use cases that involve sending a batch of patients at the end of the day

Wrap Up

• Strong convergence: multipart MIME and optional XDS
  • Volunteer to put together straw man proposal around how we could use multipart MIME and XDS rubric (Arien will put together one to react do)
• John and Vassil – document multipart MIME issues that XDS.A ran into – learn those lessons, add them to the comments on the Wiki page
• Arien will be keeping cross group synchronization