Content Packaging Meeting 2010-05-12
Jump to navigation
Jump to search
Notes from Content Packaging Workgroup
Status of Notes: DRAFT
Date: May 12, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Lin Wan, Greg Turner, Didi Davis, Vidit Saxena, Vassil Peytchev, Keith Boone, Karen Witting, Vince Lewis Mark Stine, Chris Moyer, Omar Bouhaddou, Matt Potter, David Kibbe, David McCallie, Arien Malec, Jackie Key, Honora Burnett Mohammad & Paul French, Tim McNeil, Paul Saxman
Actions for this Week
Notes
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Discussion
Debrief from Face-to-Face
· 1.0 briefing
· Many of the decisions we need to make at the detail level about content packaging are dependent on the protocol for the background and security and trust
· More conversation needed
· MIME is used for default coding
· Specifics of what is in the header and specific multipart types that would be required, suggested, discouraged
· General consensus about MIME, other details dependent on other decisions
· Hinges on other group – how do you handle encryption
1. Separation of routing metadata from content metadata
· Metadata Mapping
1. Questions – constrain message to plain text only?
2. What is the glide path from where we start to meeting providers where they are?
· Three topics:
1. Debate – if you forward the message can you change the body of the forwarded message?
2. Plain text
3. XMDD/XDR
4. Level of abstraction for content
· Can we skinny down the metadata with XDR
· Content Container Specification
o Standard email headers without any PHI
§ To
§ From
§ Message ID
§ Type
o NHIN Direct will be forced to deal with NHIN Gateway
o NHIN Direct should stay at a low bar and allow them to evolve overtime as capabilities increase
o Arien: keep the bar low to ensure that physician’s can be met where they are
§ Don’t want to constrain around needs of sophisticated institutions
§ We want this to be an escalator – gateway function and glide function
o MIME Content Objects chosen to embed
o Right now – metadata is to/from/sent – email content wrapper
Comment from Lin Wan
· Weather we can do a glide path it depends on security metadata
· Good combination
· Gateway: text message/pdf with attached CCD
o If it is fully encrypted, all there will be is access to metadata
Comment from Greg Turner & Didi Davis
· Agree with serving a smaller practice
· Understand glide path so we don’t create something and then are stick with it
Comment from Vassil Peytchev
· What does keeping the bar low mean?
· User stories based on MU IRF
· Simple/Complicated: lack of patient demographic in the metadata
o Important when content is opaque or encrypted
o If a sender has technology that satisfies MU, they do have the ability to create the sending tag, the question is how to add it to the minimum content packaging
· Assumption that the patient demographics has been through HIX?
o No
o Patient ID
o Name
· Specific MIME Type
Comment from Keith Boone
· Different level in this discussion
· Don’t go so far in development of content packaging that we are ruling something out
· Now that we have four/five required MIME headers, everything may work effectively (MIME Multipart) but that might go too far …
· We need to identify the metadata that needs to be communicated
· What is the possible packaging mechanisms that need to be in there
· Letting concrete implementations go a little further with their requirements
Comment from Karen Witting
· One small practice to another small practice is hard to duplicate names
· Conceptual change in perception
· Have to bridge that policy gap
· Not an issue of large organizations, but dependent on local
Comment from David Kibbe
· Basic issues between two edge clients
o Corporate vs. individual
o Largely individual provider practice – 850,000 practicing in this country
o VS.
o Largely corporate huge hospitals
o 70% of physicians’ practicing are in small practices
o Set bar low enough and
Comment from Tim McNeil
· Agree with low bar approach
Comment from Paul Saxman
· Focus on the patient
Summary from David McCallie
· Meaningful Use doesn’t mean that both physicians need to have a sophisticated system
· Focus on the patient
Comment from Keith Boone
· Two patient identifiers in XDR
o Associated with a patient and is being sent – both required
o Source patient identifier -- purpose to make sure that you know who the sender was
Arien’s three related questions:
1) Karen’s request for documentation of assumption
a. Should be documented – in the minimal case the receiver has some ways of mapping to their local patient information
2) Assumption that there is a clear direction on the policy side that it would be possible to configure exchange in a way that has minimal PHI in routing data
3) Kind’s of exchange we’re doing, assumption an NPI is right out – mapping doesn’t need identifier data by required data
Comment from Karen Witting
· Some organizations that won’t accept data unless the patient data is coded in a certain way
· Two content levels – receivers to accept both levels
o 1) I am the sender and I’m not going to give you anything other than this set
o 2) I’m going to give you coded information that can be accepted by everyone
· Source patient ID is required, Source Patient Info is optional
· Modified question – could we use XDM as an alternate way for sophisticated users instead of two types of content specs – give key to gateway if we wanted to
· Karen’s proposal: We want to allow for a minimal approach, but recognize that for some receivers they may reject something out of hand and that is okay
· Karen will summarize the minimal/maximal proposal his on the Wiki
· David Kibbe will summarize a difference between individual and corporate edge’s on the Wiki
· David McCallie will document the idea that the sender may have to meet the terms of MU and IFR on the Wiki
Status of Notes: DRAFT
Date: May 12, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Lin Wan, Greg Turner, Didi Davis, Vidit Saxena, Vassil Peytchev, Keith Boone, Karen Witting, Vince Lewis Mark Stine, Chris Moyer, Omar Bouhaddou, Matt Potter, David Kibbe, David McCallie, Arien Malec, Jackie Key, Honora Burnett Mohammad & Paul French, Tim McNeil, Paul Saxman
Actions for this Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 18 |
5/12/2010 |
Karen will summarize the minimal/maximal proposal his on the Wiki |
Open |
Karen |
5/19/10 |
| 19 |
5/12/2010 |
David Kibbe will summarize a difference between individual and corporate edge’s on the Wiki |
Open |
David Kibbe |
5/19/10 |
| 20 |
5/12/2010 |
David McCallie will document the idea that the sender may have to meet the terms of MU and IFR on the Wiki |
Open |
David McCallie |
5/19/10 |
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Discussion
Debrief from Face-to-Face
· 1.0 briefing
· Many of the decisions we need to make at the detail level about content packaging are dependent on the protocol for the background and security and trust
· More conversation needed
· MIME is used for default coding
· Specifics of what is in the header and specific multipart types that would be required, suggested, discouraged
· General consensus about MIME, other details dependent on other decisions
· Hinges on other group – how do you handle encryption
1. Separation of routing metadata from content metadata
· Metadata Mapping
1. Questions – constrain message to plain text only?
2. What is the glide path from where we start to meeting providers where they are?
· Three topics:
1. Debate – if you forward the message can you change the body of the forwarded message?
2. Plain text
3. XMDD/XDR
4. Level of abstraction for content
· Can we skinny down the metadata with XDR
· Content Container Specification
o Standard email headers without any PHI
§ To
§ From
§ Message ID
§ Type
o NHIN Direct will be forced to deal with NHIN Gateway
o NHIN Direct should stay at a low bar and allow them to evolve overtime as capabilities increase
o Arien: keep the bar low to ensure that physician’s can be met where they are
§ Don’t want to constrain around needs of sophisticated institutions
§ We want this to be an escalator – gateway function and glide function
o MIME Content Objects chosen to embed
o Right now – metadata is to/from/sent – email content wrapper
Comment from Lin Wan
· Weather we can do a glide path it depends on security metadata
· Good combination
· Gateway: text message/pdf with attached CCD
o If it is fully encrypted, all there will be is access to metadata
Comment from Greg Turner & Didi Davis
· Agree with serving a smaller practice
· Understand glide path so we don’t create something and then are stick with it
Comment from Vassil Peytchev
· What does keeping the bar low mean?
· User stories based on MU IRF
· Simple/Complicated: lack of patient demographic in the metadata
o Important when content is opaque or encrypted
o If a sender has technology that satisfies MU, they do have the ability to create the sending tag, the question is how to add it to the minimum content packaging
· Assumption that the patient demographics has been through HIX?
o No
o Patient ID
o Name
· Specific MIME Type
Comment from Keith Boone
· Different level in this discussion
· Don’t go so far in development of content packaging that we are ruling something out
· Now that we have four/five required MIME headers, everything may work effectively (MIME Multipart) but that might go too far …
· We need to identify the metadata that needs to be communicated
· What is the possible packaging mechanisms that need to be in there
· Letting concrete implementations go a little further with their requirements
Comment from Karen Witting
· One small practice to another small practice is hard to duplicate names
· Conceptual change in perception
· Have to bridge that policy gap
· Not an issue of large organizations, but dependent on local
Comment from David Kibbe
· Basic issues between two edge clients
o Corporate vs. individual
o Largely individual provider practice – 850,000 practicing in this country
o VS.
o Largely corporate huge hospitals
o 70% of physicians’ practicing are in small practices
o Set bar low enough and
Comment from Tim McNeil
· Agree with low bar approach
Comment from Paul Saxman
· Focus on the patient
Summary from David McCallie
· Meaningful Use doesn’t mean that both physicians need to have a sophisticated system
· Focus on the patient
Comment from Keith Boone
· Two patient identifiers in XDR
o Associated with a patient and is being sent – both required
o Source patient identifier -- purpose to make sure that you know who the sender was
Arien’s three related questions:
1) Karen’s request for documentation of assumption
a. Should be documented – in the minimal case the receiver has some ways of mapping to their local patient information
2) Assumption that there is a clear direction on the policy side that it would be possible to configure exchange in a way that has minimal PHI in routing data
3) Kind’s of exchange we’re doing, assumption an NPI is right out – mapping doesn’t need identifier data by required data
Comment from Karen Witting
· Some organizations that won’t accept data unless the patient data is coded in a certain way
· Two content levels – receivers to accept both levels
o 1) I am the sender and I’m not going to give you anything other than this set
o 2) I’m going to give you coded information that can be accepted by everyone
· Source patient ID is required, Source Patient Info is optional
· Modified question – could we use XDM as an alternate way for sophisticated users instead of two types of content specs – give key to gateway if we wanted to
· Karen’s proposal: We want to allow for a minimal approach, but recognize that for some receivers they may reject something out of hand and that is okay
· Karen will summarize the minimal/maximal proposal his on the Wiki
· David Kibbe will summarize a difference between individual and corporate edge’s on the Wiki
· David McCallie will document the idea that the sender may have to meet the terms of MU and IFR on the Wiki