Talk:Integration Statement
IHE Product Regitry - issues & comments (mail thread):
From: Wirsz, Nikolaus Sent: Freitag, 5. Januar 2007 18:44 To: 'tsippel@acc.org' Subject: Representation of IHE Integration Capabilities
Hi Teri,
I would have a couple (or more) open issues and comments to add to this mail thread. I guess I should also post this on the IHE Wiki page, I haven't seen yet any entries in the discussions section on this subject though so maybe this could trigger some more contributions.
Before I start with my issues / comments I also need to mention that the IHE Strategic Development Committee should continue to pay attention to this and coordinate among all IHE domains so that the other IHE committees provide feedback and (ideally) constantly contribute to this work which as far as I understood IHE Cardiology has taken up for a start. I should ask the IHE SDC to keep this item on their agendas for their t-con/meetings or maybe you (assuming you are the owner of this item for now) could participate in the t-cons/meetings of the SDC to provide a report on the progress of the IHE product registry and collect feedback.
And now to my reflections which I tried to put into categories as far as possible:
Connectathon Results & Publication
• IHE should continue to publish connectathon participation results (cumulated for past years & regions) regardless of whether the tested implementations were prototypes, near-release or commercially available products for known reasons: - value to implementers - proof of concept for "freshly" defined profiles - shows progress in IHE - preparation for demos - rewards participants ("stars") for their efforts - increases the confidence in IHE for vendors and users - (possible) intermediate step before moving to real-world implementations and deployments
• Connectathon participation can not be a mandatory step for each single IHE product to be commercially released for the following reasons: - A vendor that accumulated solid experience with testing and implementations of certain profiles, doesn't have to repeat this exercise - Software already successfully tested and released is being re-used for other / newer versions and products - Having each commercial version / release going to the connectathon is logistically not possible, neither for vendors nor for the technical project management
Conclusions: • Continue with the annual connectathon and results publication as before (with stars) • Successful connectathon participation (with certain products / implementations but not bound specifically to each product / version) is a prerequisite for vendors to have their IHE products listed either in the current list of links to IHE Integration statements on www.ihe.net or in the to be developed IHE product database / registry
Conditions for Publishing of IHE Integration Statements
• IHE participating vendors can publish (on their IHE web pages) IHE Integration Statements only for commercially released products and are responsible to fulfill this condition (this has already been agreed upon in the past). These documents contain among others information about: - Product name & Version - Supported IHE Integration profiles and IHE Actors (possibly options)
Criteria for Inclusion in the New IHE Product Registry
• For the first prototype of the IHE Product Registry same criteria apply as already do for publishing IHE Integration Statements: - Vendor has successfully participated at connectathons (regardless of which products / implementations) - Product in question is commercially available - Product in question supports IHE as outlined in its already published IHE Integration Statements • The first release of the IHE product registry should be limited to high-level / most relevant information (can grow for later versions of the registry) - Product type (e.g. Modality, PACS, RIS, …) - Supported IHE Profiles / Actors - No other details such as version number on this level - Link to the vendor's IHE Integration Statements for the product category in question (note that the integration statements contain detailed information such as product instance and version number)
This should do it for a start I guess, in fact the above data would replicate the current structure of the connectathon results table - with the major difference that the registry is really about commercially available products - and if one needs more details about certain products / versions she or he can click on the appropriate link and get there.
• As the IHE product registry gets more stable and proves to be a valuable and widely used tool one can think of enhancing it with additional data (granularity of information) and possibly establish other criteria for inclusion into the registry.
Conclusions / Recommendations: • Criteria for inclusion in the registry same as currently for publishing IHE integration statements (vendors responsible for accuracy) • Limit initial set of information for populating the IHE product registry to include: Vendor -> Product Type -> Supported IHE Profiles / Actors -> Link to IHE Integration Statements • Gather experience with this basic registry and enhance in the course of time as needed
Open Issues
The following issues need to be discussed in the committee(s) to determine the best way to solve these:
• Process - Who enters / changes when the product information into the registry ? Should be the vendors as the product owners know best when a product is obsolete / has been discontinued / replaced / etc. so it would be more efficient and less error prone to enter data directly.
• Policy: We should avoid the term "self-certification" at least on the public pages, since certification can always be interpreted in various ways or lead to assumptions that do not apply
• Level of details really useful or needed: e.g. product instance / version information • The question at hand is how much detail is really useful for the average registry searcher vs. overloading the user • "Pretty" product names and cryptic version numbers provide little data for the normal user (if at all), e.g. (I am coming up with these hoping not to "hit" a real product designation) does "MRIVirtue Plus VX23.7.", "Simply Store AB5.7" or "PAC Runner" (low-entry PACS) / "PACSSprinter (high-performance PACS) / "PACSMarathon ABC" (long-term archive) really help? Rather a registry should provide tangible information such as: Vendor - Profiles - Actors within profiles - (maybe profile options) + Product classes such as: HIS, RIS, PACS, Modality (CT, MR, …) + Links to IHE Integration Statements if one needs to get to more specific details • Version numbers do not add much value (Kevin has raised a similar issue in his mail below) Vendor X upgrades Product A from V3.0 to V 4.0 but keeps the same base line software for IHE connectivity, the version number is not relevant here. Vendor X replaces (discontinues) Product B V1.0 with V2.0, supports IHE in the new version but the old one is not going to be maintained, so here too the version number is rather confusing than helping • So for example knowing that Vendor A offers PACS products that support certain profiles and actors is actually what the user is looking for (of course the vendor is accountable for this data as per the already defined policy for publishing IHE Integration Statements for commercially available products) • Rather a registry should provide tangible information such as: Vendor - Profiles - Actors within profiles - (maybe profile options) + Product classes such as: HIS, RIS, PACS, Modality (CT, MR, …) + Links to IHE Integration Statements if one needs to get to more specific details
Recommendations: • Align the structure of the registry to reflect the IHE User Handbook approach augmenting it with an informative tool for purchasers and match the customers request behavior, most RFPs asking for IHE are quite high-level
• Real-world Installations - Customer Release - Customer Names & Contacts: • This is definitely too delicate and can not be accomplished as suggested because: - the customer in question would have to explicitly authorize the disclosure - company rules also have strict policies on disclosing customer data to a third party Note: these rules / policies hold regardless of whether disclosing publicly or just to one entity even if "anonymized" in the registry, no one can issues commitments / guarantees regarding handling sensitive information • Another aspect (ignoring the issue above for a moment) is that if a vendor indeed sold and installed an IHE product, there are always situations where other components in the enterprise might not support the specific IHE profile (or IHE at all), thus there are dependencies that would make a product not IHE-registrable even though in fact it really is, this would be totally unfair for the vendor that spent significant efforts to implement IHE in that specific product
Recommendations: • Customer release can not be used as criteria to enter a product into the registry
Conclusions / Recommendations
• Follow-up these and other people's comments / issues in the appropriate committees: Cardiology, SDC, … and determine a phased approach on developing an IHE product registry
Kind regards, Niki Wirsz - Siemens
_____ From: Cor Loef [1] Sent: Friday, December 15, 2006 12:22 PM To: IHE-Card-PC; ihestdev@rsna.org Subject: RE: IHE Card PC: visual representation of self-certified IHE product milestones
Teri, IHE Card, IHE Strategic,
I suggest we continue this discussion on the IHE Wiki page, which happens to be a nice forum for these kind of strategic, contentious, exciting, challenging, topics. http://wiki.ihe.net/index.php?title=Statements
Teri, I already uploaded your presentation on the Wiki pages. Maybe you want to highlight it at other places as well.
Kind regards, Cor
Cor Loef Program Director Interoperability Philips Medical Systems Veenpluis 4-6, Building QV-110 5680 DA Best - The Netherlands Tel: +31 (0)40 27 64167 - Fax: +31 (0)40 27 64263 Cell: +31 6 20395477 - Mobex: 96215 Email: cor.loef@philips.com
"Kevin O'Donnell" <kevino@tamri.com> 2006-12-15 01:59 AM To: "IHE-Card-PC" <ihe-card-pc@lists.acc.org> cc: (bcc: Cor Loef/BST/MS/PHILIPS) Subject: RE: IHE Card PC: visual representation of self-certified IHE product milestones
Hi Teri,
Started thinking about it and came up with a for-instance:
I have Product X V1.0 that supports Profile A & B and it passed Connectathon in 2006, I released it, published an Integration Statement, installed it and can provide a Clinical contact.
In January 2007 I brought V1.5 of Product X to the Connectathon to test Profile C and I will participate in the Profile C demo in the IHE booth at ACC 2007. The product release documentation is complete (including an Integration Statement) got finished as part of the prep for ACC, but we haven't shipped V1.5 to any customers yet. Support for Profile A & B is essentially the same as V1.0.
What do we put in the matrix?
Does V1.5 inherit the V1.0 information, so we show three icons each under Profile A & B, and two icons under Profile C?
Or do we put one row for V1.0 with three icons each for Profile A & B, and nothing under Profile C, and then another row for V1.5 with two icons under Profile C and ?what? under Profiles A&B?
- Kevin
_____ From: Teri Sippel (ACCF Contractor) [2] Sent: Thursday, December 14, 2006 3:57 PM To: IHE-Card-PC Subject: IHE Card PC: visual representation of self-certified IHE product milestones Importance: High
Hello Planning Committee -
VENDORS- you need to start thinking about how you will fill out this product matrix: which of your products? which icons will you request? are your Integration Statements up to date and linked through ihe.net? do you have the Clinical Site names and contact info? I will be formally asking for this in writing later, but you need to start thinking about it/gathering info now....
All- Attached is a powerpoint which contains the "definition" of the Vendor product's self-certified IHE milestones. We have gone over this powerpoint and been talking about this quite extensively since the June 2006 PC meeting at ASE.
The changes in this most recent version of the document are a result of the presentation to the IHE Strategic Development Committee this morning. This committee was clearly supportive of the general idea, but seemed glad to let Cardiology be the "guinea pig". Several other domains expressed interest in following our lead on this idea.
This committee made 3 specific changes, however: 1. merge the Commercial Release and Integration Statement icons since, by definition, you cannot have a verified Integration Statement without a Commercial Release 2. for the Clinical Site Installation icon, vendors must provide the clinical site name and contact information, although we should not publish that information publicly 3. during docent training we need to be sure that our docents understand that a Connectathon icon infers that the IHE software must have been included in some sort of pre-production release, but we do not track pre-production releases.
The fact that this idea passed by a vote of 14-1 (not unanimously) was already brought up to the Strategic Development Committee who recommended that we proceed.
Holler if questions or issues, else start making your notes... I sure more questions and issues will arise as we start to fill in these product matrix elements, but we need to start...
teri --- Teri M Sippel Schmidt Technical Project Manager, IHE Cardiology American College of Cardiology (ACC) tsippel@acc.org +1.262.385.6362