Presentation is loading. Please wait.

Presentation is loading. Please wait.

0 enabling healthcare interoperability Webinar Series Sponsored by the HITSP Education, Communications and Outreach Committee Building Blocks for Healthcare.

Similar presentations


Presentation on theme: "0 enabling healthcare interoperability Webinar Series Sponsored by the HITSP Education, Communications and Outreach Committee Building Blocks for Healthcare."— Presentation transcript:

1 0 enabling healthcare interoperability Webinar Series Sponsored by the HITSP Education, Communications and Outreach Committee Building Blocks for Healthcare Interoperability Webinar 2 June 19, 2008 | 2:00 – 3:30 pm (Eastern) Presenters  Jamie Ferguson, Executive Director, Health IT, Kaiser Permanente  Walter Suarez, MD, CEO, Institute for HIPAA/HIT Education & Research

2 Slide 1 HITSP – enabling healthcare interoperability Learning Objectives  Building on concepts introduced in webinar one, this 90-minute session will help participants better understand: — how HITSP is paving the way for interoperable healthcare information; — core concepts utilized by the Panel to harmonize standards for a specific business case as well as cross-cutting topics such as privacy, security, infrastructure and other supporting services; and — the relationship between and among the components of a HITSP Interoperability Specification (IS) — how they build upon one another and how they are shared across IS. a webinar series on U.S. healthcare interoperability

3 Slide 2 HITSP – enabling healthcare interoperability Agenda  Introduction  The HITSP Harmonization Framework  Developing a HITSP Interoperability Specification (IS)  Creating Interoperability Constructs to Address Use Case Requirements  Overview of Base and Composite Standards  Demonstrating through the review of actual Use Cases how a HITSP IS can be located, accessed, understood and implemented  Questions and Answers / Open Dialogue a webinar series on U.S. healthcare interoperability

4 Slide 3 HITSP – enabling healthcare interoperability Introduction: Steve’s Story... part two  Patient is a 26-year-old male coping with the long-term effects of a brain tumor that was removed during his childhood  Examined by a specialist in Boston that participates in Massachusetts Share — MA-SHARE makes medical information available for exchange through a Regional Health Information Organization (RHIO)  A CD-ROM of medical information was provided by the specialist to the patient  Patient’s local primary care physician could not open the files and does not have access to RHIO

5 Slide 4 HITSP – enabling healthcare interoperability Introduction: Steve’s story (continued)  The FutureHealthcare in an interoperable world — With patient’s consent, medical information can be seamlessly and securely exchanged between and among diverse systems, including providers and care settings where the patient has previously gone for testing or treatment — Care providers will have the most up-to-date records available because healthcare data will be retrieved electronically from its source

6 Slide 5 HITSP – enabling healthcare interoperability  HITSP is a volunteer-driven, consensus-based organization that is funded through a contract from the Department of Health and Human Services.  The Panel brings together public and private-sector experts from across the healthcare community to harmonize and recommend the technical standards that are necessary to assure the interoperability of electronic health records. Overview

7 Slide 6 HITSP – enabling healthcare interoperability  The HITSP Standards Harmonization Framework — Identify a pool of standards for an AHIC (American Health Information Community) Use Case — Identify gaps and overlaps in the standards for this specific Use Case — Make recommendations for resolution of gaps and overlaps — Select standards using HITSP-approved Readiness Criteria — Develop Interoperability Specifications (IS) that use the selected standard(s) for the specific context — Test the IS Deliverables and Mode of Operation

8 Slide 7 HITSP – enabling healthcare interoperability IS 01Electronic Health Record (EHR) Laboratory Results Reporting IS 02Biosurveillance IS 03Consumer Empowerment IS 04Emergency Responder Electronic Health Record (ER-EHR) IS 05 Consumer Empowerment and Access to Clinical Information via Media IS 06Quality IS 07Medication Management Current Interoperability Specifications (IS)

9 Slide 8 HITSP – enabling healthcare interoperability Overview HITSP Interoperability Specifications AHIC Use Case

10 Slide 9 HITSP – enabling healthcare interoperability AHIC Use Cases Define business and functional requirements Source: American Health Information Community; Office of the National Coordinator for Health Information Technology. June, 2008

11 Slide 10 HITSP – enabling healthcare interoperability Overview HITSP Interoperability Specifications AHIC Use Case Interoperability Specification (IS)  Identifies the framework that is a solution for business need (use case)  Defines requirements including transactions and terminology  Addresses multi-year roadmap as needed

12 Slide 11 HITSP – enabling healthcare interoperability HITSP Interoperability Specifications (IS)  A HITSP IS represents a suite of documents that integrate and constrain existing standards (base or composite) to satisfy a Use Case.  Each IS defines a set of “constructs” that: — specify how to integrate and constrain selected standards (base or composite) to meet the business needs of a Use Case; and — define a Roadmap to use emerging standards and to harmonize overlapping standards when resolved.

13 Slide 12 HITSP – enabling healthcare interoperability HITSP Interoperability Specifications (continued)  Revisions and updates may mean that multiple versions of some Interoperability Specifications exist with differing status levels  IS Status = State in the acceptance process — Released Panel approved for submission to HHS — Accepted Secretary of HHS has accepted for a period of testing — Recognized Secretary of HHS has recognized the IS for immediate implementation

14 Slide 13 HITSP – enabling healthcare interoperability Overview HITSP Interoperability Specifications AHIC Use Case Interoperability Specification (IS)  Identifies the framework that is a solution for business need (use case)  Defines requirements including transactions and terminology  Addresses multi-year roadmap as needed Constructs available for reuse or repurposing Component Transaction Transaction Package Technical Notes

15 Slide 14 HITSP – enabling healthcare interoperability HITSP Constructs (In decreasing breadth of scope)  Interoperability Specifications Integration of all constructs used to meet the business needs of a Use Case Interoperability Specifications  Transaction Packages Logical grouping of transactions Transaction Packages  Transactions Logical grouping of actions that use components and/or composite standards to realize the actions Transactions  Components Logical grouping of base standards that work together, such as messaging and terminology Components

16 Slide 15 HITSP – enabling healthcare interoperability Overview HITSP Interoperability Specifications AHIC Use Case Interoperability Specification (IS)  Identifies the framework that is a solution for business need (use case)  Defines requirements including transactions and terminology  Addresses multi-year roadmap as needed Composite Standard #1 Composite Standard #4 Base Standard #2 Base Standard #3 Base Standard #5 Base Standard #n Base Standard #n Constructs available for reuse or repurposing Component Transaction Transaction Package Technical Notes

17 Slide 16 HITSP – enabling healthcare interoperability Standards The building blocks of every Interoperability Specification Standard A well-defined approach that supports a business process and... — has been agreed upon by a group of experts; — has been publicly vetted; — provides rules, guidelines, or characteristics; — helps to ensure that materials, products, processes and services are fit for their intended purpose; — is available in an accessible format; — is subject to an ongoing review and revision process. Base Standard  capable of fulfilling a discrete function Composite Standards  groupings of coordinated base standards Examples  Basic Specifications  Implementation Guides  Code Sets and Terminologies

18 Slide 17 HITSP – enabling healthcare interoperability Standards “Real World” examples of Base and Composite Standards  XML (base)  IHE-XDS (composite)  HL7-CCD (base)  DICOM (base)  LOINC (base)  SNOMED-CT (base)  NCPDP-Script (composite)  etc. Base Standard  capable of fulfilling a discrete function Composite Standards  groupings of coordinated base standards Examples  Basic Specifications  Implementation Guides  Code Sets and Terminologies

19 Slide 18 HITSP – enabling healthcare interoperability Standards How standards are selected for an IS  The standards selected for inclusion in the pool are examined using HITSP approved Tier 1 and Tier 2 Harmonization Readiness Criteria  The standards required to support each major Use Case event are organized within an agreed upon standards taxonomy

20 Slide 19 HITSP – enabling healthcare interoperability Standards Readiness Criteria Tier One Suitability for purpose Organization and process Costs Life cycle maturity Other

21 Slide 20 HITSP – enabling healthcare interoperability Standards Readiness Criteria Tier Two  Suitability The standard is named at a proper level of specificity and meets technical and business criteria of use case  Compatibility The standard shares common context, information exchange structures, content or data elements, security and processes with other HITSP harmonized standards or adopted frameworks as appropriate  Preferred Standards Characteristic Approved standards, widely used, readily available, technology neutral, supporting uniformity, demonstrating flexibility and international usage are preferred  Standards Development Organization and Process Meet selected criteria including balance, transparency, developer due process, stewardship and others.  Total Costs and Ease of Implementation Deferred to future work

22 Slide 21 HITSP – enabling healthcare interoperability Base or Composite Standards Constructs (single purpose or reusable) Interoperability Specification (construct) Type 1: Base or Composite Standards Summary HITSP Interoperability Specifications  A complete IS set provides a framework that defines — a hierarchy of constructs — the role of each construct — the relationship of one construct to another within the context of a specific Use Case Interoperability Specification (Complete Set)

23 Slide 22 HITSP – enabling healthcare interoperability Constructs (single purpose or reusable) Type 1: Base or Composite Standards  Re-Use Applying an existing construct to more than one IS  Re-Purpose Updating a construct to meet the needs of a new Use Case KEY BENEFIT  ‘Re-use and re-purpose’ speeds the rapid roll out of Harmonized Standards HITSP Interoperability Specifications Construct Re-Use and Re-Purpose

24 Slide 23 HITSP – enabling healthcare interoperability HITSP Interoperability Specifications Construct Re-Use and Re-Purpose (continued)  No need to “reinvent the wheel” every time there is a new Use Case  The applicability of the constructs across Use Cases is done consistently  Based on requirements of Use Cases, new constructs might still be needed because existing constructs do not address the newly defined need  REAL-WORLD EXAMPLE: Security, Privacy and Infrastructure (SPI)

25 Slide 24 HITSP – enabling healthcare interoperability Security, Privacy and Infrastructure (SPI) and Healthcare Information Interoperability  Security Elements such as consistent time, secure communications channel, entity identity assertion, and others  Privacy Elements related to capturing and reporting consent directives electronically  Infrastructure Structural elements of the exchange health information, such as querying for existing data or notification of document availability

26 Slide 25 HITSP – enabling healthcare interoperability SPI and Healthcare Information Interoperability Internal Security Policies, Procedures and Practices Secure System Architecture Health Care System Internal Security Policies, Procedures and Practices Secure System Architecture Inter-organizational Exchange Security Privacy Infrastructure Intra-organizational Security, Privacy, Infrastructure Intra-organizational Security, Privacy, Infrastructure Health Care System

27 Slide 26 HITSP – enabling healthcare interoperability  Medical records contain some of the most sensitive information about a person.  The privacy and security of health information are central to the doctor-patient relationship.  Many laws and regulations address the topic: — Federal: HIPAA, Privacy Act, Education Records Law, Mental Health Records Laws, Public Health Information Laws — State: There is a patchwork of varying types and levels of state privacy laws, though few address health privacy and security in a comprehensive fashion Security and Privacy

28 Slide 27 HITSP – enabling healthcare interoperability  HITSP focuses on Security and Privacy between entities, not within an entity.  Common Security and Privacy Constructs are used across the HITSP Interoperability Specifications.  KEY BENEFIT Organizations do not need to redo internal security procedures when implementing HITSP IS Security and Privacy (continued)

29 Slide 28 HITSP – enabling healthcare interoperability Infrastructure  Most interoperability uses the same common types of mechanisms for exchanging information.  Instead of “reinventing the wheel” each time, common infrastructure constructs are reused.  Example — Many specifications use document sharing as a means of exchanging information. — One of the Infrastructure Constructs is a Transaction Package called “Manage Sharing of Documents.” — This Construct is used in many different Interoperability Specifications.

30 Slide 29 HITSP – enabling healthcare interoperability HITSP SPI Constructs  Provide Entity Identity Assertions  Managing consumer privacy Consent Directives  Establishing and manage Access Controls  Ensuring Management of Document Sharing  Utilize a Secure Communication Channel  Implementing Nonrepudiation of Origin  Collecting/communicating Security Audit Trails  Consistent use and control of system Time  Provide Patient Demographics Query  Ensure Document Reliable Exchange  Establish Patient ID Cross-Referencing  Provide Notification of Document Availability  Utilize Secure Web Connection  Allow secure Transfer of Documents on Media  Support Query for Existing Data  Support the ability to Retrieve Form for Data Capture  Provide ability to Pseudonymize and Anonymize data

31 Slide 30 HITSP – enabling healthcare interoperability HITSP SPI Constructs Use across HITSP IS SPI ConstructsIS01IS02IS03IS04IS05IS06IS07ISXX Entity Identity Assertion (C19) Consent Directives (TP30) Access Controls (TP20) Management of Document Sharing (TP13) Secure Communication Channel (T17) Non-repudiation of Origin (C26) o oo oo Collect/Communicate Security Audit Trail (T15) Consistent Time (T16) Patient Demographics Query (T23) Document Reliable Exchange (T31) Other SPI constructs….. ISXX = Initial Assessment of Applicability of SPI Constructs to New 2008 Use Cases O = Construct not required but optionally available for use

32 Slide 31 HITSP – enabling healthcare interoperability HITSP SPI Constructs Four examples of how HITSP IS Constructs help “Steve” — Security: T17 – Secured Communication Channel — Infrastructure: TP13 – Manage Sharing of Documents — Infrastructure: T23 – Patient Demographic Query — Privacy: TP30 – Manage Consent Directives Learn more about HITSP’s activities in the area of Security, Privacy and Infrastructure Webinar 7: Thursday, August 21, 2008 — 2:00-3:30 pm EDT

33 Slide 32 HITSP – enabling healthcare interoperability HITSP SPI Constructs Example One: Security  T17 HITSP Secured Communication Channel Transaction The Secured Communication Channel Transaction provides the mechanisms to ensure the authenticity, integrity, and confidentiality of Transactions, and the mutual trust between communicating parties. It supports both application and machine credentials, and user machines (user nodes). T17 HITSP Secured Communication Channel Transaction — Concept To ensure the authenticity, the integrity, and the confidentiality of transactions, and the mutual trust between communicating parties. Steve’s information is kept secure as it moves from one provider to another.

34 Slide 33 HITSP – enabling healthcare interoperability T17 HITSP Secured Communication Channel Transaction

35 Slide 34 HITSP – enabling healthcare interoperability HITSP SPI Constructs Example Two: Infrastructure  TP 13 HITSP Manage Sharing of Documents Transaction Package This Transaction Package supports the sharing of patient records in the form of source attested objects called documents. A healthcare document is a composite of structured and coded health information, both narrative and tabular, that describes acts, observations and services for the purpose of exchange. No assumption is made by this construct in terms of the format and structure of the content of documents shared. TP 13 HITSP Manage Sharing of Documents Transaction Package — Concept Defines the methodology and metadata requirements for the registration, storage and retrieval of documents across repositories. — Sharing of source attested documents, document content neutral, document registry, document repositories distributed or centralized. Steve’s doctors are able to get his medical record information on demand.

36 Slide 35 HITSP – enabling healthcare interoperability pkg TP13 «transaction package» Manage Sharing of Documents +docId = TP13 «composite standard» IHE XDS +Provide & Register Document Set:-b ITI-41 +Registry Stored Query: ITI-18 +Register Document Set:-b ITI-42 +Retrieve Document: Set ITI-43 «base standard» ISO 15000 ebRS implements constrains

37 Slide 36 HITSP – enabling healthcare interoperability HITSP SPI Constructs Example Three: Infrastructure  T23 HITSP Patient Demographics Query Transaction This PDQ Transaction is intended to provide a ‘list patients and their demographics’ query / ‘patient(s) and their demographics identified’ response message pair (QBP^Q22, RSP^K22) for use wherever such needs exist. This Transaction document extracts the Health Level Seven (HL7) version 2.5 Query and Response data mapping. The underlying basis for this extraction can be found in the Integrating the Healthcare Enterprise IT Infrastructure Technical Framework, Volume 2 (ITI TF-2), Revision 3.0: “Patient Demographics Query.” T23 HITSP Patient Demographics Query Transaction — Concept Defines the methodology for identifying a patient (or list of patients) that match a provided set of patient demographics

38 Slide 37 HITSP – enabling healthcare interoperability

39 Slide 38 HITSP – enabling healthcare interoperability T23 – Patient Demographics Query  One Transaction – Two Systems (actors) — Patient Demographic Supplier Manages the demographics traits of persons — Patient Demographics Consumer Issues a Patient Demographics Query to the Patient Demographics Supplier with some person traits, and receives in response one or more matching persons with those respective traits. Patient Demographics SUPPLIER Patient Demographics CONSUMER Patient Demographics Query [ITI-21]

40 Slide 39 HITSP – enabling healthcare interoperability HITSP SPI Constructs Example Four: Privacy  TP30 HITSP Manage Consent Directives Transaction Package The Manage Consent Directives Transaction Package provides the mechanism to capture and transmit in a codified way a consumer’s decisions regarding the collection, access, use and disclosure of his/her individually identifiable health information. Decisions affect what information can be collected, accessed, used or disclosed, by whom, to whom, when, how, and for what purpose. The transactions described in this construct are intended to be carried out by HITSP/TP13 - Manage Sharing of Documents. TP30 HITSP Manage Consent Directives Transaction Package — Concept To capture, manage and communicate information privacy rights granted or withheld by a consumer to one or more identified entities in a defined role to access, collect, use or disclose individually identifiable health information (IIHI). Also supports the delegation of the patient’s right to consent. Steve makes decisions about who can access what health information about him and for what purpose and communicates those to his provider.

41 Slide 40 HITSP – enabling healthcare interoperability T30 HITSP Manage Consent Directives T30 HITSP Manage Consent Directives High Level Sequence Diagram – Capture Consent Directives

42 Slide 41 HITSP – enabling healthcare interoperability T30 HITSP Manage Consent Directives T30 HITSP Manage Consent Directives High Level Sequence Diagram – Request Consent Directives

43 Slide 42 HITSP – enabling healthcare interoperability Electronic Health Record (EHR) Lab Results Reporting Two additional examples of how HITSP can help “Steve” — Scenario 1 Sending new lab results via a message — Scenario 2 Querying for a new lab result or historical results using a document Learn more about HITSP IS 01 Electronic Health Record (EHR) and Lab Reporting Webinar 5: Thursday, July 24, 2008 — 2:00-3:30 pm EDT

44 Slide 43 HITSP – enabling healthcare interoperability EHR-Lab Use Case Scenarios  Scenario 1 Provide new lab results to ordering clinician, to other authorized providers and to data repositories — Uses Base Standard HL7 V2.5.1 for transmission of lab result messages.  Scenario 2 Querying for a new lab result or historical results using a document — New result to ordering provider and to copy-to list on lab test order — All historical results used in clinical care — Uses Composite Standard IHE XDS which references Base Standard HL7 CDA and Base Standard XML.

45 Slide 44 HITSP – enabling healthcare interoperability A.Identify/create lab result terminology B.Send results message to ordering clinician C. Cross-reference patient’s identity D. Send results message to other authorized providers of care E. Structure lab result as lab report document F. Send document to repository, store, and register in data locator service (Note: data repository may be part of EHR or an independent actor) G. Notification of availability of lab report H. Send report to authorized providers of care A G B D F C E H EHR-Lab Use Case Scenario #1 Sending new lab results via a message

46 Slide 45 HITSP – enabling healthcare interoperability F. Send document to repository, store, and register in data locator service G. Notification of availability of lab report I. Query data locator service for lab results location and retrieve from repository J. Query repository and retrieve lab report directly from repository K. Merge lab results into EHR L. View lab results from a web application F G J LK I EHR-Lab Use Case Scenario 2 Query repository for retrieval of historical lab results

47 Slide 46 HITSP – enabling healthcare interoperability IS 01 Electronic Health Record (EHR) Laboratory Results Reporting Related Documents Document Description TP13HITSP Transaction Package: Manage Sharing of Documents Transaction Package TP14HITSP Transaction Package: Send Lab Result Message to Ordering Clinician and Providers of Care Transaction Package T18HITSP Transaction: View Lab Result from a Web Application Transaction TP22HITSP Transaction Package: Patient ID Cross-Referencing Transaction Package T23HITSP Transaction: Patient Demographics Query Transaction T29HITSP Transaction: Notification of Document Availability Transaction C35HITSP Component: EHR Laboratory Result Terminology Component C36HITSP Component: Laboratory Result Message Component C37HITSP Component: Laboratory Report Document Component

48 Slide 47 HITSP – enabling healthcare interoperability www.HITSP.org

49 Slide 48 HITSP – enabling healthcare interoperability www.HITSP.org

50 Slide 49 HITSP – enabling healthcare interoperability www.HITSP.org

51 Slide 50 HITSP – enabling healthcare interoperability C37 – Laboratory Report Document  Base standard (vocabulary) for EHR Lab Laboratory Results terminology — LOINC — SNOMED-CT — HL7 V2.5 Code Sets — HL7 V3.0 Code Sets  Base Standard HL7 V2.5.1 Lab Results messaging  Base Standard HL7 Clinical Document Architecture (CDA R2) – Core data set for Clinical Information, Continuity of Care Document (CCD)  Composite Standard IHE Laboratory Technical Framework Sharing Laboratory Reports (XD*-LAB)  Concept Specifies content for Laboratory Results data in a document-based functional flow scenario

52 Slide 51 HITSP – enabling healthcare interoperability -.-. pkg C37 «component» Lab Report Document Structure +docId = C37 «composite standard» IHE XD*-Lab «base standard» HL7 CDA R2 «base standard» HL7 V2.5 Lab «component» EHR Lab Terminology +docId = C35 constrains references constrains

53 Slide 52 HITSP – enabling healthcare interoperability Implementation Planning Considerations  “Real World” Example – EHR Lab — Current vocabulary capabilities — Laboratory Information System upgrade requirements — EHR upgrade requirements — Interface testing requirements — XML document management capabilities (i.e. XDS, XCA) — Plan for system maintenance — Other...

54 Slide 53 HITSP – enabling healthcare interoperability  Use or specify HITSP Interoperability Specifications in your HIT efforts and in your Requests for Proposals (RFPs)  Ask for CCHIT certification  Leverage Health Information Exchanges to promote HITSP specifications to make connections easier in the future  Ask... Is there a HITSP standard we could be using?  Get involved in HITSP... Help shape the standards How YOU can become involved

55 Slide 54 HITSP – enabling healthcare interoperability Webinar 1 Standardizing How We Share Information in Healthcare: An Introduction to HITSP Thursday, June 5, 2008 — 2:00-3:30 pm EDT Webinar 6Quality Thursday, August 7, 2008 — 2:00-3:30 pm EDT Webinar 2HITSP Foundational Components Thursday, June 19, 2008 — 2:00-3:30 pm EDT Webinar 7Security, Privacy and Infrastructure Thursday, August 21, 2008 — 2:00-3:30 pm EDT Webinar 3Consumer Access to Clinical Information Thursday, June 26, 2008 — 2:00-3:30 pm EDT Webinar 8EHR and Emergency Response Thursday, September 4, 2008 — 2:00-3:30 pm EDT Webinar 4Biosurveillance Thursday, July 10, 2008 — 2:00-3:30 pm EDT Webinar 9Medication Management Thursday, September 18, 2008 — 2:00-3:30 pm EDT Webinar 5Electronic Health Record (EHR) and Lab Reporting Thursday, July 24, 2008 — 2:00-3:30 pm EDT www.HITSP.org/webinars How YOU can become involved Learn more about specific HITSP activities during these upcoming webinars:  

56 Slide 55 HITSP – enabling healthcare interoperability Jessica Kant, HIMSSTheresa Wisdom, HIMSS jkant@himss.orgjkant@himss.org twisdom@himss.orgtwisdom@himss.org Re: HITSP Technical Committees Michelle Deane, ANSI mmaasdeane@ansi.org Re: HITSP, its Board and Coordinating Committees Join HITSP in developing a safe and secure health information network for the United States. Visit www.hitsp.org or contact...www.hitsp.org

57 Slide 56 HITSP – enabling healthcare interoperability Sponsor Strategic Partners www.HITSP.org

58 57 enabling healthcare interoperability Webinar Series Sponsored by the HITSP Education, Communications and Outreach Committee An Overview of Core Concepts Utilized by HITSP in the Standards Harmonization Process Building Blocks for Healthcare Interoperability


Download ppt "0 enabling healthcare interoperability Webinar Series Sponsored by the HITSP Education, Communications and Outreach Committee Building Blocks for Healthcare."

Similar presentations


Ads by Google