Health Record Exchange for HEDISStars and Clinician Exchange

Health Record Exchange for HEDIS/Stars and Clinician Exchange Clinical Data Exchange (CDex) February 26, 2019

Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification bodies under programs requiring adherence to principles of openness, voluntariness, due process and non-discrimination. ANSI, therefore, brings significant, procompetitive benefits to the standards and conformity assessment community. ANSI nevertheless recognizes that it must not be a vehicle for individuals or organizations to reach unlawful agreements regarding prices, terms of sale, customers, or markets or engage in other aspects of anti-competitive behavior. ANSI’s policy, therefore, is to take all appropriate measures to comply with U. S. antitrust laws and foreign competition laws and ANSI expects the same from its members and volunteers when acting on behalf of ANSI. Approved by the ANSI Board of Directors May 22, 2014

Agenda for February 26, 2019 • Reminder: • CDex PSS is Sponsored by Patient Care, co-sponsor SDWG • PDex PSS is Sponsored by Financial Management (FM) • HRex PSS is Sponsored in Clinical Interoperability Council • Calendar ahead: • By 3/3 – Initial IG Content supplied. (Final by 3/24) • 2/28 – Seek approval of IG Proposal in PC WG (5: 00 pm ET) • FHIR Connectathon Track Proposal by 3/24 (request 1 document type, query for 1 data example) • Today’s focus: • (Lisa) Review the CDex FHIR IG, • Review how to contribute as an Author • Each CDex Use Cases may have multiple variants to show use of different interaction options for information exchange • (Rick) Review the HRx FHIR IG • (Rick) Review content in the Attachments IG to get input on its inclusion. • Homework: • Discuss if word document editing is making sense?

WIP Da Vinci 2019 Program View Actual Core Da Vinci Team Dec Jan Events & Communication Feb Marc h Prelaunch May June July Aug Sep Oct Nov Dec HIMSS Podium HL 7 Activities to Support Use Case 4 HL 7 WG FHIR Draft Project FMG Approval Gap Scope Approv s Analysis Statement al Connectathon April Profile and Operation Development Final “for Comment” HL 7 Ballot for Implementation. IG Guide for ballot Connectathon Reference Implementatio n Test Case Development Final STU Implementation Guide for ballot HL 7 Ballot for IG Connectathon 5

Definitions and Acronyms CRD - Coverage Requirements Discovery (UC #2) DTR – Documents Templates and Coverage Rules (UC #3) e. HRx (e. QDx, CDex, PDex) - e Health Record Exchange for HEDIS/Stars and Clinicain Exchange (UC #4) Deprecated term (e. QDx) covers exchange of Measure Data used to compute quality measures. This aspect of the project is now folded into DEQM – Data Exchange for Quality Measures (UC #1) MRP – Thirty Day Medication Reconciliation (UC #1) CDex covers exchange of Clinical Data. This cover the “clinical data” generated by Providers and shared with other Providers or Payers, such as medical histories, encounter summaries, or individual pieces of clinical data gathered during the course of care. PDex It covers clinical data available through Payers for sharing with Providers such as Payer Based Health Records and clinical data gathered through the claims process.

e. HRx Framework e. HRx electronic Health Record exchange Framework Interactions and Profiles DEQM Data Exchange for Quality Measures Framework e. QDx electronic Quality Data exchange Additional Measures for DEQM IG CDex electronic Clinical Data exchange PDex electronic Payer Data exchange

e. HRx Framework Implementation Guide Interactions Push (unsolicited, POST/PUT) e. HRx electronic Health Record exchange Other Artifacts FHIR Profiles DSTU 2 Argonaut Pull (GET) Bundles STU 3 US Core and QI Core Request (solicited) Value Sets R 4 US Core and QI Core Subscribe Mappings Non-US Core Bulk Data Provenance STU 2, STU 3, R 4 C-CDA on FHIR CDS Hooks Conformance HEDIS Operations Authentication/ Authorization Da Vinci (Payer) Specific Rational Combinations Validation Access Control/Audit Examples CIMI Extensions Notes: 1) Existing work is adopted by reference

CDex Content Requirements 1. Clinical Records of Care 2. Clinical Data Sets 3. Clinical Data

CDex 1. Clinical Data as “health records” generated by practitioners • Existing IG’s Use of C-CDA on FHIR (STU 3), C-CDA on FHIR (R 4) • A collection of various types of information gathered at a point in time • Potential for authentication; persistence; provenance; context Information can be viewed a specific data elements, sets of data elements, or larger collections of data elements defined through some mechanism such as a quality measure definition or a document profile/template.

Value Proposition for CDex WHY? Improve Coordinated Care and Network Performance Increase Operational Efficiencies Improve Quality of Care Reduce Burden of Quality Reporting

What do Payers do with clinical information? When does Payer need this clinical information? Who does the information come from/who is asked? CDex Summary (slide 1): What information is needed? (1)Create a complete clinical record to improve care coordination and provide optimum medical care (e. g. reduce redundant care, in order to shift to more proactive/timely care, make better informed, more accurate medical treatment recommendations). Always looking to find new conditions or a change in status regarding the existing conditions (based on HCC model) (regular data feeds is better) Needs to come from many/all providers, but typically from outpatient providers and usually from network providers. May use HIE’s if available to Payers. Medical records, a progress note or visit summary. C-CDA’s of various types (information supporting care planning). Medications, lab results, Assessment for Diagnoses, vital signs (BP). Narrative (clinical notes). (2)Create complete, accurate risk profiles for members for valuebased care contracts and population health adjustments. On an annual contracting basis. On a monthly basis, once new claims are paid. Risk adjustments are submitted to CMS annually. (could get it after each visit) Can come from any provider (one at a time), but typically from outpatient providers and usually from network providers. Data needs to come from the Provider’s Record. Medical records, a progress note or visit summary. C-CDA’s of various types. Medications, lab results, Assessment for Diagnoses, vital signs (BP). Narrative (clinical notes). (3)Augment claims data to satisfy quality reporting requirements and improve quality care scores, and to reduce preventable medical errors. Minimum 2 x per year, sometimes monthly. More frequent info would help improve scores. Can come from any provider. Typically outpatient providers. Directly from network providers. A combination of claims and clinical info. May use HIE’s if available to Payers. (Some auditing issues when getting data from an HIEs-more work required for proper attestation. ) Medical records, a progress note or visit summary, C-CDA’s of various types, but more oriented toward data points. Medications, lab results, Assessment for Diagnoses, vital signs (BP). Narrative (clinical notes).

CDex Summary(slide 2): What do Payers do with clinical information? When does Payer need this clinical information? Who does the information come from/who is asked? What information is needed? (4)Provide documentation to support prior authorization, claims processing, audit submitted claims, to confirm medical necessity and appropriateness. At the time prior authorization is requested, or during planning, ordering or delivery of service. Or, asynchronously, tied to another event such as audit or claim processing. From the provider ordering or providing services. Supporting documentation from consulting providers may be required. Progress note, encounter summary, results from diagnostic testing including diagnosis codes, assessment and diagnoses, records of treatment. (5)Improve member experience. (Improve processes between the payer and provider so member has fewer issues-less waiting, better planning/cost information) Allows the payer to have a more informed conversation with the member. Real-time/ongoing, closely tied to the point of care. This isn’t “another ask”, its about using the existing information to make processes run more smoothly. From the provider ordering or providing services. Supporting documentation from consulting providers may be required. (Patient information can flow into provider systems, direct collection of Patient info is out of scope. ) Information that helps a payer improve care management. Uses information gathered for other purposes. Info that helps provider greater transparency to the process. Treatment information that payers want to be able to support sharing with patients.

What is the key Use Case for Provider-to-Provider exchange? When does Provider need this Who does the information clinical information? come from/who is asked? What information is needed? (6)Support provider to provider orders and referrals. The receiving provider needs the order and supporting documentation as soon as it is signed. And the referring/ordering provider needs the results from the referral / order in a clinically significant time after the resulting work is completed. There may be a need to receive intermediate information (with each visit or at the end of some defined period for an extended process (e. g. home health). The signed order/referral and documentation to demonstrate medical necessity of the ordered services must be supplied by the ordering provider to the performing provider so that the performing provider has what is needed to submit the claim for the services. Initially, information comes from the ordering/referring provider. Then, once services begin to be provided, information comes from the performing provider.

1 6 Detailed Scope for May Comment Ballot CDex HRex Interactions 1) 2) 3) 4) 5) 6) Pull Push Request (Async)? Subscribe (repeated Pull)? Bulk Data CDS-Hooks 7) Operations Profiles 1) 2) 3) 4) 5) Argonaut (CCDS DSTU 2) US Core (STU 3) US Core (R 4) CCDA on FHIR (STU 3) CCDA on FHIR (R 4) 6) QI Core Other 1) 2) Provenance (who, when – at a min) Value Sets Scenarios 1) 2) 3) 4) 5) 6) Clinical information Provider to Payer for care coordination Clinical information Provider to Payer for risk adjustment Clinical information Provider to Payer for quality management Clinical information Provider to Payer for operations (prior authorization, claims processing and auditing, and confirm of medical necessity and appropriateness) Clinical information Provider to Payer to improve Member experience Clinical information Provider to Provider for completing referrals/orders Operations (by reference with specific requirements) 1) 2) 3) 4) 5) Pull Push Request Subscribe CDS Hooks Trigger with Payer Pull Payload Specifications for each Use Case 1) 2) 3) 4) CCDA Document Composition Bundle based on US Core/Argonaut a. Single clinical resource b. Multiple clinical resources Bulk Data (need for May? )

Types of Payloads by Business Need Payload Description my range from a specific C-CDA R 2. 1 document type (exchanged using FHIR mechanisms) to a C-CDA on FHIR Document, to a specific Bundle of FHIR Resources, to a single named FHIR Resource. Payload Description Business Need Supported CCDA Progress Note Template, Encounter Based and includes the legal authenticator Medical Record Acquisition for Risk Adjustment. Trigger is upon a physician signing off on a note and the EMR knowing the patient is a particular payer’s member. Record is pushed to Provider CCDA Progress Note Template, Encounter Based and includes the legal authenticator Medical Record Acquisition for closing gaps in care. Timing – signature + 2 -3 days to allow time for lab data to come in. Chart chasing could be a trigger, this is a cyclical process. This is seasonal. In the season of obtaining records. 3 -4 times per year (risk adjustment season and HEDIS season)

Content Requirements Data Ex. Use Case: Provider receives clinical information from Payers to improve knowledge of patient’s medical history. • Patient • Encounter • Coverage • Condition (by Encounter) • Medication. Statement • Medication. Dispense • Procedure (by Encounter) • Immunization. Recommendation • Device. Use. Statement “Data Containers” Use Case: Payers receives clinical data electronically to support Payer workflows for Value Based Case. • Progress Note Provenance Requirements Subjective Information Objective Information Assessment Information Plan Information Human presentation matches EMR output • Same content as EMR output • Encounter Context • Legally Authenticated • • Other relevant documents are also provided

Pre-Packaged Information Building Blocks Subjective Reason for Visit Reason for Referral Chief Complaint Reason for Visit Chief Complaint Health Concerns Allergies & Intolerances Review of Systems History Present Illness History Past Illness Social History Family History Objective Problem Medical (Gen) History Medications Immunizations Implants Medical Equipment Procedures Results Vital Signs Admission Diagnosis Admission Meds Course of Care Hospital Course Hospital Consultations Medications Administered Anesthesia Procedure Indications Procedure Description Procedure Specimens Procedure Est. Blood Loss Procedure Findings Procedure Implants Procedure Disposition Preoperative Diagnosis Surgery Description Op Note Surgical Procedure Operative Note Fluids Surgical Drains Complications Hospital Discharge Studies Sum Hospital Discharge Physical Advance Directives Payers Encounters Physical Exam Findings Health Status Eval/Outcomes General Status Functional Status Mental Status Nutrition Assessment Postprocedure Diagnosis Postoperative Diagnosis Discharge Diagnosis Assessment & Plan of Treatment Goals Planned Procedure Instructions Hospital Discharge Instructions Discharge Medications Discharge Diet

Pre-packaged data set (Progress Note): Other Clinical Notes “Open Packaging” Allows other sections of information to be added.

Discharge Summary Story Subjective Reason for Visit Reason for Referral Chief Complaint Reason for Visit Chief Complaint Health Concerns Allergies & Intolerances Review of Systems History Present Illness History Past Illness Social History Family History Objective Problem Medical (Gen) History Medications Immunizations Implants Medical Equipment Procedures Results Vital Signs Admission Diagnosis Admission Meds Course of Care Hospital Course Hospital Consultations Medications Administered Anesthesia Procedure Indications Procedure Description Procedure Specimens Procedure Est. Blood Loss Procedure Findings Procedure Implants Procedure Disposition Preoperative Diagnosis Surgery Description Op Note Surgical Procedure Operative Note Fluids Surgical Drains Complications Hospital Discharge Studies Sum Hospital Discharge Physical Advance Directives Payers Encounters Physical Exam Findings Health Status Eval/Outcomes General Status Functional Status Mental Status Nutrition Assessment Postprocedure Diagnosis Postoperative Diagnosis Discharge Diagnosis Assessment & Plan of Treatment Goals Planned Procedure Instructions Hospital Discharge Instructions Discharge Medications Discharge Diet

Evaluation Visit (H&P) Story Subjective Reason for Visit Reason for Referral Chief Complaint Reason for Visit Chief Complaint Health Concerns Allergies & Intolerances Review of Systems History Present Illness History Past Illness Social History Family History Objective Problem Medical (Gen) History Medications Immunizations Implants Medical Equipment Procedures Results Vital Signs Admission Diagnosis Admission Meds Course of Care Hospital Course Hospital Consultations Medications Administered Anesthesia Procedure Indications Procedure Description Procedure Specimens Procedure Est. Blood Loss Procedure Findings Procedure Implants Procedure Disposition Preoperative Diagnosis Surgery Description Op Note Surgical Procedure Operative Note Fluids Surgical Drains Complications Hospital Discharge Studies Sum Hospital Discharge Physical Advance Directives Payers Encounters Physical Exam Findings Health Status Eval/Outcomes General Status Functional Status Mental Status Nutrition Assessment Postprocedure Diagnosis Postoperative Diagnosis Discharge Diagnosis Assessment & Plan of Treatment Goals Planned Procedure Instructions Hospital Discharge Instructions Discharge Medications Discharge Diet

Medical History Over a Range of Time Subjective Reason for Visit Reason for Referral Chief Complaint Reason for Visit Chief Complaint Health Concerns Allergies & Intolerances Review of Systems History Present Illness History Past Illness Social History Family History Objective Problem Medical (Gen) History Medications Immunizations Implants Medical Equipment Procedures Results Vital Signs Admission Diagnosis Admission Meds Course of Care Hospital Course Hospital Consultations Medications Administered Anesthesia Procedure Indications Procedure Description Procedure Specimens Procedure Est. Blood Loss Procedure Findings Procedure Implants Procedure Disposition Preoperative Diagnosis Surgery Description Op Note Surgical Procedure Operative Note Fluids Surgical Drains Complications Hospital Discharge Studies Sum Hospital Discharge Physical Advance Directives Payers Encounters Physical Exam Findings Health Status Eval/Outcomes General Status Functional Status Mental Status Nutrition Assessment Postprocedure Diagnosis Postoperative Diagnosis Discharge Diagnosis Assessment & Plan of Treatment Goals Planned Procedure Instructions Hospital Discharge Instructions Discharge Medications Discharge Diet

Depiction of Pre-Packaged “header” information

Provenance/Contextual “meta” information Information SHALL enable the following questions to be answered: Who is the Patient and what are their “demographics” What Identifiers are used for this person by the organization providing care to this person What encounter was this information produced after/is this information associated with? What was the time and place of the encounter Who was the responsible Provider (with NPI and NUCC qualifications) What is the definition of an “encounter”? What type of Services were provided at this Encounter Was this for a F 2 F visit? What type of service(s) were performed? Which provider is the patient’s PCP? (May need other roles played by involved providers) The care team for the patient may be specific to a condition being treated Did any orders get placed at this encounter? For what types of services? Who is the provider of record for the encounter (By NPI number and with qualifications)? Did any prior Orders get fulfilled at this encounter? Did any new orders get placed? If so, a request could go out to send the information once the order is completed. (This prevents the order from “getting lost”. )

Provenance/Contextual “meta” information Information SHALL enable the following questions to be answered: Does this information replace previous records? (Corrected data, revisions, new versions of prior info) Did the responsible provider attest to and authenticate (“sign”) the information? Information has to have ownership – know who authored it and where it came from Indicate that the Digital Signature SHOULD be included to establish non-repudiation of the “signatures” Which information did the responsible provider attest to? The legal authenticator is not “attesting” –the information should have an attributed author or source. Only “attributed” information is shared. Human readable information appears as it does in the EMR (no technology to guaranty this. ) Clinical content in the narrative preserves the content that the signing provider attested to. This only pertains to the narrative. The narrative must reflect all the clinical information in the discrete data of the entries. (Align to what the attachments guide says. ) May include PDF showing how the corresponding information looked that the physician signed. (a specific format should not be a requirement so long as the content is shared. ) Does the PDF need to include the provider’s signature. Digital Signature SHOULD be included to establish nonrepudiation of the “signatures”

Needed information Subjective: Chief Complaint or Reason for Visit (Narrative) History of Present Illness (Narrative? Coded if possible? ) Social History (coded with SCT, ICD-10) Problem List (a list of active Diagnoses coded with SCT, ICD-10) History of Procedures (a procedure coded with CPT, ICD-10, HCPCS) Medications List (coded with Rx. Norm) Immunizations (coded with CVX) Allergy/Intolerance Concerns (SCT, Rx. Norm) Objective: Vital Signs (coded with LOINC) Physical Exam (narrative) Device Information (HCPCS) Health Status Information (may be used for risk assessment) Results (A test result, coded with LOINC) Assessment: Def: narrative clinical note of the Provider’s assessment. (note: structured assessments are in the Results Section, i. e. PHQ-9) Plan: Interventions – performed during this visit (coded with CPT or ICD-10) Interventions - planned/ordered for the future (coded with CPT or ICD-10) Interventions – relevant prior procedures related to the problem for this visit.

Additional Needed information Payer Information: Is this needed? This may not be in the EHR. We don’t get this today, or May only get it at a high level. Review the Payer Value Set

Types of Payloads by Business Need Payload Description my range from a specific C-CDA R 2. 1 document type (exchanged using FHIR mechanisms) to a C-CDA on FHIR Document, to a specific Bundle of FHIR Resources, to a single named FHIR Resource. Payload Description Business Need Supported CCDA Progress Note Template, Encounter Based and includes the legal authenticator Medical Record Acquisition for Risk Adjustment. Trigger is upon a physician signing off on a note and the EMR knowing the patient is a particular payer’s member. Record is pushed to Provider CCDA Progress Note Template, Encounter Based and includes the legal authenticator Medical Record Acquisition for closing gaps in care. Timing – signature + 2 -3 days to allow time for lab data to come in. Chart chasing could be a trigger, this is a cyclical process. This is seasonal. In the season of obtaining records. 3 -4 times per year (risk adjustment season and HEDIS season)

Types of Payloads by Business Need Payload Description my range from a specific C-CDA R 2. 1 document type (exchanged using FHIR mechanisms) to a C-CDA on FHIR Document, to a specific Bundle of FHIR Resources, to a single named FHIR Resource. Payload Description Business Need Supported [CCDA document template? ] Payer Based Health Record (mostly claims based information) Provide a 360 degree view of the member to the Provider. Trigger off a scheduled appointment. Payer based data is used to determine info is missing. This becomes a request for Provider Action to add documentation to resolve the issue. Provider send back info – current visit information showing how they resolved the open “clinical inference” issue. (agree, disagree, address it later, resolved) Clinical Inference of patient condition. Example: payer has paid for a prescription for Metformin…. seems like they are a diabetic, but do not have a claim with a diagnosis of Diabetes. Clinical info can be used to resolve the open issue (or a claim)

Definitions Encounter Episode of Care • An interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient. • An association between a patient and an organization / healthcare provider(s) during which time encounters may occur. The managing organization assumes a level of responsibility for the patient during this time.

Encounter A patient encounter is further characterized by the setting in which it takes place. Amongst them are ambulatory, emergency, home health, inpatient and virtual encounters. An Encounter encompasses the lifecycle from pre-admission, the actual encounter (for ambulatory encounters), and admission, stay and discharge (for inpatient encounters). During the encounter the patient may move from practitioner to practitioner and location to location. Because of the broad scope of Encounter, not all elements will be relevant in all settings. For this reason, admission/discharge related information is kept in a separate Hospitalization component within Encounter. The class element is used to distinguish between these settings, which will guide further validation and application of business rules. There is also substantial variance from organization to organization (and between jurisdictions and countries) on which business events translate to the start of a new Encounter, or what level of aggregation is used for Encounter. For example, each single visit of a practitioner during a hospitalization may lead to a new instance of Encounter, but depending on local practice and the systems involved, it may well be that this is aggregated to a single instance for a whole hospitalization. Even more aggregation may occur where jurisdictions introduce groups of Encounters for financial or other reasons. Encounters can be aggregated or grouped under other Encounters using the part. Of element.

Draft HL 7 Project Scope

Work Group Engagements

US Core (US-Core) IG • The US Core Implementation Guide covers the 2015 Meaningful Use Common Clinical Data Set (CCDS) and defines the minimummandatory conformance requirements needed for accessing patient data based on the Argonaut pilot implementations. The US Core artifacts are consistent with the Argonaut DSTU 2 -based Data Query IG and Arganaut STU 3 based Provider Directory IG. This implementation guide forms the foundation to build future US Realm FHIR implementation guides and its content will continue to grow to meet the needs of US implementers. • http: //hl 7. org/fhir/us/core/

HEDIS IG • NCQA's Healthcare Effectiveness Data and Information Set (HEDIS) is a tool used by more than 90 percent of America's health plans to measure performance on important dimensions of care and service. Altogether, HEDIS consists of 81 measures across 5 domains of care. Because so many plans collect HEDIS data, and because the measures are so specifically defined, HEDIS makes it possible to compare the performance of health plans on an "apples-to-apples" basis. • Modern value-based care involves calculating payer-relation quality measures–– this calculation relies on access to patient information. FHIR's secure, RESTful, standards-based services for accessing patient information streamlines this process. By combining FHIR with shareable knowledge artifacts, we significantly reduce the amount of engineering effort required to implement and maintain useful HEDIS quality measure calculations for payers. Healthcare providers also experience reduced effort, as responding to quality reporting requests is greatly simplified with this approach. • HEDIS IG - http: //build. fhir. org/ig/cqframework/hedis-ig/

Past Agendas

Agenda for February 19, 2019 • Reminder: • CDex PSS is Sponsored by Patient Care, co-sponsor SDWG • PDex PSS is Sponsored by Financial Management (FM) • HRex PSS is Sponsored in Clinical Interoperability Council • Calendar ahead: • By 3/3 – Initial IG Content supplied. (Final by 3/24) • FHIR Connectathon Track Proposal by 3/24 (request 1 document type, query for 1 data example) • Today’s focus: • (Rick) Review the CDex FHIR IG, Review how to contribute as an Author • Each CDex Use Case may have multiple variants to show use of different interaction options for information exchange • (Rick) Review the HRx FHIR IG, Discuss how CDex will Reference HRex • Homework: • Review and recommend edits for the CDex TOC structure • Provide content or edits for the IG • Create a word doc of an IG section, track changes, make edits or draft material • Send word file to Lisa. Lnelson@max. md 401 219 1165

Agenda for February 5, 2019 • CDex PSS will be Sponsored in Patient Care, co-sponsor SDWG • Calendar ahead: • 2/12 and 2/14, 2/15 Calls cancelled • HRex Informal meet-up at the Interoperability Showcase (Tues @ noon ET) • Today’s focus: • (Lisa) Complete summarizing key Use Cases • (Rick) Review the IG detailed scope plan • Homework: • Send the table out in mail via a word document – Last chance to word smith. • Going forward – work on a small chunk of content in MS Word – short window to offer edits—copy will be folded into the emerging IG Send your input to Lnelson@Max. md (401) 219 -1165

Agenda for January 8, 2019 • Updated on e. HRx Document • Update on PSS Creation • Approach for CDex Content work • Calendar ahead: • 1/15 (CDex) Cancelled • Homework: • Read and Provide feedback on the Use Cases in the e. HRx Document • Read C-CDA on FHIR Profile for Progress Note Discuss specific commitments by participants—this is a team effort! Send your input to Lnelson@Max. md

Agenda for January 22, 2019 • CDex PSS will be Sponsored in Patient Care, co-sponsor SDWG • Calendar ahead: • 2/12 (CDex) Cancelled • Today’s focus: • • • Summarize answers to these key questions: Why do payers need clinical information? When do payers ask for clinical information? Who do payers ask for this information? What information and why? • Homework: • Review the table – slides 13 -14. • Look for omissions. Think about how you would populate the remaining table cells. Send your input to Lnelson@Max. md

Agenda for January 29, 2019 • CDex PSS will be Sponsored in Patient Care, co-sponsor SDWG • Calendar ahead: • 2/12 (CDex) Cancelled • Informal meet-up at the Interoperability Showcase (noon ET) • Lisa will send invite for this optional meet-up • Today’s focus: • Complete summarizing answers to these key questions: • Review the IG detailed scope plan • Renaming – Health Record Exchange framework HRex, CDex, PDex • No more little e • Homework: • Review the table – slides 13 -14. • Look for omissions. Think about how you would populate the remaining table cells. Send your input to Lnelson@Max. md (401) 219 -1165