Content Packaging Meeting 2010-05-26
Date: May 26, 2010
Time: 1pm-2pm
Leader: David McCallie
Attendees: David McCallie, Vasu Manjrekar, Vidit Saxena, Vassil Peytchev, Keith Boone, Paul Saxman, Karen Witting, Douglas Pratt, David Yakimischak
Actions for this Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 21 |
5/26/2010 |
Post a comment to the content packaging wiki page linking to HITSP C80 |
Open |
Keith Boone |
6/1/2010 |
Actions from Last Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 20 |
5/19/2010 |
Define key terms for routing metadata and post to wiki |
Closed |
John Moehrke |
5/26/2010 |
Agenda
· Review of last week’s action items
· Proposed Discussion Topics
1. Review John Moehrke’s metadata clarification
2. Synchronizing content packaging work with concrete implementations
· Next Steps
Notes
· Action #20 – put as a comment on the content container spec
· So far the WG has created an abstract, high-level model. The WG will wait for the concrete implementations to give feedback on their real-world experience before meshing this with the abstract model
Walk through of John Moehrke’s Proposal by Keith Boone
· There are three sections of proposal
· First section: routing metadata is the minimal metadata needed to support the routing of the metadata itself
Comment from David Yak
· Date would be helpful to have in content package metadata
o Ex: For a case where the package is not being transmitted immediately, date allows you to know when the package was created
· Relates-to message ID would also be useful
o Ex: For a case where the message is a response to a specific other message, relates-to allows the two messages to be correlated
Comment from Keith Boone
· Date and relates-to message ID would both be helpful metadata
o Date should be optionally required depending on the transport
o Relates-to should also be optional because you’re not always responding to a specific message
Comment from Vassil
· Relates-to is important is certain cases:
o Where there is a delivery confirmation requirement
o Specialist referral scenario would require a workflow correlation
· Date is useful for troubleshooting
Comment from David McCallie
· Date can be useful in certain settings, especially for troubleshooting
· Agree also that relates-to field is valuable in certain use cases, but if not one of those use cases then it should be optional
· Both of these are dependent on the transport model
o SMTP model would have well established behaviors for these that could be inherited
Continued Walk through of John Moehrke’s Proposal by Keith Boone
· Second section: manifest – how is the content package being organized
· John gave a high level description of what goes in the manifest
· Includes the type of content that’s being sent, information about the patient, etc
Question from David McCallie
· When we were previously discussing the XDM process of wrapping, there was a table of contents that would tie things together. Is this concept carried through in John’s proposal?
· Keith Boone
o In XDM submission sets, there is a place where you can put metadata that identifies the type of submission
o Gives the provider an idea of what they’re looking at and why
· Vassil Peytchev
o Thinks that David is referring to the ability to have a readme file as part of the zip structure
o In XDM this is the human readable version of the abstract structure John has proposed
· David McCallie
o Vassil is correct in his interpretation
o Is the hierarchy that’s available in the zip format just an artifact of the zip file and not part of the metadata?
· Vassil Peytchev
o In the general case for XDM, there is an option to have a folder structure that gives these relationships
o For NHIN Direct, the relationships in the metadata are part of the abstract manifest which in XDM would also have the human readable html readme file.
· David McCallie
o From John’s perspective, should there be a descriptor of the content hierarchy in the manifest or would this be an implementation detail?
Feedback on Section 2 of John Moehrke’s Proposal
| Name |
Feedback/Comment |
| Vasu Manjrekar |
No comment |
| Vidit Saxena |
No comment |
| Paul Saxman |
No comment |
| Karen Witting |
No comment |
| Douglas Pratt |
· Would the manifest change in if the email is forwarded? · Keith Boone o The manifest shouldn’t necessarily change o Raises policy issues, for example if an inaccurate patient ID is sent. o Content being transmitted would not be changed · David McCallie o In previous experience, have ensured that message content could not be altered if it was being forwarded o Agree that this is a policy principle |
| David Yakimischak |
· At the content package metadata level, there is only one content package and at the document level there is only one doc. · Is there only one manifest per package that contains several documents or one manifest per document? · Keith Boone o XDM can include multiple submissions for different patients. o The way this information is structured is that there are different submission sets captured in the manifest. Each submission set has specific metadata pertaining to it o Each submission set is only for one patient |
Question from David Yakimischak
· Is the document MIME type for the type of manifest file?
· Keith Boone
o MIME type is for the zip file
· Vassil Peytchev
o Keep in mind that this is an abstract representation and is dependent on the implementation
o Will there be specific MIME types submitted that will be used for specific health care use cases?
o Content type would be more useful in a manifest area
o A submission set refers to a single patient because the purpose of creating the submission set is for the care of a given patient
§ However, doesn’t mean that you can’t include documents for other patients
o Purpose of manifest is to organize multiple documents, though it may often be used for a single document
o Does having only one package for one patient constrain the ability to ability to send batches of documents?
o We should clarify our assumption that a package is for one patient
Continued Walk through of John Moehrke’s Proposal by Keith Boone
· Third section: metadata for every document inside the content package
Feedback on Section 3 of John Moehrke’s Proposal
| Name |
Feedback/Comment |
| Vidit Saxena |
No comment |
| Vassil Peytchev |
No comment |
| Paul Saxman |
No comment |
| Karen Witting |
Makes sense |
| Douglas Pratt |
No comment |
| David Yakimischak |
No comment |
· For document level metadata, sometimes the information you’re looking for can be useful to have inside the document, sometimes it can be useful to have certain information outside the document
· Is John’s list the minimal list of what should be included?
· David McCallie
o We have not yet gone into required/optional for each
· Arien Malec
o John’s list seems like a useful list
Question from David McCallie
· Question for Keith and anyone who has used XDM/XDS: Some of these fields might best be used with coded values. What codeset should be used?
o Can it be up to the affinity domain to decide?
o What about where there isn’t a clear affinity domain? What is the best practice for how to handle this?
· Keith Boone
o In response to Arien, John said that his list represents guidelines more than absolute requirements
o HITSP has given guidance for how to configure for affinity domains for NHIN
§ HITSP C80 has work around these fields, which is specific to healthcare in the US but is intended to meet the broad needs of exchange
o XDM and XDR do not require a common affinity domain. Whether there is an affinity domain is left to policy
· Karen Witting
o In XDR, and maybe XDM, if you have any agreed set you should use it
o Since we have HITSP, we should adopt whatever part of this makes sense
· David McCallie
o Sounds reasonable
· Arien Malec
o Believes that in most cases on NHIN, the actual metadata values are set by convention.
o People agree to transfer a particular document and use C80 codes that are fixed to that particular type of document
· Karen Witting
o Correct in terms of the types of metadata that refer to the type of document, but there are other metadata that are not fixed
· Vassil Peytchev
o There are different levels of configuration that may result in fixed metadata
o A user does not always have to select metadata at every instance, configuration can dynamically set the data even if there is not a specific, static value being used
· Arien Malec
o Thinking about the metadata bridging problem, there might be some values that we can fix based on specific profiles and other values that will be less constrained
o May be valuable to constrain some metadata, but may not be possible to constrain all
Comment from David McCallie
· Suggest that for the next meeting we focus on what the concrete implementation groups are learning
· Question for Karen/Keith – Are the value sets for C80 available on the HITSP site?
o Keith Boone
§ Most of the value sets are included on the HITSP site, will make sure that these are available
· Keith to post a comment to the content packaging wiki page linking to HITSP C80