Difference between revisions of "201605 Declarative Mapping"
| Line 3: | Line 3: | ||
__NOTOC__ | __NOTOC__ | ||
=Declarative Mapping= | =Declarative Mapping= | ||
| − | This track will explore mappings and/or a useful subset of mapping tasks to support interoperability. The | + | This track will explore mappings and/or a useful subset of mapping tasks to support interoperability between FHIR and other data representations. The intent is to enable mappings to be declared, transmitted and executed to translate data from one form to another (particularly FHIR). |
* Pre-requisites: none | * Pre-requisites: none | ||
| Line 13: | Line 13: | ||
* SOA Working Group | * SOA Working Group | ||
* CGIT (approval planned) | * CGIT (approval planned) | ||
| − | * CBCC ( | + | * CBCC (approval planned) |
==Justification== | ==Justification== | ||
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | <!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | ||
| − | There is a recognized need for mappings to facilitate interoperability across HL7 products, and between HL7 products and other formats and data models. Following on the Birds of a Feather CDA-to-FHIR session in Orlando, there was an agreement among the participants to pursue mapping approaches | + | There is a recognized need for mappings to facilitate interoperability across HL7 products, and between HL7 products and other formats and data models. Following on the Birds of a Feather CDA-to-FHIR session in Orlando, there was an agreement among the participants to pursue declarative mapping approaches. Objectives of the track include developing and demonstrating reusable computable artifacts that can be saved, persisted and transmitted as FHIR resources. The SOA WG has already developed "cross-paradigm" mapping guidance intended to represent the same business content in more than one structure (e.g. CDA template to FHIR profile or V2 profile components). |
| − | SOA WG has already developed "cross-paradigm" mapping guidance intended to represent the same business content in more than | ||
See also http://www.healthintersections.com.au/?p=2506 | See also http://www.healthintersections.com.au/?p=2506 | ||
Revision as of 01:01, 22 April 2016
Declarative Mapping
This track will explore mappings and/or a useful subset of mapping tasks to support interoperability between FHIR and other data representations. The intent is to enable mappings to be declared, transmitted and executed to translate data from one form to another (particularly FHIR).
- Pre-requisites: none
Schedule
Start: 1pm Saturday
Submitting WG/Project/Implementer Group
- SOA Working Group
- CGIT (approval planned)
- CBCC (approval planned)
Justification
There is a recognized need for mappings to facilitate interoperability across HL7 products, and between HL7 products and other formats and data models. Following on the Birds of a Feather CDA-to-FHIR session in Orlando, there was an agreement among the participants to pursue declarative mapping approaches. Objectives of the track include developing and demonstrating reusable computable artifacts that can be saved, persisted and transmitted as FHIR resources. The SOA WG has already developed "cross-paradigm" mapping guidance intended to represent the same business content in more than one structure (e.g. CDA template to FHIR profile or V2 profile components).
See also http://www.healthintersections.com.au/?p=2506
Proposed Track Lead
Expected participants
The expected participants include:
- Keith Dudley / Grahame Grieve
- MDMI Open Source Project (several participants)
- David Booth (Yosemite Project)
- SAMHSA BHITS Project
- Members of the i2b2 on FHIR team
- David Hay (Orion Health)
Roles
Map Designer
This is a software product that helps a user manager a set of mapping resources, and edit them, and test the mapping transform outcome interactively. Designer may offer additional assistance in Ux for mapping etc as desired. Designers implement use case #1.
Map Executor
This will be an application that takes a set of map files or resources, a CDA document and produces a FHIR Bundle Document. The executor may be wrapped in any form desired.
Scenarios
TODO: David Booth and Ken Lord to add more use case scenarios, with before and after documents.
1. Edit an existing map
Action:
The designer opens and edits the existing CDA mappings either from the map files (using the concrete syntax), or from the equivalent resources.
Success Criteria:
The map resources produced can feed into the second use case
Bonus Point:
Bonus points for being able to read and write resources from a server.
2. Execute a map
Action:
Take the CCDA draft maps, apply them to a CCDA example document, and produce a document bundle
- The test map is the one in the CCDA implementation (\maps)
- the test document is the CCDA example document distributed with the CCDA R2 (see [here]).
Success Criteria:
The output should be a Bundle that looks like [this - to be resolved closer to the day]
Future Step:
A future step will test the execution packaged in an operation on a FHIR Server.
