IHE Retrieve Form for Data Capture (RFD) Profile IHE Retrieve Form for Data Capture (RFD) Profile Presented at NCDR.11

Profile: RFD 2 Integrating the Healthcare Enterprise™ A public-private collaboration Improve patient care and provider efficiency by harmonizing electronic health information exchange Facilitating standards-based connectivity in all products IHE Cardiology – sponsored by ACC, ASE, ASNC and HRS > 370 members: 55 healthcare professional organizations 15 government agencies 15 SDOs and trade associations 40 provider, research and education organizations 250 health IT and consulting companies Implementation guides for use of HL7, DICOM, and other standards to meet specific workflow challenges

Profile: RFD 3 Retrieve Form for Data Capture (RFD) a standard for research data collection from EMRs EMRs must support ever increasing research / quality data collection for diverse organizations Researchers need a way to integrate with a broad variety of EMRs Integration must facilitate prepopulation of data forms from EMR data RFD developed by IHE with - the clinical research standards organization EMRs have one interface supporting all research data entry EDCs have one interface supporting all EMRs Prepopulation based on patient document produced by EMR (e.g., Continuity of Care Document)

Profile: RFD 4 Form Filler EMR System 1. In patent record display, user selects form to be filled 2. EMR sends request for form with attached patient record extract (CCD) Form Manager Form Receiver EDC System 3. EDC prepopulates form with data from extract 4. EDC sends prepopulated form 5. User manually completes form 6. EMR sends completed form, stored in EDC database 7. QA manager reviews data, adds subsequent info (e.g., discharge data) 8. At end of reporting period, EDC creates consolidated submission, QA manager releases to agency QRDA

Profile: RFD 5 Other RFD Capabilities (Options) Form Archiving – submitted form may be independently archived for audit purposes Retrieve Clarification – Form Filler (EHR) can retrieve previously submitted forms that have been marked by Form Manager for rework/clarification

Profile: RFD 6 Yes, It’s Real! RFD demonstrated at IHE Connectathons by: EMRs: Allscripts, Cerner, e-MDs, Epic, GE Centricity, Greenway EDCs: Cerner, Fujitsu, IPL, IBM, Nextrials, OmniComm, Outcomes

Profile: RFD 7 RFD for NCDR Responsibility for data collection and quality remains with NCDR certified EDC systems Simplified integration with EMRs Prepopulation data in XML (HL7 CDA) Minimally patient demographics, current medications, dates of procedures (Continuity of Care Document) Additional prepopulation data from procedure-specific CDA reports (e.g., Cardiac Imaging Report)

Profile: RFD 8 Participating Actors Form Filler requests form from Form Manager Parameters formID – formID of the form being requested [Required] archiveURL – URL of form archiver [Optional] prepopData – data to be used to prepopulate the form [Optional] Retrieve Form Form Manager B Form Filler A Prepopulation Data (CDA) Form

Profile: RFD 9 Participating Actors Form Filler submits form data to Form Receiver Parameters instanceData – data to be submitted to the form receiver [Required] Submit Form Form Receiver C Form Filler A

Profile: RFD 10 Prepopulation data - CDA CDA is an XML structure that uses HL7 V3 Reference Information Model classes and data types CDA itself is not a specific type of health document, but can be used to define many types of documents using constraints A CDA document contains a standard header, and a document body The document body contains sections, all of which contain narrative text, and some of which contain structured and coded data elements There are many types of CDA documents, including: Continuity of Care Document (CCD – required by US Meaningful Use regs) XDS-MS Discharge Summary (HITSP C48) History and Physical (HITSP C84) Cardiac Imaging Report (in development by IHE Cardiology)

Sample CDA

Profile: RFD 12 Documents for NCDR prepopulation All EMRs will be producing CCDs to comply with Meaningful Use regulations More specific cardiology specific CDA document templates under development in IHE Cardiology Initial Cardiac Imaging Report Content (CIRC) to be released 2Q2011 Start with CCD, evolve to other document types

Profile: RFD 13 CCD Header - recordTarget Data ElementOptionalityXML structure location Date of BirthRpatientRole/patient/birthTime GenderR patientRole/patient/administrativeGender Code EthnicityOpatientRole/patient/ethnicGroupCode RaceR2patientRole/patient/raceCode NOTE: Optionality = R for Required, R2 for Required if known, O for Optional Slide courtesy of

Profile: RFD 14 CCD Header - recordTarget Name Gender Date of Birth Slide courtesy of

Profile: RFD 15 CCD Sections Overview Section NameOptionalityTemplate ID Active ProblemsR Past Medical History R Procedures and Interventions R Social HistoryR Current Medications R Vital SignsR Slide courtesy of

Profile: RFD 16 Data ElementOptionalityTemplate ID Physical ExamR Allergies and Other Adverse Reactions R Coded ResultsR CCD Sections Overview (ctd.) Slide courtesy of

Profile: RFD 17 CCD Medications Section LOINC code identifies this section as Medication history Narrative Text Structured Data Slide courtesy of

Profile: RFD 18 CCD Medications Section - text ID may be referenced in structured data Slide courtesy of

Profile: RFD 19 CCD Medications Section – coded entry Med start and end timeRoute Dose Medication Detail Slide courtesy of

Profile: RFD 20 CCD Section - manufacturedMaterial Medication code Decoded name Reference to original verbatim text Slide courtesy of

Profile: RFD 21 Although EMRs agree to send CCD, a transformation is still necessary to bridge from CCD to the world of research – this is readily done using XSLT Transformations Slide courtesy of

Profile: RFD 22 Simple variable name mapping: birthTime  BRTHDTC Transformations – Map Variables Slide courtesy of

Profile: RFD 23 Simple code mapping (M  1, F  2): administrativeGenderCode  GENDER Transformations – Simple Codes 1 2 Slide courtesy of

Profile: RFD 24 If CCD and target system use the same coding system, codes can be directly mapped If using different coding systems, several possible techniques: Pull verbatim text into the target system and re- code Use a thesaurus and allow selection from a possible set of equivalent codes in the target coding system Transformations – Drug Codes Slide courtesy of

Profile: RFD 25 Mapping between NCDR Cath-PCI and CDA NCDRCDANotes Field IDField NameField DescriptionField Value Set Hierarchical message component HL7 Value Set 210Patient First Name ClinicalDocument > recordTarget > patientRole > patient > name = name Name data type has HL7 defined markup for components (given and family names) patient demographics are arbitrarily associated with the unique ID record target participation 220Patient M.I.Patient Middle Initial 230Patient Last Name 240Patient SSNIndicate the nine-digit Patient’s Social Security Number (SSN). Although this is the Social Security Number in the USA, other countries may have different National Identification Numbers. For example, in Canada, this would be the Social Insurance Number. ClinicalDocument > recordTarget > patientRole > id = ssn providerOrganization > name = “US Social Security Administration” Alternatively, name of provider organization may be for another country 242Unique Patient ID This is an arbitrary number (not a recognizable ID like SSN or Medical Record Number) that uniquely and permanently identifies each patient. Once assigned to a patient, this can never be changed or reassigned to a different patient. If a patient returns to the hospital, they MUST receive this same unique patient identifier. ClinicalDocument > recordTarget > patientRole > id = unique id providerOrganization > name = hospital name SSN and unique ID are conveyed in separate record target participations; patient demographics (name, DOB, sex, race) are arbitrarily associated under this unique ID record target participation Mapping by E. Honeycut (DCRI) and H. Solomon (GE) for HL7 Cardiology SIG

Profile: RFD 26 Profile: RFD Next steps Read the RFD technical specification IHE_ITI_Suppl_RFD_Rev2-1_TI_ pdfhttp:// IHE_ITI_Suppl_RFD_Rev2-1_TI_ pdf Commit to implementation of RFD Participate in the Connectathon in January 2012 Join IHE International – it’s free! Engage in the domain technical committees – Cardiology, IT Infrastructure, or Quality, Research & Public Health Help create the CDA templates for Cath PCI Report and other NCDR-related encounters