Stream: v2 to FHIR
Topic: IG support
Grahame Grieve (Jun 27 2019 at 01:06):
The next release of the IG publisher will support the spreadsheet format that the v2 mapping project is using. The way it works is :
- download the spreadsheet as a csv and save it in the resources folder of the iG
- add the csv file to the ig.json file in a “mappings” entry, just like is done for profiles as spreadsheets
- the file is loaded to a ConceptMap resource and is now a standard resource like any other
- one of the generated outputs is an HTML fragment that matches the spreadsheet format for inclusion directly in the IG
- it needs some additional metadata in the spreadsheet (name / value pairs)
Grahame Grieve (Jun 27 2019 at 01:07):
All this assumes that there is an IG being published, which assumes that someone is going to edit it... do we have a volunteer?
Jean Duteau (Jun 27 2019 at 05:31):
I haven't looked at the v2 to FHIR mapping spreadsheet but is it specific to v2 or can it handle any mapping to FHIR? So many of the IGuides that I create are based on mappings and I'd love to include the mappings in the guide. I've been doing it so far by just linking to an include spreadsheet resource, but if it actually create HTML fragments in the IG, that would be really sweet.
Grahame Grieve (Jun 27 2019 at 11:27):
it's specific to v2 right now, but that's partly because I have hard coded some things that we'd need to talk about
Grahame Grieve (Jun 27 2019 at 11:27):
but also because some of the ideas in that spreadsheet are very v2 specific
Grahame Grieve (Jun 27 2019 at 11:27):
also, do you want to live within the limitations of that format?
Craig Newman (Jun 27 2019 at 12:18):
Which spreadsheets does this support? Just the segment maps? Or does it support data type and vocabulary too? As well, we think we are honing in on a spreadsheet for message mapping (https://confluence.hl7.org/display/OO/Message+Mapping), will that be added in the future too?
Craig Newman (Jun 27 2019 at 12:24):
Finally, we still need a way to document the relationship between resources in the Bundle that is being created.
For example, the Patient resource created from PID goes in Encounter.subject from the PV1 transform and Immunization.patient from the RXA tranform.
Or the Practitioner resource created from a PRT segment with participation of "ordering provider" goes in Immunization.performer.actor where Immunization.performer.function="OP" for the Immunization resource created in the same order segment group as the PRT segment.
Does anyone have suggestions on how to make such relationships machine understandable?
Grahame Grieve (Jun 27 2019 at 13:02):
I don't believe you are on a course to machine processibility
Grahame Grieve (Jun 27 2019 at 13:02):
For now, I've just done segments
Hans Buitendijk (Jun 27 2019 at 20:34):
Have a look. It's about v2-to-FHIR mapping: https://confluence.hl7.org/display/OO/2-To-FHIR+Project.
Hans Buitendijk (Jun 27 2019 at 20:41):
Full machine processibility is not likely if the goal is to take in any v2 message and spit out FHIR on the other side. The world of v2 is too varied, with too many z-stuff and variable interpretations on where to put what data in v2 to begin with (not unlike current state FHIR really). Implementation guides could get much closer to that, particularly if they have strong conformance testing tools (e.g., the LOI/LRI guides), but still only within the non-optional space. So we really need to think of this as strongly indicative of what in v2 is intended to be mapped where in FHIR and have tooling that can use this as the starting point to enable v2-to-FHIR mappings.
Segment mapping alone is not sufficient as messages provide context, based on placement of the segments, where to map to in FHIR. I do believe that can be reasonably defined using the constructs we are working through. But will it be 100% for any v2 message sight unseen? No. Spreadsheets and mapping language won't make a difference there.
Grahame Grieve (Jun 27 2019 at 21:00):
not to that problem no, but as a format they will prevent achieving that goal once all those other problems are solved
Hans Buitendijk (Jun 28 2019 at 21:36):
Isnt' that the purpose of converting .csv to a mapping language syntax that is consumable by a tool? While perhaps the final inch may require a specific expression to be dropped in that uses the target mapping language syntax, I believe the simplicity of spreadsheet and ability to review will get us a long, long way. But we'll see. We'll augment when we run into that.
Grahame Grieve (Jul 04 2019 at 00:44):
a specific expression to be dropped in
I wish you'd listen in detail. Being able to do that requires slavish adherence to the formalisms that enable such a thing to be done. Which you are already not doing; you're just making up syntax to suit your immediate problem without any consideration for the underlying formalisms
Grahame Grieve (Jul 04 2019 at 00:45):
I'm trying to parse the spreadsheets now. I can parse them, sure. But extracting deeper meaning towards executing on the information in them is already involving guess work, and I'm only 10% into the task
Hans Buitendijk (Jul 15 2019 at 14:19):
@Grahame Grieve : "slavish adherence to a formalism" is critical to any approach, whether spreadsheet, mapping language, or whatever else we may choose. You have fair criticism that we are not yet consistent in adherence. Two considerations there: we were not yet trying hard to do so as we are getting our feet wet; we started last week to discuss a stricter formalism that we would then adhere to and can validate against.
robert worden (Aug 23 2019 at 10:59):
As we discussed at the last WGM, I am developing tooling to convert the spreadsheet mappings of the V2 to FHIR mapping project to runnable transforms. Now the core of it works - I can generate runnable transforms in HAPI Java or FHIR Mapping Language (old syntax - will be fixed).
Of course I am running head-on into the inconsistencies and ambiguities of the spreadsheets as they are being developed on the mapping project,and I have not done mapping conditions or resource references yet - still to do. But the project gradually tidies up the ambiguities and inconsistencies as we find them, and the transforms test the mappings. I know of no reason why the spreadsheet notation, after this refinement, should not be as fully machine processable as any other notation. The spreadsheets are modular and reviewable.
Naturally, local variations in V2 or FHIR or both are going to be an issue for anybody deploying a transform. There are several ways to tackle this - edit the generated FML, edit the generated Java, or edit the spreadsheets and re-generate.
Frank Oemig (Aug 31 2019 at 13:40):
My expectation would be to cover the local variations by profiling in form of hierarchies. This ist what we teach in conformance.
Therefore, the deltas should be transformed individually and then added were needed.
robert worden (Sep 02 2019 at 10:27):
Grahame wrote: 'the [csv] file is loaded to a ConceptMap resource and is now a standard resource like any other'.
Can we see an example?
For a typical message, you need about 30 spreadsheets (message, segment, data type)
Jean asked: is [the spreadseet notation] specific to v2 or can it handle any mapping to FHIR?
The spreadsheet notation has one or two columns that are V2-specific, but would easily generalise to other sources, such as CDA or OpenEHR. Similarly, the tooling I am developing to convert spreadsheets to runnable transforms has some V2-specific aspects, but could be adapted to handle mapping spreadsheets of non-V2 sources.
Grahame Grieve (Sep 02 2019 at 11:01):
the concept applies anywhere, but the specific format has some implied meanings that particularly fit v2
Grahame Grieve (Sep 02 2019 at 11:02):
I'll have an example for atlanta
Last updated: Apr 12 2022 at 19:14 UTC
