Stream: committers
Topic: RIM Mappings
Alexander Henket (Jul 21 2016 at 06:44):
I'm working through missing RIM mappings for PA. Some things just do not seem to exist in V3. What do I do in those cases? Add a text that says exactly that? Example: how would you represent Endpoint using the RIM?
Grahame Grieve (Jul 21 2016 at 06:45):
classically, you would use 'n/a'
Grahame Grieve (Jul 21 2016 at 06:46):
I think the qustion that arises is what is the point of the RIM mappings.
Grahame Grieve (Jul 21 2016 at 06:46):
if the point is to help with the definitions and reliability of the design process, there's no need to go off inventing pertinent observations for things like that
Grahame Grieve (Jul 21 2016 at 06:46):
it doesn't help anyone.
Alexander Henket (Jul 21 2016 at 06:47):
Ah, so n/a, when to the best of my knowledge there is no valid RIM mapping, would suffice to keep the QA messages down
Grahame Grieve (Jul 21 2016 at 06:48):
if, on the other hand, some one is interested in executing conversion of data, then they'll need all the full glory of pertinent or related observations with arbitraily chosen observation codes. we should not try for that
Grahame Grieve (Jul 21 2016 at 06:48):
yes
Grahame Grieve (Jul 21 2016 at 06:48):
QA knows what 'n/a' means
Alexander Henket (Jul 21 2016 at 06:48):
I don't think the v2/v3 mappings do any more than serve as a human interpretable hint
Grahame Grieve (Jul 21 2016 at 06:48):
agree.
Grahame Grieve (Jul 21 2016 at 06:49):
there's several points where we just break into text, and explain the (lack of) alignment
Alexander Henket (Jul 21 2016 at 06:50):
whew I was really struggling. For at least one instance there was a notion in the spreadsheet that we PA would be filing a harmonization proposal to get a mapping working. That was scary
Grahame Grieve (Jul 21 2016 at 06:54):
sometimes that might be justified, but only if it would actually be useful in it's own right, not just for mapping
Grahame Grieve (Jul 21 2016 at 06:55):
if we do a R3 of the v3 data types, most of the changes wll be driven from the FHIR mappings.
Alexander Henket (Jul 21 2016 at 06:58):
DTr3? Now that is scary. Unless they would be evolution on DTr2b. We will never adopt DTr2 (except for PIVL_TS by the way...) because of the huge wire format differences.
Grahame Grieve (Jul 21 2016 at 06:59):
I don't think they'll happen. I'm certainly not doing them
Grahame Grieve (Jul 21 2016 at 07:00):
and if I had anything to do with them, we'd completely rework GTS. Where we are with the TIming data type is way beyond GTS, but GTS is so complex. no one wanted to touch it
Alexander Henket (Jul 21 2016 at 07:01):
Also: unless CDA implements DTr3 it becomes a moot point to support the few messaging implentations out there. While on topic I just have to vent how sorry I am that none of the post-2012 models are useful to us since they are DTr2 based. I've done the back convert for the whole Care Provision stack including all CMETs once, but I'm not about to do that again
Alexander Henket (Jul 21 2016 at 07:03):
The errorneous V3 idea that wire format is not important because the semantics are what matters, is part of what I like being fixed in FHIR. No more business names, generated component1/2, unknown CMET versions and what not
Grahame Grieve (Jul 21 2016 at 07:04):
well, you can think of all that being a learning experience
Alexander Henket (Jul 21 2016 at 07:04):
And I do. It's an expensive one too. :-)
Grahame Grieve (Jul 21 2016 at 07:05):
all good education is expensive. but this was particularly expensive, yes
Alexander Henket (Jul 21 2016 at 07:08):
Looking at what FHIR does I cannot help but wondering how much more could have been done with V3 that we never got to. Like code generation, a proper template language that came in too late but could have saved us the CMET flavors, proper governance that would prevent duplicate efforts across domains better... aahh one can dream.
Grahame Grieve (Jul 21 2016 at 07:10):
fantasies are free.
Lloyd McKenzie (Jul 21 2016 at 08:06):
There are some concepts that are clearly out of scope for the RIM - e.g. StructureDefinition, ValueSet, etc. For those, we put N/A in the root element and we're done. For other things, the resource clearly is in scope, but there might not be a RIM attribute for a particular element. In that case, think about how you'd handle it if you needed to represent that concept in v3. Would you use an observation? Some sort of Act.text? Or would you be totally up the creek without submitting a harmonization proposal. If the latter, then write N/A for that particular element. Otherwise, include the path as you'd model it in v3, making up Observation.code and other non-constrained values as necessary.
Grahame Grieve (Jul 21 2016 at 08:29):
I don't see the point of doing this unless you have a meaningful act relationship code. If you don't, then you should out n/a
Lloyd McKenzie (Jul 21 2016 at 08:32):
You usually do - SUBJ or COMP cover most of the "extra" data elements that might exist.
Lloyd McKenzie (Jul 21 2016 at 08:32):
What you typically don't have is a defined Observation.code
Lloyd McKenzie (Jul 21 2016 at 08:32):
Or Act.code
Grahame Grieve (Jul 31 2016 at 01:33):
I don't see the point of doing this unless you have a meaningful act relationship code. If you don't, then you should out n/a
Lloyd McKenzie (Jul 31 2016 at 02:11):
N/A means "can't express this in the RIM" - things like value sets. There's lots of things that are expressible in the RIM, just sort of ugly
Grahame Grieve (Jul 31 2016 at 06:41):
I only see the point where it's useful to express it
Grahame Grieve (Jul 31 2016 at 06:41):
that, btw, sat in my ipad for months without being sent
Melva Peters (Feb 19 2021 at 15:21):
I changed the name of an attribute and now am getting an error that I need a RIM Mapping. When I look in the published spec the RIM mapping is there. I can't find where the RIM mappings are added now the build has changed. Anyone know? Also, not sure why I get this error when the RIM mapping is actually there (well somewhere) - I didn't remove it. @Mark Iantorno @Grahame Grieve
Melva Peters (Feb 22 2021 at 15:17):
this is another issue that needs to be resolved. When you edit a resource using the spreadsheet, it removes content from the structureDefinition xml where there is no ability to add the content into the spreadsheet. I changed the name of an attribute and the RIM mapping was wiped out in the structureDefinition. @Mark Iantorno @Grahame Grieve
Grahame Grieve (Feb 24 2021 at 02:51):
how do I reproduce this?
Melva Peters (Feb 24 2021 at 03:07):
I went in and changed the name of an existing attribute using the spreadsheet. The attribute had a rim mapping in it, but when the structure definition file was generated, the RIM mapping was not in there. I manually added it back in to the xml file.
Melva Peters (Mar 15 2021 at 21:45):
@Michelle (Moseman) Miller
Last updated: Apr 12 2022 at 19:14 UTC
