RE: Meeting Notes..
Schluter, Paul (GE Healthcare)
Standardizing the enumerated values is just as critical as standardizing
the identifiers of the variables that contain the enumerations. For
example, knowing that an infusion pump is in a "standby" versus an
"operational" state is critical for patient safety and it behooves us to
standardized these as much as possible.
That said, vendor-specific enumerations are still often unavoidable, but
fortunately we can represent them in the <Enums> branch by adding a
//Enums/term/Vendor (or VendorID) column, that may contain zero-or-more
standardized vendor identifier text tokens. We created a normative list
of tokens in the CSLI/NCCLS POCT1-A standard and we can expand it to
include everyone else (original list attached below). A basic version
of this is already in the IHE PCD RTM but we will expand the basic
worksheet to include the following information:
/RTM/Vendors/row/
Vendor_ID GE_Aware, Philips, Draeger
Suffix GE
Vendor_Name GE Healthcare
As you can see, we were a little loose with this, since we also used it
as a vendor_product identifier, e.g. "GE_Aware".
If we really want to make this more useful and formalize it, we could
expand the content to include:
/RTM/Vendors/term/
VendorID "GE" replaces <Suffix> in RTM) (dotted "."
extensions can be used to indicate business groups) [REQUIRED, unique]
VendorName "GE Healthcare" [REQUIRED, unique]
OUI-24 "08-00-19" IEEE Organizationally Unique Identifier
(OUI) (required for PCD-01, unique)
Authority "NYSE" { NYSE | AMEX | NASDAQ | ... | POCT1A | SELF
} the authority that VendorID was assigned by
NameSpacePrefix "ge" (vendor assigned, unique)
NameSpace "urn:ge:11073:orgs:ge" (vendor assigned, unique)
The <VendorID> is a short all-capitalized token, usually the stock
trading symbol, which guarantees uniqueness. A company can declare its
own identifier as long as it does not conflict with existing identifiers
on the list and is not already used as a stock trading symbol. The
<VendorID> can be used as a suffix for vendor-specific variants of a
standard term or as an indicator of the vendors that support/implement a
particular term. The key requirement is that it be short, recognizable
and unique, preferably by being assigned by an external authority
identified in the <Authority> element.
The <OUI-24> is the IEEE assigned "Organizationally Unique Identifier"
(OUI) that is the first three bytes of a MAC address. Companies may
purchase an OUI-24 number for modest fee, which gives them 2**40 serial
numbers in the lower five bytes of the IEEE EUI-64. The EUI-64 is a
required device identifier for the IHE PCD Technical Frameworks. If
necessary, a gateway can proxy an EUI-64 using on its own MAC address or
known vendor OUI-64 concatenated with a five byte value or other
algorithm [this would be a topic for another discussion and does not
need to be resolved here].
The <Authority> identifies the assigning authority, preferably a stock
trading organization such as NYSE. This list is not exhaustive.
The current aECG-IDC XML format definition supports the use of
namespaces for vendor specific columns/tagnames for vendor specific
discussions, using standard XML namespace techniques. The IEEE
"standard" columns/tagnames are in the default namespace and do not have
a prefix whereas all vendor specific content must be in a different
(##other) namespace and namespace prefixes.
I have attached the current (and nearly final) draft of
<<RTM-MDC.8f.2009-01-30T17.almostfinal.doc>>. The Schema and example
IDC XML files have been updated (but not the XSLT). We need to agree on
how vendor-specific enumerations will be represented in the XML; we can
leave the details of how it is actually published in the _printed_ IEEE
11073 standard (e.g. either as clearly labeled informative material in
the main body text or as a separate informative Annex). One thing is
very clear to me, however, that if a variable has a mix of standard and
vendor-specific enumerated values, then they should be listed together
under the same /*/Enums/term/_ENUM_GROUP and are considered
vendor-specific if the //VendorID element is non-empty; if empty, the
enumeration value is considered a "standard" enumeration.
Best regards,
Paul Schluter
GE Healthcare - Monitoring Solutions
office: (414) 362-3610
cell: (414) 702-2026
<<RTM-MDC.8f.2009-01-30T17.almostfinal.doc>>
List of vendors and identifiers from CLSI/NCCLS POCT1-A standard.
Vendor Code
Abaxis ABAX
Abbott Laboratories ABT
Agilent Technologies A
Avocet Medical AVOCT
Bayer Diagnostics BAYER
BD BDX
Biochemtronics BCHMX
Cerner CERN
Clarinet Systems CLAR
Comtrol Corporation CMTRL
First Medical/Sigma Diagnostics FMSDG
GE Healthcare GE
HemoCue HMCUE
HemoSense HMSNS
Instrumentation Laboratory IL
InterComponentWare ICW
i-STAT Corporation ISTAT
ITC ITC
Lantronix LTRX
LifeScan/J&J LFSCN
Medical Automation Systems MAS
Medtronic MDT
Motorola MOT
Nova Biomedical NOVABIO
Orasure Technologies, Incorporated OSUR
Pharmacia Diagnostics PHADI
Philips Medical Systems PMS
Radiometer Medical RAD
Roche Diagnostics/AVL Scientific ROCHE
Siemens SIEM
Sunquest SUNQ
TELCOR TLCOR
-----Original Message-----
From: Steblay, Nicholas J (STP) [mailto:Nicholas...@bsci.com]
Sent: Saturday, January 31, 2009 4:49 AM
To: Schluter, Paul (GE Healthcare); Alexander Kraus; Schultz, Thomas;
Wittenber, Jan; gr...@idcstandards.com
Subject: RE: Meeting Notes..
We will be putting the enumerations into the XML file in the <Enum>
partition. Our current approach is these enumerations will be published
in the annex of the IEEE ballot as non-normative.
To address Jan's question we will point to IHE profile from the
normative section of the standard. For now IHE profile will contain the
"normative" version of the enumerations. The IEEE standard's annex will
contain what we know about the enumerations at time of ballot.
In a future date we may want to consider putting the normative
enumerations in the IEEE standard.
This is what we decided in Orlando as a compromise approach.
- Nick
-----Original Message-----
From: Schluter, Paul (GE Healthcare) [mailto:Paul.S...@med.ge.com]
Sent: Friday, January 30, 2009 3:24 PM
To: Alexander Kraus; Schultz, Thomas; Wittenber, Jan;
gr...@idcstandards.com
Cc: Steblay, Nicholas J (STP); Paul.S...@med.ge.com
Subject: RE: Meeting Notes..
Greetings,
Why not store/record the vendor enumerations just like any other
enumeration in the <Enum> partition, except that we could add an
additional standard column Enums/term/Vendor that lists one or more
vendor tokens (e.g. MDT, GDT, etc.) that the enumeration is specific to?
If the column entry for a particular Enums/term/vendor is empty, then it
is a "standard" enumeration.
You could then decide later on whether or not to include the
vendor-specific terms in an Annex or printout or whatever.
Sorry for missing your tcon today, but I had a conflict at the time.
The XML representation is really crystallizing into its final form and I
expect to send another update of the write-up, example XML files and
XSLT by early next week. Practically all the open issues that were
raised during Wednesday's RTM tcon have been resolved and only a few
long-term open issues remain (synonyms and mapping to other
nomenclatures). These can be deferred to a future date to ensure timely
completion of the aECG and IDC nomenclatures.
In the meantime, please send me any other comments and suggestions you
have.
Regards,
Paul Schluter
GE Healthcare - Monitoring Systems
office: (414) 362-3610
cell: (414) 702-2026
-----Original Message-----
From: Schultz, Thomas [mailto:thomas.w...@medtronic.com]
Sent: Friday, January 30, 2009 2:24 PM
To: Wittenber, Jan; gr...@idcstandards.com
Subject: RE: Meeting Notes..
Hi Jan,
My understanding was that the "informative portion of the standard"
(annex) will have the vendor elaborated enumerations and will also have
a pointer to the profile where the latest version of the vendor
enumerations are compiled. Is this informational portion (annex) of the
standard the normative section? I thought the normative was where the
vendor agreed upon codes were kept..
Thanks for your clarification..
Tom
-----Original Message-----
From: Wittenber, Jan [mailto:jan.wi...@philips.com]
Sent: Friday, January 30, 2009 2:09 PM
To: Schultz, Thomas; gr...@idcstandards.com
Subject: RE: Meeting Notes..
Thomas,
Could you please clarify:
"4. Vendor specific enumerations will be profile related. Vendor
portion of enumerations will be part of the informative portion of the
standard but the informative section will point to the profile as having
the most up to date version of the vendor specific enumerations."
Did you mean "...but the normative section will point to..."?
/Jan
-----Original Message-----
From: Schultz, Thomas [mailto:thomas.w...@medtronic.com]
Sent: 2009 Jan 30 1:41 PM
To: gr...@idcstandards.com
Subject: Meeting Notes..
Here are the notes from today's meeting.
I have uploaded them to the site as well under the meeting notes
section.
Tom
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is
intended for use only by the individual or entity to which it is
addressed, and may contain information that is private, privileged,
confidential or exempt from disclosure under applicable law. If you are
not the intended recipient or it appears that this mail has been
forwarded to you without proper authority, you are notified that any use
or dissemination of this information in any manner is strictly
prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the
following link or manually copy and paste the link into the address bar
of a web browser: http://emaildisclaimer.medtronic.com
The information contained in this message may be confidential and
legally protected under applicable law. The message is intended solely
for the addressee(s). If you are not the intended recipient, you are
hereby notified that any use, forwarding, dissemination, or reproduction
of this message is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender by return e-mail
and destroy all copies of the original message.
Wittenber, Jan
To me, this means that some enumerations may be normative and some non-normative [/informative], including, as Paul points out, vendor-specific ones. But, as you point out, it was agreed even at the last F2F that the vendor-specific ones would have an external logistic for administration, although some such terms could also be included in the x73 document to facilitate "1-stop shopping", so to speak, in an annex, for example, with a pointer to the external authoritative source, and a proviso that that external source may differ from the x73 listing in the interim period between x73 IDC revisions [and presumably the external source takes precedence if there is any inconsistency].
While you're at it, perhaps you can clarify this: if a term is 'vendor-specific', does that mean only the given vendor can use it? [I hope not.] But, in any event, as I've said before, any vendor should disclose any vendor-specific terms they use in their user-facing documentation/device labeling, and preferably including so-called 'normative' terms from the x73 IDC (or aECG) partitions, as neither requires the use of all but whatever subset a given vendor deems appropriate.
Regards,
Jan