(Pdf) of Metadata Standards for Semantic Interoperability In

Total Page:16

File Type:pdf, Size:1020Kb

(Pdf) of Metadata Standards for Semantic Interoperability In Metadata Standards for Semantic Interoperability in Electronic Government Jim Davies, Steve Harris, Charles Crichton, Aadya Shukla, and Jeremy Gibbons Software Engineering Programme, University of Oxford Wolfson Building, Parks Road, Oxford OX1 3QD, UK [email protected] ABSTRACT a greater degree of ownership or control over the develop- Effective data sharing, across government agencies and other ment. Standards are the means by which electronic govern- organisations, relies upon agreed meanings and representa- ment can achieve interoperability across departments and tions. A key, technological challenge in electronic gover- agencies, improve their management of supplier contracts, nance is to ensure that the meaning of data items is accu- and ensure that key data remains accessible over time. rately recorded, and accessible in an economical—effectively, Standardisation activity in software was originally focussed automatic—fashion. In response, a variety of data and meta- upon language and protocol design: upon the intended in- data standards have been put forward: from government terpretation of programming statements, and upon the con- departments, from industry groups, and from organisations crete representation of data and commands. Since then, such as the ISO and W3C. there has been a pronounced shift in focus towards metadata This paper shows how the leading standard for metadata standards: descriptions of intended functionality and mean- registration—ISO 11179—can be deployed without the need ing that can be associated with particular items of data, in for a single, monolithic conceptualisation of the domain, and order to ensure a consistent treatment and interpretation. hence without the need for universal agreement upon a par- Initial work in this area was motivated by the concerns of ticular model of electronic governance. The advantages of document management: the widely-used Dublin Core stan- this approach are discussed with regard to the UK eGovern- dard, for example, is a collection of metadata items address- ment Interoperability Framework (eGIF) and the UK Inte- ing issues such as the authorship, format, intended audience, grated Public Sector Vocabulary (IPSV). and availability of information resources. Subsequent work has been focussed upon the data within documents, most notably, within the messages sent between different systems 1. INTRODUCTION in business [5] and healthcare [8]. Standards can have an important role to play in software de- The importance of metadata standards at the level of indi- velopment: by adhering to a published standard, we might vidual data elements has already become apparent in these hope that our applications or data would prove immediately and other domains: for example, compatible with those produced by others: for example, if − The NASA Mars Climate Orbiter [11] was lost after we use tags only as allowed by an earlier HTML standard, messages between two different systems were we might be confident that our web pages would render suc- misinterpreted: the first was sending values in US cessfully in a wide range of browsers. Customary units (lbf-s), the second assumed that the In industry, there may be a competitive advantage in not values arriving were measured in SI units (Ns); the following a standard: the benefits of compliance can be eval- result was an initial orbit 170km lower than uated in purely commercial terms, and it may well be that planned—23km below survivable height. they do not justify the costs. Suppliers will often add new features, adopt different interpretations, or omit certain as- − US Government compliance data on water quality pects of a standard to reduce costs, to improve performance, near industrial waste sites had to be re-evaluated or to make it more difficult for customers to use products when it was discovered that ‘rate of flow’ had been from other suppliers. taken to mean the rate of flow of waste by some In electronic government, the situation is reversed: it is teams, while others had taken it to mean the rate of often more important to work to agreed standards than to flow of the waterway [7]. reduce costs, improve performance, or to seek to establish Although in either case, misunderstandings could have been discovered earlier—and remedied—through improved com- munications, review and management activities, this kind of expensive mistake is hard to avoid when data is processed Permission to make digital or hard copies of all or part of this work for and integrated automatically, and its semantic consistency— personal or classroom use is granted without fee provided that copies are the compatibility of units, and of intended interpretation—is not made or distributed for profit or commercial advantage and that copies checked only manually. bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00. The need to record and promote—and where possible, The approach to data semantics taken in the standard is automate—the re-use of standard metadata elements across characterised by the notion of data element, characterised enterprises and initiatives has led to the establishment of by a combination of: metadata registries, for example: − a data element concept, corresponding to a property − the Intelligent Transport Systems metadata registry, of an object class; a repository of data definitions and models for − a value domain, corresponding to a set of values that transport initiatives, currently being used by the UK may be assigned to this concept, described in terms Highways Agency to improve the quality of standards of a conceptual domain. under development, such as the European DATEX II specification for travel information [15]; The notions of property and object class are only loosely defined: it is left to the implementer to decide upon their − the National Information Exchange Model (NIEM) precise interpretation. maintained by the US Departments of Justice and Homeland Security is designed to “develop, disseminate and support enterprise-wide information object class property exchange standards and processes. to effectively share critical information in emergency situations, as 0..1 0..1 well as support the day-to-day operations of agencies * * throughout the nation” [6]; * 1 data element concept conceptual domain − the METadata Online Registry (METeOR) maintained by the Australian Institute of Health and 1 1 Welfare, part of the Australian Government, is a repository of national data standards on health, * * 1 * housing and community services [12]. data element value domain Each of the registries mentioned above is designed accord- ing to the model provided by ISO 11179 [9], an international standard for metadata registration. It is this standard, and Figure 1: Basic entities in ISO 11179 its interpretation within the domain of electronic govern- ment, that is the subject of this paper. The six different entities mentioned above are related ac- The paper begins with an introduction to ISO 11179, to- cording to the class diagram shown in Figure 1, based upon gether with an explanation of its relationship to existing an entity-relationship diagram given in Part 3 of the stan- electronic government interoperability frameworks. In Sec- dard. Note that a data element is uniquely characterised tion 3, we identify a number of problems that may arise in by the combination of a data element concept and a value the implementation of the standard and related initiatives— domain. particularly in regard to the implied adoption of a single, Many data elements may share the same data element conceptual domain. concept. This allows for different kinds of measurement of In Section 4, we explain how these problems can be solved the same property: for example, the data element concept with a specific interpretation of the ISO 11179 standard, to- of a person’s weight with two different value domains to gether with an extension of the metadata registry approach produce two different data elements: a person’s weight in to include the registration of multiple models of definition, kilograms and a person’s weight in pounds. Similarly, many classification, and usage. The result is an approach to data data element concepts may share the same conceptual do- and metadata standards that supports multiple perspectives main, indicating that they share the same dimensionality: on information and its meaning, an essential prerequisite for for example, that they are all measurements of mass. interoperability across different departments, agencies, and It would seem logical for the association between data el- cultures. The paper ends with a brief discussion of the value ement concepts and conceptual domains to correspond to of the interpretation and extension, particularly with respect the composition of three other associations: that is, a data to initiatives such as the UK electronic Government Inter- element concept is associated with a conceptual domain pre- operability Framework. cisely when this is the conceptual domain for one of the value domains of an associated data element. However, the stan- dard does not explicitly require that this is the case. 2. ISO11179 All of the above entities are maintained as administered The ISO/IEC 11179 standard Metadata registries (MDR) metadata items within a registry. Each item is associated addresses “the semantics of data, the representation of data, with a collection of administrative metadata, whose function and the registration of the descriptions of that data”. Its is to support the processes of registration, maintenance, and purpose is to promote: standard descriptions, common un- re-use. For example, each item has an administration record, derstanding, harmonisation, and re-use of data in different recording status, change information, and dates of creation, contexts; and the management and re-use of the “compo- change, and effect. Guidelines for the registration and main- nents of data” [9]. It exists in six parts: the first of these tenance of administered items are set out in Part 6 of the describes the overall approach; the others address the spe- standard.
Recommended publications
  • Justice XML Data Model Technical Overview
    Justice XML Data Model Technical Overview April 2003 WhyWhy JusticeJustice XMLXML DataData ModelModel VersionVersion 3.0?3.0? • Aligned with standards (some were not available to RDD) • Model-based Æ consistent • Requirements-based – data elements, processes, and documents • Object-oriented Æ efficient extension and reuse • Expanded domain (courts, corrections, and juvenile) • Extensions to activity objects/processes • Relationships (to improve exchange information context) • Can evolve/advance with emerging technology (RDF/OWL) • Model provides the basis for an XML component registry that can provide • Searching/browsing components and metadata • Assistance for schema development/generation • Reference/cache XML schemas for validation • Interface (via standard specs) to external XML registries April 2003 DesignDesign PrinciplesPrinciples • Design and synthesize a common set of reusable, extensible data components for a Justice XML Data Dictionary (JXDD) that facilitates standard information exchange in XML. • Generalize JXDD for the justice and public safety communities – do NOT target specific applications. • Provide reference-able schema components primarily for schema developers. • JXDD and schema will evolve and, therefore, facilitate change and extension. • Best extension methods should minimize impact on prior schema and code investments. • Implement and represent domain relationships so they are globally understood. • Technical dependencies in requirements, solutions, and the time constraints of national priorities and demands
    [Show full text]
  • Towards a Conceptual Model for an E-Government Interoperability Framework for South Africa
    Towards a Conceptual Model for an e-Government Interoperability Framework for South Africa Paula Kotzé1,2 and Ronell Alberts1 1CSIR Meraka Institute, Pretoria, South Africa 2Department of Informatics, University of Pretoria, Pretoria, South Africa Keywords: e-Government, e-GIF, Interoperability. Abstract: In September 2016, the South African Government published a White Paper on the National Integrated ICT Policy highlighting some principles for e-Government and the development of a detailed integrated national e-Government strategy and roadmap. This paper focuses on one of the elements of such a strategy, namely the delivery infrastructure principles identified, and addresses the identified need for centralised coordination to ensure interoperability. The paper proposes a baseline conceptual model for an e- Government interoperability framework (e-GIF) for South Africa. The development of the model considered best practices and lessons learnt from previous national and international attempts to design and develop national and regional e-GIFs, with cognisance of the South African legislation and technical, social and political environments. The conceptual model is an enterprise model on an abstraction level suitable for strategic planning. 1 INTRODUCTION (Lallana, 2008: p.1) and is becoming an increasingly crucial issue, also for developing countries (United Implementing a citizen-centric approach, digitising Nations Development Programme, 2007). Many processes and making organisational changes to governments have finalised the design of national e- delivering government services are widely posited as Government strategies and are implementing priority a way to enhance services, save money and improve programmes. However, many of these interventions citizens’ quality of life (Corydon et al., 2016). The have not led to more effective public e-services, term electronic government (e-Government) is simply because they have ended up reinforcing the commonly used to represent the use of digital tools old barriers that made public access cumbersome.
    [Show full text]
  • Interoperability and Patient Access for Medicare Advantage Organization and Medicaid
    Notice: This HHS-approved document has been submitted to the Office of the Federal Register (OFR) for publication and has not yet been placed on public display or published in the Federal Register. The document may vary slightly from the published document if minor editorial changes have been made during the OFR review process. The document published in the Federal Register is the official HHS-approved document. [Billing Code: 4120-01-P] DEPARTMENT OF HEALTH AND HUMAN SERVICES Centers for Medicare & Medicaid Services 42 CFR Parts 406, 407, 422, 423, 431, 438, 457, 482, and 485 Office of the Secretary 45 CFR Part 156 [CMS-9115-P] RIN 0938-AT79 Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans in the Federally-facilitated Exchanges and Health Care Providers AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS. ACTION: Proposed rule. SUMMARY: This proposed rule is intended to move the health care ecosystem in the direction of interoperability, and to signal our commitment to the vision set out in the 21st Century Cures Act and Executive Order 13813 to improve access to, and the quality of, information that Americans need to make informed health care decisions, including data about health care prices CMS-9115-P 2 and outcomes, while minimizing reporting burdens on affected plans, health care providers, or payers. DATES: To be assured consideration, comments must be received at one of the addresses provided below, no later than 5 p.m.
    [Show full text]
  • Department of the Navy XML Naming and Design Rules
    Department of the Navy XML Naming and Design Rules Office of the DON Final Version 2.0 Chief Information Officer January 2005 Department of the Navy XML Naming and Design Rules January 2005 18 January 2005 MEMORANDUM FOR DISTRIBUTION Subj: EXTENSIBLE MARKUP LANGUAGE (XML) NAMING AND DESIGN RULES OFFICIAL RELEASE To comply with joint requirements as embodied in the DoD Net-Centric Data Strategy and to achieve the FORCEnet requirement for a common structure and language for information handling, the Department of the Navy (DON) is issuing Naming and Design Rules (NDR) that facilitate the discovery and use of common data across the naval enterprise. XML, an open standards based technology, is a key enabler of the Department's net-centric data strategy. The NDR provides additional rigor necessary to efficiently and effectively operate in a net-centric data-sharing environment. These rules move the DON forward to ensure that all XML is based on a consistent set of schema through the application of open standards that align with the Federal Enterprise Architecture Data Reference Model and Global Information Grid. The result will be an environment that is sustainable, responsive, and agile. The NDR is the product of expertise and energies contributed by representatives from 13 key Navy, Marine Corps, and Secretary of the Navy organizations who participated in the DON XML Working Group. To ensure these rules are applicable and current, the DON Chief Information Officer (DON CIO) has established the XML Business Standards Council and is proceeding to charter the Net-Centric Technical Standards Council to serve as liaison to organizations developing national and international standards for XML and Web Services technologies.
    [Show full text]
  • Interoperability and the Solaris™ 10 Operating System
    Interoperability and the Solaris™ 10 Operating System Interoperability from the Desktop to the Data Center Across a Range of Systems, Software, and Technologies < Investment protection in heterogeneous environments Today, businesses rely on complex, geographically dispersed computing infrastructures that often consist of hundreds of heterogeneous hardware and software platforms from a wide variety of vendors. If these environments are to remain manageable, organizations must be able to rely on interoperable products that work well together. At the same time, as organiza- tions evolve their computing environments with an eye toward improving cost-effectiveness and total cost of ownership (TCO), heavy investments in servers, operating systems, and applications must be protected, and dependence on specific hardware or software vendors must be avoided. The Solaris™ 10 Operating System meets these challenges through a number of different ways, from interoperability with both Linux and Microsoft Windows-based systems through support for a wide range of open standards and open source applications. Interoperability with Java™ technology Windows on a Solaris system by installing a Highlights The Java™ technology revolution has changed SunPCi™ card. The Solaris OS also supports An ideal platform for heteroge- how people think about interoperability by open standards and interfaces that make it neous computing, the Solaris™ no longer tying application design to a specific easier to interoperate with Microsoft Windows 10 OS: platform. Running on every major hardware systems. Authentication interoperability can • Supports open standards such platform and supported by virtually every be achieved through the Kerberos protocol as UDDI, SOAP, WSDL, and XML software vendor, Java technology enables using the Sun Enterprise Authentication • Provides source and binary business applications to be developed and Mechanism™ software built right into the compatibility for Linux applica- operated independent of operating systems.
    [Show full text]
  • UN/CEFACT – Ebxml Core Components Technical 9 Specification, Part 1 10 11 12 13 8 February 2002 14 Version 1.8
    UN/CEFACT DRAFT United Nations Centre for Trade Facilitation and Electronic Business 1 2 3 4 5 6 7 8 UN/CEFACT – ebXML Core Components Technical 9 Specification, Part 1 10 11 12 13 8 February 2002 14 Version 1.8 UN/CEFACT - ebXML Core Components Technical Specification, Part 1 V1.8 Page 1 of 97 UN/CEFACT DRAFT United Nations Centre for Trade Facilitation and Electronic Business 15 1 Status of This Document 16 This Technical Specification is being developed in accordance with the 17 UN/CEFACT/TRADE/22 Open Development Process for Technical Specifications. It 18 has been approved by the eBTWG for public review as defined in Step 5 of the Open 19 Development Process. 20 This document contains information to guide in the interpretation or implementation 21 of ebXML concepts. 22 Distribution of this document is unlimited. 23 The document formatting is based on the Internet Society’s Standard RFC format. 24 This version: Core Components Technical Specification, Version 1.80 of 8 February 25 2002 26 Previous version: Core Components Technical specification, Version 1.75 of 15 27 January 2002 UN/CEFACT - ebXML Core Components Technical Specification, Part 1 V1.8 Page 2 of 97 Core Components 2002-02-08 28 2 eBTWG - ebXML Core Components Specification 29 Project Team Participants 30 We would like to recognise the following for their significant participation to the 31 development of this document. 32 Project Team Leader: Hartmut Hermes Siemens 33 Lead Editor: Mark Crawford Logistics Management Institute 34 Editing Team Mike Adcock APACS 35 Alan Stitzer Marsh, Inc.
    [Show full text]
  • Radical Interoperability Picking up Speed to Become a Reality for the Future of Health
    FEATURE Radical interoperability Picking up speed to become a reality for the future of health Dave Biel, Mike DeLone, Wendy Gerhardt, and Christine Chang THE DELOITTE CENTER FOR HEALTH SOLUTIONS Radical interoperability: Picking up speed to become a reality for the future of health The future of health envisions timely and relevant exchange of health and other data between consumers, physicians, health care and life sciences organizations, and new entrants. What will it take for the industry to get there? Executive summary timely and relevant health and other data flowing between consumers, today’s health care Imagine a future in which clinicians, care teams, incumbents, and new entrants. This requires the patients, and caregivers have convenient, secure cooperation of the entire industry, including access to comprehensive health information hospitals, physicians, health plans, technology (health records, claims, cost, and data from companies, medical device companies, pharma medical devices) and treatment protocols that companies, and consumers. When will the industry consider expenses and social influencers of health start accelerating from today’s silos to this future? unique to the patient. Technology can aid in Our research suggests that despite a long journey preventing disease, identifying the need to adjust ahead, radical interoperability is picking up speed medications, and delivering interventions. and moving from aspiration to reality. Continuous monitoring can lead health care organizations to personalized therapies that In spring 2019, the Deloitte Center for Health address unmet medical needs sooner. And the Solutions surveyed 100 technology executives at “time to failure” can become shorter as R&D health systems, health plans, biopharma advancements, such as a continual real-world companies, and medtech companies and evidence feedback loop, will make it easier to interviewed another 21 experts to understand the identify what therapies will work more quickly in state of interoperability today.
    [Show full text]
  • Interoperability Framework for E-Governance (IFEG)
    Interoperability Framework for e-Governance (IFEG) Version 1.0 October 2015 Government of India Department of Electronics and Information Technology Ministry of Communications and Information Technology New Delhi – 110 003 Interoperability Framework for e-Governance (IFEG) in India Metadata of a Document S. Data elements Values No. 1. Title Interoperability Framework for e-Governance (IFEG) 2. Title Alternative Interoperability Framework for e-Governance (IFEG) 3. Document Identifier IFEG 4. Document Version, month, Version 1.0, Oct, 2015 year of release 5. Present Status Draft. 6. Publisher Department of Electronics and Information Technology (DeitY), Ministry of Communications & Information Technology (MCIT), Government of India (GoI) 7. Date of Publishing October, 2015 8. Type of Standard Document Framework ( Policy / Framework / Technical Specification/ Best Practice /Guideline/ Process) 9. Enforcement Category Advisory (for all public agencies) ( Mandatory/ Recommended / Advisory) 10. Creator Department of Electronics and Information Technology (DeitY) 11. Contribut or DeitY, NIC. 12. Brief Description Purpose of Interoperability Framework for e- Governance (IFEG) is: • To provide background on issues and challenges in establishing interoperability and information sharing amongst e-Governance systems. • To describe an approach to overcome these challenges; the approach specifies a set of commonly agreed concepts to be understood uniformly across all e-Governance systems. • To offer a set of specific recommendations that can be adopted
    [Show full text]
  • Introduction to Data Interoperability Across the Data Value Chain
    Introduction to data interoperability across the data value chain OPEN DATA AND INTEROPERABILITY WORKSHOP DHAKA, BANGLADESH 28 APRIL – 2 MAY 2019 Main objectives of this session • Have a common understanding of key aspects of data interoperability • Discuss how data interoperability is fundamental to data quality and a precondition for open data • Discuss the foundations of data interoperability for national SDG data across the complete data value chain (from collection to use) ▪ Global vs local data needs ▪ Top-down vs bottom-up data producers The SDG data ecosystem is ▪ Structured data exchange vs organic characterized data sharing processes by multiple tensions ▪ Sectoral vs. Cross-cutting data applications Data interoperability challenge It’s difficult to share, integrate and work with the wealth of data that is available in today’s digital era: ▪ Divergent needs and capabilities of multiple internal and external constituencies ▪ Disparate protocols, technologies and standards ▪ Fragmented data production and dissemination systems Knowledge Value creation Interoperability is a characteristic of good quality data Fitness for Collaboration purpose Technology layer The Data and format layers interoperability Human layer challenge is multi-faceted Institutional and organisational layers Data interoperability for the SDGs There are many unrealized opportunities to extract value from data that already exists to meet information needs of the 2030 Agenda Investing time and resources in the development and deployment of data interoperability
    [Show full text]
  • Using Metadata for Interoperability of Species Distribution Models
    Proc. Int’l Conf. on Dublin Core and Metadata Applications 2015 Using Metadata for Interoperability of Species Distribution Models Cleverton Ferreira Borba Pedro Luiz Pizzigatti Corrêa University of Sao Paulo, Brazil University of Sao Paulo, UNASP, Brazil Brazil [email protected] [email protected] Keywords: Metadata, Species Distribution Modeling, Dublin Core, Darwin Core, architecture, interoperability. 1. Use of Metadata for Species Distribution Modeling (SDM) This poster presents the use of metadata patterns for the field of Species Distribution Modeling and also presents a proposal for application of metadata to ensure interoperability between models generated by tools of Species Distribution Modeling (SDM). According to Peterson et al. (2010) the area of Biodiversity Informatics is responsible, by the use of new technologies and computational tools, to meet the demand for support the biodiversity conservation. Portals of biodiversity, taxonomic databases, SDM tools help the scientists and researchers to decide the best for the biodiversity conservation. However, Berendsohn et al. (2011) says that one of the most serious problems in scientific biodiversity science is the need to integrate data from different sources, software applications and services for analysis, visualization and publication and thus offer an interoperability of data, information, application and tools. In this context, the metadata patterns available, has been used to help the scientists and researchers to define vocabulary and data structure for analysis, visualization and publication of biodiversity data. Examples of metadata used in SDM are: Dublin Core (DC) (DCMI, 2012), Darwin Core (DwC) (Wieczorek et al., 2012), Darwin Core Archive (DwC-A) (GBIF, 2010), EML – Ecological Metadata Language (Fegraus et al., 2005), etc.
    [Show full text]
  • CEDS Element Naming Conventions 1
    The Consistent Naming of Elements This document describes the principles used in naming CEDS data elements and entities. These naming conventions provide consistency within the standards. Conventions used within CEDS need not restrict how education agencies and system developers implement the standards. Comparability of meaning is most critical for implementation; however, consistent and clear naming can make it easier to compare data across systems and domains of systems. Standard Name The standard name of a data element in CEDS is refined for human readability and understandability, to avoid possible confusion when using an element in a different context or across domains. CEDS elements may also be assigned a “Technical Name,” often the standard name with spaces removed, and/or an alternative name reflecting a commonly used alternative name for the same concept. Based on the ISO 11-179 guidelines, element names have name parts that consist of discrete terms. The name parts are entity terms, property terms, representation terms (optional), and qualifier terms (optional). Consider how these name parts function in the following illustration: Enrollment in Postsecondary Award Type entity qualifier property representation Entity Terms Entity terms provide the context for an element. In the following data element names, the terms Person, Accountability Report, Dental Insurance Coverage, and Advance Placement are entity terms: Person Middle Name Accountability Report Title Dental Insurance Coverage Type Advance Placement Credits Awarded CEDS Element Naming Conventions 1 Property Terms A property is an attribute common to all members of an entity. For example, all persons have a date of birth. In the following data element names, the terms Name, Title, and Credits Awarded are property terms: Person Middle Name Accountability Report Title Dental Insurance Coverage Type Advance Placement Credits Awarded In this list, three of the element names have an Entity – Property structure.
    [Show full text]
  • Georgia DCH Medicaid Enterprise – Data Management Strategy
    Georgia DCH Medicaid Enterprise – Data Management Strategy February 2015 DCH Medicaid Enterprise Data Management Strategy Version Date Document Revision History Document Author/Reviser 1.0 11/21/2014 Draft Deliverable Submission PCG 2.0 1/22/2015 Updates based upon collective feedback PCG from DCH review 3.0 2/27/2015 Finalized and approved by DCH PCG February 2015 DCH Medicaid Enterprise Data Management Strategy INTRODUCTION ....................................................................................................................................1 DATA STRATEGIES AND USAGE ..............................................................................................................1 DCH STRATEGIC PLAN .............................................................................................................................................. 1 Mission Statement ............................................................................................................................................................. 1 Vision Statement ................................................................................................................................................................ 1 Strategies and Initiatives ................................................................................................................................................... 1 HEALTH INFORMATION EXCHANGE ............................................................................................................................... 1 DATA
    [Show full text]