Stream: v2 to FHIR
Topic: Transform Validator
robert worden (Jan 09 2020 at 13:47):
The V2-FHIR Mapping project is considering developing an Open Source Transform Validator tool as one of the project deliverables.
How the transform validator will work:
Suppose somebody has a V2-to-FHIR transform engine or transform service, and they have at least one test V2 message instance, and the FHIR bundle they get by transforming it.
This pair of (V2 message, FHIR bundle) would be input to the transform validator. The validator will check that all the values to be expected from the transform are present in the FHIR bundle in the right places, and that no other values are present – checking that the transform is consistent with the mapping tables from this project. The validator will note any discrepancies, in a spreadsheet and in an OperationOutcome resource (e.g. for each discrepancy noted, giving the V2 source path, the FHIR target path, and the nature of the discrepancy).
Alternatively, someone may have a local variant of V2 and a local profile of FHIR, and have a localised V2-FHIR transform. They may have mapping tables describing their local transform requirements. Then, they can edit the mapping tables from this project, to reflect their local transform requirements, and can feed these modified mapping tables to the validator. The validator will check that the modified mapping tables are syntactically valid, before checking that the (message-Bundle) pair from the transform conforms with their own mapping tables. This is likely to be the most frequent use case.
The transform validator will be similar to FHIR validators which validate a FHIR instance against a profile. Using it, FHIR servers could offer a transform validation service. This will not compete with suppliers of transform engines and transform services, but will enable them to check and demonstrate the quality of their offerings.
The validator is partly implemented, and we are now considering various aspects of its functionality. If you have views on what it should do, please get in touch.
Oliver Egger (Jan 09 2020 at 14:13):
@robert worden is the validator using the java fhir validator as a base? because i would be also interested in such a functionality for cda to fhir transforms and back, actually for any logical model to fhir transform and back :sunglasses:
robert worden (Jan 09 2020 at 16:13):
Currently the validator is specialised to V2-to-FHIR transforms, mainly because it reads the spreadsheet mapping notation being used by the v2 to FHIR mapping project; those sheets define what the transform should do. See https://confluence.hl7.org/display/OO/2-To-FHIR+Project . However, you could use a similar layout of mapping spreadsheets to specify other transforms, such as CDA to FHIR or OpenEHR to FHIR. In that case the validator could be adapted to validate those transforms. No, it does not depend on any FHIR validator.
David Hay (Jan 09 2020 at 17:18):
Has any thought been given to using StructureMap as the mapping reference rather than the spreadsheets? (possibly with changes to StructureMap of course)...
Kevin Mayfield (Jan 10 2020 at 05:06):
I've implemented v2 to fhir and found it very useful to just run fhir validation on the output. What I've found myself doing is posting v2 and using http headers to get the responses as fhir operation outcome. This applies fhir profile rules to v2 which I think is really useful.
Kevin Mayfield (Jan 10 2020 at 05:07):
I havent tried it with Fhir MessageDefintion which seems to be the next step (we dont have any useful examples in the UK)
robert worden (Jan 11 2020 at 14:56):
The project is considering both StructureMap and ConceptMap as representations of the 'mapping reference'. StructureMap in particular has the benefit of being executable. However, I think the project's view is that StructureMap is not yet a suitable notation for capturing and reviewing mappings - because understanding of the StructureMap resource (or equivalently, of FHIR Mapping Language) is still pretty scarce - e.g. amongst the V2 experts who we need to contribute and review the mappings.
In practice it appears that most people - when thinking about the relationships (or mappings) between two notations such as V2 and FHIR - start their thinking in with spreadsheets. We don't get resistance to spreadsheets from V2 domain experts - so for capturing and reviewing the mappings, spreadsheets are the medium of choice.
The question is then - are spreadsheets precise enough and expressive enough to do the whole job? We think they are - and they are modular, and you can validate a transform result against spreadsheets. Watch this space.
robert worden (Jan 11 2020 at 15:11):
Running FHIR validation on the resulting resource or bundle is useful, but we are aiming to do better. Validating a resource is a syntactic validation - checking that the resource obeys the rules of FHIR, but not checking that the data are correct. Validating a transform result is semantic validation - checking that the content is correct, according to the V2 message it came from, via the transform.
e.g. validating a Patient resource may check that the patient has a valid birthDate - any possible birthDate. But validating the transform result checks that it is the correct birthDate, according to the V2 message source.
So the transform validator will do semantic validation, supporting the HL7 goal of semantic interoperability.
Kevin Mayfield (Jan 11 2020 at 17:47):
Fhir validation checks semantic content is correct. It can check a snomed observation in a obx segment is correct and follows any ValueSet rules.
robert worden (Jan 13 2020 at 13:14):
Kevin - agreed - FHIR validation does some semantic validation, and transform validation does more - in combination you will get pretty comprehensive semantic validation.
robert worden (Mar 08 2020 at 12:13):
The attached note expains use cases for a V2-FHIR transform validator. Comments please. Transform-Validator.docx
Last updated: Apr 12 2022 at 19:14 UTC
