I have questions about the use of Mandatory Inclusion / Conformance /
Cardinality as used in the Transport Record Summary Profile.
Using Table 6.3.1.B.4-1 (pg 37) as an example:
Injury Incident Description: R conformance, [1..1] Cardinality
Mass Casualty Incident : R conformance, [0..1] Cardinality
According to Note 1: "[...]if it has an R under conformance, it must be
present, but CAN BE NULL."
I'm a little confused how the difference in cardinality (0 instances are
allowed in Mass Casualty) affects R conformance. In other words, from
an implementation point of view, how do those two rows differ?
A second, similar question. Is there sample XML available for a "null"
section. I'm not sure what a section would look like that is null but
still obeyed all the the requirements of the template.
Thanks!
--
Andrew McCaffrey
andrew.m...@nist.gov
----
The words above do not necessarily reflect the opinions of my employers
or any organization I may be associated with. In fact, by the time you
read them, they may not even reflect my own opinions anymore.
----
Any mention of commercial products within NIST web pages or email is for
information only; it does not imply recommendation or endorsement by NIST.
On 11/22/2011 01:56 PM, Philip DePalo wrote:
> My understanding was that cardinality showed how many times it could
> appear. There would only be one injury incident description for a
> transport, and there has to be one since it wouldn't happen without it,
> but not more than one. The mass casualty can be nothing available or it
> is. Knowing it isn't is important, hence the need for the R, but the
> cardinality could be 0 since its not necessary.
>
> Let me look for XML.
>
> Philip DePalo, MS, NREMT-P
> ph...@philipdepalo.com <mailto:ph...@philipdepalo.com>
> http://www.swordshow.com
>
> On Nov 22, 2011 1:49 PM, "Andrew McCaffrey" <andrew.m...@nist.gov
> <mailto:andrew.m...@nist.gov>> wrote:
>
> PCC Folks,
>
> I have questions about the use of Mandatory Inclusion / Conformance
> / Cardinality as used in the Transport Record Summary Profile.
>
> Using Table 6.3.1.B.4-1 (pg 37) as an example:
>
> Injury Incident Description: R conformance, [1..1] Cardinality
> Mass Casualty Incident : R conformance, [0..1] Cardinality
>
> According to Note 1: "[...]if it has an R under conformance, it must
> be present, but CAN BE NULL."
>
> I'm a little confused how the difference in cardinality (0 instances
> are allowed in Mass Casualty) affects R conformance. In other
> words, from an implementation point of view, how do those two rows
> differ?
>
> A second, similar question. Is there sample XML available for a
> "null" section. I'm not sure what a section would look like that is
> null but still obeyed all the the requirements of the template.
>
> Thanks!
>
> --
> Andrew McCaffrey
> andrew.m...@nist.gov <mailto:andrew.m...@nist.gov>
> ----
> The words above do not necessarily reflect the opinions of my
> employers or any organization I may be associated with. In fact, by
> the time you read them, they may not even reflect my own opinions
> anymore.
> ----
> Any mention of commercial products within NIST web pages or email is
> for information only; it does not imply recommendation or
> endorsement by NIST.
>
> --
> You received this message because you are subscribed to the Google
> Groups "IHE PCC Technical Committee" group.
> To post to this group, send email to pcc...@googlegroups.com
> <mailto:pcc...@googlegroups.com>.
> To unsubscribe from this group, send email to
> pcctech+unsubscribe@__googlegroups.com
> <mailto:pcctech%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/__group/pcctech?hl=en
> <http://groups.google.com/group/pcctech?hl=en>.
Wendy, Andrew and all,
I have thought about this quite a bit too, from my point of view, it creates a contradiction to indicate an optionality of R and a cardinality of [0..
It seems to me that in indicating an optionality of R or M, you are indicating a cardinality of [1..
The reason you say R or M is to further specify if null values are allowed or not, but structurally you are requiring the xml to be present in the document.
If the optionality is O, then the cardinality would be [0..
Based on the definition of R, I don’t see how you could simultaneously allow a cardinality of [0..
The logic of the definitions don’t make sense together.
Lisa
From: iheqr...@googlegroups.com [mailto:iheqr...@googlegroups.com] On Behalf Of Blumenthal, Wendy J. (CDC/ONDIEH/NCCDPHP)
Sent: Monday, November 28, 2011 3:44 PM
To: pcc...@googlegroups.com; ihe-pcc-im...@googlegroups.com; Andrew McCaffrey; Philip DePalo; iheqr...@googlegroups.com; Solomon, Harry (GE Healthcare)
Subject: [iheqrphtech:1479] RE: Mandatory / Conformance / Cardinality question
Andrew,
Here are the definitions from Cardiology’s CIRC content profile (http://www.ihe.net/Technical_Framework/upload/IHE_CARD_Suppl_CIRC_Rev1-1_TI-2011-07-01.pdf) that we used for PRPH-Ca.
Optionality | Description |
M | A "Mandatory" section, entry or data element is one that SHALL always be provided. If there is information available, the element must be present and non-null. If there is no information available, or it cannot be transmitted, the data element must contain a value indicating the reason for omission of the data. Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. |
R | A "Required" section, entry or element SHALL be included in the document if its minimum cardinality is one. If the data exists, the sending application SHALL send it as a non-null value or a non-empty element. If the data does not exist and if the minimum cardinality is greater than zero, then the sending application SHALL send an appropriate null value. Only if data does not exist for a required element and that element has a minimum cardinality of 0 MAY the required element be omitted in a document. In all cases, if a required element is present in a document received by an actor claiming support for the Profile, then it SHALL be correctly processed by the receiving actor. A receiving actor SHALL NOT raise an error due to the absence of a required element with a cardinality of 0, although it MAY issue a warning that required information is missing. For required elements, conforming applications must demonstrate their ability to provide and communicate not null values. Receiving applications must demonstrate their ability to receive and process (e.g., store, or display to users) not null values for required elements. This is equivalent to a SHOULD requirement. |
O | An optional data element is one that MAY be provided, whether the information is available or not. If the implementation elects to support this optional section, then its support shall meet the requirement set forth for the "Required" or R. |
C | A conditional data element is one that is required, or optional, depending upon other conditions. These will have further notes explaining when the data element is required. |
We decided to use:
1. R to indicate that vendors must send data if they have it; there are many sections where they may not have information (hence R, instead of M)
2. [1.. because we want the vendors to formally/specifically state that they don’t have the information, rather than being allowed to omit the section or element
3. ..1] because we should only have one of each section; it doesn’t make sense to have more than one.
Having read Philip’s response and thought through this some, we think cardinality of [0..1] would be acceptable for some of our sections, but we do have this concern: how do we know that the sender really doesn’t have this information versus they didn’t program the system to send it?
If we were to keep sections as R with cardinality of [1..1], is your question related to the fact that there is no way to express some of the required elements in a section as null? For example, what statusCode would be used for the Concern Entry in a null Active Problems section? We’re not sure how to handle these situations either. Can anyone on PCC or QRPH Google Groups answer this (Harry, Keith, Vassil, Tone?)?
Thank you,
Wendy
Wendy Blumenthal, MPH
Epidemiologist
Cancer Surveillance Branch (CSB)
Centers for Disease Control and Prevention (CDC)
Phone: 770-488-1131
Fax: 770-488-4759
Email: wblum...@cdc.gov
To post to this group, send email to pcc...@googlegroups.com.
To unsubscribe from this group, send email to pcctech+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pcctech?hl=en.
--
You received this message because you are subscribed to the Google Groups "IHE QRPH Technical Committee" group.
To post to this group, send email to iheqr...@googlegroups.com.
To unsubscribe from this group, send email to iheqrphtech...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iheqrphtech?hl=en.