Meeting 2020-05-11 at 3:00pm UTC. Topic: Data elements

Dear Claire, Jay, all who stayed on until now,
sorry for being late!
I here with volunteer to start a table that starts to map the contents
of the different available questionaires.
I understood that the WHO Case Report Form is accepted as a kind of
"reference" kandidate, to build on.
https://www.who.int/publications-detail/global-covid-19-clinical-platfor...(-covid-19)-rapid-version
I would terefore use the sections of the WHO form as titles
(e.g.
"MODULE1: admission/enrolment"
includes e.g.
CLINICAL INCLUSION CRITERIA
DEMOGRAPHICS
DATE OF ONSET AND ADMISSION VITAL SIGNS
...)
The first output will be an overview, of the content of the WHO sheet,
also showing if and which of the other forms contain similar data
This would also show if any of the other forms has new things to offer.
I am happy to do that in a google spreadsheet. Coming soon.
Can anybody suggest which other forms should be considered e.g., as Jay
mentioned covering "“the field” - lifestyle, disease management,
policy/population interventions"?
Looking forward,
Stefan

Hi Stefan and colleagues.
In any case, implementation must go through the most recognized worldwide standard. I recommend the HL7 FHIR Implementation Guide: Electronic Case Reporting (eCR).
http://hl7.org/fhir/us/ecr/index.html
All the best.
Carlos.
Carlos Luis Parra Calderón
Consortium Coordinator
FAIR4Health Project
https://www.fair4health.eu/
Head of Technological Innovation
Virgen del Rocío University Hospital
Andalusian Health Service
Head of Research and Innovation in Biomedical Informatics, Biomedical Engineering & Health Economy,
Institute of Biomedicine of Seville
Honorary assistant
School Computer Science
University of Seville
_________________________________________________________________________________________________

Dear Carlos and all,
Agree, if we have all the time in the world. :)
Lets have a look at the content first, then estimate how far we can
harmonise this,
and THEN estimate when a standard may realistically be ready.
FHIR may be a way to go, but I do not see a global consent at this moment.
We may suggest this, lets see later im May.
Looking forward,
Stefan

Team:
In DDI, Dublin Core and schema.org's CreativeWork Coverage includes spatialCoverage, temporalCoverage and topicalCoverage.
In a pandemic we want to do interoperability across borders (both within and between countries).
Between countries topicalCoverage may vary. This is sometimes handled by specifying a core CRF / questionnaire and "supplementals". Not every country might get the same supplementals. Or, in other words, in a pandemic we necessarily use a protocol that invokes the core necessarily and supplementals conditionally.
Within the core on the same topic certain questions may be conditional. They may also vary geospatially.
Within the core or in a supplemental, question text and response labels may vary but the question remains the "same".
All of this goes to the "I" of Interoperability in FAIR: topicalCoverage sometimes varies with spatialCoverage. Do this well and we can reduce the noise/random variation in the information collected.
On top of the work Stefan finds himself in, I asked Maeve to think about extending Interoperability in FAIR as needed to account for at least variations in topicalCoverage by SpatialCoverage. This could be a deliverable we provide in our roadmap that takes us to FAIR (meta)data in pandemics operationally.
Note that spatialCoverage need not be by country. spatialCoverage may be by grid and the grid may be hexagons if that is your liking.
Jay
- Show quoted text -From: ***@***.***-groups.org <***@***.***-groups.org> on behalf of caustin via RDA-COVID19-Epidemiology <***@***.***-groups.org>
Sent: Monday, May 11, 2020 4:21 AM
To: RDA-COVID19-Epidemiology <***@***.***-groups.org>
Subject: [rda-covid19-epidemiology] Meeting 2020-05-11 at 3:00pm UTC. Topic: Data elements
Dear colleagues,
Please join us for our 13th meeting on Monday, May 11th at 3:00 PM UTC (Agenda).
Please note the differing times:
→ Mon, Fri 3:00 PM UTC
8:00 AM California, 11:00 AM New York, 5:00 PM France, 1:00 AM Melbourne
→ Wed (unchanged) 12:30 PM UTC
5:30 AM California, 8:30 AM New York, 2:30 PM France, 10:30 PM Melbourne
https://global.gotomeeting.com/join/190413909 (password: washyourhands).
We recommend installing the GoToMeeting app on your computer rather than connecting via a browser.
You may want to review the updated Readme first, and the Zotero Web Library ‘RDA-COVID19 WG’.
If you have not already done so, please:
→ Register your agreement/disagreement: Epidemiology data recommendations, 1st release
(7 minutes to complete), password: washyourhands
→ Complete the membership survey (5 minutes to complete), password: washyourhands
Looking forward to seeing you!
Cheers,
Claire Austin
Co-moderator

FHIR is about electronic and automatic interoperability available in many places, the EHR in Andalusia, my region, with more than 8 million inhabitants, can have it available in a few weeks. And it is real, electronic and automatic interoperability.
I understand that manual data entry from the 20th century must be proposed for those systems which cannot interoperate directly from their EHRs, but that must not be a limitation for those sites which can do so.
We will continue.
All the Best.
Carlos.
Carlos Luis Parra Calderón
Jefe de Sección de Innovación Tecnológica
Hospital Universitario Virgen del Rocío
Servicio Andaluz de Salud
Consejería de Salud
Avda. Manuel Siurot S/N - 41013 Sevilla
Tel: +34 955 01 36 62 - (31 36 62)
Móvil: +34 697 95 48 64 - (75 48 64)
www.huvr.es
***@***.***
skype: carlos.luis.parra
Director del Grupo de Investigación e Innovación en Informática Biomédica, Ingeniería biomédica y Economía de la Salud.
Instituto de Biomedicina de Sevilla
www.ibis-sevilla.es/
Asistente Honorario.
Escuela Técnica Superior de Ingeniería Informática.
Universidad de Sevilla.
_________________________________________________________________________________________________
Head of Technological Innovation
Virgen del Rocío University Hospital
Head of Research and Innovation in Biomedical Informatics, Biomedical Engineering & Health Economy,
Institute of Biomedicine of Seville
Honorary assistant
School Computer Science
University of Seville
_________________________________________________________________________________________________

Dear Carlos,
I agree that FHIR is a top candidate technology to address this on the
long term. Personally it is also my recommendation.
However we have to accept the fact that not all regions are able to
implement it on the short term.
e.g. Austria has CDA installed with millions of documents per month and
millions of € invested. No chance to migrate within the next few years.
EU cross border (CEF DSI) is also heavily into CDA.
Whatever we recommend, we must also consider feasible migration paths
and sufficent timeframes for an orderly move to these new technologies.
One other observation:
10 years ago only very few knew CDA in Austria. Now CDA still is not
rolled out completely. FHIR pops in. Everything changes ...  Pain!! Do
we throw away everything CDA?
What will be the appropriate technology 5 years from now? We therefore
want to make sure that the data still travels, no matter which
technology is used far behind the screen?
All the best,
greetings from Vienna,
Stefan

Fully agree!!!
Thanks, Stefan:-))
Carlos.

Dear Jay, all!
We know very similar requirements in many applications! I agree completely.
Could this be handled by specific valuesets, that are defined for each
region?
* e.g. The questionnaire includes a Section "Lab findings"
* Each region defines an own list of laboratory tests that it wants
recorded.
o The region does this in a valueset called e.g. "Austrian Lab Tests"
o The larger "umbrella" "core" set of codes includes ALL tests,
from ALL regions
+ the regions populate their local value sets from this "core" set
+ if they miss anything, they propose to add it to the "core" set
+ (LOINC would be a candidate "core" in the lab test space)
* As questionnares flow in from different regions, we can still link
and compare the data
o that is because the "core" set of codes is harmonised globally
o not all regions will record all tests, so be it
o at least we can work with all reports that come in.
* If global harmonisation in one agreed "core" is not feasible:
o mappings need to be defined between regional valuesets
Hope I understood right,
all the best,
Stefan