Skip to end of metadata
Go to start of metadata

Facilitator:

Lisa Nelson

Scribe:

Matt Rahn

Date:


Minutes Approved as Presented 


This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."

Attendees:

 Click here to expand...

Agenda:

Joint with FHIR-I (SDWG Hosting)

  1. Call to order
  2. Alternate encoding for CDA such as JSON as an alternative to XML

  3. CDA Logical model in FHIR - how to handle CDA extensions
  4. Inheritance tree issues, starting with Composition, Clinical Document, etc. (Lisa)

Notes/Minutes

  1. Call to order
  2. Alternate encoding for CDA such as JSON as an alternative to XML

    1. CDA spec  asserts xml is only acceptable syntax, but with new tooling you can represent cda using fhir tooling it opens up potential
      1. cda narrative could be tricky
      2. Grahame - has tried representing cda using the logical model
      3. Narrative definition - narrative is xml, but uses cda format; write out html equivalent to JSON
    2. If you really want to do cda to json there's a possibility, but implementer have said it's easier to convert cda to json, but if they looking for something lightweight to do conversions and format mix-ups. You could just use xml to json tools and work with that. Grahame never thought it bought anyone anything.
    3. CDA does allow for option to do another type of format other than XML, but there probably isn't a lot of support
      1. If I'm receiving a document I expect XML - Emma
    4. If we display examples, we wouldn't want to display in JSON
    5. Should we hide JSON and Turtle from Resource Content? Some disagreement in removing the tabs. There could be an issue with receiving in JSON as most people are exchanging in xml. It could just be rejected
      1. You have the choice to strip JSON tab out! Default will opt out of JSON until a good use case comes along and then opt in to using it.
    6. Tools all use JSON for representations. The packages is in json format for all the definitions
    7. Grahame - we will only use xml format in CDA side
    8. Default will be to opt out of JSON until a good use case comes along and then opt in to using it.
  3. CDA Logical model in FHIR - how to handle CDA extensions
    1. List of extensions for CDA R2. Can we get into logical model? Grahame - Yes. Matter of someone writing the definitions into the right format. Sean/Grahame could do it or someone could be taught. Resulting XML needs to be in a different namespace.
      1. This could be part of conversion project of putting cda templates in structured definition.
      2. Extension Definition library is light on material
      3. Look at CDA R2 extensions and migrated to confluence 
      4. Sean could propose an improved definition and bring back to SDWG
      5. We never put the rigor around the extensions we have in FHIR and should revisit and be more specific. They will be elements not extensions, but you still have definition issues
      6. Only SDTC extensions should be applied
    2. We want assurance that it's possible how to get it done. Sean, Alexander, and Grahame can collaborate to do this work!
  4. Inheritance tree issues, starting with Composition, Clinical Document, etc. (Lisa)/Maturity level on composition resource stuck at level 2-discuss bringing it up to three, possibly four (Rick Geimer)
    1. Composition Resource - lack of awareness around Clinical Document Profile
    2. Do we know when we should be building off of Composition or the profile? 
      1. US Header has extensions that are missing in Composition (Rick)
        1. They should be put in ClinicalDocument profile
      2. Grahame - problematic language in Composition; we use the word clinical a number of times; didn't intend to mean clinical info derived from patient
        1. there is a forward reference to clinical document
        2. Clinical attestation is appropriate for what we are going with, but interested in changing if it makes it more clear.
        3. Can it just be attestation rather than Clinical Attestation? TBD later
      3. SDWG has not taken a deliberate focus on looking out the difference between composition resource and profile on Composition called clinical document. Will make sure to take a long look at profile.
    3. Comment against our own Composition resource to remove Clinical from the notion Attestation - SDWG will do a fresh review of clinical document profile
      1. There is an extension difference and a constraint on the subject (patient group)
    4. Extensions should be brought up for R5!
    5. Discussed that Clinical Document is for only Clinical information
    6. Look at maturity model spreadsheets and advance them into Profiles
  5. Publication approvals for Pharmacy care plan based on FHIR and C-CDA on FHIR - never published since review wasn't complete until December ((added during Q1 by Rick Geimer)
    1. Final Review for SDWG to approve for CDA Pharmacy Care Plan
    2. Need to add to PSS so the review gets completed.
    3. Transforms from the cda representations of that document type to the FHIR representation
      1. Rick has updated the transforms for R4
      2. Bilateral transform
    4. Do you do one or two PSSs? Currently one PSS 
      1. If project is finished then it may need a new PSS, but push is to keep the current PSS
      2. Are you doing both formats or just one? Should be addressed in the PSS
    5. Not worth doing mappings or transforms if nobody is going to do it, but it could be a historical issue and maybe if started now it may not have a disconnect.
    6. As we have matured that we can realize that at the PSS level, What formats should we be supporting? e.g. Don't want to end with two value sets that aren't aligned
      1. one value set should be shared and are doing best to make that happen
    7. Not everyone would have the funding to do the conversions to another version
    8. Concept project - lighter weight before a PSS. First thing we look at a new piece of work. Which syntax's are supported. Remove the silos and think about the problem across all versions.
    9. Implementers need to be able to expect and handle both cda and fhir (Emma)
      1. Customers just want it to work
    10. Perceived problem as a SDO it's HL7 responsibility to solve the perceived issues with the standards implementations.
    11. Lisa - take issue to ask at PSS level a question that this information should be thought about in three different product families
  6. Composition Resource - Dinesh Google
    1. Have a note an addendum to that note that both have their own IDs from that system. EHR generate synthetic ID to link them together.
    2. Is there a guidance on where to store the artificial ID? Seen with Compositions and Diagnostic Resource
      1. Comp has an ID; appendum to the comp resources
    3. Two comp resources within source systems creates a third id created to represent that link
      1. relatesTo
    4. Grahame - there is a linkage resource which purpose is to identify the same document in different representations
    5. Rick - do we modify linkage so it doesn't only apply to identical item
    6. For the use case, an extension is the most logical way to solve the problem.
    7. Linkage Resource is still draft - PC is willing to entertain change requests to the resource
    8. Should write a White paper for clinical document and document in FHIR? 
      1. Could add use case to clarify in white paper
    9. Resource metadata report that a partOf that referenced to linkage?
      1. There is no implication other than they share a common set and if you wnat to define further you'd define in linkage. Pointer
    10. Where does discussion about renaming document reference lie?
      1. pushback on renaming Doc Reference 
      2. Grahame exercised his discretion that he's asking community feedback before changing the name of DocumentReference
      3. OO, Media, and SDWG combined to try and push for renaming DocumentReference
    11. R5 
      1. Looking at Choice fields on whether they are being used correctly. There could be policy coming out about how choice fields are being used.
      2. Not much a structural impact.
      3. None of them will be removed, but think about the fields around past and future timing. People haven't thought through how they all fit together and maybe dfine a single data type to invest in.
      4. Does this help us clean StatusCode?
        1. Grahame - that's a different subject. Status' will be addressed in R5, but if there are some that are not needed or should be added. Status mapped to canonical status codes.
        2. If the element has status in it it must be mapped back to the statuscode
  7. We should meet with FHIR-I in San Antonio

Error rendering macro 'include'

com.atlassian.renderer.v2.macro.MacroException: No page title provided.