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 3119: new conformance classes and the Naming Service
Issue 3136: typedefs for TimeStamp and TimeSpan that are never used
Issue 4018: GCPR Project issue: Delivering Observation Data
Issue 4019: GCPR issue: Exceptions
Issue 4020: GCPR issue: Asynchronous COAS
Issue 4021: GCPR Issue: Event Interface Enhancements
Issue 4022: GCPR Issue: Using Relational Operators
Issue 4023: GCPR issue: Updating IDL for Examples
Issue 2936: alternative verbs for Federated access and put_obsevations (coas-ftf)
Click here for this issue's archive.
Source: Level Seven Visualizations (Mr. Jon Farmer, jon(at)level7vis.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.
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. * ...
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
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 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.
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.
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.
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.
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.