HITSP Standards Harmonization Process -- A report on progress

Transcription

1 Document Number: HITSP 06 N 75 Date: May 4, 2006 HITSP Standards Harmonization Process -- A report on progress Arlington, VA May 4 th,

2 What Was Done Reviewed obligations from federal contract Observed the de facto process unfold to understand strong and weak points Developed principles / requirements for what the Interoperability Specification should be Listed implied activities ( process elements ) needed to fulfill each principle Aggregated synergistic or similar process elements into macro-process elements Intimated some basic ordering and interrelationships among process elements and among macro-process elements Digressed into some (not all) significant tangential issues 1

3 What You May Want To Do Debate the terminology and definitions used Debate the correctness and/or completeness of the Interoperability Specifications requirements/principles Debate the correctness and/or completeness of the implied process elements Debate the chunking of the implied process elements, and the interrelations of the chunks Debate the completeness or adequacy of this process-development exercise 2

4 What I Am Asking You To Do Suppress those urges until the end of the presentation Make note of which slide numbers, principle numbers, etc. you want to comment on so we can show them during the discussion period Remember that the process is evolutionary Help us get it right enough 3

5 Some Terms Interoperability Specification moniker for HITSP final and culminating artifact of an instantiation of its process lifecycle (source: distillation by project team, ONC, and HITSP Chair from early phrases for the concept) Standard (Def n #1) The term standard refers, but is not limited to: Specifications, Implementation Guides, Code Sets, Terminologies, Integration; (Def n #2) A standard specifies a well-defined approach that supports a business process and: (1) has been agreed upon by a group of experts; (2) has been publicly vetted; (3) provides rules, guidelines, or characteristics; (4) helps to ensure that materials, products, processes, and services are fit for their intended purpose; (5) is available in an accessible format; and (6) is subject to an ongoing review and revision process Profiles (source: excerpts from John Halamka s working definitions) 4

6 Some Terms (cont d) Standards Development Organization - The term standards developer organization refers to an organization that produces one or more of these documents/artifacts [referenced in the HITSP definition of a standard] (source: corollary from definition #1 of a standard ) Harmonization - the selection of standards most ready for use as an interlocking set to implement in support of breakthrough use cases, which are subject to the HITSP processes of: Selection of initial standards based on criteria; Resolution of gaps and overlaps between selected standards; Coordinated maintenance of the set of standards based upon feedback from use and new use-case requirements (source: derivation from original project leadership document) Overlap and Duplication - Duplication refers to instances where one or more standard can equally meet the requirement. Overlaps refer to instances where some of the requirements are met by multiple standards. In both instances, the duplication or overlap is only relative to the specific Use Case event. (source: Gap Analysis Template) 5

7 Some Terms (cont d) Gap - missing or incomplete standards that are required for fulfillment of the events in the given Use Case (source: derived from instructions in Gap and Overlap Analysis template) Context the coupling of a use-case and a specific request for an interoperability specification (source: presenter) 6

8 Interoperability Specification Principle #1 Specification will, for a specific context[1], endorse a set of unambiguous standards[2] which should be used in performing health information exchange/transfer actions for the purpose of interoperability of health applications within said context. Receive a context for which a specification is created Develop a list of standards that support health information exchange actions for interoperability of health applications Ensure the list of identified standards is demonstrably unambiguous as to the espoused means to achieve interoperability [1] Currently use case driven as published by ONC, but in the future, the definition of context may be refined and/or augmented [2] Products of standards development organizations recognized by HITSP 7

9 Digression into Form of HITSP Request Decisions need to be made about how to solicit appropriate information from different audiences Differing levels of knowledge Differing breadths of scope Use cases need to be coordinated for macro AHIC system to work, so post-contract model must be developed Prioritized Use Case + Request For HITSP Work Interoperability Specification Prioritized Use Case + Request For HITSP Work 1 2 n Interoperability Specifications 3 Prioritized Use Case 1 n Requests For HITSP Work 1 1 Interoperability Specifications 8

10 Interoperability Specification Principle #2 Specification will describe each endorsed standard in the most specific terms necessary, and with all necessary attendant information for its appropriate usage including conformance requirements, in order to minimize ambiguity of the authors intent and preserve the sanctity and intrinsic diversity of the context that the specification addresses. Hone standards to the most specific terms necessary to meet requirements of the context Develop or assemble instructions for achieving conformance to chosen standards and how to use them appropriately within the given context Enumerate the scenarios of intrinsic diversity within a context for traceability to endorsed standards usage in order to test preservation of sanctity 9

11 Interoperability Specification Principle #3 Specification will be sufficiently detailed, across all necessary and relevant standards, to enable technical implementation of systems and fulfill the context of the specification. The level of detail necessary for some specifications will include, as an example, the identification of specific value sets, derived from standard terminologies that are to be used in the context of that Specification context. Test granularity of standards references and descriptions against needs for technical implementation Demonstrate that the endorsed standards satisfy the context completely 10

12 Interoperability Specification Principle #4 Specification, or supporting material, will include sufficient detail and information to educate audiences about the details of the specification, to support self-testing of systems against the specification and to support third party, independent testing to the specification. Develop material to describe the specification sufficiently to enable effective use Develop detailed guidance on self-testing implementations based on the specification Develop detailed guidance on third-party testing of implementations based on the specification 11

13 Interoperability Specification Principle #5 Specification will define all requirements and conditions necessary for an implementation of the specification to be considered conformant. Develop testable requirements for conformant fulfillment of the specification 12

14 Interoperability Specification Principle #6 Specification will delineate, from a conformance perspective, those parts of the document mandatory for implementation, those parts not required but suggested for implementation, and those parts that are optional for implementation. Develop a framework for parsing and identifying specification guidance into necessary, suggested, and optional portions (note: there may be global criteria for this as well as situational criteria based on the context) 13

15 Interoperability Specification Principle #7 Specification will describe the dependencies upon other HITSP specifications. Catalogue all references and inclusions related to other HITSP specifications, and the degree to which the current specification is dependent on the content of those other specifications 14

16 Interoperability Specification Principle #8 Specification will describe, when applicable, the extent to which it is a derivation of another HITSP specification. Build a method for building the specifications that enables them to be readily comparable to one another for overlap, similarity, and duplication of content & intent Search existing HITSP specifications to determine what portions of them may be relevant to the context at hand, and thus reusable 15

17 Interoperability Specification Principle #9 Specification will describe, when expedient, distinctions from other HITSP specifications. Build a method for building the specifications that enables them to be readily comparable to one another for overlap, similarity, and duplication of content & intent Search existing HITSP specifications to determine what portions of them may be relevant to the context at hand, and thus possibly overlap or be similar enough to merit a distinction from the current work 16

18 Digression into the Essence of HITSP Activity Question: What level of information does HITSP traffic in? Some well defined unit of information needs to be defined so comparing one specification to another for similarity or reusability is easily accomplished Probably above standard level, something akin to building blocks Question: Once we determine what level of information we traffic in, to what extent do we try to proliferate that paradigm out to SDOs? 17

19 Interoperability Specification Principle #10 Specification will endeavor to enumerate and describe the scenarios of inherent diversity within its context, and indicate the applicable standards, with their appropriate usage, for addressing interoperability for each specific scenario. Enumerate the scenarios of intrinsic diversity within a context for traceability to endorsed standards usage Map standards to context scenarios for the purpose of enabling interoperability aspects of the scenarios For every indicated standard, specify the appropriate usage of the standard within the given context scenario 18

20 Interoperability Specification Principle #11 Specification will use generally-accepted diagrammatic representations of context scenarios & standards applicability, in addition to textual descriptions and annotations. Develop standards for HITSP work related to diagrammatic paradigms Develop templates and standards for specific textual descriptions and annotations for the specification Develop the diagrams and textual elements of the specification to represent the scenarios & standards applicability 19

21 Interoperability Specification Principle #12 Specification will describe the relevant real-world (e.g. clinical) framework that encompasses each scenario of the context it addresses. Develop templates and standards for describing the real-world framework surrounding a context scenario Describe the real-world frameworks associated with the scenarios 20

22 Interoperability Specification Principle #13 Specification will describe roles, responsibilities, actions, options, and interactions of all persons and/or systems involved in the context. Develop templates and standards for specifying roles, responsibilities, actions, options, and interactions of persons/systems involved in a context Identify the roles, responsibilities, actions, options, and interactions of persons/systems involved in each context Document the roles, responsibilities, actions, options, and interactions of persons/systems involved in a context 21

23 Interoperability Specification Principle # 14 Specification will incorporate and customize relevant portions of SDO interoperability guidance and detailed specifications to allow for a self-contained HITSP document. Catalogue and review all external-to-hitsp (SDO-only?) implementation guidance regarding the standards relevant to interoperability Determine the level of applicability of the external implementation guidance to the relevant contexts, and augment them as necessary to fit the context Evaluate completed specification to determine the degree of self-containment 22

24 Interoperability Specification Principle #15 Specification will contain a glossary of terms used and their relevant sources. Review specification to identify and define all the jargon/specialized terms, abbreviations, acronyms, etc., and all sources that require citing 23

25 Interoperability Specification Principle #16 Specification will contain illustrative examples. Relate illustrative examples to chosen standards and their usage 24

26 Interoperability Specification Principle #17 Specification will include guidance on how to access/obtain and use endorsed standards, and describe the intellectual property rights and conditions relevant to all endorsed standards and to the specification itself (imposed by ANSI). Research and catalogue methods to access, obtain, and use all endorsed standards Develop global statement of intellectual property rights and conditions relevant to the specification for inclusion into specification final form 25

27 Interoperability Specification Principle #18 Specification will include a summary of the rationale leading to the set of endorsed standards with a pointer to supporting material that confirms the readiness of each endorsed standard. Articulate rationale for selection of each standard Summarize collective rationale for list of endorsed standards for a context for inclusion in specification Develop criteria for deeming a standard ready for endorsement Apply readiness criteria to candidate standards to filter out those that are inappropriate for endorsement within a context 26

28 Interoperability Specification Principle #19 Specifications will point to supporting material that demonstrates the commitments of HITSP to SDOs and SDOs to HITSP in the context of the use of SDO content in the specification. Develop a standard agreement that reflects the expectations of SDO members as participants in the HITSP process Secure agreement from relevant SDOs to support HITSP Interoperability Specification appropriately, in a form that endures and is referable Reference SDO agreements in specification 27

29 Digression into The Role of The SDO in HITSP Seem to require more formality around the participation of SDOs in HITSP Nomination of standards Access to standards Balanced participation in TCs Liaison between HITSP TCs and SDO Agreement to resolve gaps Possibly work toward elimination of overlap through joint standard development Adoption of Interoperability Specification elements(?) Participation in HITSP change management Configuration management Incorporation of SDO IP into HITSP Specification (standards, implementation guidance, etc.) 28

30 Interoperability Specification Principle #20 Specification will describe alternative standards considered but not selected, and the rationale for the decision. Identify standards considered that are overlapping or duplicative to standards in the endorsed set Identify standards that met some tiers of compatibility, but not the full complement required for inclusion in the endorsed set of standards Record de-selection criteria for each candidate standard that is not included in the endorsed set for a given context, but was considered in the selection process 29

31 Interoperability Specification Principle #21 Specification will describe any gaps in fulfilling the context by the set of endorsed standards, and/or by any individual standard within that set. Identify requirements derived from the context that have no standards that meet all tiers of HITSP criteria to merit endorsement for that context If a single standard encompasses and singly fulfills a set of tightly-coupled standards from the given context, yet is lacking in fulfilling one or more of the tightlycoupled requirements, a gap within that particular standard may be identified for the given context 30

32 Interoperability Specification Principle #22 Specification will describe actions planned by HITSP and/or member SDOs to close identified gaps in fulfilling the context. Formulate a preliminary plan for resolution of all identified gaps in standards for a given context Identify candidate entities to resolve the gaps Select appropriate entities to resolve the gaps from the list of qualified candidates Secure necessary commitments from involved parties to ensure closure of the identified gaps Document full resolution plan and timeline for gaps to be closed with assistance of resolving entities 31

33 Digression into Completeness of Interoperability Specifications Question: Do we publish an Interoperability Specification when there is a plan for gap resolution or after resolution has occurred? Timeline considerations Possibly introduce work-around identification Is an incomplete specification still useful, or can it it be subdivided? 32

34 Macro Process Elements Context Receipt & Analysis Receive a context for which a specification is created Enumerate the scenarios of intrinsic diversity within a context for traceability to endorsed standards usage in order to test preservation of sanctity Enumerate the scenarios of intrinsic diversity within a context for traceability to endorsed standards usage Describe the real-world frameworks associated with the scenarios Identify the roles, responsibilities, actions, options, and interactions of persons/systems involved in each context Document the roles, responsibilities, actions, options, and interactions of persons/systems involved in a context Candidate Standards Identification Develop testable requirements for conformant fulfillment of the specification Develop a list of standards that support health information exchange actions for interoperability of health applications Ensure the list of identified standards is demonstrably unambiguous as to the espoused means to achieve interoperability Map standards to context scenarios for the purpose of enabling interoperability aspects of the scenarios Identify requirements derived from the context that have no standards that meet all tiers of HITSP criteria to merit endorsement for that context If a single standard encompasses and singly fulfills a set of tightly-coupled standards from the given context, yet is lacking in fulfilling one or more of the tightly-coupled requirements, a gap within that particular standard may be identified for the given context 33

35 Macro Process Elements Endorsed Standards Filtration Hone standards to the most specific terms necessary to meet requirements of the context For every indicated standard, specify the appropriate usage of the standard within the given context scenario Identify standards considered that are overlapping or duplicative to standards in the endorsed set Identify standards that met some tiers of compatibility, but not the full complement required for inclusion in the endorsed set of standards Record de-selection criteria for each candidate standard that is not included in the endorsed set for a given context, but was considered in the selection process Articulate rationale for selection of each standard Summarize collective rationale for list of endorsed standards for a context for inclusion in specification Apply readiness criteria to candidate standards to filter out those that are inappropriate for endorsement within a context Process Management Secure agreement from relevant SDOs to support HITSP Interoperability Specification appropriately, in a form that endures and is referable Gap Resolution Formulate a preliminary plan for resolution of all identified gaps in standards for a given context Identify candidate entities to resolve the gaps Select appropriate entities to resolve the gaps from the list of qualified candidates Secure necessary commitments from involved parties to ensure closure of the identified gaps Document full resolution plan and timeline for gaps to be closed with assistance of resolving entities 34

36 Macro Process Elements Implementation Guidance Develop or assemble instructions for achieving conformance to chosen standards and how to use them appropriately within the given context Catalogue and review all external-to-hitsp (SDO-only?) implementation guidance regarding the standards relevant to interoperability Determine the level of applicability of the external implementation guidance to the relevant contexts, and augment them as necessary to fit the context Develop a framework for parsing and identifying specification guidance into necessary, suggested, and optional portions (note: there may be global criteria for this as well as situational criteria based on the context) Internal Consistency Check Catalogue all references and inclusions related to other HITSP specifications, and the degree to which the current specification is dependent on the content of those other specifications Search existing HITSP specifications to determine what portions of them may be relevant to the context at hand, and thus reusable Search existing HITSP specifications to determine what portions of them may be relevant to the context at hand, and thus possibly overlap or be similar enough to merit a distinction from the current work Final Form Assembly Develop material to describe the specification sufficiently to enable effective use Review specification to identify and define all the jargon/specialized terms, abbreviations, acronyms, etc., and all sources that require citing Relate illustrative examples to chosen standards and their usage Reference SDO agreements in specification Develop the diagrams and textual elements of the specification to represent the scenarios & standards applicability Research and catalogue methods to access, obtain, and use all endorsed standards 35

37 Macro Process Elements IV&V Test granularity of standards references and descriptions against needs for technical implementation Demonstrate that the endorsed standards satisfy the context completely Develop detailed guidance on self-testing implementations based on the specification Develop detailed guidance on third-party testing of implementations based on the specification Evaluate completed specification to determine the degree of self-containment Coordination Artifacts Development Develop a framework for parsing and identifying specification guidance into necessary, suggested, and optional portions (note: there may be global criteria for this as well as situational criteria based on the context) Build a method for building the specifications that enables them to be readily comparable to one another for overlap, similarity, and duplication of content & intent Develop standards for HITSP work related to diagrammatic paradigms Develop templates and standards for specific textual descriptions and annotations for the specification Develop templates and standards for describing the real-world framework surrounding a context scenario Develop a standard agreement that reflects the expectations of SDO members as participants in the HITSP process Develop templates and standards for specifying roles, responsibilities, actions, options, and interactions of persons/systems involved in a context Develop global statement of intellectual property rights and conditions relevant to the specification for inclusion into specification final form Develop criteria for deeming a standard ready for endorsement 36

38 Macro Process Elements 37

39 Overlays & Elements Still Needed Relative to This Process Detailed action Division of labor and responsibility between HITSP paid staff and HITSP volunteer participants Sustainable business model should account for the level and kind of staffing HITSP will require over time, and rationalize against the services currently provided by the contract-paid staff to see what activities carry forward into HITSP staff Project management constructs to ensure forward progress, interim accountability, etc. Specific Staff, Committee, Panel, Board, SDOs, stakeholders, and third-party activities relative to the process Prioritization of the process elements according to relevance to ONC contractual obligations Consideration and consensus regarding the requirements/principles for the Interoperability Specification, and the derived process elements 38

40 Overlays & Elements Still Needed Relative to This Process (cont d) Incorporation of lessons-learned from existing HITSP process heretofore Artifacts, agreements, criteria, and other tools Change Management process for all artifacts Relationship to synergistic external processes (e.g. CCHIT) ANSI procedural and jurisdictional considerations 39

41 HITSP Milestones 03/07/06 AHIC Session 05/16/06 AHIC Session 06/13/06 AHIC Session 08/01/06 AHIC Session 09/12/06 AHIC Session Use Cases from ONC 03/10/06 HITSP Board 05/05/06 HITSP Board 06/02/06 HITSP Board 08/04/06 HITSP Board 09/08/06 HITSP Board 03/13/06 HITSP Panel 05/04/06 HITSP Panel 06/14/06 HITSP Panel 08/2206 HITSP Panel 09/20/06 HITSP Panel 02/21/06 Technical Committee #1 03/28/06 Technical Committees #2 04/18/06 Technical Committees #3 Gap & Overlap Analysis Using Use Cases TBD Technical Committees #4 List of Standards & SDO MOUs implementation guides for one or more use cases 01/18//06 Use Cases (3) 05/29/06 Gap Analysis, Process Design Effectiveness Report 06/29/06 Standards Identified 09/26/06 Implementation Instructions Business Plan 40

42 41 Thank you for your attention Open Discussion