[FGED-discuss] Notes from the Community Based Standards workshop (Part 3a)
stoeckrt at upenn.edu
Wed Feb 25 23:50:41 UTC 2015
Sorry sent this out of order. This comes before my previous post.
ULS ultra large scale systems, the software challenge of the future
D Fridsma -we are not building a building, we are city planning
standards interoperability is hard in the concrete, impossible in the abstract
Interoperability - ability to exchange, and ability to use information that has been
cannot define interoperable without consideration of the end use
frame things based on what people care about:
triple aim - health, health care, costs
what is the value proposition to the people that will use the products?
4 scales of engagement: (PPPP - Patient, Practice, Population, Public)
Genome to small molecules to patient to …
Figure out at what scale to get data and how to support it.
Informatics, standards, testing, business drivers, governance -- have to span all the scales of engagement. Not one thing for all, though.
5 technical things to standardize
Meaning (semantic interoperability), Content structure (syntactic interoperability), transport security and services.
It’s a standard because people use it, not because we say it’s so. (True)
Solve a problem and figure out how they can have ownership.
S&I Framework Overview --
It’s been very active group of multiple organizations/ agencies. There wasn’t any one organization that could do what was needed. 750-1K people participating on weekly calls. Resolved a huge number of HL7 ballots. Created a way of getting work done by engaging the community.
There will never be one model to rule them all. Illustrated by the different use cases for clinical care, research data warehouse and Clinical studies. e.g. warehouse populated by ETL from the clinical care and the data are organized differently. And studies have patients, on arms, etc. Different information model. So, how do we efficiently transform between the models. Otherwise end up with something like the D3 RIM, difficult to implement and not used.
More emphasis on the Standards lifecycle. Everything will become highly used but of declining value over time. And the link between the newer but less widely adopted may be through mappings.
Final thoughts -- (1) Modular and substitutable; (2) Postel’s principle (forward compatibility) - build in so you don’t reject the packet if there’s something you don’t recognize - OR vs AND - changes the standard for how standards developed. Certify on received, not just on send. And, (3) don’t let perfect be the enemy of the good.
Postel’s priniciple http://en.wikipedia.org/wiki/Robustness_principle
Structured data capture (SDC) initiative at ONC - granular data structure/metadata that separates the structure from the meaning
FHIR - this will the next health care standard (in some fashion). Modular, substitutable, a lot of features. At top of Gartner hype curve right now.
Session 3: ...Clinical Sciences and Potential Impacts for Advancing NIH relevant Research
Chris Chute (moderating), Clem McDonald, Jessica Tenebaum, Doug Fridsma, Tom Oniki
Clem McDonald - we’ve got to get it simpler if we’re going to get it done. There’s a lot going on, to re-emphasize what Chris said. V3 stinks. V2 everywhere. NCPDP - simple, they’ve got an easy life. V2 - biggest problem is everyone uses their own codes. LOINC for measurements, used internationally; RxNorm mandated for use for clinical drugs; SNOMED for organisms etc that you have to talk about in messages…
No end to the standards development (in HL7) too.
Let’s get out of the dual research/ patient care management.
Slow adoption of some code systems.
Jessica Tanenbaum - Standards for Precision Medicine --
• What do you want to put into the clinical record in genomics?
• HGVS - Notation that lets you know where it was when the reference terminology is changing is important.
• Proteomic, metabolomics data - wild west - using spreadsheets, etc. Many not even using terminologies put forth.
• Drug terminologies - good for some, but didn’t until recently tell you about the categories. NDF-RT did, but need to map between standards -- probably the future for these multiple standards. ATC - function changes the codes - taking as blood thinner different than … etc. DRON - RXNORM+ CHEBI, trying to solve some of the logic you can do over the existing ontologies.
• BRO - Biomedical Resource Ontology illustrates the problem of life cycle -- I’m looking for a database or an expert in the field, etc. Was done through a supplemental grant bringing people together. By luck of who had extra cycles, got the work done. When money went away, no longer work being done. It’s technically simpler than some others. It was moved around a social network - more of a popularity contest than a meritocracy. How do you get past that?
Tom Oniki - IHC - Standardization of Detailed Clinical Models (HSPC/ CIMI)
Challenges: (1) Coming together (large investments, different bandwidths, different use cases); (2) IP - who owns; (3) Mapping makes it all work? Different chunking, pre-coordination vs post-coordination, terminology vs model.
Jerry Sheehan - NLM - working with NIH ICs on common data elements. Aim to improve consistency of data collection in clinical RESEARCH studies. ICs develop CDEs through community-based process that engages clinical research experts with domain expertise. Often missing is expertise in clinical (care) data standards. CDE Portal http://cde.nih.gov. provides one-stop access to information about NIH CDEs and links out to individual CDE websites (e.g., PhenX, NINDS CDEs, PROMIS) New prototype repository http://cde.nlm.nih.gov contains CDEs from IC collections and serves as platform for: accessing/downloading CDEs; creating new collections by reusing existing content to extent possible; harmonizing across NIH CDEs (eliminating redundancy); and linking to EHR standards (e.g., SNOMED, LOINC, RxNORM).
I used to think harmonization was a good word (?) [Did Jerry S. say that? - no, I still believe it it :-)]]
Jessica T: - incentives for use of standards (including CDEs). carrots and sticks. Jerry - carrots, sticks, and enablers. Portal and repository are enablers - they make it simpler to find and use CDEs. Sticks - many ICs now encourage, expect, or require the use of CDEs in funded research. Carrots may be simplifying creation of case report forms, higher quality data through use of validated or vetted instruments. Down the road, carrot will be greater ability to compare results across studies, conduct secondary research, and meta-analyses. Jessica T - but still may be easier to create your own new data element.
Doug F. : Data sharing plan - make it a scoreable element. (Not done as you put the stamp on the envelope -- a robust way to describe the data sharing plan -- Issue of common syntax and different semantics, or vice versa. -- need to separate them out. need different experts coming to the table to fix them/ harmonize them.
Make sure ICs at NIH are on the same page (NIH needs standards internally) For core things that affect multiple ICs.
Oniki - CIMI - devil in the details: CIMI can be key, but an ecosystem needed for people to create small logical models. need a technical infrastructure, but people need to construct them at varying level of specificity. Something like FHIR (Fast Healthcare Interoperability Resources) would implement them. And some of the same issues within FHIR (‘ you will handle that by extension, or this by ...’ will end up with a lot of siblings (similar to the problems with current CDE collections.) How to do use case specializations correctly to make them into something manageable.
Clem: Let people do everything they want and then glue it together, or start with one model at the start - things are locked down, so you don’t have to worry about people putting in different answers. Jessica - but for many people it will be easier for people to create a question about smoking than go to find just the one they want where it exists somewhere else. Jerry: we have looked at that one. They do invent their own. But it limits your ability to compare data across studies. Jerry: Testing governance structures, how can you reduce the number of variants, e.g. for smoking questions. There is the legacy issue. The variants already in use. Recalibrate the existing work. [Oniki - we need the infrastructure for accommodating the different needs, map, speicalization and extension,e tc rationally. Doug: issues of syntax vs semantics. Easier to tackle and make machine readable resources encoded in a common way. Jessie: agrees, we can make it as easy as we want, but it’s still easier to write ‘how many packs per day’, so we need to incent; Clem: why not start with the low hanging fruit? The variants don’t have to do with truth. Jerry: don’t let the perfect be the enemy of the good. build incrementally and revise. Solve the 80%.
Eric Neuman - discussion of units of exchange. Can we condense it down to more atomic units that we can agree on?
Melissa Haendel emphasizes need for use cases. “We may never agree on the definition of a gene but that does not mean we can not have gene identifiers in the database.”
Clem: CDEs not in use now in clinical -- Meaningful use will use for smoking (and it’s off), but… if you could get down to a couple of the best, you might get the research CDEs used in clinical care.
Need to identify parsimonious set of CDE elements that are helpful for data integration and matching. We can not let physicians become merely checkbox checkers. We need to extract whole record into an exchangable form.
How do we get away from a very top heavy organization like HL7 to provide input into standards development. Focusing on social structures that enable small contributions by smart people. Doug Fridsma: FHIR. not technology, but social. Doug: example of SMART project at Harvard where they did bring in new people. It is a real problem. Not everyone has a week to spend in HL7 committees multiple times a year. Incubators -- maybe we need to have those for a group of similar products with liaison to the standards organizations?
FHIR uses JSON and tries to be pragmatic.
Ian Fore from NCI points out that all models are wrong.Let’s focus on how it’s useful. Monty Python spam, spam, spam is hazard. Using layers in a stack can help provide a solution and will help engage the community. This would be a metamodel.
• This is being piloted. OMG (http://www.omg.org/) is passing through UML something called AML (http://www.omg.org/cgi-bin/doc.cgi?health/2012-7-1). It is a big ask to ask all communities to use AML
“I can do anything meta than you” It was stated that the bridge model is wrong. Only relevant for simple models.
Doug worked on BRIDG, but now suggesting better to do small models with early binding rather than too much abstraction and late binding.
More information about the FGED-discuss