ITI TI Supp Updates to FHIR STU3

From IHE Wiki
Jump to: navigation, search

This wiki page is used by the ITI TC to collaborate and plan for updating ITI Supplements from FHIR DSTU2 to STU3. This page is not owned by anyone. To contribute...edit it.

Working dirctory

ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr15-2017-2018/Technical_Cmte/Workitems/STU3updates/

Short summary of updates needed

  • Add RESTful Query to ATNA -
  • Appendix Z -
  • mACM -
  • MHD -
  • PDQm-
  • PIXm - we have the opportunity to include a review of supplement defyning a new pattern (following the approach used in FHIR to cross-reference API).

FHIR DSTU2 to STU3 mapping

Note that DSTU and STU are "Trial Use", which means there is no guarantee that a change from one version to another will be compatible. STU3 has extra effort to provide a mapping. This information can be found in the FHIR specification. There is a drill down for each Resource mapping, and details on how to automatically transform.

Also tools like HAPI can support both versions at the same time.

Two perspectives on this data is important:

  1. To show our reader the impact of DSTU2 to STU3; to help them understand the impact to any code they might have.
  2. To use by editors, to guide editing of Profile text.

Our profile text should NOT concern with the translation. They should only document STU3 profiling. Do not include mapping, except possibly in throwaway introduction text such as a "Closed Issue" to help our reader find this information.

Notes & Analysis

  • Notes from the Feb ITI F2F:
    • MHD, PDQ, RESTful ATNA will be easy to update. The amount of work needed to move from DSTU2 to STU3 is less then what we've done last years.
    • mACM: could have significant changes, (this is the RISKY point, there could be a push to change the process).
    • The cmte agreed on Sending a request out to Vendors of CAT and other interested parties (specific implementers google groups) describing our intent to update the supplements. The contact list of people interested will be created by Lynn, John will prepare the email.
  • Notes from the EU 2017 Connectathon: http://wiki.ihe.net/index.php/File:NotesFromFHIRdiscussion.pdf

Open CPs to carry all changes

CP-ITI Title Doc Assignee Notes
1005 RESTful ATNA update to FHIR STU3 RESTful ATNA Mauro
1006 mACM updates to FHIR STU3 mACM Luke
1002 MHD update to FHIR STU3 MHD John
1007 Appendix Z updates to FHIR STU3 Appx Z John
1003 PDQm update to FHIR STU3 PDQm John
1004 PIXm update to FHIR STU3 PIXm Daniel


Open CPs to be handled in above CPs

CP-ITI Title Doc Assignee Notes
940 ITI-65 should specify how to link to the Binary resource from the DocumentReference MHD Walco I added a sentence to 3.65.4.1.2.1 and a reference to a clarification STU3 includes on how to resolve references within Bundles.
941 Encoding of UUIDs and OIDs in Identifiers MHD Walco Added examples to Appendix E.3 on FHIR Identifier Type, and added note in MHD 5.4.1 with reference to E.3.
942 Encoding of XDSDocumentEntry.referenceIdList in FHIR DocumentReference resource MHD Walco Added proposed text to Appendix E.3.1, and added reference from MHD referenceIdList entry in the mapping table.
943 Encoding of XDSDocumentEntry.uniqueId in FHIR Identifier MHD John added clarifiction to Appendix Z, and reference from MHD for document uniqueId. Also tracking an open FHIR CR.
944 Clarification of hash and size attributes in FHIR MHD John fixed
945 ITI-65 should define how to reference patients in a provide transaction MHD John STU3 allows us to use Reference.identifier to hold just the identifier. The current text forbids that. The current text also forbids a relative URL to a Patient within the Bundle. The current text also forbids empty. Thus a PUSH use is somewhat not possible without pre-coordinated Patient.
946 ITI-65 Provide Bundle response status codes should be clarified MHD John applied solution from 946 to MHD section 3.65.4.2.2
1036 Move security considerations to Z so that everyone can just reference it All John Prototyped this in Z, MHD, and PDQm. Seemed to work, but might also not be as useful to the reader.
826 PDQm - Clarify requirements for Pediatric Demographics PDQm Justin Added shall statements in vol 2 section.
1011 PDQm Case 3 – HTTP Return Code clarification PDQm John Reviewed this, and looked to updated FHIR. 200 is the only acceptable response. So leave as currently documented.


Editing Instructions

  • Look at the published differences between DSTU2 and STU3 http://hl7.org/fhir/STU3/diff.html
    • This should indicate big differences. Address these in your edits
  • When changing string "DSTU2" to "STU3"
    • Also make sure to change the hyper-link. Using Word Search-and-Replace will only change the text, not the underlying URL
    • Easiest: Don't use search-and-replace. Find each, Right-Click --> Edit Hyperlink --> change the "Address:" field and the "Text to display" will automatically change.
    • Most URLs will just need DSTU2 to STU3 change.
    • Make sure that each one is appropriate. Some DSTU2 pages we might have pointed at could have been specific to DSTU2, such as notes about future changes.
  • Some profiles might have given the three digit version of DSTU2 (e.g. 1.0.2). This is dangerous as corrections can increment the third digit. It is really best to just use the "STU3" tag, and not bring in the version number.
  • Search Parameters
    • Confirm that the search parameters we included still exist, are the same 'type' of search parameter.
    • STU3 added workflow, and thus there is likely a status element that tracks lifecycle. It is important we give guidance, as this element is another way that resources can be made inactive. That is in DSTU2 we assumed REST CRUD was the only state tracking. So now clients migh need to ALWAYS include a query parameter to force results to e active -- e.g. PDQm might need to force clients to always include -active search parameter.
    • Check any example search parameter values to be sure they are still valid.... Highlight those you are not sure about for group discussion
    • Look over new search parameters in STU3 to see if any might be useful to be included. Note that if we don't include it in our profile, the presumption is that a server does not need to support it, and thus a client can't be sure it will be implemented.
      • Some query parameters didn't exist in DSTU2 yet we needed them for the original usecases of the Profile -- In these cases it is acceptable to add the query parameter simply in this ballot.
        • Example: New "active" parameter in Patient
      • Some query parameters were added to STU3 that would be useful to the IHE Profile, but were not needed by the original usecases of the Profile -- In these cases it is NOT acceptable to add them in this ballot, but it is acceptable to create a new CP to be managed post
        • Example: New "phonetic" parameters on Patient that add name searching capability, but where that was not in our PDQ or PDQv3 profile usecases
  • Review examples we give to assure the are still valid. Highlight those you are not sure about for group discussion
  • Review Resource constraints we give
    • Are these constraints still needed?
  • Review Resource extensions we give
    • We tried not to extend, but if there are extensions they need to be reviewed
    • Possibly what we needed to extend is now part of the Resource
    • Note that many resources now have 'core extensions'.
    • Example: Patient now has mothersMaidenName extension, where as we did this extension ourself.
  • Conformance Resource has been renamed CapabilityStatement -- leverage Appendix Z.3
  • Explicit vocabulary -- where we tell our reader to use a specific value in a codesystem in FHIR
    • formal codes come from the root "http://hl7.org/fhir"; not from the STU3 uri.
    • For example in PDQm, case 5, error; we chose to tell the reader to report "not-supported"
    • This is done through http://hl7.org/fhir/issue-type, not-supported
      • these URI for the code system also don't have html on them.
  • Fix things for which we have a CP against the profile. We intend to produce just one CP for each supplement, including all changes needed regardless of if it is just STU3 related or was observed as a defect.
    • Major changes might still be pushed to future

Significant Dates

  • Link to FHIR publication schedule: http://wiki.hl7.org/index.php?title=FHIR_Ballot_Prep
  • Mar 23 - CP call for mobile bundle
  • Mar 30 - CP call for mobile bundle
  • Apr 24-28 - ITI TC F2F in Oak Brook
  • The following is the current timeline for republishing existing TF Vols & TI Supplements updated by CPs in 2017
    • May 15 - deadline for CPs to reach Final Text status in order to be integrated
    • May 15-June 23 - editors integrate CPs and internal review of integrations
    • June 26 - editors deliver updated docs to Mary
    • June 16 - July 15 - Mary works on repub & iterates w/ co-chairs, editors & lynn to review
    • July 30 - updated TF volumes & TI Supps are published on ihe.net
  • July 17-21 - ITI TC F2F in Oak Brook

References

Updates of Profiles to FHIR DSTU2

HL7 FHIR Profiles from other Organizations