This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201605 Declarative Mapping"

From HL7Wiki
Jump to navigation Jump to search
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
[http://wiki.hl7.org/index.php?title=Category:201605_FHIR_Connectathon_Track_Proposals Return to May 2016 Proposals]
+
[http://wiki.hl7.org/index.php?title=Category:201605_FHIR_Connectathon_Track_Proposals Return to May 2016 Proposals] - [http://wiki.hl7.org/index.php?title=FHIR_Connectathon_12 Return to FHIR Connectathon 12]
 
[[Category:201605_FHIR_Connectathon_Track_Proposals|May 2016 Proposals]]
 
[[Category:201605_FHIR_Connectathon_Track_Proposals|May 2016 Proposals]]
 
__NOTOC__
 
__NOTOC__
 
=Declarative Mapping=
 
=Declarative Mapping=
This track will explore mappings and/or a useful subset of mapping tasks using declarative languages used to address interoperability issues.
+
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).  Mappings could be written in any style, ranging from simple translation tables or expressions to executable code such as EcmaScript.  Different participants may demonstrate the virtues of different mapping styles.
 +
 
 
* Pre-requisites: none
 
* Pre-requisites: none
  
 
==Schedule==
 
==Schedule==
Start: 1pm Saturday
+
Saturday 1pm-4pm:
 +
 
 +
* Participants show & tell
 +
* Draft summary and outcomes
 +
 
 +
Sunday 9am-12:30pm:
 +
* Finish up summary and outcomes -- See [https://goo.gl/xmeL6 report]
 +
* Start planning for [http://www.hl7.org/events/wgm092012/ Baltimore FHIR Connectathon]
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
 
* SOA Working Group  
 
* SOA Working Group  
 
* CGIT (approval planned)
 
* CGIT (approval planned)
* CBCC (approvalplanned)
+
* 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  Following on the Birds of a Feather CDA to FHIR session in Orlando, there was an agreement among the participants to pursue declarative approaches or mappings. Objectives of the track include reuseable computable artifacts that can be saved / persisted as FHIR resources from the approaches presented in the Connectathon.
+
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 on structure (e.g. CDA template to FHIR profile or V2 profile components)
 
  
 
See also http://www.healthintersections.com.au/?p=2506
 
See also http://www.healthintersections.com.au/?p=2506
Line 39: Line 46:
 
=== Map Designer ===
 
=== 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
+
This is a software product that helps a user manage 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 ===
 
=== Map Executor ===
Line 80: Line 87:
  
 
A future step will test the execution packaged in an operation on a FHIR Server.
 
A future step will test the execution packaged in an operation on a FHIR Server.
 +
 +
=== 3. Translate data (Yosemite Project / cMUMPS data) ===
 +
 +
'''Start condition:'''  A patient record extracted from an unspecified cMUMPS-based system as JSON-LD, containing demographics, prescriptions and lab results.  (cMUMPS is used here as in lieu of an existing MUMPS-based DOD electronic health record system that shall remain nameless.)
 +
 +
'''End condition:''' A FHIR RDF document containing representative source data translated into the FHIR resources.
 +
 +
'''Process:''' Using sharable, pluggable translators, translate source data to target data by running each translator (on an appropriate translation engine) and automatically assembling the results.
 +
 +
'''Extra Credit:''' Demonstrate how translators written in different languages can be used together.
 +
 +
=== 4. Translate data (Yosemite Project / AALTER data) ===
 +
 +
'''Start condition:'''  Data describing multiple procedures performed on a single patient, extracted from an AALTER system as JSON-LD.  (AALTER is used here in lieu of an existing DOD electronic health record system that shall remain nameless.)
 +
 +
'''End condition:''' A FHIR RDF document containing data expressed as FHIR Procedure resources.
 +
 +
'''Process:''' Using sharable, pluggable translators, translate source data to target data by running each translator (on an appropriate translation engine) and automatically assembling the results.
 +
 +
'''Extra Credit:''' Demonstrate the use of sharable, pluggable translators to produce a FHIR Bundle in FHIR RDF, containing both the results of this use case and Use Case #3.

Latest revision as of 14:37, 9 June 2016

Return to May 2016 Proposals - Return to FHIR Connectathon 12

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). Mappings could be written in any style, ranging from simple translation tables or expressions to executable code such as EcmaScript. Different participants may demonstrate the virtues of different mapping styles.

  • Pre-requisites: none

Schedule

Saturday 1pm-4pm:

  • Participants show & tell
  • Draft summary and outcomes

Sunday 9am-12:30pm:

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 manage 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.

3. Translate data (Yosemite Project / cMUMPS data)

Start condition: A patient record extracted from an unspecified cMUMPS-based system as JSON-LD, containing demographics, prescriptions and lab results. (cMUMPS is used here as in lieu of an existing MUMPS-based DOD electronic health record system that shall remain nameless.)

End condition: A FHIR RDF document containing representative source data translated into the FHIR resources.

Process: Using sharable, pluggable translators, translate source data to target data by running each translator (on an appropriate translation engine) and automatically assembling the results.

Extra Credit: Demonstrate how translators written in different languages can be used together.

4. Translate data (Yosemite Project / AALTER data)

Start condition: Data describing multiple procedures performed on a single patient, extracted from an AALTER system as JSON-LD. (AALTER is used here in lieu of an existing DOD electronic health record system that shall remain nameless.)

End condition: A FHIR RDF document containing data expressed as FHIR Procedure resources.

Process: Using sharable, pluggable translators, translate source data to target data by running each translator (on an appropriate translation engine) and automatically assembling the results.

Extra Credit: Demonstrate the use of sharable, pluggable translators to produce a FHIR Bundle in FHIR RDF, containing both the results of this use case and Use Case #3.