Private Circulation Document: IST/35_07_0075

Transcription

1 Private Circulation Document: IST/3_07_007 BSI Group Headquarters 389 Chiswick High Road London W4 4AL Tel: +44 (0) Fax: +44 (0) Committee Ref: IST/3 Date: 0 April 2007 Direct details: Telephone: Fax: csc@bsi-global.com Dear Member ISO NEW WORK ITEM PROPOSAL (NWI) REPLY TO CSC@BSI-GLOBAL.COM BEFORE 08 JUNE 2007 Please find attached the following New Work Item Proposal: ISO/TC21 N37 HL7 Electronic Health Record System Functional Model, Release 1 Please consider whether this project should be added to the work programme of ISO/TC 21 and provide comments on the proposed scope and target date together with relevant details of standards or regulatory matters. If you think the UK should submit a negative vote please give reasons. Please note the following: - if the UK is to vote positively or negatively, then BSI has to answer the questions attached as Annex A. If you wish BSI to submit a positive or negative vote please also submit proposed UK responses. - if the UK is to vote to participate in the project then BSI has to nominate an expert to the project team. If you want to be nominated please let us know by the date above. - the project will not be accepted unless: - the average total score >1 on questions 9 to 13 in Annex A - there is a simple majority of P-members of the committee - at least P-members are willing to participate - at least experts are named Please consider if the draft should be circulated as a CD or a DIS and send any technical comments you wish to be considered as UK comments by the date above. When submitting comments please ensure that they are entered into the ISO comments template. If you have any queries in how to use the template then please do not hesitate to contact the Committee Service Centre. If no comments are received by the above date, the UK will vote "abstain". Yours sincerely Committee Service Centre

2 Annex A - Ballot responses if the UK does not abstain No. Questions 1 Do you agree, as the voting member body, that the requirements in the ISO/IEC Directives, Part 1, 2001, Annex C on the "Justification of proposals for the establishment of standards" have been met by this proposal? 2 We have completed a SVAT (Standards Value Assessment Tool) analysis (see questions 9 to 13), and in order to prepare market relevant and globally relevant International Standards: 3 We agree that a globally relevant International Standard on this subject is feasible and therefore to the addition of the proposed New work item to the programme of work of the committee 4 We are prepared to participate actively in the development of the project (even if voting "No"), i.e. to make an effective contribution at the preparatory stage, at least by commenting on working drafts (If "Yes", nominate experts) Do you agree to direct submission of the draft associated with the New work item proposal as a DIS (Note: A "Yes" implies your acceptance of the attached draft as a CD) 6 If voting 'No" on question, i.e. to the progression of the draft associated with the New work item proposal to a DIS, would you nevertheless agree with direct submission of the draft as a CD 7 Standard(s), regulation(s), and other relevant documentation existing in our country, with any remarks concerning their application if necessary and consequences for global relevance, are attached Possible Answers Yes No We consider that there is no impediment of this project We notice that there is an impediment of this project [Comment required] Yes / No [Comment required] We abstain / have no interest Yes [Comment required] No Yes No Yes No Yes [Comment required] No 8 Do you wish to add any additional comments? Yes [Comment required] No 9 SVAT1 - What is the potential of this project to contribute to international trade and production (1 = lowest, = highest)? 10 SVAT2 - What is the potential of this project to contribute to economic efficiency, health, safety, or the environment (1 = lowest, = highest)? 11 SVAT3 - How great is the need to harmonize national approaches in this subject area that may serve as barriers to international trade (1 = lowest, = highest)? 12 SVAT4 - What is the feasibility of achieving consensus on International Standard(s) in this subject area by the proposed target dates (1 = lowest, = highest)? 13 SVAT - What priority should be assigned to the development of International Standard(s) in this subject area (1 = lowest, = highest)?

3 NEW WORK ITEM PROPOSAL Date of presentation Reference number (to be given by the Secretariat) Proposer HL7 ISO/TC 21 / SC WG8 N 37 Secretariat ANSI/HIMSS A proposal for a new work item within the scope of an existing committee shall be submitted to the secretariat of that committee with a copy to the Central Secretariat and, in the case of a subcommittee, a copy to the secretariat of the parent technical committee. Proposals not within the scope of an existing committee shall be submitted to the secretariat of the ISO Technical Management Board. The proposer of a new work item may be a member body of ISO, the secretariat itself, another technical committee or subcommittee, or organization in liaison, the Technical Management Board or one of the advisory groups, or the Secretary-General. The proposal will be circulated to the P-members of the technical committee or subcommittee for voting, and to the O-members for information. See overleaf for guidance on when to use this form. IMPORTANT NOTE: Proposals without adequate justification risk rejection or referral to originator. Guidelines for proposing and justifying a new work item are given overleaf. Proposal (to be completed by the proposer) Title of proposal (in the case of an amendment, revision or a new part of an existing document, show the reference number and current title) English title HL7 Electronic Health Record System Functional Model, Release 1 French title (if available) To be supplied Scope of proposed project The HL7 EHR System Functional Model provides a reference list of functions that may be present in an Electronic Health Record System (EHRS). The function list is described from a user perspective with the intent to enable consistent expression of system functionality. This EHRS Functional Model, through the creation of Functional Profiles for care settings and realms, enables a standardized description and common understanding of functions sought or available in a given setting (e.g., intensive care, cardiology, office practice in one country and primary care in another country. Concerns known patented items (see ISO/IEC Directives Part 1 for important guidance) Yes No If "Yes", provide full information as annex Envisaged publication type (indicate one of the following, if possible) International Standard Technical Specification Publicly Available Specification Technical Report Purpose and justification (attach a separate page as annex, if necessary) Providers of care and users of EHRS depend on some definable set of functions to meet the IT needs for their organization. The purpose of the HL7 EHRS Functional Model is to provide a superset of the functionalities required to support an EHRS. The internationally-oriented EHRS FM received ANSI accreditation on and contains a superset of over 10 functions that facilitate consistent expression of EHR system features and functionality. The model also contains over 1000 conformance criteria that further clarify system functionality on behalf of EHR system purchasers, vendors, and system integrators. Such a standard becomes the basis for certification of EHRS and may be specific to a realm, a site of care, or a business agreement. See attached for details. Target date for availability (date by which publication is considered to be necessary) Relevant documents to be considered ISO/HL7 Standards Partner Agreement Relationship of project to activities of other international bodies ISO/TC 21/WG 1 and WG 8 FORM 4 (ISO) Page 1 of 3 Version

4 New work item proposal Liaison organizations HL7 Need for coordination with: IEC CEN Other (please specify) Preparatory work (at a minimum an outline should be included with the proposal) A draft is attached An outline is attached. It is possible to supply a draft by The proposer or the proposer's organization is prepared to undertake the preparatory work required Yes No Proposed Project Leader (name and address) W. Ed Hammond, Ph.D. Box 304 Durham, NC 2771 Name and signature of the Proposer (include contact information) Health Level Seven, Inc Washtenaw Ave., Suite 227 Ann Arbor, MI Comments of the TC or SC Secretariat Supplementary information relating to the proposal Other: This proposal relates to a new ISO document; This proposal relates to the amendment/revision of an existing ISO document; This proposal relates to the adoption as an active project of an item currently registered as a Preliminary Work Item; This proposal relates to the re-establishment of a cancelled project as an active project. Voting information The ballot associated with this proposal comprises a vote on: Other: Adoption of the proposal as a new project Adoption of the associated draft as a committee draft (CD) (see ISO Form, question 3.3.1) Adoption of the associated draft for submission for the enquiry vote (DIS or equivalent) (see ISO Form, question 3.3.2) Annex(es) are included with this proposal (give details) Date of circulation Closing date for voting Signature of the TC or SC Secretary Audrey Dickerson Use this form to propose: a) a new ISO document (including a new part to an existing document), or the amendment/revision of an existing ISO document; b) the establishment as an active project of a preliminary work item, or the re-establishment of a cancelled project; c) the change in the type of an existing document, e.g. conversion of a Technical Specification into an International Standard. This form is not intended for use to propose an action following a systematic review - use ISO Form 21 for that purpose. Proposals for correction (i.e. proposals for a Technical Corrigendum) should be submitted in writing directly to the secretariat concerned. Guidelines on the completion of a proposal for a new work item (see also the ISO/IEC Directives Part 1) a) Title: Indicate the subject of the proposed new work item. b) Scope: Give a clear indication of the coverage of the proposed new work item. Indicate, for example, if this is a proposal for a new document, or a proposed change (amendment/revision). It is often helpful to indicate what is not covered (exclusions). c) Envisaged publication type: Details of the types of ISO deliverable available are given in the ISO/IEC Directives, Part 1 and/or the associated ISO Supplement. d) Purpose and justification: Give details based on a critical study of the following elements wherever practicable. Wherever possible reference should be made to information contained in the related TC Business Plan. 1) The specific aims and reason for the standardization activity, with particular emphasis on the aspects of standardization to be covered, the problems it is expected to solve or the difficulties it is intended to overcome. 2) The main interests that might benefit from or be affected by the activity, such as industry, consumers, trade, governments, distributors. 3) Feasibility of the activity: Are there factors that could hinder the successful establishment or general application of the standard? 4) Timeliness of the standard to be produced: Is the technology reasonably stabilized? If not, how much time is likely to be available before advances in technology may render the proposed standard outdated? Is the proposed standard required as a basis for the future development of the technology in question? FORM 4 (ISO) Page 2 of 3

5 New work item proposal ) Urgency of the activity, considering the needs of other fields or organizations. Indicate target date and, when a series of standards is proposed, suggest priorities. 6) The benefits to be gained by the implementation of the proposed standard; alternatively, the loss or disadvantage(s) if no standard is established within a reasonable time. Data such as product volume or value of trade should be included and quantified. 7) If the standardization activity is, or is likely to be, the subject of regulations or to require the harmonization of existing regulations, this should be indicated. If a series of new work items is proposed having a common purpose and justification, a common proposal may be drafted including all elements to be clarified and enumerating the titles and scopes of each individual item. e) Relevant documents: List any known relevant documents (such as standards and regulations), regardless of their source. When the proposer considers that an existing well-established document may be acceptable as a standard (with or without amendment), indicate this with appropriate justification and attach a copy to the proposal. f) Cooperation and liaison: List relevant organizations or bodies with which cooperation and liaison should exist. FORM 4 (ISO) Page 3 of 3

6 HL7 Electronic Health Record System Functional Model, Release 1 OVERVIEW What are Electronic Health Record Systems? The effective use of information technology is a key focal point for improving healthcare in terms of patient safety, quality outcomes, and economic efficiency. A series of reports from the U.S. Institute of Medicine (IOM) identifies a crisis of "system" failure and calls for "system" transformation enabled by the use of information technology. Such a change is possible by "an infrastructure that permits fully interconnected, universal, secure network of systems that can deliver information for patient care anytime, anywhere."( HHS Goals in Pursuing HL7 EHR Functional Standard" in Memorandum to HIMSS from C. Clancy and W. Raub co-chairs of HHS Council on the Application of Health Information Technology, dated November 12, 2003.) A critical foundational component for resolving these system and infrastructure issues is the Electronic Health Record System (EHR-S). In developing this EHR-S Functional Model, HL7 relied on three well-accepted definitions: two provided by the U.S. Institute of Medicine and one developed by the European Committee for Standardization/ Comité Européen de Normalisation (CEN). This Functional Model leverages these existing EHR-S definitions and does not attempt to create a redundant definition of an EHR-S. How were the Functions Identified and Developed? To achieve healthcare community consensus at the outset, the functions are described at a conceptual level, providing a robust foundation for a more detailed work. Functions were included if considered essential in at least one care setting. Written in user-oriented language, the document is intended for a broad readership. Functional Granularity is a term used to describe the level of abstraction at which a function is represented. Functions that are commonly grouped together in practice or by major systems have been consolidated where appropriate; functions requiring extra or separate language or involving different workflows have been kept separate where appropriate. For example, decision support is maintained as a separate section, but mapped to other key sections, to indicate the "smart" function behind an action. All of the functions could be expanded into more granular elements but a balance between a usable document and an unwieldy list of functions has been agreed upon. The goal of determining an appropriate level of functional granularity at this time is to present functions that can be easily selected and used by readers of this standard, but that are not so abstract that readers would need to create a large number of additional functions within each function. Although the determination of functional granularity is a relatively subjective task, systematic evaluation of each function by diverse groups of industry professionals has resulted in a level of granularity appropriate for this EHR-S Functional Model. Every attempt has been made to provide supporting information in the functional descriptions to illustrate the more granular aspects of functions that may have been consolidated for usability purposes. 1

7 Keeping with the intent of this EHR-S Functional Model to be independent with regard to technology or implementation strategy, no specific technology has been included in the functions, but may be used in the examples to illustrate the functions. Inclusion of specific technologies in the examples does not endorse or support the use of those technologies as implementation strategies. Drafts of the EHR-S Functional Model and of specific functions have been widely reviewed by healthcare providers, vendors, and other stakeholders. This proposed standard reflects input from all these reviewers. What is the EHR-S Functional Model Package? This EHR-S Functional Model package includes both Reference and Normative sections. (See the following table for a description of these terms). Document Type Status Reference Normative (table 1) Description Content of the EHR-S Functional Model Package that contains information which clarifies concepts or otherwise provides additional information to aid understanding and comprehension. Reference material is not balloted as part of the standard. Content that is part of the EHR-S Functional Model which HL7 committee members and interested industry participants have formally reviewed and balloted following the HL7 procedures for Balloting Normative Documents. This HL7 developed Functional Model document has been successfully balloted as a normative standard by the HL7 organization. The EHR-S Functional Model Package includes the following materials: Document title Target file name Status of Content EHR-S Functional Model Chapter One: Overview EHR_FM_Overview_R1_ 2007FEB Normative and Reference (see table 3) EHR-S Functional Model Chapter Two: Conformance Clause EHR-S Functional Model Chapter Three: Direct Care Functions EHR-S Functional Model Chapter Four: Supportive Functions EHR-S Functional Model Chapter Five: Information Infrastructure Functions EHR_FM_ConformanceClause_R1_ 2007FEB EHR_FM_DC_R1_ 2007FEB EHR_FM_SP_R1_2007FEB EHR_FM_IN_R1_2007FEB EHR-S Functional Model Glossary EHR_FM_Glossary_R1_2007FEB Reference Normative and Reference (see table 3) Normative and Reference (see table 3) Normative and Reference (see table 3) Normative and Reference (see table 3) EHR-S Functional Model How-to- Guide for Creating Functional Profiles EHR_FM_ProfileHowToGuide_R1_2007 FEB Reference 2

8 FM Chapter Section Status of Content Chapter 1 Introduction Reference Chapter 1 1 Background Reference Chapter 1 2 Purpose and Scope Normative Chapter 1 3 Overview and Definition of the Functional Model Normative Chapter 1 4 Anticipated Uses Reference Chapter 2 Introduction Reference Chapter 2 Conformance Clause Normative & Reference Chapters 3,4 and Chapters 3,4 and Chapters 3,4 and Chapters 3,4 and Chapters 3,4 and (table 3) Function Name Function Statement Function Description See Also Conformance Criteria Normative Normative Reference Reference Normative Purpose and Scope The HL7 EHR System Functional Model provides a reference list of functions that may be present in an Electronic Health Record System (EHR-S). The function list is described from a user perspective with the intent to enable consistent expression of system functionality. This EHR-S Functional Model, through the creation of Functional Profiles for care settings and realms, enables a standardized description and common understanding of functions sought or available in a given setting (e.g., intensive care, cardiology, office practice in one country or primary care in another country). EHR-S Functional Model Scope The HL7 EHR-S Functional Model defines a standardized model of the functions that may be present in EHR Systems. From the outset, a clear distinction between the EHR as a singular entity and systems that operate on the EHR i.e., EHR Systems is critical. Section describes the basis and foundation for the HL7 definition of an EHR System. Notably, the EHR-S Functional Model does not address whether the EHR-S is a system-of-systems or a single system providing the functions required by the users. This standard makes no distinction regarding implementation - the EHR-S described in a functional profile may be a single system or a system of systems. Within the normative sections of the functional model, the term system is used generically to cover the continuum of implementation options. This includes core healthcare functionality, typically provided by healthcare-specific applications that manage 3

9 electronic healthcare information. It also includes associated generic application-level capabilities that are typically provided by middleware or other infrastructure components. The latter includes interoperability and integration capabilities such as location discovery and such areas as cross application workflow. Interoperability is considered both from semantic (clear, consistent and persistent communication of meaning) and technical (format, syntax and physical connectivity) viewpoints. Further, the functions make no statement about which technology is used, or about the content of the electronic health record. The specifics of 'how' EHR systems are developed or implemented is not considered to be within the scope of this model now or in the future. This EHR-S Functional Model does not address or endorse implementations or technology, nor does it include the data content of the electronic health record. Finally, the EHR-S Functional Model supports research needs by ensuring that the data available to researchers follow the required protocols for privacy, confidentiality, and security. The diversity of research needs precludes the specific listing of functions that are potentially useful for research. Overview and Definition of the Functional Model The EHR-S Functional Model is composed of a functional outline (which is divided into three sections, direct care, supportive and information infrastructure), functional profiles (which overlay the outlined functions) and assigned priorities for the functions in the profile. While the functional outline should contain all reasonably anticipated EHR-S functions, it is not itself intended as a list of all functions to be found in a specific EHR-S. Functional profiles can be used to constrain the functions to an intended use. This document defines the Functional Outline and describes the general use of profiles and priorities. Direct Care Supportive Information Infrastructure Profiles (figure 1) The EHR-S functional outline of the EHR-S Functional Model is divided into three sections: Direct Care, Supportive and Information Infrastructure functions. Within the three main sections are thirteen subsections (see the graphic below). There are over 140 individual functions in the outline, each including a Function Name, Function Statement, and Conformance Criteria (normative) as well as other associated information such as description (reference information). Important to note; the numbering of the functions indicates parent-child relationships (e.g. DC.1.1 Record Management (parent), DC Identify and Maintain a Patient Record (child)). In many cases the parent is fully expressed by the children. In the aggregate, the functional model is intended to include the superset of functions from which a subset can be generated by the user to 4

10 illustrate what they need within their EHR-S. Only a subset of this inclusive set of functions will apply to any particular EHR-S. A Conformance Clause, which exists as normative language in this standard, defines the minimum requirements for profiles claiming conformance to the EHR System Functional Model. The Conformance Clause is a high level description of what is required of profiles and implementations. It, in turn, refers to other parts of the standard for details. The Conformance Clause describes concepts critical to the understanding and implementation of the Functional Model, such as: what is a profile, what are conformance criteria, and how do you know what is mandatory versus optional. A conformance clause can also provide a communication between the implementers (vendors) and users (buyers) as to what is required, and gives meaning to the phrases, conforming profile and conforming EHR system. Additionally, it serves as the basis for testing and certification activities which may be performed by organizations external to HL7. Direct Care DC.1 DC.2 DC.3 Care Management Clinical Decision Support Operations Management and Communication Supportive S.1 Clinical Support S.2 Measurement, Analysis, Research and Reports S.3 Administrative and Financial Information Infrastructure (figure 2) IN.1 IN.2 IN.3 IN.4 IN. IN.6 IN.7 Security Health Record Information and Management Registry and Directory Services Standard Terminologies & Terminology Services Standards-based Interoperability Business Rules Management Workflow Management

11 EHR-S Functional Outline: The Functions and Their Use The EHR-S Functional Outline provides a list (superset) of functions organized into discrete sections and sub-sections. Functions describe the behavior of a system in user-oriented language so as to be recognizable to the key stakeholders of an EHR-S. EHR-S functions can be used to: Facilitate describing end user defined benefits such as patient safety, quality outcomes and cost efficiencies in terms of standard EHR-S functions. Promote a common understanding of EHR functions upon which developers, vendors, users and other interested parties can plan and evaluate EHR-S functions. Provide the necessary framework to drive the requirements and applications of next level standards, such as EHR content, coding, information models, constructs and interoperability for information portability between sub-systems of an EHR-S and across EHR-S. Establish a standards-based method by which each realm (country) can apply these EHR functions to care settings, uses, and priorities. Inform those concerned with secondary use of EHR data and national infrastructure what functions can be expected in an EHR System. Components of EHR-S Functional Outline Each function in the HL7 EHR-S Functional Model is identified and described using a set of elements or components as detailed below. Conformance ID Type Name Statement /Description See Also Criteria Normative Normative/Reference Reference Normative Row # Function ID This is the unique outline identification of a function in the outline. The Direct Care functions are identified by DC followed by a number (Example DC ; DC ). Supportive functions are identified by an 'S' followed by a number (Example S.2.1; S.2.1.1). Information Infrastructure functions are identified by an 'IN' followed by a number (Example IN.1.1; IN.1.2). Numbering for all sections begins at n.1. Anticipated Uses HL7 is an international community and supports the development of Functional Profiles, which are country specific (HL7 realm) specifications within a standard. It is anticipated that there will be profiles registered with HL7 that designate a subset of functions from the model for use in specific care settings (e.g. Behavioral Health) or functional areas (e.g. the legal EHR). Included in the EHR-S standard package will be samples of registered functional profiles. These example profiles will be included as reference documents in the How-to Guide for Creating Functional Profiles. 6

12 Anticipated Development Approach: Functional Profiles A functional profile" is a selected set of functions that are applicable for a particular purpose, user, care setting, domain, etcetera. Functional profiles help to manage the master list of functions. It is not anticipated that the full Functional Model will apply to any single EHR-S implementation. As such, an EHR system does not conform directly to the Functional Model; rather, it conforms to a functional profile. For more information about creating, registering, and balloting functional profiles, see Chapter Two: Conformance Clause, Sections 2 and 6. Functional profiles are the expression of usable subsets of functions from this EHR-S Functional Model. In this EHR-S Functional Model the reader will see a long list of Function Names and Function Statements, which serve as reasonable representations of functions that may be needed for a clinical environment. The list of functions is not intended to be used in its entirety. For example, the functions outlined in this model apply differently to different care settings. Many of the functions in the model apply to a nursing home setting, but some like DC (Manage Orders for Blood Products and Other Biologics) would not apply. The list of functions is not considered to be in a usable form until a functional profile or constraint is generated. The act of creating a functional profile is to support a business case for EHR-S use by selecting an applicable subset of functions from the EHR-S Functional Model list of functions, in effect constraining the model to meet specific requirements. For example, a functional profile may be created by a purchaser, to indicate requirements; by a vendor, to indicate the capability of specific products; or by any person/entity wishing to stipulate a desired subset of functions for a particular purpose, including a care setting within a specific realm. Once an applicable subset of functions has been selected, the person/entity creating the profile gives each function a priority of essential now, essential future or optional. For more information about the steps to creating a functional profile, see the How-to Guide for Creating Functional Profiles. 7