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

www.IHE.net

> 370 members: 55 healthcare professional organizations15 government agencies15 SDOs and trade associations40 provider, research and education organizations250 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 ManagerForm 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 Element Optionality XML structure location

Date of Birth R patientRole/patient/birthTime

Gender R patientRole/patient/administrativeGenderCode

Ethnicity O patientRole/patient/ethnicGroupCode

Race R2 patientRole/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 Name Optionality Template ID

Active Problems R 1.3.6.1.4.1.19376.1.5.3.1.3.6

Past Medical History R2 1.3.6.1.4.1.19376.1.5.3.1.3.8

Procedures and Interventions R2 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11

Social History R2 1.3.6.1.4.1.19376.1.5.3.1.3.16

Current Medications R 1.3.6.1.4.1.19376.1.5.3.1.3.19

Vital Signs R2 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2

Slide courtesy of

Profile: RFD

16

Data Element Optionality Template ID

Physical Exam R2 1.3.6.1.4.1.19376.1.5.3.1.1.9.15

Allergies and Other Adverse Reactions

R 1.3.6.1.4.1.19376.1.5.3.1.3.13

Coded Results R2 1.3.6.1.4.1.19376.1.5.3.1.3.28

CCD Sections Overview (ctd.)

Slide courtesy of

Profile: RFD

17

CCD Medications Section

LOINC code identifies this section as Medication historyNarrative 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 time Route

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

<ItemData ItemOID='BRTHDTC'> <xsl:attribute name="value"

select="ClinicalDocument/recordTarget/patientRole/patient/birthTime/@value"/>

</ItemData>

Slide courtesy of

Profile: RFD

23

Simple code mapping (M 1, F 2):

administrativeGenderCode GENDER

Transformations – Simple Codes

<ItemData ItemOID='GENDER'> <xsl:attribute name="value"><xsl:choose> <xsl:when test="…/administrativeGenderCode='M'"> 1 </xsl:when> <xsl:when test="…/administrativeGenderCode='F'"> 2 </xsl:when></xsl:choose></xsl:attribute></ItemData>

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

NCDR CDA NotesField ID Field Name Field Description Field Value

SetHierarchical message component

HL7 Value Set  

210 Patient First Name

Patient 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

 

220 Patient M.I. Patient Middle Initial  230 Patient Last

NamePatient Last Name  

240 Patient SSN Indicate 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 = ssnproviderOrganization >name = “US Social Security Administration”

Alternatively , name of provider organization may be for another country

 

242 Unique 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 idproviderOrganization >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• http://www.ihe.net/Technical_Framework/upload/

IHE_ITI_Suppl_RFD_Rev2-1_TI_2010-08-10.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