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

The QueryAccess interface has a matching interface called AsynchAccess which mirrors many operations in QueryAccess except the data is returned asynchronously. FCPR is looking at the ConstraintLanguage interface for doing population studies. The time needed to find and return the data from these types of queries could be significant. Yet these calls are synchronous. It may be useful to mirror this interface with one that has corresponding asynchronous operations. Additionally, the interfaces could be expanded to allow for clients to check on the status of their request.

There is one enhancement that will be treated in a separate issue paper: that of using another mechanism for the delivery of observation data such as XML or an IDL instead of the current nested ObservationData structure. For now we will simply mention that this is an area that needs to be enhanced. Massive amounts of data being moved across in the QueryAccess services need metadata or more descriptive access for clients to decode the data. We have suggested using XML in the any portion of the observation data structure. A DTD could be used for clients to decode the data in then XML stream. This removes the burden from the client of having to understand the internal data structures of the data being passed back. COTS products could be used to unwind the data and display the required portions. Versioning would also be easier to handle using XML since different versions of the DTD could be used to decode different XML format versions.

In editing the COAS specification to include the resolved solutions for the various issues I have come across the following problem with regard to the Naming Service:

The revised COAS now has three independent conformance categories:
1) interface conformance, i.e. the set of interfaces implemented by the server,
2) data structure conformance, i.e. whether ObservationDataStruct is used, or some other solution, e.g. OBV
3) qualified code conformance, i.e. whether the COAS rules for creating qualified codes from HL7 were used, etc.

The current text for relating COAS and the Naming Service has the COAS conformance class (note the singular noun) placed in the "kind" member of the CosNaming::NameComponent struct, which is defined as a "string".
Several solutions are possible:

• define delimiters to be placed between the conformance categories in the "kind" string,
• define a hierarchy of COAS names, with a different category placed in the "kind" string at each level of the hierarchy,
• define a set of combination conformance class names that combine a common conformance class from each category, representing the set with a single name,
• ...

My preference is ??,

• while the third would be take the least effort right now, it provides the least extensibility and interoperability,
• the second would only require small additions to the section in the appendix that describes how COAS and Naming work together, but it places some fairly strong constraints on Naming hierarchies, possibly requiring a complex hierarchy and naming schemes
  for servers that support multiple interface and qualified code conformance classes (which is likely).
• the first may break other clients that use the naming service, or it may be the best solution of the three.
• ...

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

As mentioned in the previous paragraph, the IDL does not reflect the examples correctly in all cases, such as the Numeric data type. The entire IDL needs to be vetted to insure that the examples are accurately captured in the IDL.

The ability to specify qualifiers will be an important facet of the GCPR COAS Implementation. Thus the get_observations_by_qualifier call will be used to specify filters for the data being requested. Relational operators will be a key element of the inbound qualifiers on this call - for example to specify that the results include values greater than a specified value.
Though the COAS Specification shows that relational operators (greater-then, less-than, etc) can be specified for a value field, such as Numeric, in an optional component, the IDL does actually not contain any such optional field. Thus there is no current way to specify these relationships. Additionally, we suggest that the CodedElement class (subclass to ObservationValue) contain an optional field for relational operators. It is possible that a qualifier may include a coded element that needs such a relational operator.

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

The EventSupplier interface in COAS has one simple call for a client to receive events: subscribe. This operation allows a client to specify a sequence of subscriptions which are structures that include data on who and what the client is interested in. According to the specification, calling this operation will replace any current subscriptions made by a previous invocation. Thus this operation is not additive. We recommend that an additional operation be added which would allow subscriptions to additive - not replacing the current subscriptions but adding new ones. Conversely the ability to remove specific subscriptions would be required as well. GCPR will want to keep a cache of patient data up to date. The event interfaces may be useful for this purpose. As new patients are added to cache, servers could be notified of the new subscriptions. Without additive subscriptions, the client would have to resend the same subscription information on current patients already in cache each time a new subscription was needed.

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