CCOW Executive Summary Executive Summary Multiple Birth

Document Sample
CCOW Executive Summary Executive Summary Multiple Birth Powered By Docstoc
					From:     CCOW TC Co-Chairs                Date:        November 10, 2000
To:       HL7 ARB                          Subject:     CCOW Scope

Executive Summary

The Co-Chairs of the CCOW TC would like to attend the ARB teleconference scheduled
for December 14.

In preparation we have attached the existing CCOW mission statement (see attachment
A). This statement does not currently appear on the CCOW web page, as the statement on
the page is quite old and dates back to when CCOW was an independent consortium.
Nevertheless, the attached statement was created from text that appears existing HL7-era
CCOW documents.

The reason we would like to meet with the ARB is to discuss whether certain uses of the
CCOW Version 1.3 draft-standard specification for "annoation agents" would cause
CCOW to exceed its charter. These uses are discussed below, as well as arguments for
and against the intended uses.

We seek the guidance of the ARB with three possible outcomes:

1. The intended uses are within the charter of CCOW.

2. The intended uses are not within the charter of CCOW but the ARB grants CCOW
permission to broaden its charter.

3. The intended uses are not within the charter of CCOW and the ARB does not grant
CCOW permission to broaden its charter.

It is important to note that the issue is not whether the specification for annotation agents
would cause CCOW to exceed its charter, but rather whether certain intended uses of
annotation agents would do so.

CCOW Architecture Summary

CCOW works on the principle that applications are linked to context subjects, and remain
synchronized even as the subjects change. Each context subject represents an identifiable
real-world entity (e.g., patient) or concept (e.g., encounter). It is generally the case that
only an identifier for the context subject is needed in order to "set" the context.
Applications "get" this identifier and use it to access databases, etc., in order to retrieve
the application-specific data pertinent to the subject.
Application synchronization is managed by a context manager, which is a coordination
component that each application interfaces with. The context manager ensures that the
applications remain linked with each other, when in fact, they only actually interact with
the context manager. The overall process of changing the context is referred to as a
context change transaction, the protocol for which forms the foundation of the CCOW

Several components in addition to the context manager are also defined by CCOW. These
components generally plug into the context manager to provide enhanced capabilities.
Examples are mapping agents and annotation agents, summarized in the next section.

The core of the CCOW specification defines the messages that applications send to, a
receive from, the context manager. The specification also defines the data definitions for
each context subject. These definitions describe a context subject as a set of items, each
of which is represented as a name/value pair. Items for each subject are grouped as

   Identifiers – These are items that identify a real-world entity or concept. An example
   is a medical record number, used to identify a patient.

   Corroborating Data – These are items that applications, and sometimes users, may
   use to cross-check the value of an identifier. For example, a person’s name is
   corroborating data for the patient subject. While not used to identify a patient, it can
   be used to verify that the identifier is for the intended person.

   Annotation Data – These items represent information about a real-world entity or
   concept. For example, a home telephone number or next of kin representats
   demographics data for a patient.

The data definitions specify the set of items for each subject, and for each item, the
meaning of the item, its name, and data type used to represent the item’s value. Whenever
applicable, to date the items definitions have been leveraged from the HL7 2.3
specification, as this has been the most recently ratified HL7 specification.

Agents Overview

A mapping agent is a type of CCOW component, defined in CCOW Version 1.0, that is
responsible, during the course of a context change transaction, for automatically adding
identifier data to the clinical context maintained by the context manager. There can be a
mapping agent for each context subject. Mapping agents are optional.

For example, consider a patient mapping agent. If the user selects a patient of interest in
application X, then application X sets the patient context using the identifier by which the
patient is known to application X. If the other applications participating in the common
context do not necessarily identify patients using the same identifiers, then a patient
mapping agent may provide the additional identifiers automatically, whenever a patient is
selected. A patient mapping agent may be readily implemented using an EMPI.

An annotation agent is a new type of component, introduced in CCOW Version 1.3,
which is presently undergoing full membership ballot. Annotation agents are modeled
upon mapping agents.

Annotation agents are allowed to add data, as opposed to identifiers, to a context subject.
The objective is to enable the augmentation of the context with data in addition to
identifiers. Data may only be added to one of the subjects presently identified in the

For example, the user subject uses the user's logon name to identify the user. CCOW
V1.3 augments the user subject with the inclusion of the user's digital certificate. By
including the certificate in the context, all applications have the opportunity to use the
same digital credentials for the user, as opposed to a different certificate for each

As used in CCOW, a digital certificate does not identify the user but rather is data that
augments the user context, as maintained by the context manager. The certificate data is
automatically added into the context by a certificate annotation agent, whenever the user
context is set during the course of a context change transaction.

Intended Uses of Annotation Agents That Might Exceed CCOW's Charter

CCOW V1.3 originally included the specification for a patient demographics annotation
agent. Building upon the general CCOW specification of an annotation agent, this
particular agent was intended to add demographics data to the patient context whenever
the patient context is set. Applications would then be able to access the full demographics
data for the current patient from the context, in addition to the identifier for the patient.
The source of the demographics data would be the whatever is deemed to be the authentic
source for the enterprise, such as an EMPI or registration system. The data definitions as
originally specified for the demographics annotation appears in Attachment B.

The specification for the patient demographics annotation agent was removed from
CCOW V1.3 due to concerns that by incorporating demographics data into the context,
CCOW was moving beyond its charter for visual integration and context management,
and was infringing on the data exchange standards that have been the traditional purview
of HL7. However, the specification for an annotation agent remains in the specification,
because not all uses of an annotation agent elicit the same concerns. For example, using
an annotation agent as the source of a user’s digital certificate is not viewed as moving
CCOW beyond its charter.

   CCOW Is Exceeding Its Charter

    By adding demographics to the context, CCOW risks confusing application
    developers by presenting an alternative means to obtaining demographics data. Now
    developers will need to choose between traditional HL7 messaging interfaces and
    CCOW context sharing. Also, it may not be clear to developers as to which data
    source is the accurate source, as the answer may vary from site to site. Further, the
    incorporation of demographics could open the door to all types of clinical data being
    included into the context, further exacerbating the complexities of developing clinical
    applications. Finally, there are security and privacy considerations that need to be
    addressed, although CCOW’s existing security capabilities could be applied such that
    demographics data would only be accessible to authorized applications.

   CCOW Is Not Exceeding Its Charter

    CCOW has continued to adhere to the HL7-specified data and information models
    whenever these models were pertinent to the context subjects defined by CCOW.
    With the core value proposition of HL7 being its models, rather than the means for
    applying these models, the incorporation of demographics into the context is entirely
    consistent with HL7's overall mission. CCOW simply provides another means to
    access demographics, albeit not via traditional EDI-style messaging. The meaning
    and representation of demographics data within the context would continue to adhere
    to the current and future HL7 models. Further, the incorporation of context-sensitive
    data into the context provides application developers even more ways to benefit from
    HL7 standards. In particular, the inclusion of demographics data within the context,
    piloted at Duke University, is one of the most frequently requested CCOW
    enhancements within the vendor community.


We look forward to our discussion with the ARB. We realize that the teleconference may
not be conclusive, but it should at least enable us to establish a common understanding of
the issue confronting CCOW and HL7.
                                     Attachment A

                              CCOW Mission Statement


With an emphasis on the point-of-use of applications, the mission of the HL7 CCOW
Technical Committee is to define standards that enable the visual integration of healthcare
applications. Applications are visually integrated when they work together in ways that the
user can see in order to enhance the user’s ability to incorporate information technology as
part of the care delivery process.


Since its inception as an HL7 Technical Committee, CCOW has focused on specifying the
Context Management Standard. Context management entails the coordination and
synchronization of applications so that they are mutually aware of the set of common things –
known as the context - that frame and constrain the user’s interactions with applications.

The context is primarily comprised of the identity of real-world things, such as patients, and
real-world concepts, such as encounters, that establish the common basis for a consistent set
of user interactions with a set of healthcare applications. The elements of the context may be
provided directly by users as they interact with applications, or may be provided
automatically by underlying programmatic sources.

Specifically, the Context Management Standard defines a protocol for securely “linking”
applications so that they “tune” to the same context. The context is represented as a set of
subjects, each of which generally identifies a real-world entity such as a patient or a real-
world concept such as an encounter. Linked applications remain automatically synchronized
even when a context subject changes, for example, due to the user’s inputs (e.g., the user
selects a different patient). The user inputs of particular interest are those that are used to
identify something, such as medical record number for patients, or an account number for a
clinical encounter.


CCOW standards specify technology-neutral architectures, component interfaces, and data
definitions as well as an array of interoperable technology-specific mappings of these
architectures, interfaces, and definitions. It is the intent of CCOW that its standards may be
implemented using broadly accepted and/or industry standard computing technologies, with
emphasis on those that are most relevant to the HL7 membership. It is also the intent of
CCOW that its specifications provide all of the details needed to ensure robust and consistent
implementations of compliant applications and system services. However, CCOW does not
intend for its specifications to serve as an implementation or the design of an implementation.
                                         Attachment B

               Patient Subject Data Definitions, as Originally Proposed

Note: The data definitions for the identifier items and corroborating items for this subject
are unchanged since CCOW Version 1.0 was ratified. New for CCOW V1.3 is the
definition of annotation items for this subject.

Patient Subject
   The patient subject identifies a real world patient. A patient is a person who is subject to
   receive, is receiving, or has received healthcare services.

   The subject label for the patient subject is “Patient”.

   The patient subject is not a secured subject. Any application may set or get the patient

Patient Subject Dependencies
   The patient subject is not dependent upon any other subject.

Sharing Patient Context At a Site
   A particular real world patient may be identified at a site using one of several identifiers.
   Further, some of these identifiers may represent the same conceptual concept, but may
   nevertheless have different values for different applications. For example, various
   applications may use the concept of a medical record number as the means for identifying
   patients, but may nevertheless employ different medical record number values to represent
   the same people.

   Therefore, in the specification of the patient subject certain context subject identifier items
   may be differentiated by a site-defined suffix. A Patient Link-enabled application shall be
   configurable such that it can be configured on-site as to which suffix (or suffices) it is to use
   when it interacts with the context manager to set or get patient context data. This suffix may
   be the name of a locale, facility, application, or other sensible identifier, such that the
   “context” for interpreting the patient context data can be readily represented.
Standard Patient Context Data Items
   The standard context data items for the patient subject are specified below.

Patient Subject                              HL7 Meaning       HL7          HL7 Semantic           Case
Identifier Item Name                                           Data         Constraints on         Sensitive
                                                               Type         Values
Patient.Id.MRN.Suffix                        Patient’s medical ST           HL7 Table 0203         No
                                             record number,                 Identifier Type =
                                             per PID-2                      MR

Patient.Id.MPI                               Patient’s             ST       HL7 Table 0203         No
                                             identifier in the              Identifier Type =
                                             “Master Patient                PT or PI (as
                                             Index”, per PID-               agreed upon by
                                             2                              context sharing
                                                                            systems) and
                                                                            represents the
                                                                            MPI system
Patient.Id.NationalIdNumber                  Patient’s national ST          HL7 Table 0203         No
                                             identifier                     Identifier Type =
                                             number, per                    PT and Assigning
                                             PID-2                          Authority
                                                                            represents agreed
                                                                            upon National

Patient.Id.Alternate.Suffix                  Alternate patient ST           HL7 Table 0203         No
                                             identifier, per                Identifier Type not
                                             PID-2, PID-3,                  = DL or SS
                                             PID-4, or PID-18
                                             as agreed to by
                                             context sharing

   An application shall set a value for at least one of items defined above whenever it sets the
   patient context.
Patient Subject                             HL7 Meaning          HL7       HL7 Semantic         Case
Corroborating Item Name                                          Data      Constraints on       Sensitive
                                                                 Type      Values
Patient.Co.PatientName                      Patient’s legal      XPN       Table 0200           No
                                            name, per PID-5

Patient.Co.AliasName                        Alias name for       XPN       Table 0200           No
                                            the patient, per
Patient.Co.DateTimeOfBirth                  Patient’s Date       TS        None                 No
                                            and time of birth,
                                            per PID-7
Patient.Co.Sex                              Patient’s gender,    IS        Table 0001           No
                                            per PID-8
Patient.Co.DLN                              Patient’s driver’s   DLN       None                 No
                                            license number,
                                            per PID-20
Patient.Co.SSN                              Patient’s Social     ST        None                 No
                                            Number, per

   An application may optionally set a value for items defined above when it sets the patient
Patient Subject                     Repeat   HL7               HL7    HL7         Case
Annotating Item Name                         Meaning           Data   Semantic    Sensitive
                                                               Type   Constraints
                                                                      on Values
Patient.An.PatientName.Suffix        Yes     Patient’s legal   XPN    Table 0200 No
                                             name, per

Patient.An.MothersMaidenName.Suff    Yes     Patient’s         XPN    Table 0200   No
ix                                           mother’s
                                             maiden name,
                                             per PID-6
Patient.An.DateTimeOfBirth            No     Patient’s date    TS     None         No
                                             and time of
                                             birth, per
Patient.An.Sex                        No     Patient’s         IS     Table 0001   No
                                             gender, per
Patient.An.AliasName                 Yes     Alias name        XPN    Table 0200   No
                                             for the
                                             patient, per
Patient.An.Race.Suffix               Yes     Patient’s race,   IS     Table 0005   No
                                             per PID-10
Patient.An.Address.Suffix            Yes     Address of        XAD    Table 0190   No
                                             residence, per
Patient.An.CountyCode                 No     County of         IS     Table 0289   No
                                             residence, per
Patient.An.PhoneNumberHome.Suffix    Yes     Patient’s         XTN    None         No
                                             number, per
Patient.An.PhoneNumberBusiness.Su    Yes     Patient’s         XTN    None         No
ffix                                         business
                                             number, per
Patient Subject                     Repeat   HL7               HL7    HL7         Case
Annotating Item Name                         Meaning           Data   Semantic    Sensitive
                                                               Type   Constraints
                                                                      on Values
Patient.An.PrimaryLanguage            No     Patient’s         XTN    Table 0296 No
                                             language, per
Patient.An.MaritalStatus              No     Patient’s         IS     Table 0002   No
                                             marital status,
                                             per PID-16
Patient.An.Religion                   No     Patient’s         IS     Table 0006   No
                                             religion, per
Patient.An.PatientAccountNumber       No     Patient’s         ST     None         No
                                             number, per
Patient.An.SSN                        No     Patient’s         ST     None         No
                                             Number, per
Patient.An.DLN                        No     Patient’s         DLN    None         No
                                             number, per
Patient.An.MothersIdentifier.Suff    Yes     Identifier for    ST     Table 0124   No
ix                                           patient’s
                                             mother (e.g.,
                                             if patient is a
                                             newborn), per
Patient.An.EthnicGroup.Suffix        Yes     Patient’s         IS     Table 0189   No
                                             ethnic group,
                                             per PID-22
Patient.An.BirthPlace                 No     Patient’s birth   ST     None         No
                                             place, per
Patient Subject                               Repeat     HL7                HL7      HL7         Case
Annotating Item Name                                     Meaning            Data     Semantic    Sensitive
                                                                            Type     Constraints
                                                                                     on Values
Patient.An.MultipleBirthIndicator                No      Indicator of       IS       Table 0136 No
                                                         patient is part
                                                         of multiple
                                                         birth, per
Patient.An.BirthOrder                            No      Patient’s birth    NM       None         No
                                                         order, per
Patient.An.Citizenship.Suffix                   Yes      Patient’s          IS       Table 0171   No
                                                         per PID-26
Patient.An.VeteranMilitaryStatus                 No      Patient’s          IS       Table 0172   No
                                                         status, per
Patient.An.Nationality                           No      Patient’s          IS       Table 0212   No
                                                         per PID-28
Patient.An.DeathDateTime                         No      Patient’s          TS       None         No
                                                         death date and
                                                         time, per PID-
Patient.An.DeathIndicator                        No      Indicator of       IS       Table 0136   No
                                                         patient death,
                                                         per PID-30

     An application may optionally set a value for items defined above when it sets the patient

     When present, the suffix shall be formed as defined in Section 1.5, Repeating Annotating
     Data Items.
Examples of Patient Subject Items
   Below are examples of patient subject items:

Example Item Names                                Example Item Values
Patient.Id.MPI                                    001KM002130-JJXXX-98
Patient.Id.MRN.St_Elsewhere_Clinic                SEC-KMAR-00hjd7792
Patient.Id.MRN.St_Somewhere_Clinic                SSC-KMAR-00WSB887455
Patient.Co.DateTimeOfBirth                        19580317
Patient.Co.PatientName                            Marchant^Kyle^^^^
Patient.An.MaritalStatus                          M

Shared By:
Description: CCOW Executive Summary Executive Summary Multiple Birth