1. Women’s Health Technologies CRN
Clinical Working Groups and Informatics Working Group Coordination:
Harmonizing and standardizing
Core Data Elements
Julia Skapik, Terrie Reed,
Cognitive Medicine FDA
(Moderator)
Lisa Lang, Farrah Darbouze,
NLM ONC

2. Agenda Overview of CDE Work WHT Federal Partners and their Roles
Updates on Key Activities
Harmonization and standardization of Core Data Elements (CDEs) identified by Clinical Working Groups
Outcomes from the registry environmental scan
Instantiation of core minimum set in the HL7 Implementation Guide
Pilot: Evaluate WHT-CRN’s ability to address priority questions from stakeholders
Next Steps: Timeline and deliverables
Discussions across stakeholder groups

3. What is a Common Data Element?
Basic Definitions
Data Element (DE) - Information that describes a piece of data to be collected. The DE does not include the data themselves.
According to ISO/IEC terminology, a Data Element is the fundamental unit of data that an organization disseminates.
Attributes of DEs often include: name, definition, modifiers or restrictions, value set, and context
Common Data Element (CDE) – A clearly defined data element that is common to multiple data sets across different use cases.
Can be required for some use cases including programs, standards, and reporting purposes.
Sources Definition
1) Health IT Enabled Quality Improvement – A Vision To Achieve Better Health and Health Care. ONC 2)
3)Demonstrating “Collect once, Use Many” Assimilating PH Secondary Data Use Requirements into an Existing DAM
4) From PowerPoint presentation 5)

4. PCOR TF Project Goal: Collect Once, Use Many Times
Research,
Comparative
Effectiveness
Clinical
Decision
Support
Public & Population
Health
Quality
Measurement & Patient
Safety
Business
Operations,
Administration
Clinical Data
US CDI (w/UDI)
WHT CDE
Provided by courtesy of Donald T. Mon, PhD
Adapted by T. Reed
We must look ahead to what is required for secondary data use and integrate those requirements in primary data collection

5. “Common” Does Not Mean “Similar”
Anyone can create well-specified data elements– but what makes CDEs common is that they are SHARED
Otherwise – semantic interoperability cannot be guaranteed. That means not just a name, but:
Format/standard
Terminology bindings
Optionality vs required elements
And USE! (i.e. someone other than you)
Currently, ONC/CMS/NIH/others oversee different large-scale efforts to identify sets of “common data elements,” but use cases differ; overlapping CDEs pose burden for systems and users. 
Fundamental goal for optimal use/reuse of data: CDEs that span patient care, research, administrative and other use cases
Source:

6. Clinical System to Registry Swivel Chair Interoperability Wes Rishel
Desired State:
Clinical Systems
Registry Data Entry

7. HL7 Common Clinical Registry Framework
GOAL: Create a domain analysis model (DAM) to define commonalities (functions and data) across most registry systems. This scope will cover Clinical Data and Disease Registries. The audience includes developers, implementers, owners and those entities (includes EHR or CIS vendors)who exchange data with registries
Define what is common across Registries
Identify what standards exists to support Registries
Identify gaps in standards to support Registries

8. Improving Healthcare Data Interoperability Focus on US Core Data for Interoperability (USCDI)
Patient name
Date of birth
Race
Smoking status
Lab values / results
Problems
Medication allergies
Care team members
Immunizations
UDI
Provenance
Sex
Preferred language
Ethnicity
Laboratory tests
Vital signs
Medications
Health concerns
Assessment / plan of rx
Procedures
Goals
Clinical notes
See

9. Example: SEX Example: Sex
Clinical concept label: Sex [Birth Sex, Sex (Birth Sex)]
Clinical definition: A person's biological sex, assigned at birth, not to be confused with the social construct of gender.
Clinical allowed values: F, M, UNK [Female, Male, Unknown]
Database field label: SEX
Database field data type / format: Value Set – Char(3)
Database field business rules:
Database allowed values: F | M | UNK
Allowed values definitions: Female, Male, Unknown - a proper value is applicable, but not known. Includes ambiguous, variations of unknown, and variations of null.
Reference ontology concept: LOINC: LL3324-2, Sex assigned at birth
Reference ontology allowed value bindings: LOINC: LA3-6, LOINC: LA2-8, LOINC: LA4489-6
FHIR Profile: FHIR Resource: Value Set:
Sources / references / notes: USCDI

10. Unique Device Identification
Compliance -Class III, Class II and implantable life supporting/life sustaining devices meeting UDI regulatory requirements
Data million records in AccessGUDID
Health IT EHR vendors certified for implantable device UDI capture; registries and other data sources using APIs and downloads
Standards - HL7 CDA template for UDI; HL7 FHIR device resource; HL7 UDI Harmonization Pattern
International Medical Device Regulatory Forum – UDI Application Guide (imdrf.org)

11. Women’s Health Technology Informatics Working Group – Federal Leadership
National Institutes of Health (NIH)/National Library of Medicine (NLM)
Provide guidance and best practices for data collection, reuse of high quality CDEs and forms, and tooling to support the reuse and creation of CDEs and forms.
Provide curation services and copyright verification services for the minimum core set of data elements and forms to be used by the identified registries.
Leverage NLM clinical data standards and clinical work.
Food and Drug Administration (FDA) Informatics
Project Management over the PCORTF Informatics team.
Model the PCORTF WHT project requirements (including the device’s UDI) into data exchange messages (e.g. HL7 FHIR).
Identify and resolve data quality issues with GUDID entries for WHT-CRN devices.
Enable interface with the GUDID to enhance the CRN tools.
The Office of the National Coordinator for Health Information Technology (ONC)
Leverage existing work being done in the research community and utilize national health standards to test the building of an infrastructure examining women’s health technologies.
Recruit pilot participants and propose an analytical framework to address feasibility issues for each of the identified registries.

12. Overview of Key Steps for CRN-CDE Harmonization and Standardization
Clinical Working Groups (CWG)
Identify and refine CDEs (e.g. DELPHI)
Format CDEs using CDE Template
Provide additional information as needed to IWG
Provide support as IWG harmonizes / standardizes CDE
Interactive and iterative process between IWG and CWGs to harmonize and standardize CDEs
Informatics Working Group (IWG)
Develop CDE template and Orient CWGs to harmonization / standardization process for CDEs
Review completed CDE Template and work with CWG to get needed data
Harmonize / standardize CDEs, using existing resources / other CDEs when possible
Iterative process to get feedback from CWGs on CDEs during harmonization / standardization
Informed by external stakeholders (e.g., ONC USCDI and HL7 CCRF activities)

13. CRN CDE Collection – Target Endpoint
Registry1 CDE
Registry3
CDE
Registry2
Shared Elements (e.g. Registry 1 + 2)
US Core (Demographics)
Common Elements
This is a dynamic and evolving process, with ONC leading the effort to develop Phase 2 (US Core)
Registry-specific Elements (non-shared)

14. Objective – Move from Concept to Precise Definitions
Moving from concept to precisely-defined CDEs has many moving parts and interactive steps
Discovery
Local Agreement
Global Harmonization
Keep it simple to start
Identify and organize the concepts within generic domains (i.e. shared across clinical working groups)
Capture minimum sets of required elements and refine each iteration
Grow the complexity
Increase precision of variable definitions
Identify clinical measures
Develop technical representations for variables (e.g. data format, code values/value sets
Deliver a harmonized set of CDEs with respect for the unique needs of the individual domains

15. CDE Spreadsheet Template
Variable
Description
Unique ID
Assign a unique ID to each data element (System Assigned)
Technical Short Name *
This is an abbreviated name for the data element typically for database purposes.
Data Element Short Name *
Short (familiar) name for the concept.
Data Element Label * (Long Name/Question Text)
The full name for the concept or the Question text. This should be recognizable to both a business and technical person.
Data Element Definition *
A short description of the data element and its concept. This should align to other sources to ensure interoperability and include synonyms or any alternate names used for the same concept (e.g., first and last name would be synonyms of given and family name (respectively)).
Data Type *
How the data should be collected (e.g., code, numeric, alphanumeric, Boolean, value set)
Value parts + (UOM, Range, Limits, Numerical Precision, Conditional Logic)
If a value is structured and has multiple parts, they should be identified as individual attributes o E.g., measurements have a value and unit of measure (e.g., 5 cm) o E.g., ranges have the potential for an upper and lower value and unit of measure (e.g., temperature of 96F – 100F)
Value set (Value) +
List each value in the value set (part of a Value:Meaning pair, see element below)
Definitions of the elements of the value set (Value Meaning)+
Provide a definition for each value in the value set.
Code System +
For codified values, do we know of a code system that could be used
Reference source * (if known) (Reference Document)
Provide a reference for the value set, especially if it is different than the code system. In some cases, there will not be an associated code system for the value set)
Classification +
Organizing principle, Delphi priority. Where does it fit? How are you thinking about it?
Frequency of Collection
If this data element is collected in set interval and/or a particular frequency - please note it here.
Example Data
Examples are great to verify form and intent. Include whenever possible.
Harmonization process
Starting with focusing on the Question, e.g. Data Element Label – Long Name/Question Text) to identify common terms/concepts
Comparing the concepts across the 4 registries using the 4 completed templates and 1 data dictionary, to identify the questions/answers that are included in at least 2 of the 4 groups and see if they are similar
Review of national standards to identify if there is a standard for the asking/answering the question, e.g. USCDI, FHIR, LOINC, SNOMED
Recommendations for harmonized set for feedback – the recommendation could include:
A harmonized question with an aggregation of values from all working groups
A 5th way of asking the question, based on recommended standards

16. Identification of Common Concepts: Weight, Height, BMI
Sterilization UF
POP
SUI
Other: LOINC
Weight X
(pounds)
Weight (kgs/lbs)
Weight (in pounds)
3141-9: Body weight measured
Height
Height (feet, inches)
Height (cm/inches)
Height (in inches)
8302-2: Body height
BMI
MI (Respondents can choose to enter both Height and Weight, or just enter BMI. BMI=(weight in pounds/height in inches^2)*703)
Body Mass Index (BMI=(weight in pounds/height in inches^2)*703))
: Body mass index (BMI) [Ratio]
Example of common demographic concepts in registries that we can define based on existing codes (LOINC). Note that BMI, a desired variable by two of the registries, is a derived/computed variable from height and weight.

17. Identification of Common Concepts: Pelvic Pain
Sterilization UF
POP
SUI
Other: LOINC
Question
Does the patient have pelvic pain?
What fibroid-related symptoms are you currently experiencing?
Short-term Follow-up (30-90 days), Complications noted at short-term follow-up (30-90 days), If yes, select all complications that occurred (see drop down list options below- one option is pelvic pain)
Have you had pain in the pelvis, vagina, or groin, that lasted at least 4 week that was not present before your surgery?
1) : I have discomfort or pain in my pelvic area in the past 7 days [FACIT]
2) : I have pain in my pelvic area in the past 7 days [FACIT]
Answer
Y/N
Permitted values includes: Pelvic pain regularly requiring either over the counter or prescription medications & Abdominal or pelvic pressure; Abdominal bloating
LL2095-9, Permitted values:
Very much
Quite a bit
Somewhat
A little bit
Not at all
Moving to WHT Concepts: Common concept but note different wording of questions, different permitted values – ultimately resolve to one data element or many?
Example of how challenging it will be to coordinate across even a straightforward overlapping concept “pelvic pain.” EG, Is there a rationale/literature behind timeframe (pain currently or in past 7, 30, 90 days)?
What’s good process for definitively coming to agreement? Who, what consultative/Delphic process?
If not resolvable in this timeframe, might just be part of later phase…

18. Identification of Common Concepts: Pregnancy History: Number of Pregnancies
Sterilization UF
POP
SUI
Other: LOINC
Question
Gravidity: How many previous pregnancies has the patient had? - the number of pregnancies, current and past, regardless of the pregnancy outcome.
If yes, how many pregnancies have you had?
1) Gravidity: The number of pregnancies, current and past, regardless of the pregnancy outcome
2) Parity: The number of vaginal and cesarean deliveries (live births) X
1) : Including live births, stillbirths, miscarriages, abortions, and tubal and other ectopic pregnancies, how many times have you been pregnant [PhenX]
2) : [#] Births total
3) : Previous cesarean deliveries #
4) : [#] Parity
Answer
Numeric
Here is example of a clinical data element with slight differences in the question, but the same permitted values - will need to get agreement on meaning of question, but seems (at this point) straightforward to harmonized.
NOTE: We are starting our identification of potential harmonization candidates looking for concepts common to a minimum of just two registries.

19. Identification of Common Concepts: Pregnancy History: Outcome of Pregnancies
Sterilization UF
POP
SUI
Other: LOINC
Question
Outcome of previous pregnancies
Outcome by Pregnancy #
1) Vaginal Births
2) C-Sections X
1) : Was your pregnancy a live birth, stillbirth, miscarriage, abortion, or ectopic pregnancy [PhenX]
2) : Pregnancy sequence [PhenX]
Answer
Permitted values: first trimester miscarriage, second trimester miscarriage, term pregnancy, first trimester elective abortion, second trimester elective abortion, preterm delivery, term delivery
Permitted values: Delivered; Miscarriage; Elective or Therapeutic Abortion; Stillbirth; Tubal or Ectopic Pregnancy
1) Numeric
2) Y/N
1) LL1232-9, Permitted values: Live birth, Stillbirth, Miscarriage, Abortion, Ectopic/Tubal, Currently pregnant, Other
2) LL1476-2, Permitted values: Pregnancy 1...Pregnancy 6
Opportunity to examine alternative approaches to same question – specific info by pregnancy sequence or general list…

20. An example of one potential end state: a Form with a harmonized set of data elements; underlying structure would support data capture of pregnancy outcome for each pregnancy.

21. Overview
Current State: Report out of ONC Environmental Scan
Moving Towards Coordination: Implementation Guide
Testing it Out: Pilots & Pilot Development
Timelines

22. Current State: Report out of ONC Environmental Scan
During the spring of 2018 the ONC Team conducted an environmental assessment to understand the current state of women’s health registries and CRNs. Various stakeholders working with women’s health registries were interviewed and asked to:
Examine the current state and use of standards & other relevant tools;
Analyze current registries to address pilot feasibility; and
Examine metadata and descriptive statistics for each CRN.
Stakeholders included:
FDA Clinical Workgroups: Sterilization/LARC (Long Acting Reversible Contraceptives); Pelvic Organ Prolapse (POP); and Uterine Fibroids (UF)
Comparing Options for Management Patient Centered Results for Uterine Fibroids (COMPARE-UF)
The American College of Obstetricians and Gynecologists (ACOG)
Society of Urodynamics, Female Pelvic Medicine & Urogenital Reconstruction (SUFU)
The American Urogynecologic Society (AUGS); Stress Urinary Incontinence (SUI) Surgery Registry; The Pelvic Floor Disorders Registry (PFDR); and, Urogynecology Quality Registry (AQUIRE)
Examine the detailed metadata and descriptive statistics for each CRN describing:
Population demographics
Device Exposure
Relevant clinical outcomes captured
Disease prevention
Follow-up duration
CRN Stakeholders included:
Sterilization/LARC
POP UF
COMPARE-UF
ACOG
SUFU
AUGS
SUI
Surgery Registry
PFDR
AQUIRE

23. Current State: Environmental Scan Key Findings
The environmental assessment outlined several key findings, including:
Variations in the operational capabilities of the registries
Variations in the data collection process
Minimal adoption of technical standards among the registries

24. Current State: Environmental Scan Additional Findings
Additionally, there was variation in the data elements captured
Registries are collecting various data elements based on their specific use case for women’s health
Variations in the data elements being captured varies in numbers where some registries are collecting 200 to 300 data elements and some registries are capturing upward of 700 data elements
Lack of common core data elements across the registries
Some registries are still in their infancy identifying data elements
Technical healthcare standards are not widely used to define data elements, to collect structured data (data that is machine processable) and to store standardized data

25. Moving Towards Coordination: Implementation Guide
Create a Technical Solutions Roadmap or Implementation Guide (IG) with
Actors
Capabilities
Use Cases
Technical Flow Diagram
Data Elements, etc.
CRN IG will include:
Harmonized set of common or core data elements related to women’s health to refine existing standards; and
Integrate work from existing IGs and profiles (SDC, US Core, DAF for Research IG, etc)
It is important to first create a technical solutions road map that will produce an interoperable framework and allow clinical registries to create and share data with each other. This can be achieved through the creation of an implementation guide (IG), which includes actors, capabilities, use cases, technical flow diagram, data elements and the like.
The CRN IG will utilize the harmonized set of common or core data elements related to women’s health to refine existing standards (i.e. update FHIR resource extensions) and integrate the work from existing implementation guides and profiles (i.e. Structured Data Capture IG, US Core profiles, DAF for Research IG, etc.) .

26. Moving Towards Coordination: Implementation Guide
For an IG to have the most impact we must
Work with an internationally recognized standards development organization (SDO), such as Health Level Seven International (HL7)
HL7 is
ANSI-accredited SDO that provides a comprehensive framework and standards that supports clinical practice and the management, delivery and evaluation of health services.
To obtain the most far reaching impact, it is vital to work with a nationally recognized standards development organization (SDO) such as Health Level Seven International (HL7).
HL7 is an “ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.”

27. Moving Towards Coordination: Implementation Guide
Value of working with HL7
Using existing standards to create a national health information network
Facilitate an interoperable EHR systems
Implement cost effective solutions
Work across several standards projects across HL7
Work with a large group of industry adopters and vendors.
Value
Utilize existing standards to help create a national health information network
Facilitate the development of interoperable EHR systems
Implement cost effective solutions pertaining to healthcare
Work across several standards projects within HL7 (SDC, PRO, Argonaut and CRN) to build a framework that can help increase use cases for CRN
Assist in the pre-population of data from other data sources
Re-use existing frameworks to share health data
Work with large group of industry adopters and vendors such as Argonaut to advance industry adoption of modern, open interoperability standards, such as CRN

28. Testing it Out: Pilots & Pilot Development
We’ll have an HL7-approved IG (anticipated Dec. 2018)
Existing women’s health registries and CRNs can apply to be a pilot site
Pilots allow us to
Test the technical specifications that we’ve developed with your input
Use the data elements and measures you’ve identified to test the interoperability of the IG
Pilot settings can be
Clinical; or
Provider organizations using their EHRs
Once the next iteration (Standards for Trial Use 1) of the CRN HL7 implementation guide is published this December, existing women's health registries and CRN’s will have the opportunity to apply as a pilot site to build, test and implement the contents of the CRN IG
The purpose of the pilots is to test the technical specifications that are being developed as part of the CRN project. The pilots will utilize the identified set of data elements and measures expressed in standard structured definitions to test interoperability with other data sources via software apps and application programming interfaces (APIs), including those related to a unique device identifier (UDI).
Pilot demonstrations may occur in a variety of settings such as clinical or provider organizations using electronic health record systems and applications.

29. HL7 Standards Development Timeline
Apr ‘18
May ‘18
Jun ‘18
Jul ‘18
Aug ‘18
Sept ‘18
Oct ‘18
Nov ‘18
Dec ‘18
Jan ‘18
Feb ‘18
May HL7 WGM
Sept. 29- Oct. 5 HL7 WGM
Jan HL7 WGM
TODAY 9/7
PSS May 27
Notification of Intent to Ballot July 15
Ballot Open
September 1-October 1
Notification of Intent to Ballot October 28
Ballot Open
December 7-January 7
Final list of FDA CDE’s October 19th
Final STU 1 Ballot Content December 2
Final Ballot Content August 19
**Internal Working Deadlines**
October 20th - November 16th
Finalize the mappings to FHIR resources, create any extensions or profiles and ensure alignment with the Argonaut project and other stakeholders/parties of interest
November 17th - December 1st
Conduct an end to end review of the IG
December 2nd
Submit IG for STU 1
PRIMARY WG SPONSOR: Biomedical Research and Regulation (BR&R) 6/12
WG CO-SPONSORS: Orders and Observation (O&O) 5/3 and Clinical Interoperability Council (CIC) 4/26 ADDITIONAL PSS APPROVALS: US Realm Steering Committee (USR-SC) 6/5; FHIR Management Group (FMG) 7/11; Steering Division (SD) 7/30, and, Technical Steering Committee (TSC) 8/13

30. Discussion Topics
What would motivate your registry to share the data? What do you need in order to make it happen?
Other concerns?

31. Questions? Contact Us -
Terrie L. Reed, FDA Senior Advisor for UDI Adoption, U.S. Food & Drug Administration (FDA)
Lisa Lang, Assistant Director for Health Services Research Information and Head, National Information Center on Health Services Research and Health Care Technology (NICHSR), National Library of Medicine (NLM)
Farrah Darbouze, Public Health Analyst, Office of the National Coordinator for Health Information Technology (ONC)