Hi Vivian,
Thanks, good points, I have implemented most of them. I have changed the enumeration values as well. The thing with minimal is to denote almost, but not quite, negligible :-) Individual systems and applications can use these as they fit; it is not for us to define strict semantics on these enumerations. So long as we provide a reasonable scale, it should be enough for our purposes.
Let me know if there are other issues. I would also like to hear comments from the rest of the group. Getting some consensus and voting on something next week should be our target now. Then we’ll look at the profile in more detail.
Thanks,
Stavros
From: Vivian Lee [mailto:Vivian.Lee@uk.fujitsu.com]
Sent: 27 October 2011 17:38
To: Isaiadis, Stavros; Black, Alvin; saf@lists.oasis-open.org; Vaught, Jeffrey A
Cc: David Snelling; Lipton, Paul C
Subject: Re: [saf] RE: Some points in the spec
Hi Stavros and All,
My comments on both the degree and the Appendix B.
Degree: I think that the Low and Minimal are similar _expression_, and if we have Minimal, do we want to add Maximal? Also in terms of treatment, what are the distinctive difference between a Low and Minimal? If it is Low then we should treat and if it is Minimal we should ignore?
The Appendix B and the schema example:
1. comparing to Appendix A, we have Bob as Practitioner and Jane as Case Manager, I suggest that we should use some other names for catalogue authors.
2. if we were having another role called Catalogue Authors, should it be added into Appendix A? Might not need explanation, but at least should have another box inside the diagram.
3. when reading 6.1, I feel there are lots of contradictions to the definition of the Signature and Directive:
· line 527, I would say “finds the schema defined by the SymptomSchema”, this indicate where the schema comes from, if it is from Catalogue, if it is “used by Symptoms”, it should from the SymptomStore. Unless we define an extra step that extract all the SymptomSchemas from the existing SymptomStore, do we want to do that?
· line 531 onwards, I think the PrescriptionSchema is a little bit different here from the SymptomSchema, cause the PS can be totally defined by the Catalogue author from general knowledge, not necessarily consult existing Prescription. So I would omit “she requires ... Above 38.5.”
· line 537 I would put “how to extract the value of these arguments”
· line 539, I still not sure who generate the “PrescriptionSchema” here.
4. A general comment on the schema examples: all the Types need to be changed to Contain <Uri>, maybe nice to have <Version>.
Let me know if these make sense?
Vivian
On 25/10/2011 12:59, "Isaiadis, Stavros" <stavros.isaiadis@baml.com> wrote:
Hi Alvin,
I struggled about the likelihood semantics as well. We use “Common” currently which implies we see this as some sort of frequency –plus the description also talks about “the typicality” of this symptom. I agree about the Unknown in Effectiveness, and also agree into at least exploring whether we could just use the same scale for all enumeration types.
Thanks,
Stavros
From: Black, Alvin [mailto:Alvin.Black@ca.com]
Sent: 25 October 2011 12:56
To: Isaiadis, Stavros; saf@lists.oasis-open.org
Subject: RE: Some points in the spec
Do we need an “Unknown” as part of “effectiveness?” That would mean every enumeration would have six possible values, which would add some symmetry (which always seems right).
One other minor semantic concern: As I think this through, “likelihood” seems like it is has a different connotation than “frequency” so the enumeration terms seem “wrong” somehow. It seems like we could use the same enumeration values as most of the other enumeration types perhaps. (Maybe I’m not thinking about this right though)
From: saf@lists.oasis-open.org [mailto:saf@lists.oasis-open.org] On Behalf Of Isaiadis, Stavros
Sent: Tuesday, October 25, 2011 6:36 AM
To: saf@lists.oasis-open.org
Subject: [saf] Some points in the spec
Hi all,
As we approach a more polished version we would like to vote on, here’s some points to consider:
· Enumerations such as Impact, Risk, Likelihood, and Urgency: I propose adding two more levels to make them more granular, and eliminate the name of the enum as a suffix of the values. Specifically:
Likelihood {VeryFrequent, Frequent, Balanced, Infrequent, Rare, NotAvailable}
Impact {VeryHigh, High, Moderate, Low, Minimal, Unknown}
Urgency {VeryHigh, High, Moderate, Low, Minimal, Unknown}
Risk {VeryHigh, High, Moderate, Low, Minimal, Unknown}
Duration{VeryLong, Long, Moderate, Short, VeryShort, Unknown}
Effectiveness {Effective, PartiallyEffective, BestEffort, Ineffective, Inconclusive}
· Adding examples of the elements right after the pseudo schemas, and in the end in the appendix pull all the examples together in a scenario-based one, following our medical sequence diagram. This would clarify things a lot probably.
· Conformance: I don’t think we have anything special to add here
· Non-normative text: we should just remove this section
More may come later. Thoughts?
Thanks,
Stavros
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan does not guarantee that it has not been intercepted or amended nor that it is virus-free. |