The DRM uses a flexible and standards-based approach to describe the categorization, exchange, and structure of data. (2IWE)
The categorization of data is achieved through the use of the BRM as the organizational construct for identifying the data’s business context. (2IWF)
The exchange of data is facilitated through the information exchange package and describes a packaged set of data categorized into a message that can be re-used by other users. The specific standards associated with this concept will be defined in future volumes of the DRM. (2IWG)
In the DRM, a common approach to the structure of data is realized through an adaptation of the ISO/IEC 11179 standard as a guide. This standard provides the structure by which data can be defined in terms of its business context. The common structure implements a basic set of constraints and requirements while providing agencies the flexibility to use the DRM in a way that is consistent with their own business needs. (2IWH)
The DRM addresses business needs through its common approach to the categorization, exchange, and structure of data. Exhibit E illustrates the DRM’s approach in the context of an example involving organizations that provide health services. Through this example, one can see how the common categorization, exchange, and structure of data will allow agencies engaged in health services to share data regarding a variety of topics in a common way. (2IWI)
Categorization of Data (2J0E)
Leveraging the BRM, categorization is achieved through the use of the BRM’s subfunction. Use of the BRM’s sub-function establishes the business context of a given set of data. (2IWL)
Note: The categorization of subject areas at the Line of Business (LoB) level does not imply that data is applicable only within a line of business. Future volumes of the DRM will address the categorization and exchange of data across LoBs. (2IWM)
Line of Business: Many organizations within the federal government provide services that contribute to the health of citizens and residents of the United States of America. These organizations are part of the Health LoB within the Services for Citizens business area (from the BRM). The LoB represents organizations that have a common business or program interest. The organizations in this case include federal programs and activities that ensure and provide for the health and well-being of the public. (2IWN)
Note: Line of Business categories are obtained from the BRM. (2IWO)
Subject Areas: Organizations within the Health LoB perform many business activities. One of these activities is population health management; this is equal to the DRM’s subject area. The subject area is the first element used to represent the business context of a particular set of data. Population health management involves activities associated with the management and monitoring of health, health planning, and health management. Population health management is a sub-function and is located under the Health LoB within the BRM. BRM sub-functions are supported by lower-level activities that represent more detailed views of the business function. For example, immunization is an activity supporting the BRM sub-function of population health management. (2IWP)
Note: Sub-functions are obtained from the BRM. (2IWQ)
Super Types: Super types represent lower level business activities that represent data that is used in support of the subject area. Super types provide an additional level of detail regarding the subject area. In the example illustrated in Exhibit E, the super type is an immunization which represents an activity in support of the population health management subject area. (2IWR)
Note: Super types are obtained from agency EA. Future volumes of the DRM will address the process of identifying super types from agency EAs. (2IWS)
Exchange of Data (2IWT)
Data that is categorized around a particular business context can be exchanged in support of a business function or process. The DRM uses the information exchange package as a structure to enable the exchange of data: (2IWU)
Information Exchange Package: The information exchange package represents a set of data that is transmitted for a specific business purpose. It makes use of the ISO/IEC 11179 concept of Information Interchange. (2IWV)
The information exchange package is used to fulfill business requests that make use of agency business processes. In this scenario, the information exchange package provides data resulting from a business process that is engaged in supporting the population health management BRM sub-function. The actual content of the information exchange package is dependent upon the particular business process accessed. In this case, it could communicate information about immunization records and/or disease characteristics. (2IWW)
Structure of Data (2IWX)
Structured data has the standards and definitions necessary to describe the data that is associated with a business context. The Data Element concept is used to structure data within the DRM. To clarify the business context of a particular set of data, the subject areas and super types of the data set are supported by additional levels of detail described within the data element. A collective set of three layers, the data element enables a more accurate description of the business purpose of the data. It is consistent with the ISO/IEC 11179 standard and includes a Data Object, a Data Property, and the Data Representation. In practical terms, the data element provides a set of information that is used in a given business context. (2IWY)
Data Element: A data element is a representation of a data object, a data property, and a data representation. The data element defines a particular concept or item that is of interest within the super type. (2IWZ)
Data Object: In describing the super type of immunization, it is necessary to more specifically define the particular concept or item that is of interest within the immunization super type. This item is called a data object, and, in this scenario, represents a vaccine. The vaccine represents a particular item of interest within the super type of immunization. (2IX0)
Data Property: The DRM uses a data property to distinguish or describe the actual vaccine. The data property represents the elements used to describe an object and can include characteristics such as type, weight, potency, etc. In this scenario, the data property is the name of the vaccine. (2IX1)
Data Representation: The DRM uses a data representation or value domain to represent the type of value that can be associated with the data element. Representation values can include integers, whole numbers, dollars, etc. In the case of vaccine, the value is plain text. (2IX2)
Security and Privacy (2IX3)
The successful categorization, exchange, and structure of data are dependent on the implementation of security regarding the data being exchanged. Security requirements must be considered at each level of the DRM and, in particular, regarding the exchangeof-data transaction. The DRM is designed to allow for the integration of existing federal information security and privacy policies within each of its elements. It provides for this integration through its common approach and use of standards. Exhibit F generally describes the relationships between the DRM and several sets of security/privacy policies and legislation. (2IX4)
Exhibit F: DRM - Policy and Legislation Relationships (2IX5)
========================================================================================================= (2JRI)
Comments (2JRJ)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX3 (2JRK)
- Comment: With respect to Security and Privacy, it is recognized that security will be addressed in Volume III (Technical Data Standards). However there are serious concerns regarding security and privacy policies and issues as currently reflected in Volume I. Security and privacy needs, and the Information Systems Security Officer’s (ISSO) involvement, should be articulated to some degree in Volume I and expanded on in later DRM volumes. Some items the DRM must address include the following: (2JRL)
- While some data should not or cannot be shared, some data can be shared. The same level of security/privacy controls must be placed on it by those wanting to share it just as the owning organization has placed on it. (2JRM)
- The principles and requirements established under HSPD 12, specific to the levels of access. (2JRN)
- It is acknowledgesd that constraints should be recognized in the DRM, beyond those mentioned. This should include legal constraints on taxpayer-related data, intelligence data, and health and financial data as mandated by various laws. (2JRO)
- Somewhere in the description of the data itself, there must also be a description of its sensitivity, privacy constraints, and possibly any required controls. (agency comment / compiled 2004.12.06) (2JRP)
- Comment: With respect to Security and Privacy, it is recognized that security will be addressed in Volume III (Technical Data Standards). However there are serious concerns regarding security and privacy policies and issues as currently reflected in Volume I. Security and privacy needs, and the Information Systems Security Officer’s (ISSO) involvement, should be articulated to some degree in Volume I and expanded on in later DRM volumes. Some items the DRM must address include the following: (2JRL)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX3 (2JTY)
- Comment on Data Security and Privacy: With the rate of computer crime on the raise, there is a definite need for the DRM to address the concepts of security and privacy if data exchange is to be successfully achieved with minimal risks. Agencies must evaluate the sensitivity of the data to be exchanged along with the extent of their current controls in order to appropriately secure data against loss, misuse, unauthorized access or modification. Even though the Federal CIO Council (CIOC) has completed a FEA Security and Privacy Profile, which is to be embedded within the FEA Reference Framework, there is no mention of this guideline in the DRM. This would seem to be contradictory to the guidelines themselves in that “…the guidelines urge thinking about data privacy and data security as early as possible and at the highest levels possible.” The DRM needs to mention the security and privacy guidelines that are being developed as an overlay to the FEA reference framework, along with the need for agencies to be consistent with the requirements of the Federal Information Security Management Act (FISMA). (agency comment / compiled 2004.12.06) (2JTZ)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX3 (2K2L)
- Comment: The section on Security and Privacy is also not very helpful other than to identify sources of policy. (agency comment / compiled 2004.12.06) (2K2M)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX3 (2K39)
- Comment: It states that "Security requirements must be considered at each level of the DRM..." it’s not particularly obvious how security requirements apply to the top level or "Categorization of Data". Need to expand on how security requirements must be considered at each level of the DRM. (agency comment / compiled 2004.12.06) (2K3A)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX3 (2KG0)
- Comment: Security Concerns Under-represented. The DRM-I does not appear to adequately address security considerations respective to interoperability, especially for agencies that traditionally have little or no experience with interagency sharing of high security data, in contrast to the established community and protocols for sharing classified information in DOD. Security is left for a future volume. While Exhibit F Policy and Legislation Relationships, indicates that all of the DRM is applicable to various, intertwined security policies, it doesn’t provide any insight into exactly what that interrelationship is. When a system undergoes a security risk assessment, different transactions within a process at that level of aggregation (one below sub-function) have different security implications/needs. Different parts of the data have very different security constraints that transcend the transaction (e.g., social security number, medical history, etc). (agency comment / compiled 2004.12.06) (2KG1)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2J0E (2JVH)
- Comment: The DRM's Categorization of Data also uses the BRM for classification purposes, which in FY05, prescribes the Lines of Business (LOB)agencies can use. This could limit the relevancy of the DRM when applied to a true "Mode of Delivery" operating unit. (agency comments / compiled 2004.12.06) (2JVI)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2J0E (2K2F)
- Comment: The BRM does not go down to the level needed to get into the "Real World" of data that flows across communities of interest and vertically among local, tribal, state and federal entities. Much work needs to be done if the LOB Concept is to be extended to deal with intergovernmental flow of information - particularly if the concept of Categorization/ Classes is to extend to state/local levels. (agency comment / compiled 2004.12.06) (2K2G)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2J0E (2LVW)
- Comment: In the DRM briefing, the concept of vertical and horizontal exchanges of data are presented. Horizontal is described as across federal agencies and vertical as described as federal down to state, then local. These descriptions omit industry which is a critical partner to the government both in terms of conducting business as well developing IT that will utilize FEA/DRM concepts. It also omits other governments and multinational organizations such as IMF, NATO and the UN. Another view of horizontal vs. vertical is to consider the LOBs as horizontal and the SRM elements (e.g., Supply Chain Management) as vertical. The core component methodology can create components that can be re-utilized across both axes. (agency comment / compiled 2004.12.06) (2LVX)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWN (2JW6)
- Comment: The DRM links to the Business Reference Model (BRM) starting at the Line Of Business (LOB) level. The BRM highest level is the Business Area, next the LOB, and finally the sub-function. It is recommended that linkages begin at the Business Area level. (agency comment / compiled 2004.12.06) (2JW8)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWH (2JWV)
- Comment: The DRM cites and is modeled after ISO 11179. The approach used by the DRM to represent business functions from the BRM (i.e., Categorizations of Data); however, deviates from ISO 11179. The reason for this deviation is unclear, as the ISO 11179 model for value domains could be used to represent BRM business functions. This change has caused the DRM to lose most of the semantic model established in ISO 11179. Unless a strong argument can be made to the contrary, the DRM should simply adopt the ISO Metadata Registries Framework (i.e., 11179 Part 1).(agency comments / compiled 2004.12.06) (2JWX)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWY (2JXS)
- Suggest changing the first sentence from: Structured data has the standards and definitions necessary to describe the data that is associated with a business context. (2JXT)
- Changing it to read: The Structure of the Data component of the DRM includes the standards and definitions necessary to describe the data that is associated with a business context. (agency comment / compiled 2004.12.06) (2JXU)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWY (2JXV)
- Suggest changing the last sentence from: In practical terms, the data element provides a set of information that is used in a given business context. (2JXW)
- Changing it to read: In practical terms, a data element is a unit of information that is used in a particular business context. (agency comments / compiled 2004.12.06) (2JXX)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWY (2K3I)
- The DRM’s input on the “Categorization of Data” calls for the mapping of the BRM constructs of functions, activities, and processes to agency data assets. As a result, the DRM contends that data will be more readily identified, and therefore shared. The following comments express concern with this approach. (2K3J)
- Comment 1: In a number of places throughout Volume I and in the following two sentences of this paragraph, the draft DRM seems to advocate the definition of data in a functional way “To clarify the business context of a particular set of data, the subject areas and super types of the data set are supported by additional levels of detail described within the data element. A collective set of three layers, the data element enables a more accurate description of the business purpose of the data.” Is this intentional? It appears to contradict long-standing data design principles to identify and define data independent of function. (2K3K)
- Comment 2: In addition, there are related concerns about this sentence three paragraphs up under Exchange of Data: “Data that is categorized around a particular business context can be exchanged in support of a business function or process.” Why does data become exchangeable because it “is categorized around a particular business context”? It would seem that data not categorized along business function or activity is equally, if not more, exchangeable. Data that is “packaged” based upon one LOB’s business function or activity may also include incorrectly identified, unneeded, irrelevant, or redundant data. The “receiving” LOB could, and would, have their own “business context” for the needed data, and therefore would not be interested in another LOB’s functions or activities as a categorization method of data. They may only want very modular/atomic data, independent of another LOB function, and therefore are not interested in another LOBs “business context”. (2K3L)
- Comment 3: The DRM’s input on the “Categorization of Data” calls for the mapping of the BRM constructs of functions, activities, and processes to agency data assets. As a result, the DRM contends that data will be more readily identified, and therefore shared. The following comment express concern with this approach. The Draft DRM advocates categorizing data based on the BRM which is a functional orientation toward categorization. This appears to couple function and data closely. Practitioners of data design have learned to name and define data independently of function so that data can be used by any appropriate function (also known as - stored once, used many times). It is not clear in the draft DRM whether the BRM will be used for more than categorization or classification, or whether the BRM constructs to identify or name data constructs (data objects and data elements in particular). Naming or defining data from a functional perspective will usually embed function with data at times. (2K3Q)
- There is a many-to-many relationship between functions (or processes) and data objects and/or data elements. While a functional classification or categorization can be useful as a navigation tool (or a way to find data), it is not used to define or name data. (2K3N)
- A data or object oriented categorization or classification is not only useful, but also more rigorous and can be non-redundant. In that sense, it can approach the characteristics of a biological taxonomy. The relationship between a higher level data construct (such as a subject area as defined in information engineering) and a data object and/or data element is most often, or nearly always, one to many. This leads to a non-redundant categorization or classification of data. (2K3O)
- If a functional classification of data is needed, consider augmenting a data classification of an organization’s data with an additional classification scheme based on function. (2K3P)
- Comment 4: A result of data categorized within a hierarchy based on how the data is used, viewed, and/or reported, is that data is then categorized within a specific operational perspective, and at a current point in time. This approach may not be conducive for other agencies, with different business views on the data, to identify and locate this data. To identify an item categorized on function will compel the “searching” agency to obtain an understanding of, and navigate through, the “categorizing” agency’s functions and business processes involved. It is recognized that standard 11179 allows for multiple classifications of data. We can see the potential need for multiple classifications and recognize the maintenance burden of maintaining each data classification scheme (keeping the mappings current as constructs change). (2K3V)
- Comment 5: Since the same data can be created, updated, and deleted by numerous processes, identifying data via a functional hierarchy will invariably result in data being located via several access paths, which could be confusing. Also, if numerous processes interact with data, locating the needed data could be time consuming. In addition, since each access path will result in a different lowest level business process, the resulting data could again be more or less than what is actually needed. In our work, we have seen functionally oriented classifications of data and they can be quite complex with a large number of relationships or mappings of functions/processes to data. Unless done carefully, we have found this can make it more difficult for a user to find their data. (2K3W)
- Comment 6: Since the same data can be created, updated, and deleted by numerous processes, identifying data via a functional hierarchy will invariably result in data being located via several access paths, which could be confusing. Also, if numerous processes interact with data, locating the needed data could be time consuming. In addition, since each access path will result in a different lowest level business process, the resulting data could again be more or less than what is actually needed. In our work, we have seen functionally oriented classifications of data and they can be quite complex with a large number of relationships or mappings of functions/processes to data. Unless done carefully, we have found this can make it more difficult for a user to find their data. (agency comment / compiled 2004.12.06) (2K3X)
- The DRM’s input on the “Categorization of Data” calls for the mapping of the BRM constructs of functions, activities, and processes to agency data assets. As a result, the DRM contends that data will be more readily identified, and therefore shared. The following comments express concern with this approach. (2K3J)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWF (2K0K)
- Comment: The DRM should indicate how the DRM is related and linked to the PRM, SRM, and TRM. The relationship to the BRM is documented in the next several paragraphs, however further clarification is needed for the other reference models. (2K0L)
- Suggested Action: As illustrated in this graphic, provided by former Chief Architect Bob Haycock, please provide guidance on how the DRM maps to these models. (agency comments / compiled 2004.12.06) (2K0M)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWF (2JWT)
- Comment: The DRM does not define currently, nor does there seem to be plans to define, what methods will be used to manipulate data other than to link the DRM to the Business Reference Model (BRM). (agency comment / compiled 2004.12.06) (2JWU)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWF (2K2D)
- Comment: We believe there is a need for distributed authorities for categorization and definition of meaning for messages. According to the DRM, all categorization is defined via business contexts, as defined by the FEA BRM. This implies a single authority for categorization, via the centralized list of business contexts, rather than deriving meaning from a larger number of sources. (agency comment / compiled 2004.12.06) (2K2E)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWF (2K2H)
- Comment: Business contexts, tied to a hierarchical BRM, are not a practical way of providing context for data in the real world. The document mentions some reasons (BRM is too high-level, it's only one aspect of many with which to describe context, etc.), we would like to add that there is a simpler approach that works well - using functional context. To illustrate what we mean, think of an address: it is easier to provide context in terms of its function (mailing address, residence address, or GIS spatial location) rather than the business area (human resources, law enforcement, etc.). The business area is helpful for some degree of categorization, but should not be seen as providing anything but the minimum level of context. For many common types, business area provides almost zero context. (agency comment / compiled 2004.12.06) (2K2I)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWT (2K1C)
- Comment: It would be useful to address how someone building an information exchange package might go through the whole process of Discovery and building the Information Exchange Package based on querying Lines of Business Categorizations/ Classes and then being led to Data Element Representations, etc. (agency comments / compiled 2004.12.06) (2K1D)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWT (2K1E)
- Comment: There are several aspects to information sharing: (2K1F)
- The meaning of the message (2K1G)
- What information is being conveyed? People use ontologies, taxonomies, dictionaries, and other methods to help define the meaning of information. (2K1R)
- The structure of the message (2K1J)
- How is the message organized? How is the information grouped into useful blocks, to enable building and understanding of messages? How is an object defined, and how are its parts defined? (2K1S)
- The exact syntax of the message (2K1M)
- What is the exact allowable content of a message? What is the exchange language? There are numerous different syntaxes possible for any given logical organization of a message. (2K1O)
- The meaning of the message (2K1G)
- The DRM defines the "structure of data" to be the construction of basic, semantic-free data objects. It defines the "categorization of data" to be the categorization of data according to "business contexts" defined by the BRM. This is a gross simplification of what is really required to convey meaningful messages across diverse communities. (agency comment / compiled 2004.12.06) (2K1Q)
- Comment: There are several aspects to information sharing: (2K1F)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWT (2JWG)
- Comment: More clarification is needed on how the Information Exchange Package will work. The brief explanation in the document does not provide sufficient details on how it is created and how XML technology will be utilized. (agency comment / compiled 2004.12.06) (2JWH)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWT (2K2P)
- Comment: The "Exchange of Data" in this section is difficult to follow. The basic understanding is there, however, it is unclear what the intent of this section is. The approach, the format, design, etc. need to be clearer. For example, the illustration of the exchange package concept in Exhibit D is not consistent with the example given in http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/Exhibit_E_Example_DRM_VolIv1#nid2IZS Exhibit E]. But then the "exchange package" in Exhibit H really doesn't correlate to either of the prior two. In short, this section still needs a lot of thought. (agency comment / compiled 2004.12.06) (2K2Q)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWG (2K46)
- Comment: Some examples or more specifics about an Exchange Package would help explain and provide context. The draft DRM is not clear. (agency comment / compiled 2004.12.06) (2K47)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWG (2K48)
- Comment: Some agencies are making use of international data standards activities including an extended version of the Aeronautical Information Exchange Model (AIXM) from Eurocontrol, data standards in development from the Commercial Aviation Safety/ICAO Common Taxonomy Team, Geospatial One-Stop, and other data initiatives. It is suggested that the DRM emphasize the value of making use of data standards that have a larger domain, either across the US, internationally, or inter-governmentally. (agency comment / compiled 2004.12.06) (2K49)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWR (2K4K)
- Comment: The DRM calls for repeating BRM constructs as the basis for the DRM Subject Areas and Supertypes. That appears to be redundant. If you need mapping of data objects to BRM constructs, then can you require that without having redundant constructs in the DRM. (agency comment / compiled 2004.12.06) (2K4L)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWR (2LVQ)
- Comment: The DRM Approach appears to drop from the high level of broad categorization of Subject Area and Super Type (the first two levels of the BRM) and then immediately down to Information Exchange Packages (transactions) and Data Elements. In doing this, it appears to skips over the important business process layer (although perhaps super types are intended to be business processes). Business processes Footnote 16 are very important because they often create groups of transactions that are often similar and use many of the same elements and groups of elements. These groupings will make up a substantial portion of the DRM population. The following figure depicts a view of information layers from the business (enterprise) at the top down through the underlying infrastructure. It highlights the importance of business processes and their related IT systems. (2LVR)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWR (2JWE)
- Comment:Further clarification on "Super Type Entity" is needed. It is explained as a lower level of detail of the Subject Area. This is defined by the agency therefore it will not be a common taxonomy. This will make it difficult to achieve data harmonization across the federal government. (agency comments / compiled 2004.12.06) (2JWF)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX1 (2KGI)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IX1 (2KGL)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWP (2KGX)
- Comment: Supertype and Sub-area aren't clearly distinguished. Sometimes DRM-I implies that Super Type is a category of data (e.g., Exhibit C and the name which is data vs process oriented) and sometimes it is described as the next level of functional activity under Line of Business/ Sub-Function where supertypes is described as representing a lower level of business activity and use “immunization” as an example – it is clear from the context that this means the activities related to immunization within the sub area/sub-function of population health mgmt). Part of the problem is that the Sub Area/ Sub-Functions are still so high that they don’t do much to categorize data so it is necessary to drill down the business function to another level for it to be meaningful. (agency comment / compiled 2004.12.06) (2KGY)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWP (2KIJ)
- Comment: “Population Health Management” is not a a sub-function of the Health line of business; perhaps Public Health Monitoring was intended. (agency comment / compiled 2004.12.06) (2KIK)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWV (2LVS)
- Comment: We suggest introducing an important companion to ISO11179, and that is ISO 15000-5. This standard defines a modeling methodology and technique for defining core components. In general, core components are standardized “data elements” that can be re-used across many transactions. This international standard provides an excellent basis for developing the DRM Footnote 15 (agency comment / compiled 2004.12.06) (2LVT)