Issues for Clinical Observations Access Service (COAS) Revision Task Force mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2936: alternative verbs for Federated access and put_obsevations
Issue 2981: how to use HL7 data types
Issue 2983: Pg. 81 Under section - 3.3.2.5 Constants
Issue 2984: Pg. 86 Under section - 3.3.2.8 Exceptions
Issue 2985: Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10
Issue 2986: Pg. 90 Under section - 3.3.3.3 AccessComponent
Issue 2987: Pg. 91 Under section - 3.3.3.3 AccessComponent
Issue 2988: Pg. 92 Under section - 3.3.3.3 AccessComponent
Issue 2989: Pg. 95 Under section - 3.3.3.5 AsynchCallBack
Issue 2990: Pg. 108 Under section - 3.3.3.13 FederatedAccess
Issue 2991: interfaces are presented in alphabetical order and not in logical order
Issue 2992: Pg. 5 Under section - 3.1.4 Objects By Value (OBV)
Issue 2993: Pg. 5 Under section - 3.1.5 BOCA & CDL
Issue 2994: Pg. 70 Under section -3.3.2.1 Include Files
Issue 2995: Pg. 71 Under section - 3.3.2.1 Include Files
Issue 2996: Pg. 75 Under section - 3.3.2.4.3 ObservationData
Issue 2997: Pg. 79 Under section - 3.3.2.4.9 TimeStamp
Issue 2998: Pg. 81 Under section - 3.3.2.5 Constants
Issue 2999: Pg. 120 Under section - 3.4.2 Supporting Types
Issue 3005: Pg. 129 Under section - 3.5.4 Sequence Types
Issue 3006: Pg. 133 Under section - 3.6.1 Genera
Issue 3007: Pg. 141 Under section - 3.7.1 General
Issue 3008: Pg. 145-152 Under section - 3.8.1-3.8.17
Issue 3009: Pg. 153 Under section - 3.9 Conformance Classes
Issue 3010: Pg. 208 Under section - 12.7 AbbreviatedCorba.idl
Issue 3011: Pg. 193 Under section - D.3 Secure Interoperability Concerns
Issue 3012: Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram
Issue 3013: Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservatio
Issue 3042: COAS operations that return ObservationData
Issue 3136: typedefs for TimeStamp and TimeSpan that are never used
Issue 4019: GCPR issue: Exceptions

Issue 2936: alternative verbs for Federated access and put_obsevations (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

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.

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.

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

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 ;-)

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Missing a space.

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?

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.

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.

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.

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?

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

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.

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.

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.

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.

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.

This is not an issue.
They have been typedef correctly to refer back to the one required idl file called DsObservationAccess.idl

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.

exception InvalidCodes {
QualifiedCodeStrSeq codes;
};

exception InvalidIds {
ObservedSubjectIdSeq ids;
};

ObservationDataSeq get_observations_by_time (
in ObservedSubjectId who,
in QualifiedCodeStrSeq what,
in TimeSpan when,
in unsigned long max_sequence,
out ObservationDataIterator the_rest )
raises (
InvalidIds,
InvalidCodes,
DuplicateCodes,
InvalidTimeSpan );

For an exception like "patient not found" get_observations_by_time uses the InvalidIds exception to notify the user that there is a problem with the ObservedSubjectId that was passed in.  
Passing back an empty "any" indicates, "no results found"
An exception for "unable to get access" could be interpreted as a security problem and should be handled through a security mechanism. 
An exception for "system down" can be handled when the client attempts to get a handle to the server.
When the submitters were working on this specification exceptions were of concern as to how in depth we should go. There were multitudes of possibilities that the submitters felt were to extension to list and based on the usage could be very extensive.
What was discussed and remains today, is that; what is really needed is a robust Error Handling Facility that could be used to catalog and provide textual messages for clients to display to their users providing run-time and administrative capabilities that all submissions could use. This would provide a more extensible solution to the never-ending possibilities of exceptions. This, of course, is out of scope for this submission.
The submitters encourage those who have a burning desire to pursue the topic of error handling to bring solutions forward to the OMG and see where such a facility may fit in.