Content Packaging Meeting 2010-04-14
Jump to navigation
Jump to search
Notes from 'Content Packaging' Workgroup
Status of Notes: DRAFT
Date: April 14, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, David Kibbe, Didi Davis, Greg Turner, Omar Bouhaddou, Tim Crowmell, Vassil Peytchev, Vasu Manjrekar, Vidit Saxena, Mark Stine, Keith Boone, Chris Lomonico & Tim McNeil
Actions
Notes
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Actions Items from Last Week:
· Main framing issue will be to walk through proposal based on some of the feedback we’ve heard
· Document multipart MIME issues that XDS.a ran into – learn those lessons, add them to the comments on the Wiki page
· Keep cross group synchronization
· Create framing issues for next week’s call
· Put together Straw Man proposal around how we could use multipart MIME and XDS rubric
Discussion:
· http://nhindirect.org/Content+Container+Specification
· Multipart MIME could be an option, but needed a little more variety
· Framing issue: Looking at AS1 and AS2 as solutions
o Internet messaging format
o Content description for email
o All the common things that map to the Use Cases
§ To
§ From
§ Message ID’s
o Multipart Content Types – can get very complicated
o A Health Content Container SHALL be an Internet Message Format document conforming to RFC 5322.
Synopsis
· When explicitly creating a Health Content Container, the message body SHALL be one of the following:
o Multipart/mixed (conforming to RFC 2045 and |RFC 2046)
o Multipart/related (conforming to |RFC 2387), containing a recognized manifest metadata section in the root (the start element for the multipart/related document). This document explicitly describes the use of XDS metadata as the metadata manifest.
o Multipart/signed or multipart/encrypted, containing of the above content types in the main body part
· Rules for processing:
· When processing a Health Content Container, there are two levels of conformant processing for a Health Content Container:
o Basic processing, which MUST process simple message bodies and multipart/mixed and multipart/signed (where the main body part is multipart/mixed) content types, including base64 encoded body parts, and properly interpret the associated content type metadata (but need not understand all possible content types)
o XDS Metadata processing, which MUST interpret a multipart/related and multipart/signed (where the main body part is multipart/related) content parts where the metadata manifest is XDS metadata and a multipart/mixed format where the body parts are base64 encoded compressed XDM files
· If we want to allow plain old email, there is a lot of stuff that comes along with that – worst case, treat everything like multipart mixed
· Multipart is a recursive container specification, in that body parts may themselves be multipart messages.
· The use of multipart/encrypted is confined to cases where the Source and Destination prefer end-to-end encryption and, as such, require the Source and Destination to communicate key information out of band.
Message Headers
· From
· To
· Origin-Date
· Message-ID
· In-Reply-To
· CC
· MIME
Message Signature Headers
The following headers are to be used for message or transaction level signatures, to assert that the sending party has adhered to the policy framework associated with the certificate used for signature:
· FRAMING: Message Signature Heading
Comments/Feedback for Specification
Vassil and Keith discuss in the context of that feedback discuss content type and SDS.a
Comment from Vassil Peytchev
· Applicable, actionable item
Comment from Keith Boone
· Struggle with expressing in multipart MIME
· Two different cases that need consideration
o 1) What your exchanging is a single, clinical document (CDA document)
§
§ Mail client won’t be able to display this – need a style sheet to display a view of this information and this style sheet might make use of another style sheet
§ With healthcare standard formats, there are ways to pull out the metadata (patient, provider, etc), but not in a consistent format
o 2) What you’re exchanging is a collection of clinical documents
§ Need for each one to have a style sheet associated with it – should be using
§ If multipart representation is flat, you’ve lost something useful in order to organize these different components in a way that makes them easy to manage
§ Multipart MIME recursive structures are harder to get at
§ Plethora of application software that deals with the processing of Zip files that many developers are familiar with
§ Dealing with multipart MIME
§ Easier to deal with when you have to send multiple documents to zip them and send them as a package
§ MIME can work, but the flattening of the structure to avoid complexity illuminates some of the ways that people want to organize these, so ZIP is an easier approach
§ Zipped XML files often compress down 6:1, requiring less bandwidth
§ MIME types, there are no official, registered types
§ Text/xml is often used, and xml allows trivial parsing to figure out the doctype
§ Want to know about the type
· Base type
· What set of rule it conforms to in terms of content (format code)
· Classification of the kind of information
· Class code that is independent from weather this is a text/HTML
o Think about ZIP for packaging up the collection rather than multipart MIME
o One content container that works across two of the three “recommended mechanism for transporting”
o Relationship of MIME to REST
§ Representation of resource retrieving is health content
Arien summarizes the thought process to getting here
· Where the spec came from – two different directions
· Thread of discussion in this working group
o There is a basic set of metadata that is reasonably well addressed
o Know what the type is and leave to receiver to do the processing
o Merits of that approach is that it provides a low barrier of entry to guys in the garage and the provider who wants to use a plain email client as their endpoint system
o 1) Lowest threshold can be expressed as multipart MIME – but an option to have more highly structured content
o 2) Relates to user stories
§ Many of them want to do things like send over information and technical information
§ Lowest threshold of this is textual representation with attached summary document
§ Low threshold for describing a continuity of care document
o 3) Posited meeting providers where they are and allowing for simple use of email client
o 4) thinking about interoperability between SMTP and rest and IHE
§ Where are limits?
· Preconditions correct assumptions
· Concluding the correct conclusions
Comment from David Kibbe
· Clinicians, providers in fairly simple conditions
o A lot less information
o Summary, or summary with an image
· What are use cases for larger organizations?
Comment from Vassil Peytchev
· Need to go one or few steps deeper to work on this collaboratively and how that maps to the simple use cases that we want to start with
· 1) Import email client with more than one thing to attach, it is simpler to put them in a directory and zipping them is easier than defining a MIME structure
· 2) Not talking about email, but talking about REST or more complicated protocol
o Trying to use MIME multipart is not well represented in the tool-kit
· Vassil will write up more about MIME on the Wiki
Comment from Keith Boon
· Keith Boone will write up the applicability of the ZIP on the Wiki
· Simple interoperability that Dr. Kibbe talks about is when summary document is in CCD or CCR format
Wrap up from Arien
· Arien will post to the Wiki: over constraining on an SMTP client
· Thinking about mail/email client interoperability
· Multipart MIME isn’t as developer friendly
· Arien will post on the wiki further thoughts on an alternative, super simple content packaging formula that meets use case of presupposition – that is simple from developer and end user perspective?
Notes from 'Content Packaging' Workgroup
Status of Notes: DRAFT
Date: April 14, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, David Kibbe, Didi Davis, Greg Turner, Omar Bouhaddou, Tim Crowmell, Vassil Peytchev, Vasu Manjrekar, Vidit Saxena, Mark Stine, Keith Boone, Chris Lomonico & Tim McNeil
Actions
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 8 |
4/14/10 |
Provide post on the wiki further thoughts on an alternative, super simple content packaging formula that meets use case of presupposition – that is simple from developer and end user perspective? |
Open |
Arien |
4/21/10 |
| 9 |
4/14/10 |
Provide post on applicability of ZIP on Wiki |
Open |
Keith |
4/21/10 |
| 10 |
4/14/10 |
Provide Post about MIME on Wiki |
Open |
Vassil |
4/21/10 |
| 11 |
4/14/10 |
Next time discuss message signature heading |
Open |
All |
4/21/10 |
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Actions Items from Last Week:
· Main framing issue will be to walk through proposal based on some of the feedback we’ve heard
· Document multipart MIME issues that XDS.a ran into – learn those lessons, add them to the comments on the Wiki page
· Keep cross group synchronization
· Create framing issues for next week’s call
· Put together Straw Man proposal around how we could use multipart MIME and XDS rubric
Discussion:
· http://nhindirect.org/Content+Container+Specification
· Multipart MIME could be an option, but needed a little more variety
· Framing issue: Looking at AS1 and AS2 as solutions
o Internet messaging format
o Content description for email
o All the common things that map to the Use Cases
§ To
§ From
§ Message ID’s
o Multipart Content Types – can get very complicated
o A Health Content Container SHALL be an Internet Message Format document conforming to RFC 5322.
Synopsis
· When explicitly creating a Health Content Container, the message body SHALL be one of the following:
o Multipart/mixed (conforming to RFC 2045 and |RFC 2046)
o Multipart/related (conforming to |RFC 2387), containing a recognized manifest metadata section in the root (the start element for the multipart/related document). This document explicitly describes the use of XDS metadata as the metadata manifest.
o Multipart/signed or multipart/encrypted, containing of the above content types in the main body part
· Rules for processing:
· When processing a Health Content Container, there are two levels of conformant processing for a Health Content Container:
o Basic processing, which MUST process simple message bodies and multipart/mixed and multipart/signed (where the main body part is multipart/mixed) content types, including base64 encoded body parts, and properly interpret the associated content type metadata (but need not understand all possible content types)
o XDS Metadata processing, which MUST interpret a multipart/related and multipart/signed (where the main body part is multipart/related) content parts where the metadata manifest is XDS metadata and a multipart/mixed format where the body parts are base64 encoded compressed XDM files
· If we want to allow plain old email, there is a lot of stuff that comes along with that – worst case, treat everything like multipart mixed
· Multipart is a recursive container specification, in that body parts may themselves be multipart messages.
· The use of multipart/encrypted is confined to cases where the Source and Destination prefer end-to-end encryption and, as such, require the Source and Destination to communicate key information out of band.
Message Headers
· From
· To
· Origin-Date
· Message-ID
· In-Reply-To
· CC
· MIME
Message Signature Headers
The following headers are to be used for message or transaction level signatures, to assert that the sending party has adhered to the policy framework associated with the certificate used for signature:
· FRAMING: Message Signature Heading
Comments/Feedback for Specification
Vassil and Keith discuss in the context of that feedback discuss content type and SDS.a
Comment from Vassil Peytchev
· Applicable, actionable item
Comment from Keith Boone
· Struggle with expressing in multipart MIME
· Two different cases that need consideration
o 1) What your exchanging is a single, clinical document (CDA document)
§
§ Mail client won’t be able to display this – need a style sheet to display a view of this information and this style sheet might make use of another style sheet
§ With healthcare standard formats, there are ways to pull out the metadata (patient, provider, etc), but not in a consistent format
o 2) What you’re exchanging is a collection of clinical documents
§ Need for each one to have a style sheet associated with it – should be using
§ If multipart representation is flat, you’ve lost something useful in order to organize these different components in a way that makes them easy to manage
§ Multipart MIME recursive structures are harder to get at
§ Plethora of application software that deals with the processing of Zip files that many developers are familiar with
§ Dealing with multipart MIME
§ Easier to deal with when you have to send multiple documents to zip them and send them as a package
§ MIME can work, but the flattening of the structure to avoid complexity illuminates some of the ways that people want to organize these, so ZIP is an easier approach
§ Zipped XML files often compress down 6:1, requiring less bandwidth
§ MIME types, there are no official, registered types
§ Text/xml is often used, and xml allows trivial parsing to figure out the doctype
§ Want to know about the type
· Base type
· What set of rule it conforms to in terms of content (format code)
· Classification of the kind of information
· Class code that is independent from weather this is a text/HTML
o Think about ZIP for packaging up the collection rather than multipart MIME
o One content container that works across two of the three “recommended mechanism for transporting”
o Relationship of MIME to REST
§ Representation of resource retrieving is health content
Arien summarizes the thought process to getting here
· Where the spec came from – two different directions
· Thread of discussion in this working group
o There is a basic set of metadata that is reasonably well addressed
o Know what the type is and leave to receiver to do the processing
o Merits of that approach is that it provides a low barrier of entry to guys in the garage and the provider who wants to use a plain email client as their endpoint system
o 1) Lowest threshold can be expressed as multipart MIME – but an option to have more highly structured content
o 2) Relates to user stories
§ Many of them want to do things like send over information and technical information
§ Lowest threshold of this is textual representation with attached summary document
§ Low threshold for describing a continuity of care document
o 3) Posited meeting providers where they are and allowing for simple use of email client
o 4) thinking about interoperability between SMTP and rest and IHE
§ Where are limits?
· Preconditions correct assumptions
· Concluding the correct conclusions
Comment from David Kibbe
· Clinicians, providers in fairly simple conditions
o A lot less information
o Summary, or summary with an image
· What are use cases for larger organizations?
Comment from Vassil Peytchev
· Need to go one or few steps deeper to work on this collaboratively and how that maps to the simple use cases that we want to start with
· 1) Import email client with more than one thing to attach, it is simpler to put them in a directory and zipping them is easier than defining a MIME structure
· 2) Not talking about email, but talking about REST or more complicated protocol
o Trying to use MIME multipart is not well represented in the tool-kit
· Vassil will write up more about MIME on the Wiki
Comment from Keith Boon
· Keith Boone will write up the applicability of the ZIP on the Wiki
· Simple interoperability that Dr. Kibbe talks about is when summary document is in CCD or CCR format
Wrap up from Arien
· Arien will post to the Wiki: over constraining on an SMTP client
· Thinking about mail/email client interoperability
· Multipart MIME isn’t as developer friendly
· Arien will post on the wiki further thoughts on an alternative, super simple content packaging formula that meets use case of presupposition – that is simple from developer and end user perspective?