Clinical Observation Access Service Avatar
  1. OMG Specification

Clinical Observation Access Service — Open Issues

  • Acronym: COAS
  • Issues Count: 6
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

GCPR issue: Updating IDL for Examples

  • Key: COAS-6
  • Legacy Issue Number: 4023
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR Issue: Using Relational Operators

  • Key: COAS-5
  • Legacy Issue Number: 4022
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR Issue: Event Interface Enhancements

  • Key: COAS-4
  • Legacy Issue Number: 4021
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR issue: Asynchronous COAS

  • Key: COAS-3
  • Legacy Issue Number: 4020
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR Project issue: Delivering Observation Data

  • Key: COAS-2
  • Legacy Issue Number: 4018
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

new conformance classes and the Naming Service

  • Key: COAS-1
  • Legacy Issue Number: 3119
  • Status: open  
  • Source: Philips Electronics ( Charles Carman)
  • Summary:

    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.
    • ...
  • Reported: COAS 1.0b1 — Wed, 15 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT