Stream: implementers
Topic: Data Element Definition
Grahame Grieve (Sep 15 2016 at 09:45):
When I visited Mitre this week, @Mark Kramer expressed the belief that the cascade of Questionnaire, DataElement, and ElementDefinition is confusing
Grahame Grieve (Sep 15 2016 at 09:46):
I don't see a standard extension to link a question with a data element.
Grahame Grieve (Sep 15 2016 at 09:47):
and I think it's time for me to ask why we don't collapse Data Element into StructureDefinition
Lloyd McKenzie (Sep 15 2016 at 13:46):
So, DataElement is also intended for Observation masterfile type stuff. Are we going to want to add that into StructureDefinition?
Grahame Grieve (Sep 15 2016 at 13:47):
I don't think we do, but I don't think it does that well
Lloyd McKenzie (Sep 15 2016 at 13:51):
We should think about and get some consensus around how we're going to solve that use-case before doing the merge.
Grahame Grieve (Sep 15 2016 at 13:52):
agree. it would be good to be clear about what the scope of observation master file is
Eric Haas (Sep 15 2016 at 18:39):
yes we (OO) have been looking at this using labtestcatalog. So far have seen very little overlap between this use case and DE we are also looking at ActivityDefinition as an alternative - not much overlap there either as far as I can tell. Besides ---at least to me- it makes more sense conceptually to define a service item with a activity than a DE. Jose is looking at the drug formulary use case. Was the expectation that DE be used there as well?
Stephen Royce (Sep 16 2016 at 07:05):
We use DataElement as a means of recording data element definition externally to StructureDefinition to ensure consistency of meaning where the same element is used in 2 (or more) StructureDefinitions. Personally, I think a StructureDefinition should never be able to define a data element itself, but only reference a pre-existing one that's defined in a data dictionary. I know that'll never happen because it's deemed "too hard" to do proper data modelling for resources, but if the DataElement is ditched, those of us who do want to do it properly in our logical models are stuffed.
Mark Kramer (Sep 16 2016 at 12:57):
Aside from the implementation, what I've found is that clinicians think in terms of data elements. Discussions of data exchange, particularly on the research side, are often phrased in terms of which data elements to exchange. In addition, there are large existing libraries of common data elements found at US NIH and many other places. It seems a pity not to have a formulaic way to build FHIR profiles out of these libraries.
Brian Postlethwaite (Sep 16 2016 at 22:48):
The extension for questionnaire that links a question to the dataelement is here:
http://hl7.org/fhir/extension-questionnaire-dereference.html
Brian Postlethwaite (Sep 16 2016 at 22:50):
And if not embedding directly in the Questionnaire, then there is this extension to point it to a ConceptMap
http://hl7.org/fhir/extension-questionnaire-demap.html
Grahame Grieve (Sep 16 2016 at 23:07):
@Mark Kramer we certainly need to be clear about it how that works, yes.
Grahame Grieve (Sep 16 2016 at 23:11):
@Stephen Royce - you've jumped the gun here. I wouldn't propose removing data element if I didn't think there were other solutions to acehive the same outcome. As for defining data elements directly - I think that's wrong; data elements are defined in a context, and not reused elsewhere
Stephen Royce (Sep 19 2016 at 01:25):
So what are the the "other solutions"? We need a context-independent means of defining data elements. (Which doesn't mean that context is ignored when doing so, that wouldn't make any sense, but, nonetheless, the concepts exist in their own right regardless of how they are used. Think of "Name" if you want an example. We all know what name means despite the fact that name can be used for a person, for an organisation and for a cat. These are all different contexts, probably with their own concept that is a subclass of name, but the idea of "Name" is still very useful.)
Marc de Graauw (Sep 19 2016 at 09:48):
@Grahame Grieve Before I worked in healthcare, I saw corporate data dictionaries with what I'd call data elements everywhere (insurance, justice, governmental). Those would be (re)used in a certain context, usually a message-like construct. In Dutch healthcare we're doing the same - setting up data dictionaries with elements like smoking behaviour, education etc. I fail to see what's wrong with such an approach, though I may misunderstand your remark about data elements not being reused and only defined in context.
Grahame Grieve (Sep 19 2016 at 09:54):
I was referring to the data elements defined as part of FHIR resources. I agree that the higher level data elements you refer to are intended for re-use. But I also observe that these things called 'data elements' are usually clusters of information, with some (variable) provenance information as well as the actual focus value, and sometimes several fields of data (not always corresponding to a type)
Marc de Graauw (Sep 19 2016 at 10:10):
There's always some ontological commitment (smoking behaviour pertains to persons, not devices) and that is context too. And you need some type-level "elements" too. (Or looser aggregations, if that's what you refer to.) It would be nice to be able to capture those in some FHIR artefact - either the DataElement resource or something else. Problem is there are lots of definitions from healthcare professionals out there, not based on FHIR, and we need some way to relate those to FHIR resources. Currently I was thinking of expressing those in Data Elements, aggregate them in Logical Models and use Concepts Maps to relate to FHIR resources. But I'm in the process of figuring out what and how, so maybe that's not the best approach.
Grahame Grieve (Sep 19 2016 at 10:15):
we're in about the same place as you, though I have something specific to illuminate my thinking - see http://fhir.hl7.org.au/fhir/rcpa/explanation.html. This is a current matter of focus for us
Ewout Kramer (Sep 19 2016 at 11:51):
When I visited Mitre this week, @Mark Olschesky Kramer expressed the belief that the cascade of Questionnaire, DataElement, and ElementDefinition is confusing
And I heard someone at the connectathon say that the fact that Questionnaire is not part of the StructureDefinition/ElementDefinition framework, makes it harder to write Implementation Guide and validation for Quesionnaires - or it will cause duplicate work for tooling.
Stephen Royce (Sep 21 2016 at 04:06):
I hope that's not a bad approach because that was pretty much what we're (starting to) do here in Australia!
Grahame Grieve (Sep 21 2016 at 10:19):
we'll be working on this over the next few weeks to calrify how this all works. I'll be providing a worked example (one that you'll find quite familiar!)
Eric Haas (Sep 26 2016 at 01:40):
So where are we with master files?... I am moving forward from the ground up on a labtestcatalog and still don't see a clear link to data element. GG can we resurface your "data dictionaires" somewhere so I can try to connect the dots?
Bryn Rhodes (Sep 29 2016 at 16:45):
This has bearing on ActivityDefinition as well, is that resource as defined a good fit for a lat test catalog? And if not, why not?
Eric Haas (Sep 29 2016 at 17:33):
@Bryn Rhodes Here is my preliminary (= first draft) mapping to ActivityDef. I don't see a lot of overlap with either DataElement or ActivityDef - i.e need lots of extensions. for this admittedly narrow use case. There are other people approaching lab catalogs from different angles.
Eric Haas (Sep 29 2016 at 17:34):
hope to get some more input on this from others
Last updated: Apr 12 2022 at 19:14 UTC
