Content Packaging Meeting 2010-05-19
Jump to navigation
Jump to search
Notes from Content Packaging Workgroup
Date: May 19, 2010
Time: 1pm-2pm
Attendees: David McCallie, Vidit Saxena, Vassil Peytchev, John Moehrke, Karen Witting, Mark Stine, David Yakimischak, Steve Waldren, Arien Malec, Jackie Key
Actions for this Week
Notes
Agenda
· Review of last week’s action items
· Proposed Discussion Topics
1. Inclusion of patient identifying information as part of the message header
2. Issues raised by Dr. Kibbe’s discussion of differences between individual (simple) vs corporate (complex) systems
3. Bridging between different protocol systems
· Next Steps
Discussion
· Review of action items
o Action #18 – Rather than summarizing the proposal, Karen posted a discussion subject on metadata to the wiki
o Action #19 - David Kibbe completed this item
o Action #20 – Not complete, will be rolled into next round of actions
· Status of content specification: Content team is bouncing ideas off of the implementation group
· Karen Witting summarized her proposal, as posted to the wiki discussion tab
o Decided to focus on metadata where both sides need metadata and a more complex system would want more metadata than a simpler system
§ A simple system only needs a health internet address
§ A complex environment will often include more info about the entity that created the content
o Most concerned with the exchange of patient identifying information
§ Complex environments would prefer to have consistent, structured format for this info
§ Karen has proposed a minimum set of patient identifying metadata in her discussion post
· Keith Boone previously proposed using a message ID as a replacement identifier
o This may not make work because message ID wouldn’t be a consistent identifier from that source
o In the real-world consistency is desirable but not always possible
o Goal is to have some identifier to help the manual process of identifying the patient
o Arien thinks that Keith was trying to solve a different problem: audit
o Some systems will never send a local patient identifier (ex: labs)
· Where will this metadata go, in the message header or body?
o Will depend on the type of transport
o Karen thinks that it belongs in the message body, not the header
o Previously group had discussed the ability to use xdm wrapper to send more complete structured metadata when it’s available
· NHIN Direct shouldn’t impose requirements that make best use of a complex system on less complex systems
Comment from 'Vassil Peytchev
· Important to recognize the utility of having the metadata in a single format
Comment from 'John Moerkhe
· Need for flexibility with these values (ex: labs may not have a patient name)
· Would be good to have consistent ways of describing content packaging and content metadata when the information is available and you need to send it, however there are times when the info is not available/not needed
· More message levels that just header and body – not black and white
o Different concrete models will place metadata in different places based on the capability of that concrete model
o Content work group should recommend what would be better in the most external wrapper vs most internal part of a message
· David McCallie intended to use the terms message header and body based on the email model
· May make more sense to classify data in terms of what is exposed for the purpose of delivery vs what is opaque
Comment from Mark Stine:
· Need for flexibility in terms of where metadata values are placed
· Concern that we are only looking at email as the de-facto model, when certain choices may not apply to other transport models
Comment from David Yakimischak
· If you make everything optional then nothing is necessary
· Propose to add zip code in addition to the other minimum patient identifying metadata proposed by Karen
· All of this metadata should be inside the message body, the outside should only contain routing/destination addressing info, not patient info
Comment from Steve Waldren
· If we make a standard set of metadata required for every use case, NHIN Direct will be less usable
· Calling this information metadata is troublesome, may better be thought of as a content standard transmitted by NHIN Direct
Comment from Arien Malec
· Need to understand the realities of what systems send, different systems have different info that they send and maintain
o Argues for optionality and flexibility in terms of what goes into patient identifying information
Comment from David McCallie
· Zoom back out to the Content Packaging group’s original mandate to create a simple secure mechanism for delivering content using a simple addressing model
o We’re solving this by having a minimum set of routing and delivery data which will expose the minimum amount of PHI
o The content, which is opaque, will be a MIME-wrapped package that may or may not be encrypted before it enters the network
· We’ve distinguished between what’s necessary for delivery and what should be in the body itself
· The content packaging group should agree on what’s necessary for delivery and be highly flexible on what is in the content
· As long as we have delivery parameters and agreement on mime, then details about content should be pushed down to each implementation model
Comment from 'John Moerkhe
· What if a concrete implementation doesn’t need to wrap in mime?
o This concept is tied to the email delivery model
· Thinks the Content Packaging group should look inside the envelope, not just on the outside
Comment from Karen Witting
· The current Content Packaging spec seems very implementation-specific, it should be made more abstract
Comment from David McCallie
· Process started with a push messaging assumption where email-like behaviors were created at the core
· Because MIME can be used across different transports, it is a reasonable abstraction
· May need to wait for further definition until the decision is made about the concrete implementation
Comment from Arien Malec
· Intent of Content Packaging specification was to provide an approach that could work across implementations but recognize that some implementations may have their own natural ways of packing content
o The content packaging spec should not get in the way of these other ways
Comment from David McCallie
· Propose that we suspend some of these decisions until backbone protocol is chosen
· We have at least identified some important questions that can be pushed back to each implementation group, including:
o How much PHI is exposed in routing info?
o Does each message need to pertain to one patient or can it be for multiple patients?
Comment from 'John Moerkhe
· Content Packaging specification could be an implementation of simple MIME but also should clarify that not doing simple MIME is out of compliance
· We should clarify terms such as message routing, message manifest, etc
Comment from David McCallie
· Agree that these terms should be defined
· If a message benefits from having a manifest, then it can be packaged as a xdm object. If not, negotiate (out of band agreement) appropriately
· A system should not send xdm unless it knows that the receiving system is prepared to deal with it
Comment from 'Vassil Peytchev
· This is not an interoperable solution
o How is a HL7 v2 message formatted?
Comment from David McCallie
· We’re aiming to solve addressability for a particular use case
Comment from Arien Malec
· A lot of systems have a proprietary but secure way of doing this
Comment from 'Vassil Peytchev
· In order for this to be truly interoperable, we cannot stop at the MIME package
· We need to have a standards-based way for processing the message
· Each of the implementation groups will take the appropriate path with their respective implementations
o Do the implementation groups feel constrained by what has been formulated so far?
o Need to solve the metadata cross
o Need to solve mandatory vs optional issue regardless
· John Moerkhe will take a short at defining the key terms for routing metadata
Date: May 19, 2010
Time: 1pm-2pm
Attendees: David McCallie, Vidit Saxena, Vassil Peytchev, John Moehrke, Karen Witting, Mark Stine, David Yakimischak, Steve Waldren, Arien Malec, Jackie Key
Actions for this Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 20 |
5/19/2010 |
Define key terms for routing metadata and post to wiki |
Open |
John Moerkhe |
5/26/2010 |
Notes
Agenda
· Review of last week’s action items
· Proposed Discussion Topics
1. Inclusion of patient identifying information as part of the message header
2. Issues raised by Dr. Kibbe’s discussion of differences between individual (simple) vs corporate (complex) systems
3. Bridging between different protocol systems
· Next Steps
Discussion
· Review of action items
o Action #18 – Rather than summarizing the proposal, Karen posted a discussion subject on metadata to the wiki
o Action #19 - David Kibbe completed this item
o Action #20 – Not complete, will be rolled into next round of actions
· Status of content specification: Content team is bouncing ideas off of the implementation group
· Karen Witting summarized her proposal, as posted to the wiki discussion tab
o Decided to focus on metadata where both sides need metadata and a more complex system would want more metadata than a simpler system
§ A simple system only needs a health internet address
§ A complex environment will often include more info about the entity that created the content
o Most concerned with the exchange of patient identifying information
§ Complex environments would prefer to have consistent, structured format for this info
§ Karen has proposed a minimum set of patient identifying metadata in her discussion post
· Keith Boone previously proposed using a message ID as a replacement identifier
o This may not make work because message ID wouldn’t be a consistent identifier from that source
o In the real-world consistency is desirable but not always possible
o Goal is to have some identifier to help the manual process of identifying the patient
o Arien thinks that Keith was trying to solve a different problem: audit
o Some systems will never send a local patient identifier (ex: labs)
· Where will this metadata go, in the message header or body?
o Will depend on the type of transport
o Karen thinks that it belongs in the message body, not the header
o Previously group had discussed the ability to use xdm wrapper to send more complete structured metadata when it’s available
· NHIN Direct shouldn’t impose requirements that make best use of a complex system on less complex systems
Comment from 'Vassil Peytchev
· Important to recognize the utility of having the metadata in a single format
Comment from 'John Moerkhe
· Need for flexibility with these values (ex: labs may not have a patient name)
· Would be good to have consistent ways of describing content packaging and content metadata when the information is available and you need to send it, however there are times when the info is not available/not needed
· More message levels that just header and body – not black and white
o Different concrete models will place metadata in different places based on the capability of that concrete model
o Content work group should recommend what would be better in the most external wrapper vs most internal part of a message
· David McCallie intended to use the terms message header and body based on the email model
· May make more sense to classify data in terms of what is exposed for the purpose of delivery vs what is opaque
Comment from Mark Stine:
· Need for flexibility in terms of where metadata values are placed
· Concern that we are only looking at email as the de-facto model, when certain choices may not apply to other transport models
Comment from David Yakimischak
· If you make everything optional then nothing is necessary
· Propose to add zip code in addition to the other minimum patient identifying metadata proposed by Karen
· All of this metadata should be inside the message body, the outside should only contain routing/destination addressing info, not patient info
Comment from Steve Waldren
· If we make a standard set of metadata required for every use case, NHIN Direct will be less usable
· Calling this information metadata is troublesome, may better be thought of as a content standard transmitted by NHIN Direct
Comment from Arien Malec
· Need to understand the realities of what systems send, different systems have different info that they send and maintain
o Argues for optionality and flexibility in terms of what goes into patient identifying information
Comment from David McCallie
· Zoom back out to the Content Packaging group’s original mandate to create a simple secure mechanism for delivering content using a simple addressing model
o We’re solving this by having a minimum set of routing and delivery data which will expose the minimum amount of PHI
o The content, which is opaque, will be a MIME-wrapped package that may or may not be encrypted before it enters the network
· We’ve distinguished between what’s necessary for delivery and what should be in the body itself
· The content packaging group should agree on what’s necessary for delivery and be highly flexible on what is in the content
· As long as we have delivery parameters and agreement on mime, then details about content should be pushed down to each implementation model
Comment from 'John Moerkhe
· What if a concrete implementation doesn’t need to wrap in mime?
o This concept is tied to the email delivery model
· Thinks the Content Packaging group should look inside the envelope, not just on the outside
Comment from Karen Witting
· The current Content Packaging spec seems very implementation-specific, it should be made more abstract
Comment from David McCallie
· Process started with a push messaging assumption where email-like behaviors were created at the core
· Because MIME can be used across different transports, it is a reasonable abstraction
· May need to wait for further definition until the decision is made about the concrete implementation
Comment from Arien Malec
· Intent of Content Packaging specification was to provide an approach that could work across implementations but recognize that some implementations may have their own natural ways of packing content
o The content packaging spec should not get in the way of these other ways
Comment from David McCallie
· Propose that we suspend some of these decisions until backbone protocol is chosen
· We have at least identified some important questions that can be pushed back to each implementation group, including:
o How much PHI is exposed in routing info?
o Does each message need to pertain to one patient or can it be for multiple patients?
Comment from 'John Moerkhe
· Content Packaging specification could be an implementation of simple MIME but also should clarify that not doing simple MIME is out of compliance
· We should clarify terms such as message routing, message manifest, etc
Comment from David McCallie
· Agree that these terms should be defined
· If a message benefits from having a manifest, then it can be packaged as a xdm object. If not, negotiate (out of band agreement) appropriately
· A system should not send xdm unless it knows that the receiving system is prepared to deal with it
Comment from 'Vassil Peytchev
· This is not an interoperable solution
o How is a HL7 v2 message formatted?
Comment from David McCallie
· We’re aiming to solve addressability for a particular use case
Comment from Arien Malec
· A lot of systems have a proprietary but secure way of doing this
Comment from 'Vassil Peytchev
· In order for this to be truly interoperable, we cannot stop at the MIME package
· We need to have a standards-based way for processing the message
· Each of the implementation groups will take the appropriate path with their respective implementations
o Do the implementation groups feel constrained by what has been formulated so far?
o Need to solve the metadata cross
o Need to solve mandatory vs optional issue regardless
· John Moerkhe will take a short at defining the key terms for routing metadata