FHIR Chat · Mapping Language · implementers

Stream: implementers

Topic: Mapping Language

David Hay (Nov 23 2016 at 06:18):

In the description of the mapping language, it states that the language can work on specs that don;t have a typing system like v2. Do you still create a logical model (StructureDefinition) for a v2 message when used as a target/source of a mapping? If so, what type would you use?

Grahame Grieve (Nov 24 2016 at 08:05):

no typing system, you probably can't define a logical model for it. If you can't, you can still use the mapping language, but you have to be careful about what you try to achieve

David Hay (Nov 24 2016 at 12:43):

I was thinking or using it to convert between v2 & FHIR. Can't you define a separate type system in a Logical Model? Not understanding why we can't do that for v2...

Grahame Grieve (Oct 22 2018 at 19:14):

I've just committed a set of updates to the R3/R4 transforms. They are in final state for the following resources:

• AuditEvent
• Basic
• Binary
• CapabilityStatement
• CodeSystem
• CompartmentDefinition
• Composition
• ConceptMap
• DocumentManifest
• DocumentReference
• GraphDefinition
• ImplementationGuide
• Linkage
• MessageDefinition
• MessageHeader
• NamingSystem
• Observation
• OperationDefinition
• OperationOutcome
• Parameters
• Patient
• Provenance
• SearchParameter
• StructureDefinition
• StructureMap
• Subscription
• ValueSet

Grahame Grieve (Oct 22 2018 at 19:16):

this includes all the normative resources. Round-tripping is 100% ok, and most of the R4 resources are valid (there's a few mandatory attributes here and there that mean that the R3->R4 process will never produce valid r4 resources

Grahame Grieve (Oct 22 2018 at 19:18):

I've changed the syntax of the mapping language a little, to make it more efficient. Changes:

• changed the group declaration - moved group inputs to be like parameters
• removed 'for' from the statements
• replaced 'make' with '->'
• added a ; at the end of each rule to reduce ambiguity
• moved the rule name to the end of the rule
• defaulted the rule name for simple rules so that it doesn't need to be present

The outcome is much more readable. Here's an example:

group string2Annotation(source src : stringR3, target tgt : Annotation) extends Element <<types>> {
  src -> tgt.text as vt0 then string(src, vt0);
}

Grahame Grieve (Oct 22 2018 at 19:19):

The only change that is not purely syntatical is the last one - defaulting names

Grahame Grieve (Oct 22 2018 at 19:20):

I can easily revert this change, but I think it's a real improvement. We have a week to decide whether to adopt it as the only option, allow it, or just revert

Grahame Grieve (Oct 22 2018 at 19:21):

@Vadim Peretokin @Gustav Vella @Robinette Renner (some users I know will be interested)

Lloyd McKenzie (Oct 22 2018 at 19:29):

So R4 is making elements mandatory that weren't in R3? Are we confident that those newly mandatory elements are appropriate global constraints?

Jean Duteau (Oct 22 2018 at 19:35):

I'm okay with all of those rules except for: "moved the rule name to the end of the rule" Why did you make that one?

Jean Duteau (Oct 22 2018 at 19:36):

looking at all of my map files, the other rules would greatly clean up the maps and make them easier to read (imnsho)

Grahame Grieve (Oct 22 2018 at 21:15):

because it lead to consistency. There's no need for the name, mostly, now. Prefixing it, it got in the way of reading it. Task this:

Grahame Grieve (Oct 22 2018 at 21:17):

group ValueSet(source src : ValueSet, target tgt : ValueSetR3) extends DomainResource <<type+>> {
  src.url -> tgt.url;
  src.identifier -> tgt.identifier;
  src.version -> tgt.version;
  src.name -> tgt.name;
  src.title -> tgt.title;
  src.status -> tgt.status;
  src.experimental -> tgt.experimental;
  src.date -> tgt.date;
  src.publisher -> tgt.publisher;
  src.contact -> tgt.contact;
  src.description -> tgt.description;
  src.useContext -> tgt.useContext;
  src.jurisdiction -> tgt.jurisdiction;
  src.immutable -> tgt.immutable;
  src.purpose -> tgt.purpose;
  src.copyright -> tgt.copyright;
  src.extension as ext where url = 'http://hl7.org/fhir/StructureDefinition/X34-vs-extensible' then {
    ext.value : boolean as vs0 -> tgt.extensible = vs0 "extensible2";
  } "extensible";
  src.compose as vs0 -> tgt.compose as vt0 then compose(vs0, vt0);
  src.expansion as vs0 -> tgt.expansion as vt0 then expansion(vs0, vt0);
}

Grahame Grieve (Oct 22 2018 at 21:17):

compare to this:

group ValueSet(source src : ValueSet, target tgt : ValueSetR3) extends DomainResource <<type+>> {
  src.url -> tgt.url;
  src.identifier -> tgt.identifier;
  src.version -> tgt.version;
  src.name -> tgt.name;
  src.title -> tgt.title;
  src.status -> tgt.status;
  src.experimental -> tgt.experimental;
  src.date -> tgt.date;
  src.publisher -> tgt.publisher;
  src.contact -> tgt.contact;
  src.description -> tgt.description;
  src.useContext -> tgt.useContext;
  src.jurisdiction -> tgt.jurisdiction;
  src.immutable -> tgt.immutable;
  src.purpose -> tgt.purpose;
  src.copyright -> tgt.copyright;
  "extensible": src.extension as ext where url = 'http://hl7.org/fhir/StructureDefinition/X34-vs-extensible' then {
    "extensible2" : ext.value : boolean as vs0 -> tgt.extensible = vs0;
  };
  src.compose as vs0 -> tgt.compose as vt0 then compose(vs0, vt0);
  src.expansion as vs0 -> tgt.expansion as vt0 then expansion(vs0, vt0);
}

Grahame Grieve (Oct 22 2018 at 21:18):

it's not something I feel about strongly

Jean Duteau (Oct 22 2018 at 21:53):

There's no need for the name, mostly, now. Prefixing it, it got in the way of reading it.

Okay, let me ask a different question then - when do we need names for rules? I don't remember being able to call a rule explicitly so why do we name them at all?

Grahame Grieve (Oct 22 2018 at 21:53):

the name appears in the conversion log, so you can see what rules were used in what order.

Grahame Grieve (Oct 22 2018 at 21:54):

I rely on that log to understand what is going on when I get results I don't expect - and I've just beefed up the usefulness of the log this week

Grahame Grieve (Oct 22 2018 at 21:55):

the automatic name for the rule is the element name + the type if specified e.g.
"url" for

  src.url -> tgt.url

Grahame Grieve (Oct 22 2018 at 21:56):

or "value-boolean" for

  src.value : boolean -> tgt.value

Grahame Grieve (Oct 22 2018 at 21:56):

you only need to name the rules now if that automatic name won't differentiate them enough in the log, like

  src.extension where url = 'xxxx' -> ...
  src.extension where url = 'yyy' -> ...

Grahame Grieve (Oct 22 2018 at 21:58):

though the engine could automatically name those extension1, extension2 etc. perhaps the name is under useful altogether

Vadim Peretokin (Oct 23 2018 at 19:22):

@Grahame Grieve what resources can I pick up on?

Grahame Grieve (Oct 23 2018 at 20:53):

anything in the Clinical panel - these would be a good place to start: AllergyIntolerance, Condition, Procedure, FamilyMemberHistory, ClinicalImpression, DetectedIssue - thanks

Vadim Peretokin (Oct 24 2018 at 07:18):

Will do

Grahame Grieve (Oct 24 2018 at 09:02):

keep track of work here: http://wiki.hl7.org/index.php?title=Progress_on_FHIR_R3/R4_conversions

Robinette Renner (Oct 24 2018 at 12:22):

The following is a small snippet of code using the previous syntax and the new syntax. Please let me know if my interpretation of the changes is correct:

Previous syntax:
group PatientElements
input src: QuestionnaireResponse as source
input tgt: Patient as target

"section": for src.item as section then
{
    "question": for section.item as question then
    {
        "answer": for question.answer as answer then
        {
            "gender":  for answer.valueString as gender make tgt.gender = gender
        }
    }
}

endgroup

New syntax:
group PatientElements (source src: QuestionnaireResponse, target tgt: Patient)
{
src.item as section then
{
group.item as question then
{
question.answer as answer then
{
answer.valueString as gender -> tgt.gender = gender "gender";
} "answer";
} "question";
} "section";
}

Robinette Renner (Oct 24 2018 at 12:25):

I like all of the changes except the positioning of the rule name. Having it at the end of the rule can be very confusing when there is a lot of nesting. For most resources there will not be much nesting. However, with questionnaires there can be a significant amount.

I recommend supporting both the previous and new syntax for a while. This will prevent breaking existing applications such as Robert Worden's TBX tool.

Vadim Peretokin (Nov 16 2018 at 23:04):

It's a pitfall that the mapping language allows for double quotes but fhirpath only uses single-quotes for strings. Spent some time on why my matching rule value = "something" wasn't catching anything

Grahame Grieve (Nov 17 2018 at 05:04):

there's a long thread on the fhirpath stream about that. I completely agree. I've got to get around to improving the logging around that

Grahame Grieve (Jan 16 2019 at 17:42):

I'll be doing a quick break out from the network reception tonight at about 6pm on a couple of mapping language problems. I'll do it in regency ball room east #3

nicola (RIO/SS) (Jan 17 2019 at 00:58):

@Grahame Grieve can you share summary after breakout here?

Grahame Grieve (Jan 17 2019 at 13:27):

the breakout didn't really happen. Unfortunately - and my apologies. They were cleaning up the room, and I was scared off :-(

Grahame Grieve (Jan 17 2019 at 13:28):

the summary was that I rewrote Oliver's mapping statements and posted them in a different topic here

Grahame Grieve (Jan 17 2019 at 13:28):

do people think it's worth creating a specific mapping language stream?

Robinette Renner (Jan 17 2019 at 13:44):

Yes. It would be good to have a specific mapping language stream. It would help to build the community of mappers and facilitate the sharing of example code.

Oliver Egger (Jan 17 2019 at 13:52):

+1 for a separat stream and maybe an upcoming fhir connecathon track with fhir mapping language?

Grahame Grieve (Jan 17 2019 at 14:17):

do it as part of the connectathon stream we just agreed to

Grahame Grieve (Jan 17 2019 at 14:19):

new stream: https://chat.fhir.org/#narrow/stream/181579-mapping-framework

Last updated: Apr 12 2022 at 19:14 UTC