Personal Health Records Portability

1. Personal Health Records Portability April 11, 2008 Webinar Plan to Plan Data Transfer of PHR CCD Implementation Guide Ballot

2. Introduction • This webinar is being provided as an industry service • Questions will be addressed in a Q&A period at the end of this ballot briefing

3. Agenda • Overview of HL7, our current PHR & CCD initiatives • Introduction of the session speakers • Context and Background for the X12 & HL7 roles in the Plan to Plan Data Transfer for PHR • Update and Overview on the X12 275 transaction • CCD IG Overview • Background on CDA and CCD • High-level review of the CCD Implementation Guide • Update and Expectations for the Ballot process • Questions and Answers

4. Health Level Seven (HL7) • HL7 is a collaborative volunteer-driven organization with 2300 individual and corporate members • HL7 members represent vendors, consultants, provider organizations, payers, government agencies and the regulated products industry. • HL7 has developed and published more than 30 American National Standards • HL7 has a worldwide presence with Affiliates in more than 30 countries around the globe • HL7 is an ANSI accredited standards developer • For more information visit www.HL7.org

5. HL7 Vision To create the best and most widely used standards in healthcare.

6. HL7 Mission • HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

7. American National Standards Institute • ANSI • Accredits Standards Developing Organizations • Approves all American National Standards • Liaison to standards bodies in other countries • Proponents of open consensus process

8. Objectives of this Webinar • Provide an overview of current PHR and CCD initiatives • Ensure that the industry has an awareness and understanding of the opportunity for participation in April, May and June • Provide for a forum for Q&A on this particular PHR portability effort

9. Status of CDA Implementation Guides HL7-balloted Implementation Guides: • Continuity of Care Document (CCD) w/ASTM complete • History & Physical (H&P) CDA4CDT complete* • Consult Note CDA4CDT complete* • Healthcare Associated Infection CDC/NHSN complete* • Operative Note CDA4CDT May ’08** • Diagnostic Imaging Reports w/DICOM May ’08** • Personal Health Monitor Report w/Continua May ’08** • PHR2PHR Summary w/AHIP/BCBSA May ’08** • Quality Reporting Document Arch w/QRDA Sept ’08** • others in development: • anesthesiology, anatomic pathology, lab, long term care, pediatrics * = will be published shortly ** = first ballot

10. Status of PHR-S FMDraft Standard for Trial Use Ballot The PHR-System Functional Model: • Balloted in November 2007 • Reconciliation Complete in March 2008 • Anticipate Publication in June 2008 • Lists the functions that PHR systems should or may perform • Provides support for a certification framework • Serves as an anchor point for PHR system interoperability

11. Speakers: • Lenel James, Blue Cross and Blue Shield Association • Co-lead of PHR-S Functional Model DSTU ballot • BCBSA project team liaison • Liora Alschuler, Alschuler Associates, LLC • Co-Editor, CDA; • Co-Chair, HL7 Structured Documents Work Group; • Co-Editor, Plan-to-Plan PHR Data Transfer IG

12. Agenda • Overview of HL7, our current PHR & CCD initiatives • Introduction of the session speakers • Context and Background for the X12 & HL7 roles in the Plan to Plan Data Transfer for PHR • Update and Overview on the X12 275 transaction • CCD IG Overview • Background on CDA and CCD • High level review of the CCD Implementation Guide • Update and Expectations for the Ballot process • Questions and Answers

13. Health Plan Commitment to Advancing Health Information Exchange Health IT will help transform our industry and making PHRs available to consumers is a key building block of that vision • Information collection from full range of providers and settings • Pre-populate and update PHRs • PHR adoption promoted via well established relationships with consumers and providers • PHRs integrated with health plan tools to improve care Offering PHRs : a natural extension of what Plans do Key Outcomes Affordable 1st steps Build toward interoperability Immediate availability Spur consumer uptake Increase provider adoption Empower consumers

14. Developing Plan-to-Plan PHR Data Feed:CORE CONCEPTS • Data follows the member • Plan and Member data sources • Enrollment-related data • Claims-related data • Member self-reported data • Health plans are already implementing PHRs • Longitudinal data also available for consumer wellness tools • Emphasis on preserving the longitudinality of PHR data • Not lost when member changes coverage from one health plan to another • “Portability” not “interoperability:” • Prior data incorporated with current data for new Plan’s Member view • Data transfer is after-the-fact to change of health plan • Data not used for rating/underwriting

15. Participants • Subscriber - an individual eligible for coverage because of their association with a sponsor. Owner of their PHR data. Also, known as the health care consumer. May include dependents of the subscriber. • Sponsor - A sponsor is the party that ultimately pays for the coverage, benefit, or product. Can be an employer, union, government agency, association, or insurance agency. • Health Insurance Plan - The product, coverage, and benefits provided to an enrolled individual. • Predecessor is the sending health plan or current custodian of the PHR • Successor is the receiving health plan or the new custodian of the PHR

16. AHIP/BCBSA Project Overview • Developed prototype for PHR data and portability • Created an initial implementation guide • Developed operating rules • Pilot-test of plan-to-plan transfer • Hand-off to X12 and HL7 • Draft X12 and HL7 standards, Spring 2008 • Pilot test of clinical data transfer, Summer 2008 • Finalize X12 and HL7 standard, Fall 2008 • Operationalize plan-to-plan transfer, 2009?

17. AHIP/BCBSA Project Overview AHIP and BCBSA developed a payer-based Personal Health Record data transfer standard framework where the data follows the Member • 16 Standard PHR Data Domains: Patient Information, Encounters, Medications, more • Map identifying the data source • Data Dictionary • Implementation Guide and Operating Rules • Plan-to-Plan standardfor transferring PHR information Deliverables • Portability standards in synch with AHIC/HITSP/HL7 and will impact standardization of PHR core data elements across vendors

18. Core PHR data set was confirmed across constituents* ADOPTION “Give me one access point and give me only relevant data; I have 15 seconds to make a decision” – Emergency Department Physician • Provider surveys and interviews show: • Different data are prioritized by context and specifics of ‘use case’ • Physicians suggested pilot of confirm PHR standards and confirm value • Physicians concerned about liability, roles and workflow disruption • Largest incentive would be ease of use and transparency of value * Health insurance plans, providers, consumers, standards bodies and vendors

19. Content and Data Stakeholder discussions have confirmed and prioritized data domains Self-Reported Data: System Populated Data: * Benefit information will be populated by each plan; portability of this information is not currently being addressed by PHR specifications.

20. Standard PHR Data Domains Yellow Rows are Systems-Populated Information White Rows are Self-Reported Information

21. Operating Rules Framework PHR Operating Rules Framework Access: Defines access to data, information inclusion, delegation Legislative / Regulatory Privacy / Security Access Control Presentation Control: Defines controls over PHR and usage Presentation: Defines requirements for data presentation consistency across specified media Interoperability Portability Interoperability: Defines data, technical and business process requirements to enable transfer of data between systems Standards Adherence Portability: Defines requirements that enable data to be extracted from the PHR and transported by specified media Standards Adherence: Defines which standards the PHR leverages The PHR Consensus Group must define rules for each of the operational domains of a PHR standard Legislative / Regulatory: Defines federal, state, local, regulatory compliance Privacy / Security: Defines organizational and regulatory compliance rules

22. Agenda • Overview of HL7, our current PHR & CCD initiatives • Introduction of the session speakers • Context and Background for the X12 & HL7 roles in the Plan to Plan Data Transfer for PHR • Update and Overview on the X12 275 transaction • CCD IG Overview • Background on CDA and CCD • High level review of the CCD Implementation Guide • Update and Expectations for the Ballot process • Questions and Answers

23. Business Use • Support Health IT: help consumers to document and manage their health events and improve communication with health care stakeholders to improve patient safety, health care outcomes and quality care: • By providing a standardized specification for one health insurance plan to electronically send PHR data to another health insurance plan: • X12 275 (X274)Transaction • HL7 Clinical Document Architecture (CDA) Release 2 (R2) based upon CCD • Include claim data, medications, administrative data, information about providers and facilities, self reported data, and other relevant clinical information

24. Plan to Plan PHR Data transfers Maximize usage of existing HIPAA transaction infrastructure; Supports both bulk (employer group) and individual transmission; Practical transfer of PHR data for large number of subscribers to single destination; Allows for future EHR data from providers into PHRs hosted at health plans; Supports use of XML for PHR encoding, as used in CCD. ASC X12 275 (X274) Standard Transaction

25. 275 for Transfer of PHR Data Milestones to Publish the X12 Implementation Guide • Version 5050 published in the third quarter 2008 • 3/17 Get a complete, clean copy of version 5050 • 3/24 Obtain TG4/TG8 Approval by 4/15 • 4/15 Post the draft for Public Comment Period for 30 days • 5/19 Reconcile and post comments • 6/03 Informational Forum at X12 meeting (6/01/08 – 6/07/08) • 6/05 Approved vote to publish • 9/30 WPC publishes 275 X274 version 5050 TR3 Webinar April 24, 2008 @ 2pm ET

26. Agenda • Overview of HL7, our current PHR & CCD initiatives • Introduction of the session speakers • Context and Background for the X12 & HL7 roles in the Plan to Plan Data Transfer for PHR • Update and Overview on the X12 275 transaction • CCD IG Overview • Background on CDA and CCD • High level review of the CCD Implementation Guide • Update and Expectations for the Ballot process • Questions and Answers

27. HL7 V3:CDA:CCD:P2P • How do they all relate? • Worldwide agreement at the most abstract, general level • HL7 V3 RIM, data types are ISO standards • CDA is in use worldwide • Community of interest agreement at the most specific level • CCD represents exchange requirements in the US • P2P represents exchange requirements for Plans

28. HL7 V3:CDA:CCD:P2P • Common foundation at highest level of common implementation • data types, model in use globally • specific data elements defined for this application • How is this expressed? • each specification is a set of constraints on the more general standard • CDA constrains the RIM • CCD constrains CDA • P2P PHR constrains CCD

29. HL7 V3:CDA:CCD:P2P • Pluses & Minuses of this approach • Pluses: • highly interoperable across domains • locally customizable • efficient specification of each layer of constraint • Minuses • each layer specifies only the constraint, so, is not a full recipe for implementation

30. Clinical Document Architecture • Clinical Document Architecture (CDA) is a Version 3 specification • ANSI / HL7 CDA R1 1.0 - 2000 • ANSI / HL7 CDA R 2.0 - 2005 • CDA is a specification for a document exchange using • Extensible Markup Language (XML) • The HL7 Reference Information Model (RIM) • Version 3 methodology • Vocabulary - SNOMED, ICD, local...

31. Clinical Document Architecture • CDA Release 2, section 2.1: • A clinical document …has the following characteristics: • Persistence • Stewardship • Potential for authentication • Context • Wholeness • Human readability • CDA = Header + Body

32. Clinical Document Architecture • CDA Header • Metadata required for document discovery, management, retrieval • CDA Body: Human Readable • Clinical Report • Discharge Summary • Care Record Summary • Progress Note • H&P • Public health report • Any content that carries a signature

33. Sample CDA • Header • Body • Readable: required • Computable: optional

34. CDA: Incremental Semantic Interoperability • Standard HL7 metadata • Simple XML for point of care human readability • RIM semantics for reusable computability (“semantic interoperability”)

35. Relationship to HL7 messages • CDA complements HL7 messaging specs • A CDA document is a defined and complete information object that can exist outside of a messaging context • A CDA document can be a MIME-encoded payload within an HL7 message

36. Relationship to HL7 messages • CDA documents are encapsulated as MIME packages within HL7 messages HL7 V3 <someMessage> <Act.Code code="11488-4“ codeSystem="2.16.840.1.113883..." displayName="Consultation note"/> <Act.text type="multipart/related"> MIME-Version: 1.0 Content-Type: multipart/related; boundary="HL7-CDA-boundary"; type="text/xml"; start="10.12.45567.43" Content-Transfer-Encoding: BASE64 --HL7-CDA-boundary Content-Type: text/xml; charset="US-ASCII“ Content-ID: &lt;10.12.45567.43> ... Base 64 of base CDA document, which contains ... <observationMedia classCode="OBS" moodcode="EVN"> <id root="10.23.4567.345"/> <value mediaType="image/jpeg"> <reference value="left_hand_image.jpeg"/> </value> </observationMedia> ... --HL7-CDA-boundary Content-ID: &lt;10.23.4567.345> Content-Location: canned_left_hand_image.jpeg Content-Type: image/JPEG ... Base64 image ... --HL7-CDA-boundary-- </Act.text> </someMessage> HL7 V2.x MSH|... EVN|... PID|... PV1|... TXA|... OBX|1|ED|... |...

37. General Relationship to Messaging • CDA can be the payload in any kind of message • And can be passed from one kind to another V2 X12 V3 XDS

38. Primary Use Cases • access/portability/exchange • query/locate by patient, provider, practitioner, setting, encounter, date • access distributed information through common metadata • document management • integration • transcription systems • EHR records • re-use/derivative data • summaries, reports • decision support

39. CDA for Information Exchange in the US • Recommended by Health Information Technology Standards Panel (HITSP) work groups • CMS Notice of Proposed Rule Making • Claims attachments using CDA + X12 • First pilot concluded, others underway • Widespread vendor adoption: • Integrating the Healthcare Enterprise • CDA4CDT • Other

40. CDA Implementation Guides • The CDA itself is generic • To define specific requirements, CDA is constrained through Implementation Guides (IGs) • Specific use case, audience, application • Balloted Implementation Guides: • Continuity of Care, transfer of care • H&P, US realm, history-taking • Consult Report, US realm, consultations • Healthcare Associated Infection Reports, US CDC, National Healthcare Safety Network

41. Conformance to template ID • DOCUMENT LEVEL: <ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension='POCD_HD000040' root='2.16.840.1.113883.1.3'/> <templateId root='2.16.840.1.113883.10.20.1'/> … </ClinicalDocument> • PATTERN LEVEL: <Section> <templateId root='2.16.840.1.113883.10.20.1.14'/> … <Observation classCode=”OBS” moodCode=”EVN”> <templateId root='2.16.840.1.113883.10.20.1.32'/> … </Observation> </Section>

42. Validation • All instances are valid CDA • maintain and validate multiple document types using single generic schema • single stylesheet rendering • Schematron/XPath statements • validate constraints that can’t be specified in W3C schema language • validate constraints specific to IG

43. HL7/ASTM Continuity of Care Document (CCD) • A CDA Implementation Guide, issued April, 2007 • Constrains CDA to represent the data elements of the ASTM Continuity of Care Record (CCD)

44. ASTM CCR+HL7 CDA = CCD • CCR Primary use case • snapshot in time • summary of the pertinent clinical, demographic, and administrative data for a specific patient • CDA • supports professional society recommendations, national clinical practice guidelines, standardized data sets, etc... • ASTM CCR is a standardized data set that can be used to constrain CDA specifically for summary documents • Result: The Continuity of Care Document (CCD).

45. Continuity of Care Document CCD maps the CCR elements into a CDA representation.

46. Continuity of Care Document CCD maps the CCR elements into a CDA representation. <Results> <Result> <CCRDataObjectID> 2.16.840.1.113883.19.1 </CCRDataObjectID> <DateTime> <Type> <Text>Assessment Time</Text> </Type> <ExactDateTime> 200004071430 </ExactDateTime> </DateTime> <Type> <Text>Hematology</Text> </Type> <Description> <Text>CBC WO DIFFERENTIAL</Text> <Code> <Value>43789009</Value> <CodingSystem>SNOMED CT</CodingSystem> </Code> </Description> <Status><Text>Final Results</Text></Status> <section> <code code="30954-2“ codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <title>Laboratory results</title> <text> CBC (04/07/2000): HGB 13.2; WBC 6.7; PLT 123* </text> <entry> <observation classCode="OBS" moodCode="EVN"> <id root="2.16.840.1.113883.19" extension="1"/> <code code="43789009" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="CBC WO DIFFERENTIAL"/> <statusCode code="completed"/> <effectiveTime value="200004071430"/>

47. CDA beyond CCD • How do other exchange requirements relate to CCD? • Not everything we want to exchange is a summary or the same kind of summary • Some implementation guides re-use CCD templates • H&P, Consult... • Other implementation guides are strict constraints on CCD • P2P PHR

48. CDA for Common Document Types • Project initiated in January, 2007 • M*Modal • AHDI(was AAMT)/MTIA • AHIMA • Strong support from dictation / transcription and document management industries • Cooperation/coordination with HL7, IHE, EHR vendors and providers • Developed and brought to ballot: • History & Physical • Consult Report • Operative Note • Diagnostic Imaging Reports (with DICOM)

49. Other current projects • Pilots: • Healthcare Associated Infection Reports • with Centers for Disease Control and Prevention • CDA R2 reporting to the National Health Safety Network • Cancer Abstract submission • North American Association of Central Cancer Registries • Evaluation: • Long Term Care documentation • Quality reporting • Many domain-specific reports

50. Other CDA Implementation Guides • IHE • 2006: 1 content type built on HL7 CRS • 2007: 7 content types, some constrain CRS, others new • HITSP: included in all use cases – adopting pre-defined profiles, so far... • Providers: MHS, VA, Mayo, UPMC, NY Presbyterian, BIDMC, others • Internationally: sets of IGs in Germany, Finland, Greece, Canada, Japan, Korea, UK, France, Italy