Standards Harmonization Technical Committees Update

Transcription

1 Document Number: HITSP 06 N 71 Date: May 3, 2006 Discussion Document Standards Harmonization Technical Committees Update Report to the Healthcare Information Technology Standards Panel Arlington, VA May 4, 2006 This briefing is being provided to HITSP. This material is intended to facilitate discussions during the HITSP meeting. All information contained in this briefing and the related documents is draft.

2 Table of Contents Introduction Standards Gap and Overlap Process Overview HITSP Technical Committees Overview Pool of Standards Required By The Use Case Categories of Standards Standards Gap and Overlap Analysis - By Technical Committee Pool of Standards By Use Case Assumptions Made In Creating The Pool Of Standards Duplications and Overlaps In Standards Identified Gaps In Standards HITSP Comments Next Steps 1

3 Introduction The Biosurveillance, Consumer Empowerment and Electronic Health Record Technical Committees were charged with identifying and analyzing gaps and duplications within the standards industry as they relate to the events in their Use Case. Specifically, each Technical Committee has: Prepared interoperability requirements based on the Use Case. Created a Pool of Standards, including assumptions, that could meet the Use Case requirements Provided a description of all duplications and overlaps among standards for the Use Case Provided a description of the gaps, including missing or incomplete standards Considered alternatives for resolving the gaps 2

4 Standards Gap and Overlap Analysis Process Overview The work of the Technical Committees is initiated by the HITSP, informed by the work of the American Health Information Community (The Community), and has the oversight and backing of the Office of the National Health Information Technology Coordinator (ONC). The Community selected breakthrough areas to be worked across ONC contracts. The HITSP chartered Technical Committees to address three of the four break through areas. Harmonized Use Cases were received from ONC and the following tools were used to perform the Standards Gap and Overlap Analysis process over the past 6 weeks. Conference calls Face to Face meetings SharePoint portal for document sharing Enterprise Architect modeling tool NetSpoke collaborative Web-based tool 3

5 HITSP Technical Committees Overview Biosurveillance 63 members Consumer Empowerment 61 members Electronic Health Record 77 members Transmit essential ambulatory care and emergency department visit, utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized Public Health Agencies with less than one day lag time. Allow consumers to establish and manage permissions access rights and informed consent for authorized and secure exchange, viewing, and querying of their linked patient registration summaries and medication histories between designated caregivers and other health professionals. Allow ordering clinicians to electronically access laboratory results, and allow nonordering authorized clinicians to electronically access historical and other laboratory results for clinical care. Floyd P. Eisenberg, MD MPH, SIEMENS Medical Solutions Health Services - Presenter Peter L. Elkin MD FACP, Mayo Clinic College of Medicine Shaun Grannis, MD, The Regenstrief Institute, Indiana University School of Medicine Soloman I. Appavu, John H. Stroger Cook County Hospital - Presenter Elaine A. Blechman PhD, Professor, Univ. of Colorado-Boulder Charles Parisot, EHR Vendor Association Jamie Ferguson, Kaiser- Permanente - Presenter John Madden, MD, PhD, SNOMED Intl Steve Wagner, Department of Veterans Affairs 4

6 The Pool of Standards Required By The Use Case The standards required to support each major Use Case event were organized within an agreed upon standards taxonomy. The definition and several examples of each category in the taxonomy are provided on the following slides. The standards selected for inclusion in the pool were examined using HITSP approved Tier 1 Harmonization Readiness Criteria. 5

7 Categories of Standards Category Description Example standards & specific elements Information Model Information Interchange Terminology Security & Privacy Those standards that regulate context by defining the relationship between data elements, and facilitate standardized data representation. Those standards that define and facilitate communication between systems usually within well-defined domains. These standards regulate the messages and documents, including their format and interaction, sent between systems. Those standards that enable the consistent definition of entities and attributes, usually with a specific domain, and therefore facilitate standardization of data representation. These standards include code sets, vocabularies, terminologies and nomenclatures. Those standards that facilitate uniform protection of electronically maintained and transmitted healthcare information; and in addition ensure that healthcare information is used only by those authorized to do so. HL7 v3 Patient demographics NCPDP Script ASTM E ebxml HL7 v2.5 Register a patient X12N 270/271 IHE XDS ICD, CPT SNOMED LOINC RxNorm TLS HTTPS OASIS/WSS SAML 6

8 Categories of Standards Category Description Example standards & specific elements Identifier (Individual and Organizational) Functionality and Process Workflow Other Standards Those standards that facilitate the unique identification of individuals, providers and healthcare centers, etc. Those standards that define how orders and results are processed, and provide feedback, in addition they relate to system states and transitions Related policies/regulations FEIN HIPAA National Provider Identifier Payor Identifier ISO/IEC Clinical Guidelines HIPAA 7

9 Biosurveillance Use Case Gap and Overlap Analysis Overview The use case addressed in this document is for the transmission of essential data from: ambulatory care visits emergency department visits resource utilization lab result data from electronically enabled healthcare delivery and public health systems in a standardized and anonymized format, to authorized Public Health Agencies with less than one day lag time. 8

10 Biosurveillance Use Case Gap and Overlap Analysis Overview The system and processes must also support the ability for authorized public health personnel to go back to the data source to seek to re-link the anonymized biosurveillance data to the data source as part of an appropriate public health investigation by enabling: The management of data to ensure proper routing, security, privacy and timely reporting Potential architectural solutions to data flow issues Other permutations of the previous two models 9

11 Pool of Standards for the Biosurveillance Use Case Timeline and Approach - Feb TC Meeting and Subsequent TCONs: Started with the HITSP Biosurveillance Use Case Established Task Groups to focus on standards for each data source Identified >570 standards (master list) covering: 7 categories of standards (Context, Terminology, Information Exchange, Security, Identifiers, Workflow/Functionality, Other not used) SDOs (Health Informatics, Non-Health Informatics) Profiling Organizations (Health Informatics, Non-Health Informatics) Reviewed informally with SDO members (e.g. DICOM, IHE, IEEE), ongoing March 19 Harmonized Use Case was received from ONC 10

12 Pool of Standards for the Biosurveillance Use Case March TC Meeting and Subsequent TCONs Selected >250 standards from the master list based upon the reduced harmonized use case scope. April TC Meeting and Subsequent TCONs Identified common building blocks and associated standards across the 3 HITSP Use Cases Reduced the standards pool to 180: Removed standards referenced by the common building blocks Removed engineering standards already referenced in selected health informatics standards April 26 Deliverable to HITSP Standards Gap and Overlap Analysis Document 11

13 Pool of Standards for the Biosurveillance Use Case Context/Information Model: Need clarification on essential data data dictionary to finalize the standards pool The standards pool remains primarily as in the master list pending clarification of the data dictionary Information Exchange: The standards pool was reduced, but remains broad to accommodate local communication capabilities (e.g. X12 for military, HL7 hospitals, etc.) Terminology: Core (e.g. SNOMED-CT, LOINC, ICD9-CM, CPT, NDF-RT / RxNorm, etc.) Infrastructure (e.g. NIST GPS, FIPS, OWL, etc.) Standards relevant to filtering criteria (e.g. GEM, GELLO, Arden, Prodigy, etc.) 12

14 Pool of Standards for the Biosurveillance Use Case Security: Engineering (e.g. IETF, OASIS, ITU, WS0, ETSI, ECMA, etc.) Health Informatics (e.g. ASTM E31.20, ISO TC215, IHE, DICOM, etc. ) Identifier: Clinical Laboratory Improvement Amendments (CLIA) number HIPAA National Provider Identifier (NPI) Specifications/guides (e.g. DICOM, ISO TC215, ADA, ASTM E31, ISO/IEC, etc.) Functionality/Workflow: Biosurveillance Processes (e.g. Common Alerting Protocol (CAP), Health Alert Network (HAN), National Notifiable Disease Surveillance System (NNDSS), etc.) Health Informatics (e.g. IHE, HL7/OMG, ISO TC215, etc.) 13

15 Assumptions Made in Creating the Pool of Standards Biosurveillance Event Code Event Description Filter existing data to identify data required by public health agencies Anonymize data required by public health agencies Major Assumptions Security/communications policies between institutions are established using established standards for trust management, risk assessment and cross-jurisdiction information exchange. Standards will differ by data source (Lab, Visit, Resource Utilization (Utilization)) Machine-generated Radiology Results are included in data requirements for Lab Results Re-identification as needed is authorized for public health authorities Format (transform) data required by public health agencies Visit data is likely to be supplied through the admitting/registration system Transformation includes formatting data into a message and content mapping Standards will differ by data source (Lab, Visit, Utilization) Machine-generated Radiology Results are included in data requirements for Lab Results HL7 V2.6 will proceed to normative work in time to support this initiative 14

16 Assumptions Made in Creating the Pool of Standards Biosurveillance Event Code Event Description Transmit relevant data to public health agencies Major Assumptions Standards will differ by data source (Lab, Visit, Utilization) Machine-generated Radiology Results are included in data requirements for Lab Results HL7 V2.6 will proceed to normative work in time to support this initiative Receive Biosurveillance data A separate response is sent from the BIS to the originating source indicating that a person or automated process has reviewed the data. This is more than an application acknowledgment that the data was received. Architecture of Biosurveillance Information System (BIS) will in part dictate the security and access 15

17 Duplications and Overlaps in Standards - Biosurveillance Event Code Event Description Standard Duplication/ Overlap Recommended Resolution Format data required by public health agencies 1. Utilization- Information Exchange - Bed availability HL7 V2.x:4 candidate messages potential overlap: OASIS HAVE 1. Work with HL7 to assess recommendations for bed/resource availability. address at the next meeting of HL7 name a liaison to carry the issue Compare to OASIS HAVE 2. Lab Information Exchange Lab Results Message: DICOM/HL7 2. DICOM/HL7 selection criteria for human analysis: HL7 Order Result for machine analysis: DICOM 3. Lab Terminology -Specimen Site, Presumptive DX: HL7/SNOMED/ICD9/ICD10 3. Review and assess relevant work to express Specimen Site and Presumptive DX 4. Visit - Information Exchange visit data messages: Potential Overlap HL7/X12 4. Work with SDOs to harmonize standards (e.g. translation mapping) 5. Lab, Visit, Utilization Context Possible overlap for information models: ASTM/HL7/DICOM/ADA/ISO etc. 5. Identify the appropriate information model 16

18 Duplications and Overlaps in Standards - Biosurveillance Event Code/ Event Description General: Security Standard Duplication/ Overlap 1.Multiple security standards identified do not represent overlapping standards in security. These standards and profiles may vary based upon architecture. ASTM E2085 and E2086 provide guidance for selection of engineering standards, but does not include guidance on newer technologies. 2.Possible overlap: ASTM E1985 with ANSI/INCITS 359 Recommended Resolution 1.Review and update ASTM E2085 and E2086 to include guidance for new WS, ISO, and engineering standards. 2.Review and harmonize 17

19 Duplications and Overlaps in Standards - Biosurveillance Resolving Duplications and Overlaps - When overlap is within the standard: work with SDO to resolve internal issue (e.g. HL7 bed availability) When overlap is across standards: work with affected SDOs through joint meetings (e.g. SNOMED/LOINC) translation mapping for data standards (e.g. CCR/CDA-2) request SDOs to jointly conduct harmonization (e.g. SNOMED/LOINC) Apply evaluation criteria (e.g. current use, ease of implementation for use case, etc) to select standards for interoperability specification until harmonization between identified overlapping standards is complete Once harmonization is complete, update the interoperability specification accordingly 18

20 Identified Gaps in Standards - Biosurveillance Event Code Event Description Filter existing data to identify data required by public health agencies Identified Gap in Standards Lab Terminology Orders/Results (Test Batteries) Possible Gap: Lab indication /presumptive diagnosis/ reason for test Lab, Visit, Utilization - Functionality/ workflow/ process - Filtering process Anonymize data required by public health agencies Lab, Visit, Utilization - Functionality/ workflow/ process Need method for abstracting important concepts from free text records to effect anonymization Format data required by public health agencies, Transmit relevant data to public health agencies Lab Terminology - need granular ontology of body sites Lab - Functionality /workflow/ process - need definition of data set to send to BIS Lab, Visit, Utilization - Context accurate information model for visit data Lab, Visit, Utilization - Functionality/ workflow/ process - transformation, mapping of local/custom codes to whom to send data 19

21 Identified Gaps in Standards - Biosurveillance Event Code Event Description Identified Gap in Standards Provide listing of required biosurveillance data Receive biosurveillance data Lab, Visit, Utilization Context - need definition of data set to send to BIS Functionality /workflow/ process - need definition of data set to send to BIS Information Exchange & Functionality/process/workflow - communication protocols; This is a paper/human process today Lab, Visit, Utilization - Functionality/process/workflow need consistency in the level of Acknowledgement (ACK) 20

22 Identified Gaps in Standards - Biosurveillance Resolving Gaps: Work with SDO/Profiling Organizations - When relevant current work is identified: Establish Technical Committee (TC) Liaison to monitor, inform, and participate in the development process to assure that the work fills the gap When relevant pending work is identified: Work with organization to request acceleration Establish TC Liaison to inform and contribute to the new standard/profile development process to assure that the work is established to fill the gap Adjust the Biosurveillance Interoperability Specification roadmap to accommodate estimated timeline for completion of pending work 21

23 Identified Gaps in Standards - Biosurveillance Resolving Gaps: Work with SDO/Profiling Organizations - When no current/pending efforts are identified: Work with organization(s) to request new standard/profile Establish TC Liaison to inform, and contribute to the new standard/profile development process to assure that the work is established to fill the gap Adjust the Biosurveillance Interoperability Specification roadmap to accommodate estimated timeline for completion of pending work When multiple organizations have current/pending work: Request joint development and concurrent harmonization to assure that the work is filling the gap and not introducing duplications Establish TC Liaison with each affected organization to inform, harmonize, and contribute to the concurrent development process to assure that the work fills the gap without introducing duplications Adjust the Biosurveillance Interoperability Specification roadmap to accommodate estimated timeline for completion of pending work 22

24 Biosurveillance Technical Committee - Summary Pool of standards identified can support near-term implementation Semantically interoperable data in mid/long-term will improve: decision support event detection process efficiency BIS must interoperate with existing systems (e.g. RHIOs, EMRs) The Biosurveillance Use Case and associated pool of standards can be extended to address other use cases, e.g.: case identification and management pharmacovigilance clinical trials quality processes and quality measures International standards must be considered as disease/pandemic episodes are not bound by national borders 23

25 HITSP Comments The title of this Use Case should be Population Health. The term Biosurveillance is unduly alarmist and misleading. Prior to 9/ military health professionals had been discussing this subject for years during the cold war when the threats were arguably more real in terms of public health activities and data. A proposed global Process Model for healthcare uses the proposed new term which would be much more relevant to the subject matter developed than the present term and would be much better appreciated by the public. The new title would be much more quickly understood by the intended health professional discipline participants in the HITSP as well as AHIC. 24

26 HITSP Comments Under the section on inclusions, #1 should specifically include that data captured during patient care by EMS first responders. This data has been clearly noted as part of the EHR (the primary source of data for population health and public health agencies) in existing EHR standards (ASTM E-1384, E-1744) addressing the Basic Care Scenario. This emergency care data was originally identified with respect to combat casualty care 30 yrs ago and was subsequently related to the conventions that arose in the civilian sector for EMS Care. A careful distinction (that is only presently implied) should be made relating to Resource Management data (e.g. Run Reports) in both the inclusion and exclusion paragraphs of this section. Inclusion #1 should be expanded to help make this clear. Specifically, this section should emphasize that the EHR Structure and Content (including associated value sets and terminologies used in the Patient Care functions being addressed by the EHR Use Case) are THE source of the reportable Population Health Data used in this Use Case. Thus, there is very close linkage and an essential need for consistency between these two use cases. There is also an essential link with the Personal Health Record of the Consumer Empowerment Use Case since it too receives captured data from the EHR but also includes uncontrolled direct patient-entered data. These statements will explicitly link the AHIC Use Cases to the coordinated work of the ANSI HITSP Technical Committees so that they maintain close and effective coordination on both the implications of the Conceptual Content and the approaches to its implementation within the technical infrastructure. 25

27 Consumer Empowerment Use Case Gap and Overlap Analysis Overview Consumer Empowerment: Allow consumers to establish and manage permissions, access rights and informed consent for authorized and secure exchange, viewing, and querying of their linked patient registration summaries and medication histories between designated caregivers and other health professionals. The Consumer Empowerment Use Case represents four unique perspectives: 1) Consumer, 2) Provider of Personal Health Record (PHR) Services, 3) Health Care Provider and 4) Data or Network System. It also provides three (3) flow scenarios which describe the interactions between each of these perspectives: Consumer creates account to host registration summary and medication history Consumer visits Health Care Provider and provides registration summary information Authorized Health Care Provider reviews medication history. 26

28 Pool of Standards Required for Consumer Empowerment Used the building block approach to help identify common functions across Use Case events & actions Organized detailed standards into categories which were identified via crossbreakthrough dialogues and shared across by all TC committees (e.g. Information Model, Information Interchange, etc) Identified standards within each category applicable to each building block and used the BB -to- Use Case events/actions association to complete detailed Pool of Standards table Common sets of standards listed in individual action rows of the table were extracted to a table header for simplifying its presentation although it doesn t reduce the breadth of standards potentially applicable to a specific event/action Availability of consumer-related policies, e.g HIPAA, and their association to the implementation of an effective PHR solution is a critical component of realizing the Consumer Empowerment breakthrough 27

29 Assumptions Made in Creating the Pool of Standards Consumer Empowerment Event Code Event Description Major Assumptions Select a provider of PHR services Create Account , Establish/Change permissions Permissions are provided to a caregiver s organization within appropriate constraints (e.g. a doctor and associate practitioner s nurse, or a covering physician) but not to the level of a specific individual , Log on to system A commonly available authentication mechanism is used at login (may be token or not) View registration and medication data Authentication of consumer is performed by the PHR service provider according to policy set by appropriate authorities. We assumed that other parties that may release data to this PHR service provider are part of a trusted environment. Registration summary will be patient created by either entering info by the consumer (e.g. allergies) or obtained by the PHR service provider from a provider or a payer. It remains the responsibility of the providers to validate the consistency of this registration summary information with their own information or that of a payer. The PHR will offer a blind aggregate but not attempt clinical reconciliation of information. Consumers and providers will need to assume this responsibility. An MPI and a Data Locator is required for the PHR to operate. If the PHR system assumes this role, it requires all data sources to inform MPI & data locator of patient identities and data existence. 28

30 Duplications and Overlaps in Standards- Consumer Empowerment Event Code Event Description Standard Duplication/ Overlap View reg/med data Modify reg/med data Gather reg/med data Process request for reg/med data View reg/med data Integrate reg data into EHR or other Process requested data Process request for reg/med data View reg/med data Modify reg/med data Gather reg/med data Process request for reg/med data View reg/med data Integrate reg data into EHR or other Process requested data Process request for reg/med data Medication List may be conveyed in multiple ways: Message in HL7 V2 Message in NCPDP/SCRIPT Message in HL7 V3 Persistent Object in CCR Persistent Object in CDA/CRS/IHE-XDS-MS Persistent Object in CDA/CCD Registration Summary may be conveyed in multiple ways: Message in HL7 V2 Message in X12 (270/271/834) Message in HL7 V3 Persistent Object in CCR Persistent Object in CDA/CRS/IHE-XDS-MS Persistent Object in CDA/CCD Recommended Resolution 29

31 Duplications and Overlaps in Standards- Consumer Empowerment Event Code Event Description Standard Duplication/ Overlap , Establish/change permissions Create account Establishing / modifying access permissions may be conveyed in multiple ways: ebxml MS Registry Web Services HTTP MLLB Recommended Resolution Almost all events Many formats are used for the identification of the patient in both the information models and in the information exchange standards:hl7 V3 Patient Demographics; HL7 v2.5 Patient Mgmt; ASTM CCR E2369; X12N; IHE PDQ/PIX 30

32 Identified Gaps in Standards- Consumer Empowerment Event Code Event Description Identified Gaps Recommended Resolution View Reg/Med data Consumer oriented terminology for medications with mapping to clinical terminologies. Identify and assemble topic experts from TC members to describe requirement(s) of identified gap in more detail and submit same to HITSP panel for further attention by appropriate SDO WG s 2.1.x.x, 2.2.x.x Select Provider of PHR Services Establish/Change permissions A standard for increasing the consumer awareness and level of understanding of the PHR content is not available. Identify and assemble topic experts from TC members to describe requirement(s) of identified gap in more detail and submit same to HITSP panel for further attention by appropriate SDO WG s 31

33 Identified Gaps in Standards- Consumer Empowerment Event Code Event Description Identified Gaps Recommended Resolution Establish/Change Permissions Create account Permission management standards including role definitions are incomplete standards Identify and assemble topic experts from TC members to describe requirement(s) of identified gap in more detail and submit same to HITSP panel for further attention by appropriate SDO WG s View Reg/Med data The federation of User Authentication is only partially covered by the existing standards of : SAML 2.0 Liberty Alliance Identify and assemble topic experts from TC members to describe requirement(s) of identified gap in more detail and submit same to HITSP panel for further attention by appropriate SDO WG s 32

34 Identified Gaps in Standards- Consumer Empowerment Event Code Event Description Identified Gaps Recommended Resolution Integrate registration data into EHR system A standardized topic hierarchy for processing acknowledgements of registration/medication updates in a data repository or EHR is not available. Identify and assemble topic experts from TC members to describe requirement(s) of identified gap in more detail and submit same to HITSP panel for further attention by appropriate SDO WG s 33

35 HITSP Comments Regarding the identified Gap: "Consumer oriented terminology for medications with mapping to clinical terminologies - a request was received for further clarification as how this gap was identified, where in the use case this gap shows up and a more detailed understanding of what this gap means and implies? [John Kilbourne M.D., Medical Officer, NIH/NLM] Response: The gap was identified following open discussion at one/more of the TC meetings The gap has been associated with Use Case event , View Registration / Medication Data The gap is intended to highlight the absence of a uniform language for the presentation of medication history terminology to the consumer; emphasizing the use of non-clinical terminology, presenting generic and brand-name medications under a common name/group, and otherwise facilitating consumer understanding with regards to the specific medications they have been prescribed 34

36 Electronic Health Record Use Case Gap and Overlap Analysis Overview The information in this document pertains to the EHR (Laboratory Result Reporting) Use Case: This use case will provide the following functionality for laboratory results reporting and notification, and is applicable to many types of laboratory tests, including but not limited to: clinical chemistry, hematology, serology, and microbiology: Transmission of complete, preliminary, final and updated lab results to the EHR system (local or remote) of the ordering clinician. Transmission of complete, preliminary, final and updated (or notification) to the EHR system (local or remote) or other clinical data system of designated providers of care (with respect to a specific patient). Retrieval of historical lab results by providers of care. Clinician access to test results respects privacy concerns, sensitivity designations or other attributes. Clinician access to results respects access rules determined by policy (e.g., certain results categorized as sensitive and not normally made available). Sending and accepting appropriate acknowledgement of receipt for interactions. 35

37 Pool of Standards Required for Electronic Health Record Categories of Shared Standards: - Context (Information Model) - Information Interchange - Terminology - Security - Identifier (Individual and Organizational) - Functionality and Process Workflow Categories of Standards for Lab Reports and Results, Vocabularies and Codesets: - Clinical Chemistry, Hematology, Serology, Microbiology, Blood-banking, and Surgical Pathology Reports - Newborn screening, Genetics, Molecular Pathology - Lab tests and Result Status Codes - Record Locator Services - Data Repository Services - Shared Medical Vocabularies EHR Number of Standards Total standards identified in the EHR Use Case* standards identified as unique to EHR Use Case* *Technical Committee is working to reduce these to a core set of standards for further analysis 36

38 Assumptions Made in Creating the Pool of Standards Electronic Health Record Event Code a Event Description Laboratory System notification (patientid, labresults) Data Repository. Notification (patientid, labresults) Major Assumptions The metadata in the Data Repository and in the Locator Service must be consistent and they may need to perform these interactions in a transaction. The phrase carbon copy as used in the use case identifies an exact copy of the results as sent to a pre determined list of recipients (see issues) Historical records will be available for clinical use, unaltered, in compliance with regulatory specifications for the duration of the records retention. The range of lab results within the use case also includes: newborn screening terminology, genetics testing and anatomical pathology. Vocabularies may require constraints in some situations, e.g., ability to limit the use of certain status codes based on the type of result being reported. EHR Scenarios include merge, combine, and resolve discrepancies of results from multiple repositories (see open issues) All system have Patient ID information 37

39 Assumptions Made in Creating the Pool of Standards Electronic Health Record Event Code Event Description Major Assumptions End user authentication and authorization User authentication and authorization will be unique to an application (EHRS or Web app). All interactions All interactions Immature standards Patients consent and provider access to medical information is assumed to be an application level implementation out of scope for this use case. We assume that CMS, National Provider Identifier (NPI) are not mature enough, but it and/or the CMS Legacy Medicare provider number could be used in the interim. Standards and practices for biometric identification of patients are not mature enough to be in scope. 38

40 Duplications and Overlaps in Standards- Electronic Health Record Event Code Event Description Standard Duplication/ Overlap Recommended Resolution All events that rely on standard terminology SNOMED and clinical LOINC overlap in some metadata and test names HL7 Body site and SNOMED body structure overlaps exist ICD and SNOMED overlap, but do have mapping from SNOMED to ICD only Input from Panel members is sought by the EHR TC. EHR TC will conduct reviews of overlaps in upcoming meetings and panel members are encouraged to participate in this resolution process. Events that rely on standardized security ISO and NIST SP800-30, -53 and others 39

41 Identified Gaps in Standards- Electronic Health Record Event Code Event Description Identified Gap in Standards Recommended Resolution a AHIC Use Case Scope Statement (section 3) Lab notification Transmission of Unsolicited Results States: A common description of states that may apply to lab results (i.e. preliminary vs. completed, pending, corrected, etc.) Mechanism for referral trail or consulting physician trails. Input from Panel members is sought by the EHR TC. EHR TC will conduct reviews of this gap in upcoming meetings and panel members are encouraged to participate in this gap resolution process. 40

42 Identified Gaps in Standards- Electronic Health Record Event Code Event Description Identified Gap in Standards Recommended Resolution Acknowledgements as per AHIC Use Case Scope Statement (section 3) No standard mechanism or terminology to indicate success/failure and error notification/resolution for receipt and use of Lab results. Anatomic Pathology and Newborn Screening Terminology Input from Panel members is sought by the EHR TC. EHR TC will conduct reviews of this gap in upcoming meetings and panel members are encouraged to participate in this gap resolution process. 41

43 Next Steps May 5 May 16 May 17 May 23 May 24 - May 26 May 30 May 31 June 1 June 2 Technical Committees complete their analysis and the TC Leadership works in collaboration with TC members and the identified Panel members to develop strategies for resolving overlaps, duplications, and gaps Publish the completed Standards Gap and Overlap Analysis for HITSP review and comment Technical Committees address comments Finalize and submit Standards Gap and Overlap Analysis to ONC Face to face meeting of TC Leadership Chicago, IL Face to face meeting of Technical Committees Chicago, IL May 17 June 2 June 3 June 12 June 14 Use the Standards Harmonization Readiness Criteria Level 2 to work with industry and government stakeholders to develop a draft list of selected standards Vet the lists of draft selected standards widely (SDOs, HHS ONC, NHIN Consortia, CCHIT, etc.) and refine the lists as appropriate; garner commitments from industry as appropriate Present the draft selection of standards at the HITSP June 14 th session for review and approval June 15 June 29 Refine and revise the lists of selected standards for publication on June 30 42