Onc si frwk_spec factory_2010


Published on

Presentation on the NIEM to the NHIN Spec Factory

Published in: Health & Medicine
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Add NIEM process for IEPD
  • Kevin
  • Kevin
  • Onc si frwk_spec factory_2010

    2. 2. Outline <ul><li>The ONC S&I Framework (what is it, why is it, how does it work) </li></ul><ul><ul><li>Activities and Processes </li></ul></ul><ul><ul><li>National Information Exchange Model </li></ul></ul><ul><ul><li>Information Exchange Package Documentation </li></ul></ul><ul><li>Model-Centric Specifications (using models to do what???) </li></ul><ul><ul><li>The Approach – Model Centric Specification </li></ul></ul><ul><ul><li>SSA Example </li></ul></ul><ul><li>Next Steps (discussion) </li></ul>
    3. 3. ONC Standards and Interoperability Framework Tools and Services (Use Case Development, Harmonization Tools, Vocabulary Browser, Value Set Repository, Testing Scripts, etc) Use Case Development and Functional Requirements Standards Development Certification and Testing Harmonization of Core Concepts Implementation Specifications Pilot Demonstration Projects Reference Implementation
    4. 4. Why do we need an interoperability framework?
    5. 5. Why do we need an interoperability framework? <ul><li>Move toward more “computational” implementation specifications (IS) </li></ul><ul><ul><li>Scalable processes </li></ul></ul><ul><ul><li>Ability to develop tools to increase the efficiency of IS development and maintenance </li></ul></ul><ul><ul><li>The importance of developing IS that are explicit and subject to less interpretation </li></ul></ul><ul><li>Link use cases and standards from inception to certification </li></ul><ul><ul><li>Keep the certification processes tightly linked to the standards and IS processes </li></ul></ul><ul><ul><li>Support tool development for certification testing </li></ul></ul><ul><ul><li>Develop the testing for compliance at the same time as developing the standards </li></ul></ul><ul><li>Integrate multiple SDOs with different expertise across the process </li></ul><ul><ul><li>Transport packages </li></ul></ul><ul><ul><li>Vocabulary </li></ul></ul><ul><ul><li>Value sets </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><li>Provide repeatable mechanisms for harmonization and integration of existing standards across SDOs </li></ul>08/26/10
    6. 6. S&I ConOps Organizing Principles <ul><li>Not a “waterfall” Process : Developing and harmonizing standards and service specifications across diverse communities necessitates concurrent, agile activities , not waterfall processes </li></ul><ul><li>Need for Structured Coordination : To manage coordination of the concurrent activities within the framework , we need well defined: </li></ul><ul><ul><li>Artifacts </li></ul></ul><ul><ul><li>Roles </li></ul></ul><ul><ul><li>Decisions (Control Points) </li></ul></ul><ul><li>Artifacts : To support the requirement of computable and traceable resultant artifacts, the S&I framework needs ensure the content and structure of the artifacts within the process are well defined and provide continuity within the activities and the tools. </li></ul><ul><li>Roles : Clear “ownership” of significant artifacts and activities must be assigned to ensure coordination, lack of duplication and discontinuity throughout the process. An example of this is the Use Case Stewart, but there are additional roles throughout the process. </li></ul><ul><li>Control Points : At points in an iterative and incremental process, prioritization, validation or approval of artifacts is required to ensure quality and alignment with goals. These points, and the approval entities need to be well defined for the framework to operate smoothly. </li></ul>
    7. 7. S&I Activities Use Cases and Harmonization <ul><li>Engages a wide community in defining use cases to be driven through the process </li></ul><ul><li>Focus on solving a real problem </li></ul><ul><ul><li>Determines scope </li></ul></ul><ul><ul><li>Able to “test” if the use case solves the problem </li></ul></ul><ul><ul><li>Prevents “analysis paralysis” </li></ul></ul><ul><ul><li>Does not model in the abstract </li></ul></ul><ul><ul><li>Open, transparent process </li></ul></ul><ul><li>Output Business Scenarios should describe </li></ul><ul><ul><li>Services </li></ul></ul><ul><ul><li>Standards </li></ul></ul><ul><ul><li>Business rules, trust, policies </li></ul></ul><ul><li>Output can be captured as </li></ul><ul><ul><li>Use Cases and Activity Diagrams </li></ul></ul><ul><ul><li>Collaborations </li></ul></ul><ul><ul><li>BPMN </li></ul></ul><ul><ul><li>Etc… </li></ul></ul><ul><li>Use-case driven (bottom up) with top down coordination </li></ul><ul><li>Multiple use cases might have overlapping standards, services or policies </li></ul><ul><ul><li>E-prescribing and adverse event reporting </li></ul></ul><ul><ul><li>Clinical care summary and quality reporting </li></ul></ul><ul><ul><li>Laboratory data exchange and clinical decision support </li></ul></ul><ul><li>Need to have a strong harmonization framework that spans different standards organizations </li></ul>Use Case Development and Functional Requirements Harmonization of Core Concepts
    8. 8. S&I Activities Standards Development and Implementation Specs <ul><li>As part of the use case development and harmonization process gaps in standards may arise </li></ul><ul><li>Gaps may exist in </li></ul><ul><ul><li>Data package </li></ul></ul><ul><ul><li>Value Sets </li></ul></ul><ul><ul><li>Services </li></ul></ul><ul><li>Work with SDOs (NLM, HL7, IHE etc) to fill in gaps </li></ul><ul><li>Allows the standards work to proceed in parallel with development of the implementation specifications </li></ul><ul><li>Using a model-centric approach to provide sufficient details to support implementation </li></ul><ul><li>Implementation Specification is an explicit description of the </li></ul><ul><ul><li>Standards </li></ul></ul><ul><ul><li>Services </li></ul></ul><ul><ul><li>Policies </li></ul></ul><ul><li>Specifications are packaged together to support use cases and business scenarios </li></ul><ul><li>Create guidelines for development of reference implementation </li></ul>Standards Development Implementation Specifications
    9. 9. S&I Activities Reference Implementation and Pilots <ul><li>Executable implementations of specifications </li></ul><ul><li>Can be used by others to help guide their own implementation or find problems with specifications </li></ul><ul><li>Encourages feedback to ONC </li></ul><ul><li>Reference implementations in use by stakeholders </li></ul><ul><li>Confirms use case is being supported </li></ul><ul><li>ONC helps provide coordination of pilot demonstrations </li></ul>Pilot Demonstration Projects Reference Implementation
    10. 10. S&I Activities Certification and Testing and Tools and Services <ul><li>Provides mechanisms and infrastructure for testing specification implementations </li></ul><ul><li>Includes conformance testing for individual specifications as well as interoperability testing for business scenarios </li></ul><ul><li>Tools and Tests can be used as part of ONC Certification </li></ul><ul><li>Tools and Repositories used to support the other S&I activities </li></ul><ul><li>Example </li></ul><ul><ul><li>IEPD and model repositories </li></ul></ul><ul><ul><li>Vocabulary sets </li></ul></ul><ul><ul><li>Modeling tools and guidelines </li></ul></ul><ul><ul><li>Collaboration tools </li></ul></ul><ul><li>Will leverage existing tools and repositories whenever possible </li></ul><ul><li>Many of the repositories and collaboration tools to be publically available </li></ul>Tools and Services (Use Case Development, Harmonization Tools, Vocabulary Browser, Value Set Repository, Testing Scripts, etc) Certification and Testing
    11. 11. S&I Governance (Artifacts, Roles and Controls) 08/26/10 Core artifacts are versioned and controlled Artifacts are “packaged” and released Each artifacts has a responsible role Artifacts and releases have prioritization and approval points, or “controls”
    12. 12. National Information Exchange Model Overview <ul><li>The National Information Exchange Model (NIEM) is a Federal, State, Local and Tribal interagency initiative providing a foundation for seamless information exchange. </li></ul><ul><li>NIEM is a framework to: </li></ul><ul><ul><li>Bring stakeholders and Communities of Interest together to identify information sharing requirements in day-to-day operational and emergency situations; </li></ul></ul><ul><ul><li>Develop standards, a common lexicon and an on-line repository of information exchange package documents to support information sharing; </li></ul></ul><ul><ul><li>Provide technical tools to support development, discovery, dissemination and re-use of exchange documents </li></ul></ul><ul><ul><li>Provide training, technical assistance and implementation support services for enterprise-wide information exchange. </li></ul></ul><ul><li>ONC Office of Standards and Interoperability plans build a Health Information Exchange Model (NIEM Health) that is harmonized with NIEM </li></ul><ul><li>NIEM Health to leverage NIEM conventions and NIEM components where possible </li></ul>From NIEM website http://www.niem.gov/index.php
    13. 13. What is an IEPD? <ul><li>An I nformation E xchange P ackage D ocumentation (IEPD) is a collection of artifacts that describe the construction and content of an information exchange </li></ul><ul><ul><li>Developed to provide the business, functional, and technical details of the information exchange through predefined artifacts </li></ul></ul><ul><ul><li>Created with a core set of artifacts in a prescribed format and organizational structure to allow for consistency </li></ul></ul><ul><ul><li>Designed to be shared and reused in the development of new information exchanges through publication in IEPD repositories </li></ul></ul><ul><ul><li>IEPDs contain design specifications for an information exchange but may not include supplementary information such as implementation decisions. </li></ul></ul>08/26/10
    14. 14. NIEM Process From NIEM website http://www.niem.gov/index.php IEPD: Information Exchange Package Documentation
    15. 15. The IEPD Artifacts <ul><ul><li>IEPDs contain both required and recommended artifacts </li></ul></ul><ul><ul><li>Required : Bold </li></ul></ul><ul><ul><li>Recommended : Italic </li></ul></ul><ul><ul><li>Note: Best practices for most organizations include many of the optional artifacts listed here </li></ul></ul>No required artifacts. Publish the IEPD to a repository and implement the exchange Scenario Planning Analyze Requirements Map & Model Build & Validate Assemble & Document Publish & Implement
    16. 16. S&I NIEM Harmonization Strategy <ul><li>ONC’s Office of Interoperability and Standards is building a Health Information Exchange Model (NIEM Health) that is harmonized with NIEM </li></ul><ul><li>Health and Human Services petal to serve as bridge between NIEM and NIEM Health </li></ul>Human Services
    17. 17. S&I NIEM Process Harmonized Capability Elaboration Capability Formulation Construction Release & Publication Use Case Development Spec Development Harmonization Reference Impl Cert &Testing S&I Development Phases S&I Governance Health Community Participants Scenario Planning Analyze Requirements Map & Model Build & Validate Assemble & Document Pub. & Impl. NIEM Lifecycle
    18. 18. Addressing Challenges for the Health Information Exchange Model Challenge Approach Existence of disparate health information exchange standards and specifications and implementation approaches Map exchange requirements to existing standards & specifications and address any gaps, duplications, or overlaps Harmonization and management of several well-established, large vocabularies for semantic interoperability Leverage existing vocabulary repositories (e.g. PHIN VADS), coordinate with Unified Medical Language System (UMLS), and collaborate with standards development organizations Usability of existing HIT exchange protocols and specifications Use NIEM processes and adapt supporting tools to create computable, useable implementation specifications NIEM only addresses data content, but transaction behavior and security provisions are necessary for health information exchange Adapt structure and content of S&I IEPD to incorporate transport and security aspects of exchange Compatibility of S&I IEPDs with existing NIEM infrastructure and tools, as well as existing health information exchange protocols Develop and adapt NIEM and health information technology tools and framework to support NHIN goals
    19. 19. Model Centric Specifications
    20. 20. Model Centric Specification Development <ul><li>The S&I Framework uses models to capture the information required to specify exchanges between parties on the NHIN. This supports the 2 primary goals of the S&I Framework </li></ul><ul><ul><li>To aid in the creation of specifications that are less ambiguous than specs traditionally done using word processing tools. </li></ul></ul><ul><ul><li>To support the creation of specifications by other groups </li></ul></ul><ul><li>Models refers largely to the visual representation of exchange syntax, semantics, dependencies and rules. </li></ul><ul><li>By using models the S&I Framework intends to: </li></ul><ul><ul><li>Establish a repeatable pattern for evolution and traceability from requirements to implementation of specifications </li></ul></ul><ul><ul><li>Provides for the implementation of specifications using multiple possible technologies </li></ul></ul><ul><ul><li>Support the composability and reuse among specifications </li></ul></ul><ul><ul><li>Support the creation of specifications by groups outside ONC by providing guidelines, patterns, repositories and tools </li></ul></ul>
    21. 21. Developing the Model Centric Approach <ul><li>Identify Specific Requirements </li></ul><ul><li>Define a Solution Strawman </li></ul><ul><li>Use an existing NHIN business scenario as a proof of concept </li></ul>
    22. 22. Requirements for a Model Centric Approach <ul><li>The modeling approach used by the S&I Framework must </li></ul><ul><ul><li>Provide traceability from Use Case and Requirements through to one or more implementations </li></ul></ul><ul><ul><li>Provide semantic and syntactic modeling constructs to support defining the information and behavior that are part of exchanges </li></ul></ul><ul><ul><li>Support the need to harmonize with existing standards defined at different levels of abstraction </li></ul></ul><ul><ul><li>Be adoptable by different organizations </li></ul></ul><ul><ul><li>Be able to integrate into NIEM process </li></ul></ul>
    23. 23. Solution Strawman <ul><li>Three main components </li></ul><ul><ul><li>Adopt the OMG Model Driven Architecture (MDA) based modeling concepts </li></ul></ul><ul><ul><li>Select a set of tools/technologies/practices that are easily adoptable </li></ul></ul><ul><ul><li>Utilize the model-centric paths through the NIEM processes and related artifacts </li></ul></ul>
    24. 24. S&I Model Centric Proof of Concept <ul><li>Used SSA Disability Determination business scenario as a starting point </li></ul><ul><li>Goals </li></ul><ul><ul><li>Refine NIEM process to develop S&I implementation specifications based on the SSA Disability Determination business scenario </li></ul></ul><ul><ul><li>Develop IEPD artifacts using NIEM process </li></ul></ul><ul><ul><ul><li>Computable UML model for content and transactions based on MDA </li></ul></ul></ul><ul><ul><ul><li>IEPD for content and transactions </li></ul></ul></ul><ul><ul><li>Identify tools/technologies/practices needed for S&I Framework process and gaps in existing tools </li></ul></ul>
    25. 25. Model-Centric Solution - MDA <ul><li>Base S&I Framework modeling on the 3 OMG/MDA model abstractions. </li></ul><ul><ul><li>Computational Independent Model (CIM) </li></ul></ul><ul><ul><li>Platform Independent Model (PIM) </li></ul></ul><ul><ul><li>Platform Specific Model (PSM) </li></ul></ul><ul><li>Define a mechanism to show traceability from Use Cases and Functional Requirements through to technical bindings defined in a PSM. </li></ul><ul><li>Define a flexible modeling foundation by which different types of specifications can be defined. </li></ul><ul><li>Provides ability for multiple technology bindings for the same set of logical specifications (multiple PSMs) </li></ul>
    26. 26. Model-Centric Solution – Tools/Technologies/Practices <ul><li>Use the OMG Unified Modeling Language v2.x </li></ul><ul><ul><li>Is an industry standard general modeling language </li></ul></ul><ul><ul><li>Provides mechanisms for customization of modeling constructs via profiles . </li></ul></ul><ul><li>Utilize OMG XML Model Interchange (XMI) format </li></ul><ul><ul><li>Provides flexibility for non-graphical manipulations of models (ex searching, transforming, reporting, …) </li></ul></ul><ul><ul><li>Vendor neutral standard allowing use of multiple UML modeling tools </li></ul></ul><ul><ul><li>Allows for sharing of models and offers path to integration with NIEM tooling </li></ul></ul><ul><li>Adopt/Adapt an existing UML profile/framework/modeling standard for defining specifications of exchange behaviors. </li></ul><ul><ul><li>Examined HL7 SOA-Aware Interoperability Framework (SAIF) and OMG Service Oriented Architecture Modeling Language (SoaML). </li></ul></ul><ul><ul><li>SoaML or some variation with some influences from SAIF appears to be the best fit. </li></ul></ul>
    27. 27. Model Centric Solution - NIEM Harmonization of Core Concepts Implementation Specifications Reference Implementation and Pilots Use Case Development and Functional Requirements Certification and Testing CIM PIM PSM Scenario Planning Analyze Requirements Map and Model Publish and Implement Build and Validate Assemble and Document Specification Models NIEM Processes and Artifacts S&I Activities Business Processes, Use Cases Business Rules, Business Requirements Exchange Content Model, Mapping Document Exchange Schema, Subset/Constraint Schema, Main Document, IEPD Catalog, IEPD Metadata, Sample XML Vision Document, Process Model Use Case Model, Interaction Model, Domain Model Behavior Model Domain Model Web Services Schema and WSDL
    28. 28. Proposed Structure for S&I IEPD 08/26/10 <ul><li>Notes </li></ul><ul><li>3 Levels of Modeling Abstractions </li></ul><ul><ul><li>Computational Independent Model (CIM) </li></ul></ul><ul><ul><li>Platform Independent Model (PIM) </li></ul></ul><ul><ul><li>Platform Specific Model (PSM) </li></ul></ul><ul><li>Overall IEPD package contains artifacts from each specification level (CIM, PIM, PSM) each covering behaviors, rules, and content </li></ul><ul><li>The S&I IEPD is intended to provide a complete set of specification information for any implementers starting from any abstraction level </li></ul>
    29. 29. Sample Model – CIM Business Scenario
    30. 30. Sample Model – PIM Realization
    31. 31. Sample Model – PIM Service Architecture
    32. 32. Sample Model – PIM Domain Model
    33. 33. Sample Model – PSM WSDL Interface
    34. 34. Where are We Now <ul><li>SSA Prototype effort confirms the concepts of using models to define NHIN specifications </li></ul><ul><li>Open Questions </li></ul><ul><ul><li>Finding the right Too-Much vs. Too-Little modeling balance (can model-centric be agile?) </li></ul></ul><ul><ul><li>Best way to model existing vocabularies and code sets. </li></ul></ul><ul><ul><li>How much harmonization with NIEM models is possible </li></ul></ul><ul><ul><li>How existing interoperability efforts (e.g. PHIN, caBIG) relate to NHIN – NIEM Health </li></ul></ul><ul><ul><li>How Public Health Information Exchanges will be managed, modeled, and enabled </li></ul></ul>
    35. 35. What’s Next <ul><li>Create a NIEM Health standards harmonization process and governance framework </li></ul><ul><li>Establish roadmap for existing NHIN standards, MU harmonization, and non-MU health information exchange specifications </li></ul><ul><li>Establishes a repeatable, iterative process for developing widely reusable, computable implementation specifications </li></ul><ul><li>Establishing the tooling and repositories needed </li></ul><ul><li>Establishing the practices and guidelines for modeling </li></ul><ul><li>Enables semantic traceability so that useable code can be traced back to original requirements and definitions </li></ul><ul><li>Promotes transparency and collaboration from broad range of health stakeholders </li></ul>Scenario Planning Use Case Development and Functional Requirements Standards Development Certification and Testing Harmonization of Core Concepts (NIEM framework) Implementation Specifications Pilot Demonstration Projects Reference Implementation NIEM IEPD Lifecycle
    36. 36. Questions