The COAS operations that return ObservationData are locked into using a
structuring mechanism that is defined as a stop gap solution due to the
lack of extensive support for the ValueTypes by ORBs today. This
proposal addresses that problem by suggesting a simple change that
allows the same COAS operational interfaces to be used in the future
with ValueTypes (or additional types that may be created for IDL in the
future).

I propose that the current ObservationData type be renamed to
ObservationDataStruct. Any data types that reference ObservationData
would then reference ObservationDataStruct (with the exception of
ObservationDataSeq). A typedef for ObservationData being of the type
"any" would be created as such:

typedef any ObservationData;

In this way observations are passed by value via the "any" type
(actually a typedef to the "any" type) in the operations which frees up
the possibility of using ValueType (and other type) definitions for
observations in the future or by local agreement in specialized
environments.

In addition a new Conformance class (e.g. "Structured COAS") should be
created that indicates a server uses the ObservationDataStruct as the
explicit type returned/passed in via the ObservationData in operations.
This allows future standardization using value types in which additional
conformance points can be made for other structuring used by servers.
Note these conformance classes are independent of the conformance
classes specifying which interfaces a server implements.

resolved in COAS FTF

Issue:
Pg. 193 Under section - D.3 Secure Interoperability Concerns
Text in question:
"Each CSI level is parameterized by mechanisms that can support the level of security functionality, such as SPKM for CSI Level 0, GSS Kerberos for CIS Level 0 or CIS Level 1, and CSI_ECMA for CSI Level 2. Future developments in security functionality and mechanism are not restricted, and mechanisms can be added to each level."

Misspelling.

resolved in COAS FTF

Issue:
Pg. 208 Under section - 12.7 AbbreviatedCorba.idl
Suggest remove & just document that COAS only uses TCKind & RepositoryId.

resolved in COAS FTF

Issue:
Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservationAccess ObservationType
Imported enums are dangerous. This has to do with TCKind and get_observation_type.

resolved in COAS FTF

Issue:
Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram
Ensure that the semantics of the aggregate relationship and the cardinality is what is meant.

resolved in COAS FTF

Issue:
Pg. 145-152 Under section - 3.8.1-3.8.17
A multitude of const were typedefed yet in the const declaration the primitive type was used.

resolved in COAS FTF

Issue:
Pg. 141 Under section - 3.7.1 General
Text in question:
• replace "/" with "_".
• replace space with nothing, capitalizing next word.
• Omit apostrophe, periods, parenthesis, and other punctuation.

Needs to be indented.

resolved in COAS FTF

Issue:
Pg. 129 Under section - 3.5.4 Sequence Types
Text in question:
case OtherSeqDataType : any the_any;

Is the any required to be a sequence? Or can it be just any old any?

resolved in COAS FTF

Issue:
Pg. 120 Under section - 3.4.2 Supporting Types
Text in question:
typedef DsObservationAccess::AbstractManagedObjectAbstractManagedObject;

Missing a space.

resolved in COAS FTF

Issue:
Pg. 81 Under section - 3.3.2.5 Constants
Text in question:
const QualifiedCodeStr PARTIAL_RESULT
const QualifiedCodeStr COMPLETING_RESULT
const QualifiedCodeStr ASYNC_OBSERVATION_COUNT
const QualifiedCodeStr EVENT_SOURCE_DOMAIN
const QualifiedCodeStr EVENT_SOURCE_SERVER_NAME
const QualifiedCodeStr EVENT_NAME
const QualifiedCodeStr TEST_EVENT
const QualifiedCodeStr TRADER_1_0_CONSTRAINT_LANGUAGE
const QualifiedCodeStr OCL_1_1_CONSTRAINT_LANGUAGE
const QualifiedCodeStr COAS_OBSERVATION_ID

Complete the const spec here are simply state names of constants & refer to IDL.

resolved in COAS FTF

DsObservationValues.idl has typedefs for TimeStamp and TimeSpan that are
never used. Why not delete them since they create problems in the IDL2Java
mapping by creating *Helper classes than cause name collisions?
DsObservationQualifers.idl has a typedef for TimeStamp that also is not used.

Can we remove these references? They can have no impact on any
application that uses these interfaces.

rejected

Issue:
Pg. 133 Under section - 3.6.1 General
Text in question:
• replace "/" with "_".
• replace space with nothing, capitalizing next word.
• Omit apostrophe, periods, parenthesis, and other punctuation.

Needs to be indented.

resolved in COAS FTF

Issue:
Pg. 153 Under section - 3.9 Conformance Classes
Doesn't say what one needs to do to claim conformance to this spec I guess the requirement is conformance to at least one?

resolved in COAS FTF

It took me a LONG time to realize that the interfaces are presented in alphabetical order and not in any logical order. A sentence to explain this would have been useful. While that organization may be useful from a reference perspective it is very confusing when you try to read the specification and understand the functionality and how it is partitioned between the interfaces. This significantly increased the time it took me to review the submission.

resolved in COAS FTF

Pg. 108 Under section - 3.3.3.13 FederatedAccess
The name of this interface was confusing to me. In the CORBA world I think of federation as a way to connect multiple services, not just a way to get data feeds to a single service from other services. I'm not saying this isn't important, just that I think the interface name is confusing.

resolved in COAS FTF

Pg. 70 Under section -3.3.2.1 Include Files
This abbreviated include must not be part of the standard - it is a deployment convenience. 5.2.1 dealing with abbreviated includes should not be normative.

resolved in COAS FTF

Text in question:
"Although the Business Object Component Architecture (BOCA) was not adopted as an OMG specification, a portion of the work defining Common Business Objects was adopted.

There is interest in defining COAS such that it will build on top of the appropriate Common Business Objects, and that in the future if a BOCA specification is adopted, the COAS can be used as a stand-alone service and also as a business object compatible with the BOCA. Since this is new ground, it will take some experimentation to determine the way to accomplish this."

Statement of pious intentions regarding unpredictable future events.

resolved in COAS FTF

Pg. 79 Under section - 3.3.2.4.9 TimeStamp
Text in question:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
http://www.roguewave.com/products/resources/exchange/iso8601.html
http://www.hut.fi/u/jkorpela/iso8601.html
http://www.w3.org/TR/NOTE-datetime
http://www.lanl.gov/projects/ia/stds/ia830210.html
http://www.magnet.ch/serendipity/hermetic/cal_stud/newman.txt

Need a normative place.

resolved in COAS FTF

Issue:
Pg. 75 Under section - 3.3.2.4.3 ObservationData
This is strange use of IDL. I would have used a union for composite and value.

resolved in COAS FTF

Pg. 95 Under section - 3.3.3.5 AsynchCallBack
put_observations() The text states that the as_iterator is a sequence. It is not. It is an objref. Also there is no mention of what it means if the are_iterators_supported is FALSE

resolved in COAS FTF

Pg. 92 Under section - 3.3.3.3 AccessComponent
get_observation_type() I'm unclear the purpose of this parameter and also the description of where it is applicable is unclear. "will be returned" from what operations? What if it isn't? I'm just not sure what the purpose of this actually is.

resolved in COAS FTF

Pg. 90 Under section - 3.3.3.3 AccessComponent
It is not stated whether each interface is required to return the same response to one of these operations being called.

resolved in COAS FTF

Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10
Your definition of a clinical observation specifically states a human being as the subject (which I thought was a bit restrictive), but in this section you admit it might be an animal

resolved in COAS FTF

Pg. 5 Under section - 3.1.4 Objects By Value (OBV)
Text in question:
"Also, typical usage patterns of OBV, appropriate to healthcare, have not been identified. During the implementation phase of the COAS specification, it is expected that these patterns will be identified, and changes may be recommended through normal OMG revision processes."

May be beyond the scope of what an FTF or RTF is allowed to do.

resolved in COAS FTF

Pg. 71 Under section - 3.3.2.1 Include Files
Text in question:
"Another abbreviated file, AbbreviatedCorba.idl, includes two definitions from the fundamental CORBA 2.2 definitions. This file is provided as part of the normative section for convenience. The full CORBA 2.2 IDL specification for ORB vendors, in plain IDL, is lengthy and may not be easily available in IDL text format."

It must not be normative.

resolved in COAS FTF

Pg. 86 Under section - 3.3.2.8 Exceptions
The description of these exceptions is not sufficient for an implementation to know what the actual meaning of the results should be. For example, the "Duplicate*" exceptions; is it required that the service parse all inputs and return all duplicates or may it return only the first duplicate found? The same question for Invalid* exceptions

resolved in COAS FTF

Pg. 91 Under section - 3.3.3.3 AccessComponent
get_supported_codes() It wasn't clear to me what a "query code" is. This should be clarified.

resolved in COAS FTF

here are our desired positions in dimensions of connotation:

• multiple instance vs. one instance vs. one atribute of an instance - we
  want to connote multiple instances
• does a the requestor get any info back - no.

======== options, their thesaurus equivalents, and assessment for
suitability ===================
place - connotes location to explicitly

put or put-in (insert, place, store, publish) - reasonable but can we do
better?

write (communicate, mark, record) - implies recording on a persistence
medium - too underlying technology-connotative

load - has precedent in pids; implies multiple, and already understood in IS
as "batch" and one-way-transfer with no significant return info. I also lke
the "ammo" connotation. We are "charging" a sevice with useful info or
potential energy - ready to be put to useful work.

add - in o-o circles, this connotes adding an (singleton) entry to a
dictionary or to a container.

set - connotes setting a property or a primitive value. no batch semantics
permitted.

======================= my recommendation

interface: ObservationLoader (a utility with a manifest puprose)

operation: load_observations

resolved in COAS FTF

Pg. 81 Under section - 3.3.2.5 Constants
Many of the constants do not have the values specified in this section although they are in the IDL.

resolved in COAS FTF

This is an issue for both the PIDS2 RTF and the COAS FTF.

The PIDS and COAS specifications both indicate how to use HL7 data types
with those services but neither have specified a way for an
implementation to claim conformance to using them. A conformance point
should be added to both specifications. This will enhance the
expectations of interoperability for using those services since a user
and of the servcie and the servcie have to be compatible on the
information type specification as well as the service specification.

resolved in COAS FTF

In the current specification we find that exceptions are limited. For example, when invoking get_observations_by_time, the patient specified may not exist on the server. We can return empty ObservationData in this case, but a more descriptive exception such as "patient not found" would be useful here. Other exceptions that give information for "no results found" or "unable to get access" or "system down" etc. would give the client more flexibility to notify the user of the status of the call and how to handle any repeated tries. In other words, more application level information should be allowed to be sent back. These types of enhancements will require input from programmers and developers to make sure we capture relevant and meaningful exceptions.

see above, issue rejected