Clinical Observation Access Service Avatar
  1. OMG Specification

Clinical Observation Access Service — All Issues

  • Acronym: COAS
  • Issues Count: 31
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
COAS-35 COAS operations that return ObservationData COAS 1.0b1 COAS 1.0 Resolved closed
COAS-32 Pg. 193 Under section - D.3 Secure Interoperability Concerns COAS 1.0b1 COAS 1.0 Resolved closed
COAS-31 Pg. 208 Under section - 12.7 AbbreviatedCorba.idl COAS 1.0b1 COAS 1.0 Resolved closed
COAS-34 Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservatio COAS 1.0b1 COAS 1.0 Resolved closed
COAS-33 Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram COAS 1.0b1 COAS 1.0 Resolved closed
COAS-29 Pg. 145-152 Under section - 3.8.1-3.8.17 COAS 1.0b1 COAS 1.0 Resolved closed
COAS-28 Pg. 141 Under section - 3.7.1 General COAS 1.0b1 COAS 1.0 Resolved closed
COAS-26 Pg. 129 Under section - 3.5.4 Sequence Types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-25 Pg. 120 Under section - 3.4.2 Supporting Types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-24 Pg. 81 Under section - 3.3.2.5 Constants COAS 1.0b1 COAS 1.0 Resolved closed
COAS-36 typedefs for TimeStamp and TimeSpan that are never used COAS 1.0b1 COAS 1.0 Resolved closed
COAS-27 Pg. 133 Under section - 3.6.1 Genera COAS 1.0b1 COAS 1.0 Resolved closed
COAS-30 Pg. 153 Under section - 3.9 Conformance Classes COAS 1.0b1 COAS 1.0 Resolved closed
COAS-17 interfaces are presented in alphabetical order and not in logical order COAS 1.0b1 COAS 1.0 Resolved closed
COAS-16 Pg. 108 Under section - 3.3.3.13 FederatedAccess COAS 1.0b1 COAS 1.0 Resolved closed
COAS-20 Pg. 70 Under section -3.3.2.1 Include Files COAS 1.0b1 COAS 1.0 Resolved closed
COAS-19 Pg. 5 Under section - 3.1.5 BOCA & CDL COAS 1.0b1 COAS 1.0 Resolved closed
COAS-23 Pg. 79 Under section - 3.3.2.4.9 TimeStamp COAS 1.0b1 COAS 1.0 Resolved closed
COAS-22 Pg. 75 Under section - 3.3.2.4.3 ObservationData COAS 1.0b1 COAS 1.0 Resolved closed
COAS-15 Pg. 95 Under section - 3.3.3.5 AsynchCallBack COAS 1.0b1 COAS 1.0 Resolved closed
COAS-14 Pg. 92 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-12 Pg. 90 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-11 Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10 COAS 1.0b1 COAS 1.0 Resolved closed
COAS-18 Pg. 5 Under section - 3.1.4 Objects By Value (OBV) COAS 1.0b1 COAS 1.0 Resolved closed
COAS-21 Pg. 71 Under section - 3.3.2.1 Include Files COAS 1.0b1 COAS 1.0 Resolved closed
COAS-10 Pg. 86 Under section - 3.3.2.8 Exceptions COAS 1.0b1 COAS 1.0 Resolved closed
COAS-13 Pg. 91 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-7 alternative verbs for Federated access and put_obsevations COAS 1.0b1 COAS 1.0 Resolved closed
COAS-9 Pg. 81 Under section - 3.3.2.5 Constants COAS 1.0b1 COAS 1.0 Resolved closed
COAS-8 how to use HL7 data types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-37 GCPR issue: Exceptions COAS 1.0b1 COAS 1.0 Resolved closed

Issues Descriptions

COAS operations that return ObservationData

  • Key: COAS-35
  • Legacy Issue Number: 3042
  • Status: closed  
  • Source: 2AB ( Tim Brinson)
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Wed, 17 Nov 1999 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 193 Under section - D.3 Secure Interoperability Concerns

  • Key: COAS-32
  • Legacy Issue Number: 3011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 208 Under section - 12.7 AbbreviatedCorba.idl

  • Key: COAS-31
  • Legacy Issue Number: 3010
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservatio

  • Key: COAS-34
  • Legacy Issue Number: 3013
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram

  • Key: COAS-33
  • Legacy Issue Number: 3012
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 145-152 Under section - 3.8.1-3.8.17

  • Key: COAS-29
  • Legacy Issue Number: 3008
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 141 Under section - 3.7.1 General

  • Key: COAS-28
  • Legacy Issue Number: 3007
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 129 Under section - 3.5.4 Sequence Types

  • Key: COAS-26
  • Legacy Issue Number: 3005
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 120 Under section - 3.4.2 Supporting Types

  • Key: COAS-25
  • Legacy Issue Number: 2999
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    Missing a space.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 81 Under section - 3.3.2.5 Constants

  • Key: COAS-24
  • Legacy Issue Number: 2998
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typedefs for TimeStamp and TimeSpan that are never used

  • Key: COAS-36
  • Legacy Issue Number: 3136
  • Status: closed  
  • Source: Cognition Group, Inc. ( David Forslund)
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 133 Under section - 3.6.1 Genera

  • Key: COAS-27
  • Legacy Issue Number: 3006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 153 Under section - 3.9 Conformance Classes

  • Key: COAS-30
  • Legacy Issue Number: 3009
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interfaces are presented in alphabetical order and not in logical order

  • Key: COAS-17
  • Legacy Issue Number: 2991
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 108 Under section - 3.3.3.13 FederatedAccess

  • Key: COAS-16
  • Legacy Issue Number: 2990
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 70 Under section -3.3.2.1 Include Files

  • Key: COAS-20
  • Legacy Issue Number: 2994
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 5 Under section - 3.1.5 BOCA & CDL

  • Key: COAS-19
  • Legacy Issue Number: 2993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 79 Under section - 3.3.2.4.9 TimeStamp


Pg. 75 Under section - 3.3.2.4.3 ObservationData

  • Key: COAS-22
  • Legacy Issue Number: 2996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 95 Under section - 3.3.3.5 AsynchCallBack

  • Key: COAS-15
  • Legacy Issue Number: 2989
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 92 Under section - 3.3.3.3 AccessComponent

  • Key: COAS-14
  • Legacy Issue Number: 2988
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 90 Under section - 3.3.3.3 AccessComponent

  • Key: COAS-12
  • Legacy Issue Number: 2986
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10

  • Key: COAS-11
  • Legacy Issue Number: 2985
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 5 Under section - 3.1.4 Objects By Value (OBV)

  • Key: COAS-18
  • Legacy Issue Number: 2992
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 71 Under section - 3.3.2.1 Include Files

  • Key: COAS-21
  • Legacy Issue Number: 2995
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 86 Under section - 3.3.2.8 Exceptions

  • Key: COAS-10
  • Legacy Issue Number: 2984
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 91 Under section - 3.3.3.3 AccessComponent

  • Key: COAS-13
  • Legacy Issue Number: 2987
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

alternative verbs for Federated access and put_obsevations

  • Key: COAS-7
  • Legacy Issue Number: 2936
  • Status: closed  
  • Source: Level Seven Visualizations ( Jon Farmer)
  • 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

  • Reported: COAS 1.0b1 — Mon, 27 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 81 Under section - 3.3.2.5 Constants

  • Key: COAS-9
  • Legacy Issue Number: 2983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

how to use HL7 data types

  • Key: COAS-8
  • Legacy Issue Number: 2981
  • Status: closed  
  • Source: 2AB ( Tim Brinson)
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR issue: Exceptions

  • Key: COAS-37
  • Legacy Issue Number: 4019
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: COAS 1.0b1 — Mon, 6 Nov 2000 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    see above, issue rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT