RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
Mark Sinke
Hi all,
(Sorry for cross-posting to Rad, ITI and dental, but I think it is relevant to all.)
We (referring to the ITI Tech Committee) should do a better job of describing the event code list. As Charles uses the term, we can use it to add extra queryable metadata to XDS, something that using additional slots will not do.
Now speaking in general for all three committees. The proposal as suggested uses a text string to identify the coding scheme. I’d suggest to formalize that and issue and OID or URN to make it unambiguous. Otherwise, I think the proposal is reasonable, and, if accepted, should be reflected in XDS-I.b (and related Rad profiles), SEDI (now in Public Comment!, we have a chance to change the custom slot to an entry in the event code list, if we act quickly), and potentially even further profiles such as in cardiology.
Regards, Mark.
CTO – Forcare BV
From: IHE-Ra...@googlegroups.com [mailto:IHE-Ra...@googlegroups.com] On Behalf Of Okken,Brett
Sent: Wednesday, December 05, 2012 22:54
To: Parisot, Charles (GE Healthcare); IHE-Ra...@googlegroups.com
Subject: [IHE-Rad-Tech1406] RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
Charles,
That does not seem to match what is described in ITI TF-3[1] 4.1.11.1, which seems to indicate that the XDS Affinity Domain should specify all acceptable values for coded attributes, including the eventCode.
4.1.11.1 Required Initialization of the XDS Affinity Domain
This initialization supports the operation of the Registry Adaptor. The following information must be provided by the XDS Affinity Domain administrator and loaded into the Registry Adaptor. This supports the functionality specified for the Registry Adaptor in ITI TF-3: 4.1.11. How this information is loaded into the Registry Adaptor or how the Registry Adaptor is implemented is not defined by this profile.
1. List of acceptable mimeTypes for documents indexed by the registry.
2. PIX domain name (Assigning Authority) for XDS Affinity Domain. PatientIds attached to metadata submitted to this registry must come from this PIX Assigning Authority.
3. Acceptable values for all coded attributes represented in the registry by ebXML External Classifications. These include classCode, eventCode, confidentialityCode, healthCareFacilityTypeCode, formatCode for XDS Document and XDSSubmissionSet.code and XDSFolder.codeList.
[1] - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol3.pdf
Brett Okken | CAMM Platform Services | Lead Architect | 816.201.6112 | www.cerner.com | bok...@cerner.com
From: Parisot, Charles (GE Healthcare) [mailto:charles...@med.ge.com]
Sent: Wednesday, December 05, 2012 12:56 PM
To: Okken,Brett; IHE-Ra...@googlegroups.com
Subject: RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
Brett,
I understand your point, but it seems to stem from a mis-sunderstanding about eventCodeList. It is not of the same nature as the CDA header EventCodeList, although it uses the same name !
In XDS Metadata, it is defined as a “key word” and using a code from a coding scheme is just one way to create such key words. The eventCodeList is intended to host extension to metadata that is specific to certain classes of documents.
In other terms, all elements of metadata have been designed as “tier 1” for the attribute that are expected across ALL documents, irrespective of content. EventCodeList is the second tier attribute that contains all third their extensions.
IHE ITI is developing educational material to make this easily understood by deployment projects.
That is precisely what we do here. Creating a new metadata attribute would generate very bad issues:
- Creates complex deployment issues on existing deployed environment
- Requires to create new stored queries
- There will be other document/workflow specific requirements for keywords/identifiers.
Extending the metadata needs to be placed under strict control.
Does that help ?
Charles
From: Okken,Brett [mailto:BOK...@CERNER.COM]
Sent: mercredi 5 décembre 2012 12:42
To: Parisot, Charles (GE Healthcare); IHE-Ra...@googlegroups.com
Subject: RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
It seems like a stretch to try to treat an accession number as a code. I would expect codes to be well defined and (relatively) static.
This change seems to make it very difficult for a registry to enforce the use of well-defined codes for the affinity domain. A registry implementation would now to maintain a list of codingSchemes whose member codes are not pre-defined.
I understand the desire to try and put the data into an existing field. However, if implementations are going to have to be changed to relax the requirement for pre-defined codes, it would seem (to me at least) to be clearer to simply define a new field expressly for this content. Then registry implementations would have to explicitly indicate whether the field is supported or not.
Brett Okken | CAMM Platform Services | Lead Architect | 816.201.6112 | www.cerner.com | bok...@cerner.com
From: IHE-Ra...@googlegroups.com [mailto:IHE-Ra...@googlegroups.com] On Behalf Of Parisot, Charles (GE Healthcare)
Sent: Tuesday, December 04, 2012 9:47 PM
To: IHE-Ra...@googlegroups.com
Subject: [IHE-Rad-Tech1401] FW: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
IHE Rad colleagues,
ITI knows that you are also working on this CP.
PCC has just expressed today interest in solving how this “request ID” may be conveyed in the XDS/XCA/XDM/XDR metadata.
Note the ITI tech T-con where the assigned CP will be discussed on Friday Dec 7th 9:00 - 11;00am
Charles
From: Moehrke, John (GE Healthcare)
Sent: mardi 4 décembre 2012 17:01
To: iti...@googlegroups.com
Cc: pcc...@googlegroups.com; Lindop, Christopher (GE Healthcare); Parisot, Charles (GE Healthcare)
Subject: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
Attached is the current text of the CP discussed today in the joint session of ITI, QRPH, and PCC. This is regarding making it clear how a document can indicate that it is in fulfillment of a previous object – Accession/Order/Request Number. This will be discussed and further refined on Friday ITI CP call.
John Moehrke
Principal Engineer: Interoperability and Security
GE Healthcare
John.M...@med.ge.com
www.gehealthcare.com
productsecurity.gehealthcare.com
3200 N. Grandview Blvd
Mail stop: WT-881
Waukesha, WI 53188
GE imagination at work
--
You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
To post to this group, send email to IHE-Ra...@googlegroups.com.
To unsubscribe from this group, send email to IHE-Rad-Tech...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/IHE-Rad-Tech?hl=en.
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
--
You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
To post to this group, send email to IHE-Ra...@googlegroups.com.
To unsubscribe from this group, send email to IHE-Rad-Tech...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/IHE-Rad-Tech?hl=en.
Kevin O'Donnell
Hi Folks,
For the record, the discussion in Rad Tech was similar to Brett’s initial comment;
That the event code list describes the type of event rather than an event instance.
ITI TF-3 Table 4.1-5 defines eventCodeList as:
“This list of codes represents the main clinical acts, such as a colonoscopy or an appendectomy, being documented. In some cases, the event is inherent in the typeCode, such as a "History and Physical Report" in which the procedure being documented is necessarily a "History and Physical" act.”
It seemed that putting the “event id” (accession, order, request number) in event code list would be breaking the information model for expediency and would be analogous to putting a ProviderID in the healthcareFacilityTypeCode, or a document ID in the typeCode, or for that matter, putting the serviceStartTime in the eventCodeList as additional information that describes the event.
It seemed like it would make more sense to recognize the lack of an eventID as a gap in the XDS information model and add a field that could be populated with an appropriate flavor of a structured event id (accession, order, request number, with issuer information as needed). Or if we want to recommend putting it (and anything else) in a grabBagList, then create such a list rather than demoting eventCodeList from its current semantics to that status.
Ultimately it’s ITI TCs choice, but it seems like stuffing it in eventCode might be short-sighted and we might regret it later.
Best Regards,
Kevin
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
David Clunie
The notion of stuffing Accession Number into eventCode and using its
assigning authority as the coding scheme, whilst it might work, is
clearly an ugly hack, so let's not play semantics and pretend that
it is either legitimate or what was was intended. This is the typical
retrospective abuse of something intended for a completely different
purpose that brought us such abominations as Presentation of Grouped
Procedures. Changing the concept to "keyword" does not help either,
since an identifier is not general considered a "keyword", at least
not in my lexicon. Perhaps "arbitrary unspecified code for anything"
might be a better description.
Since the concept of an Accession Number or Order Filler Number is
fairly common across domains, it seems reasonable to extend XDS
meta data across domains and implementations to handle it, explicitly.
Perhaps in the "spirit" of eventCode, this could be a more generic
"identifier" that came with some (coded) qualification of what type
of identifier it was and in what domain it was assigned.
By the way, it is unfortunate that eventCode is a single code, rather
than name-value pair of codes for a concept and a selected value from
a value set, since it implies either that the concept and the value
be pre-coordinated together, or that the recipient make assumptions
about what the concept is from a generic keyword (e.g., if one sends
a general SNOMED anatomical code for "brain", or a code for "left",
what does that "mean"?).
I don't think it is realistic to assume that the initial set of
metadata defined some time ago is going to be sufficient forever.
David
On 12/14/12 4:47 AM, Parisot, Charles (GE Healthcare) wrote:
> Kevin,
>
>
>
> What you quote is unfortunately, what was taken out of a CDA header data element, that was redefined by XDS as a set of "key words".
>
> So you should not take this in a literate sense. The use of the word "code" in eventCodeLists is the issue. We should have called it KeyWordList, also "word" has some other misinterpretation risks.
>
>
>
> It is actually a consistency and a long-term perspective to enable the event code list to extend going forward in an effective way.
>
>
>
> Adding new metadata, at the top tier, which is specific to certain classes of documents has some very negative impact from a backward and forward compatibility point of view.
>
>
>
> ITI should indeed address these issues.
>
>
>
> Charles
>
>
> From: IHE-Ra...@googlegroups.com [mailto:IHE-Ra...@googlegroups.com] On Behalf Of Okken,Brett
> Sent: Wednesday, December 05, 2012 22:54
> To: Parisot, Charles (GE Healthcare); IHE-Ra...@googlegroups.com
> Subject: [IHE-Rad-Tech1406] RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
>
>
>
> Charles,
>
>
>
> That does not seem to match what is described in ITI TF-3[1] 4.1.11.1, which seems to indicate that the XDS Affinity Domain should specify all acceptable values for coded attributes, including the eventCode.
>
>
>
> 4.1.11.1 Required Initialization of the XDS Affinity Domain
>
> This initialization supports the operation of the Registry Adaptor. The following information must be provided by the XDS Affinity Domain administrator and loaded into the Registry Adaptor. This supports the functionality specified for the Registry Adaptor in ITI TF-3: 4.1.11. How this information is loaded into the Registry Adaptor or how the Registry Adaptor is implemented is not defined by this profile.
>
> 1. List of acceptable mimeTypes for documents indexed by the registry.
>
> 2. PIX domain name (Assigning Authority) for XDS Affinity Domain. PatientIds attached to metadata submitted to this registry must come from this PIX Assigning Authority.
>
> 3. Acceptable values for all coded attributes represented in the registry by ebXML External Classifications. These include classCode, eventCode, confidentialityCode, healthCareFacilityTypeCode, formatCode for XDS Document and XDSSubmissionSet.code and XDSFolder.codeList.
>
>
>
>
>
> [1] - http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol3.pdf
>
>
>
>
>
> From: Parisot, Charles (GE Healthcare) [mailto:charles...@med.ge.com]
> Sent: Wednesday, December 05, 2012 12:56 PM
> To: Okken,Brett; IHE-Ra...@googlegroups.com
> Subject: RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
>
>
>
> Brett,
>
>
>
> I understand your point, but it seems to stem from a mis-sunderstanding about eventCodeList. It is not of the same nature as the CDA header EventCodeList, although it uses the same name !
>
>
>
> In XDS Metadata, it is defined as a "key word" and using a code from a coding scheme is just one way to create such key words. The eventCodeList is intended to host extension to metadata that is specific to certain classes of documents.
>
>
>
> In other terms, all elements of metadata have been designed as "tier 1" for the attribute that are expected across ALL documents, irrespective of content. EventCodeList is the second tier attribute that contains all third their extensions.
>
>
>
> IHE ITI is developing educational material to make this easily understood by deployment projects.
>
>
>
> That is precisely what we do here. Creating a new metadata attribute would generate very bad issues:
>
> - Creates complex deployment issues on existing deployed environment
>
> - Requires to create new stored queries
>
> - There will be other document/workflow specific requirements for keywords/identifiers.
>
>
>
> Extending the metadata needs to be placed under strict control.
>
>
>
> Does that help ?
>
>
>
> Charles
>
>
>
> From: Okken,Brett [mailto:BOK...@CERNER.COM]
> Sent: mercredi 5 d�cembre 2012 12:42
> To: Parisot, Charles (GE Healthcare); IHE-Ra...@googlegroups.com
> Subject: RE: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
>
>
>
> It seems like a stretch to try to treat an accession number as a code. I would expect codes to be well defined and (relatively) static.
>
>
>
> This change seems to make it very difficult for a registry to enforce the use of well-defined codes for the affinity domain. A registry implementation would now to maintain a list of codingSchemes whose member codes are not pre-defined.
>
>
>
> I understand the desire to try and put the data into an existing field. However, if implementations are going to have to be changed to relax the requirement for pre-defined codes, it would seem (to me at least) to be clearer to simply define a new field expressly for this content. Then registry implementations would have to explicitly indicate whether the field is supported or not.
>
>
>
>
>
> From: IHE-Ra...@googlegroups.com [mailto:IHE-Ra...@googlegroups.com] On Behalf Of Parisot, Charles (GE Healthcare)
> Sent: Tuesday, December 04, 2012 9:47 PM
> To: IHE-Ra...@googlegroups.com
> Subject: [IHE-Rad-Tech1401] FW: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
>
>
>
> IHE Rad colleagues,
>
>
>
> ITI knows that you are also working on this CP.
>
> PCC has just expressed today interest in solving how this "request ID" may be conveyed in the XDS/XCA/XDM/XDR metadata.
>
>
>
> Note the ITI tech T-con where the assigned CP will be discussed on Friday Dec 7th 9:00 - 11;00am
>
>
>
> Charles
>
>
>
> From: Moehrke, John (GE Healthcare)
> Sent: mardi 4 d�cembre 2012 17:01
> To: iti...@googlegroups.com
> Cc: pcc...@googlegroups.com; Lindop, Christopher (GE Healthcare); Parisot, Charles (GE Healthcare)
> Subject: IHE ITI CP on how to handle document entry 'in fulfilment of' a references to Accession/Order/Request Number of predicate
>
>
>
>
>
> John Moehrke
> Principal Engineer: Interoperability and Security
> GE Healthcare
>
>
>
> M +1 920 912 8451
>
> www.gehealthcare.com <https://urldefense.proofpoint.com/v1/url?u=http://www.gehealthcare.com/&k=PmKqfXspAHNo6iYJ48Q45A%3D%3D%0A&r=Ay8NGdQ%2F3M8lZrGkFaSc%2BDs%2BpmqDdfZvmLCXafmwolU%3D%0A&m=FHODFYkz3GaFfk8d1kuCs5CxA%2FAhbvg%2BqRr726wgfwQ%3D%0A&s=5b301d7c986be1bd9bed00b3f2bde85022c2771756b40c72db2a462074af9be3>
>
> productsecurity.gehealthcare.com <https://urldefense.proofpoint.com/v1/url?u=http://productsecurity.gehealthcare.com/&k=PmKqfXspAHNo6iYJ48Q45A%3D%3D%0A&r=Ay8NGdQ%2F3M8lZrGkFaSc%2BDs%2BpmqDdfZvmLCXafmwolU%3D%0A&m=FHODFYkz3GaFfk8d1kuCs5CxA%2FAhbvg%2BqRr726wgfwQ%3D%0A&s=44eaf0f9ad32d7a51975bd5bbde015ca9dba944954f21dc425343d95c48ceee9>
Parisot, Charles (GE Healthcare)
Kevin,
What you quote is unfortunately, what was taken out of a CDA header data element, that was redefined by XDS as a set of “key words”.
So you should not take this in a literate sense. The use of the word “code” in eventCodeLists is the issue. We should have called it KeyWordList, also “word” has some other misinterpretation risks.
It is actually a consistency and a long-term perspective to enable the event code list to extend going forward in an effective way.
Adding new metadata, at the top tier, which is specific to certain classes of documents has some very negative impact from a backward and forward compatibility point of view.
ITI should indeed address these issues.
Charles
Moehrke, John (GE Healthcare)
First, I think this is going to be discussed at 9:00 Central time TODAY.
* Meeting Number: 925 498 985
* Meeting Password: meeting
* Go to https://himss.webex.com/himss/j.php?J=925498985&PW=NZTdkNThhOTMz
Second: an eventCode is a triplet. The Vol 3 documentation simply doesn't
make this clear. Each coded value in XDS metadata is not really a 'code'
and a 'description'. They are really a 'code', 'codingScheme', and
'codeName'. So please don't worry about how one will differentiate between
codes from different codingScheme. In the proposal codingScheme is the
assigning authority for the accession number, and the code is the accession
number. It fits quite nicely.
Third, the discussion is to discover the 'best' solution. Where 'best' will
not be 'perfect'. XDS/XDM/XCA/XDR have now legacy, so one of the factors of
'best' will be dealing with that legacy. This means no proposal will be
perfect, they all will have drawbacks. The proposal as written today was
just the proposal provided by the CP writers as their 'best effort'. Yes
Charles was involved in that writing. Yes it is known that the drawback to
the overloading of EventCodeList is that the Registry can no longer validate
upon the Register transaction that all values belong to the approved list.
This is a problem with the proposal, but it is also something that many
Registries can turn-off, especially those spanning large regions.
The drawback of a brand new metadata element is that it will not be
queryable. If we don't ever need to query for this, then this model would
work out great. But I understand from the use-cases that one must be able to
include the accession number they are interested in in a XDS Query so as to
get back only results that match. For this, we must extend the Query
catalog. This means adding more stored queries, and thus a new named OPTION.
There have been other proposals, such as simply use an empty documentEntry
to represent your Accession number, and use the Document Relationships. One
might see this as a 'XFRM', but I think we would need to add a new Document
Relationship (Vol 3 - Table 4.1-2)
So, the meeting is to DISCUSS alternatives. Please spend effort
understanding the proposals presented, and formulating your proposal.
John
You received this message because you are subscribed to the Google Groups
To post to this group, send email to iti...@googlegroups.com.
Rita.N...@etsmtl.ca
Here is my feedback about accession number and XDS from my involvement with the largest 'real' deployment of XDS-I:
Unfortunately ...
XDS metadata was 'extended' to include a new field for accession number !
Moreover,
KOS header was extended to include accession number !
Why ?
Ask Dejarnette. There must be a real need.
How ?
In a non standard way !
Many non standard data were added !
as a XDS-I consumer, we have struggled to limit the mess.
KOS was also extended to include many (almost the same data extended at the XDS metadata) at the series level.
Such as
The number of images (or instances) per series.
People are trying to mimic intra workflows between institutions.
I believe it is very important to understand the real need (the real use case) in terms of requirements engineering
And not in terms of data engineering in order to come out with a standard solution to the requirement that is continuing to popup from the beginning of IHE (accession and order)
Rita Noumeir
-----Original Message-----
From: IHE-Ra...@googlegroups.com [mailto:IHE-Ra...@googlegroups.com] On Behalf Of David Clunie
Sent: December 14, 2012 8:01 AM
To: Parisot, Charles (GE Healthcare)
Okken,Brett
In the spirit of oppose/propose, I propose 2 options:
1. Make the accessionNumber/orderIdentifier a first class (optional) attribute. This will require making changes to the query transaction to add support for this attribute.
2. Add a "otherAttributes" type field that allows for the storage of additional name/value pairs. This would also require making changes to the query transaction to add support for querying on this attribute. This field could be used for affinity domain specific purposes or to support new attributes like this which come up in the future.
I understand that these changes are more impactful from a standards perspective. However, from an implementation perspective they might actually be simpler. Additionally, they allow affinity domains to maintain a controlled set of eventCode values. It will also make it very clear if a specific Registry implementation supports this functionality or not.
Brett Okken | CAMM Platform Services | Lead Architect | 816.201.6112 | www.cerner.com | bok...@cerner.com
Okken,Brett
Just for context, here is the entirety of the text from the XDS spec (Table 4.1-5 from http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol3.pdf):
This list of codes represents the main clinical acts, such as a colonoscopy
or an appendectomy, being documented. In some cases, the event is
inherent in the typeCode, such as a "History and Physical Report" in
which the procedure being documented is necessarily a "History and
Physical" act.
An event can further specialize the act inherent in the typeCode, such as
where it is simply "Procedure Report" and the procedure was a
"colonoscopy". If one or more eventCodes are included, they shall not
conflict with the values inherent in the classCode, practiceSettingCode or
typeCode, as such a conflict would create an ambiguous situation.
This short list of codes is provided to be used as “key words” for certain
types of queries. If present, shall have one or more values. Code multiple
values by creating multiple classification objects.
Kevin quoted from the first paragraph. The only mention of the “key words” concept is in the final paragraph with no further explanation. And even in that sentence, refers to the attribute as a code. The attribute is referred to as a “code” no fewer than 3 times. Taken in conjunction with section 4.1.11.1 (which I referenced below) which “requires” affinity domains to define allowable values for all coded attributes, including “eventCode”, it is unreasonable to expect any reader of this specification to treat it differently than all the other coded attributes.