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

Difference between revisions of "2018 02 26 Minutes - Technical Team"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Return to  
 
Return to  
*[C-CDA_on_FHIR_Mappings_and_Profile_Updates|C-CDA on FHIR Mappings and Profile Updates]] Project
+
*[[C-CDA_on_FHIR_Mappings_and_Profile_Updates|C-CDA on FHIR Mappings and Profile Updates]] Project
  
Attendees:
+
=Attendees=
  
 
Lisa Nelson (convener)<br>
 
Lisa Nelson (convener)<br>
Line 14: Line 14:
  
  
Agenda:
+
=Agenda=
 
# Discuss project scope definition
 
# Discuss project scope definition
 
# Discuss the process we will use to Define the CCDA test cases and test sling
 
# Discuss the process we will use to Define the CCDA test cases and test sling
 
## Gather current ideas for CCDA test cases and test sling  
 
## Gather current ideas for CCDA test cases and test sling  
 
# Clarify CCDA/FHIR Task Force meeting requirements, wiki documentation, membership, purpose, etc.
 
# Clarify CCDA/FHIR Task Force meeting requirements, wiki documentation, membership, purpose, etc.
 +
 +
=Minutes=
 +
 +
<p>Background – invest in C-CDA to FHIR Mapping, help implementers deal with this need
 +
</p><p>Idea: start a task force to select a set of test cases and prioritize sections out of test cases, then use some ONC money to write the transforms using the FHIR mapping language. Grahame would write a test sling to do a round-trip validation process.  Resource would bring discovered issues to this group and triage them. This would group would send the issues to CDA or FHIR to work on.  The output of the transform/map development work would be added to the next version of the C-CDA on FHIR Implementation Guide.
 +
</p><p>Timeframe: cycle of the work might be associated with impact on ballot, might like to have some output to review by the May meeting. 
 +
This is more of a proof of concept to see what we learn. Would like to see results in this half of the year.
 +
</p><p>Potential focus: Meds, Allergies, Problems, as a potential starting spot. 
 +
</p><p>Approach would be incremental and add more over time.
 +
</p><p>We have the Sections mapped into the FHIR documents, but we don’t have evidence of how the mappings from C-CDA to corresponding FHIR US Core Profiles.  Known challenges:  value sets, status.
 +
 +
</p><p>Rick mentioned maturity issues with FHIR Mapping language:
 +
Doable with xslt and xpath, but handling context conduction was challenging. 
 +
# How to pull in the context from the CDA document into the FHIR resource.  How to conditionally and positionally tell how to get the correct information. Rick has example xslt to handle the logic that needs to be expressed.
 +
# Negation issues – Boolean in CDA, but lots of vocabulary codes that might be appropriate maps.
 +
# Concern wrapper – how to handle the transformation of Problem Concerns because they can hold multiple clinical statements.  This would be broken into multiple Condition Resource – and won’t be able to round-trip correctly. This is a known issue that could be documented, and no need to resolve it here.
 +
# Same author or same subject in several locations in a CDA, for example, Prescribing Physician is the author in many spots of the CDA.  Would it be expected to dedup this into a single Provider resource.  This brings us to an issue of use of ids in CDA.  What if the same business identifier, i.e. same NPI.    Do we want to tackle this? Would we want to show a way in CDA to establish how to do this so only one reference would be the “master reference”?  (This would not impact prior documents already designed without this.)
 +
# Primary scope is CDA to FHIR, but FHIR to CDA is in scope relative to “round-trip” requirements.  What about FHIR to CDA?  Is that in scope?  For example, what do you do with composition.text when there is no equivalent in CDA?  (Grahame: was not thinking this is going to take on the general problem of FHIR to CDA.) Rick agreed as long as we document this is not an expectation.
 +
# Narrative – no trouble with CDA to FHIR rendering.  Going the other way, if you use all HTML in FHIR, you will have trouble when round-tripping.  Need to identify the subset of xhtml that is “round-tripable”. Rick says he has played with this and it is less challenging than you might expect as long as you are careful what you choose to use from xHTML.
 +
# Fixed codes, such as status codes in FHIR, where there isn’t a corresponding concept in CDA.  Just a code in FHIR with a fixed binding.  Example: TBD.  These could be flagged as issues and documented.
 +
 +
</p><p>Grahame – the mapping language is important to use because it is declarative and can be used to create profiles.
 +
Concept of conformance from any implementation guidance that results from this. Are we saying that you can choose to do mappings this way, or do we need to allow to do mappings in some other way. 
 +
</p><p>Rick asked: Have we ever considered putting tags on a resource to assert that they followed certain standard rules when creating this from a CDA? This was created using the known mapping process as defined on a certain date. 
 +
</p><p>Austin: You may need this sort of assertion to tell what may have happened if clinical data is lost.
 +
</p><p>Rick: because of open slices, implementers could put information somewhere “unintended” and still pass the validator for the IG.
 +
 +
</p><p>Rick – FHIR Validator should be able to be run on the FHIR document that results from a C-CDA conversion to FHIR Document. 
 +
Even if done correctly – map a CDA Vital Sign to a Vital Sign Profile defined in FHIR, but you don’t use the correct observation status, then that would not be “meaningfully conformant” but might be “testably conformant”.
 +
“Making the claim you conform to the C-CDA on FHIR IG means you have conformed to the mappings.” This implies you have followed the logic, and if you didn’t follow the logic, you did it wrong.
 +
</p><p>Josh: the profile tag …
 +
 +
</p><p>Can the test sling produce/gather results in a way that allows us to learn from the experience?  For example, could we tell how many conversions results in the same set of resources being generated.
 +
</p><p>Are there tools that can assess CDA document now? 
 +
</p><p>Grahame did some work for Argonaght project to analyze CDA and resulting FHIR output documents.  This might be a separate tool that could be used to add to what can be analyzed about CDA of FHIR documents.  (Action: Ask ONC to see if they can run additional analytics on documents that get run through the Scorecard.)
 +
 +
=Logistics:=
 +
Does this effort need to be formulated with a PSS and follow a standard HL7 project process?
 +
Rick spoke in favor of this idea.  Make it a SDWG project? Yes, sounds good.  Calvin agreed.
 +
<p>Rick will work with Lisa on making a PSS.
 +
<p>Add to SDWG wiki under C-CDA on FHIR.
 +
<p>Do we need others to be involved? Wayne, Calvin and Grahame will handle writing the RFP. 
 +
=Test Cases=
 +
Where would test cases come from?  Could we have implementers submit files?  Sure!
 +
Could we gather files from prior/July CDA Implementation-A-THON (Lisa – ask about current, Brett samples from prior CDA Implementation-A-THONs.  Offer options for organizations who might like to offer their documents to be used for multiple purposes. Also could offer the sling to be used at additional FHIR Connectathons.
 +
=Future Meeting Plans=
 +
Follow-up phone calls?  Week after HIMSS?  Could we meet every two weeks, starting on March 19th. Lisa will book these meetings. Lisa will offer to use my Goto Meeting line.  Can we do Mon 2-3pm ET?  Grahame said ok for now…. Bring PSS back to this group on the 19th to review.
 +
 +
=Summary of Decisions=
 +
# Lisa, Rick and Grahame to formulate Draft PSS
 +
# Get feedback in SDWG on 3/15
 +
# Bring back to this task force on 3/19 for Review
 +
=Next Meeting=
 +
March 19th, 2:00pm ET

Latest revision as of 07:56, 15 March 2018

Return to

Attendees

Lisa Nelson (convener)
Grahame Grieve
Josh Mandel
Brett Marquard
Rick Geimer
Calvin Beebe
Austin Kreisler
Wayne Kubick


Agenda

  1. Discuss project scope definition
  2. Discuss the process we will use to Define the CCDA test cases and test sling
    1. Gather current ideas for CCDA test cases and test sling
  3. Clarify CCDA/FHIR Task Force meeting requirements, wiki documentation, membership, purpose, etc.

Minutes

Background – invest in C-CDA to FHIR Mapping, help implementers deal with this need

Idea: start a task force to select a set of test cases and prioritize sections out of test cases, then use some ONC money to write the transforms using the FHIR mapping language. Grahame would write a test sling to do a round-trip validation process. Resource would bring discovered issues to this group and triage them. This would group would send the issues to CDA or FHIR to work on. The output of the transform/map development work would be added to the next version of the C-CDA on FHIR Implementation Guide.

Timeframe: cycle of the work might be associated with impact on ballot, might like to have some output to review by the May meeting.

This is more of a proof of concept to see what we learn. Would like to see results in this half of the year.

Potential focus: Meds, Allergies, Problems, as a potential starting spot.

Approach would be incremental and add more over time.

We have the Sections mapped into the FHIR documents, but we don’t have evidence of how the mappings from C-CDA to corresponding FHIR US Core Profiles. Known challenges: value sets, status.

Rick mentioned maturity issues with FHIR Mapping language:

Doable with xslt and xpath, but handling context conduction was challenging.

  1. How to pull in the context from the CDA document into the FHIR resource. How to conditionally and positionally tell how to get the correct information. Rick has example xslt to handle the logic that needs to be expressed.
  2. Negation issues – Boolean in CDA, but lots of vocabulary codes that might be appropriate maps.
  3. Concern wrapper – how to handle the transformation of Problem Concerns because they can hold multiple clinical statements. This would be broken into multiple Condition Resource – and won’t be able to round-trip correctly. This is a known issue that could be documented, and no need to resolve it here.
  4. Same author or same subject in several locations in a CDA, for example, Prescribing Physician is the author in many spots of the CDA. Would it be expected to dedup this into a single Provider resource. This brings us to an issue of use of ids in CDA. What if the same business identifier, i.e. same NPI. Do we want to tackle this? Would we want to show a way in CDA to establish how to do this so only one reference would be the “master reference”? (This would not impact prior documents already designed without this.)
  5. Primary scope is CDA to FHIR, but FHIR to CDA is in scope relative to “round-trip” requirements. What about FHIR to CDA? Is that in scope? For example, what do you do with composition.text when there is no equivalent in CDA? (Grahame: was not thinking this is going to take on the general problem of FHIR to CDA.) Rick agreed as long as we document this is not an expectation.
  6. Narrative – no trouble with CDA to FHIR rendering. Going the other way, if you use all HTML in FHIR, you will have trouble when round-tripping. Need to identify the subset of xhtml that is “round-tripable”. Rick says he has played with this and it is less challenging than you might expect as long as you are careful what you choose to use from xHTML.
  7. Fixed codes, such as status codes in FHIR, where there isn’t a corresponding concept in CDA. Just a code in FHIR with a fixed binding. Example: TBD. These could be flagged as issues and documented.

Grahame – the mapping language is important to use because it is declarative and can be used to create profiles.

Concept of conformance from any implementation guidance that results from this. Are we saying that you can choose to do mappings this way, or do we need to allow to do mappings in some other way.

Rick asked: Have we ever considered putting tags on a resource to assert that they followed certain standard rules when creating this from a CDA? This was created using the known mapping process as defined on a certain date.

Austin: You may need this sort of assertion to tell what may have happened if clinical data is lost.

Rick: because of open slices, implementers could put information somewhere “unintended” and still pass the validator for the IG.

Rick – FHIR Validator should be able to be run on the FHIR document that results from a C-CDA conversion to FHIR Document.

Even if done correctly – map a CDA Vital Sign to a Vital Sign Profile defined in FHIR, but you don’t use the correct observation status, then that would not be “meaningfully conformant” but might be “testably conformant”. “Making the claim you conform to the C-CDA on FHIR IG means you have conformed to the mappings.” This implies you have followed the logic, and if you didn’t follow the logic, you did it wrong.

Josh: the profile tag …

Can the test sling produce/gather results in a way that allows us to learn from the experience? For example, could we tell how many conversions results in the same set of resources being generated.

Are there tools that can assess CDA document now?

Grahame did some work for Argonaght project to analyze CDA and resulting FHIR output documents. This might be a separate tool that could be used to add to what can be analyzed about CDA of FHIR documents. (Action: Ask ONC to see if they can run additional analytics on documents that get run through the Scorecard.)

Logistics:

Does this effort need to be formulated with a PSS and follow a standard HL7 project process? Rick spoke in favor of this idea. Make it a SDWG project? Yes, sounds good. Calvin agreed.

Rick will work with Lisa on making a PSS.

Add to SDWG wiki under C-CDA on FHIR.

Do we need others to be involved? Wayne, Calvin and Grahame will handle writing the RFP.

Test Cases

Where would test cases come from? Could we have implementers submit files? Sure! Could we gather files from prior/July CDA Implementation-A-THON (Lisa – ask about current, Brett samples from prior CDA Implementation-A-THONs. Offer options for organizations who might like to offer their documents to be used for multiple purposes. Also could offer the sling to be used at additional FHIR Connectathons.

Future Meeting Plans

Follow-up phone calls? Week after HIMSS? Could we meet every two weeks, starting on March 19th. Lisa will book these meetings. Lisa will offer to use my Goto Meeting line. Can we do Mon 2-3pm ET? Grahame said ok for now…. Bring PSS back to this group on the 19th to review.

Summary of Decisions

  1. Lisa, Rick and Grahame to formulate Draft PSS
  2. Get feedback in SDWG on 3/15
  3. Bring back to this task force on 3/19 for Review

Next Meeting

March 19th, 2:00pm ET