View source for Updates of Profiles to FHIR DSTU2

This page holds the overall plan (current a work-in-progress) for updating the IHE Profiles to FHIR DSTU2.  The purpose is to ensure consistency of updates across affected IHE profiles.

= Meeting =
Bi-Weekly: Starting November 23, 2015
https://himss.webex.com/himss/j.php?MTID=m9db38c21ca7f849cf3ca6f9c5c88dc4c

= Timeline =
Goal is to have the updates ready for EU connectathon. This means:

* done with the CP ballot by March 1
* into ballot by February 1

= List of Profiles to be updated =

The HL7 FHIR specification [http://wiki.hl7.org/index.php?title=FHIR_Profiles_from_other_Organizations lists the following IHE profiles]

In ITI, Initial work is being done using CPs.  These are found in ITI's [ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2016/CPs/1_Assigned/ Assigned directory for CPs]. The CP will be balloted as an augmented CP, that is a CP that points to a WORD change-tracked supplement,: 
* mACM - CP-ITI-883 - assigned to Luke Duncan
* RESTful ATNA Query - CP-ITI-887 - assigned to Mauro Zanardini

In PCC, (Not clear how PCC is managing the updates. Not sure if they are using the same CP plan as ITI)
* CMAP -- Keith
* GAO -- Keith (Likely starting with the HL7 IG and working back to IHE?)
* RECON -- George/Emma

Done -- Ballot #32
* MHD - CP-ITI-886  - assigned to John Moehrke -- again tracking on [[MHD Status]]
* PDQm - CP-ITI-885 - assigned to Justin Fyfe
* PIXm - CP-ITI-884 - assigned to Daniel Berezeanu
* Appendix on FHIR - CP-ITI-919

= Task =

* Mauro -- editor of RESTful ATNA
* Luke -- editor of mACM

Process
# Using WORD change tracking
# work through the Punch List, using the Google spreadsheet to track progress
# issues to be brought to the bi-weekly tcon should be highlighted using WORD comments
# upload your work with filename including date stamp
# send email to ititech after you put a draft for discussion on the FTP

= Working Directory=
Working Directory:  ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr14-2016-2017/Technical%20Cmte/Workitems/DSTU2updates/
* sub-workgroup participants use WORD change-tracking to add comments and corrections
* Save your updates to the FTP using a new date or your initials in the filename

= Punch List of changes =

There are some things that need to be done consistently for all profiles of FHIR. There are other things that need to be unique to each profile. Profile specific changes are managed independently of this punch list.

The following list of items have been brought into a Google Spreadsheet for tracking
https://docs.google.com/spreadsheets/d/1wCsi18VRaekJ4Kdljb-Stk6HjD1vYtlv7We4ojtB9BA/edit?usp=sharing


* Spell out FHIR properly "Fast Healthcare Interoperability Resources", 
** on first invocation include TM and Copyright. --- Or is this done by Mary in the front material?
* Align on DSTU2 final published http://hl7.org/fhir/DSTU2/index.html
* Make sure the URLs to the FHIR specification are fully specified and accurate.  
** The links to value sets (eg administrative-gender) have changed.  Eg. from http://hl7.org/fhir/link-type to https://www.hl7.org/fhir/valueset-link-type.html
** others TBD.
* FHIR section numbers
** Some section numbers have changed between DSTU2 and earlier versions.  Each TI Supplement needs to be reviewed to ensure FHIR section numbers are still accurate.
** Need a consistent way to use FHIR section numbers that are distinct from IHE section numbers. For example when we refer into the FHIR specification (e.g. when referencing the Signature data type we could use "1.19.0.16 Signature", or could use the anchor URL http://hl7.org/fhir/DSTU2/datatypes.html#signature). If using the section numbers (e.g. 1.19.0.16) it needs to be clear that is a FHIR spec number, not an IHE profile number. -- Might we define a prefix "fhir:1.19.0.16"
** DO NOT use FHIR section numbers, they seem too unstable and are built dynamically by the FHIR build. use the URL from the http://hl7.org/fhir/DSTU2/. Use anchor URL when possible.
* Fixup where we have duplicated FHIR specification using methods other than by-reference or perfect-copy. For example where we have copied FHIR specification and changed the format. General guidance is to not duplicate, but rather give the reader a URL and expect they can navigate to the FHIR specification.
* Opportunity to improve readability or implementation
** Where we might need to explain how to translate between companion profiles
*** For example where a PDQ query exists, show how to do the same query in PDQm
* Clearly indicate as Open-Issue which FHIR resources are being used that are indicated as Frozen by DSTU2, and which ones are not. (e.g., ATNA - AuditEvent is not DSTU2, but will be in DSTU2.1 ballot)
* Create a HL7 balloted and published FHIR Profile
* Focus on Appendix Z -- the shared appendix on FHIR Implementation Materials
** Should we extract out Appendix Z from PDQm? Thus making it more obvious as a shared appendix?
** What should be added to Appendix Z?
* Use the same definition of "Mobile", look to RESTful ATNA for current-best-explaination.
* Similar specification for Audit Logging 
** To address the fact that mobile clients are sometimes underpowered and thus don't have the ability to do all the audit logging we normally expect of a client use the text "should send audit messages if possible" for the client side.
** Consider changing the style of auditing for PIXm and PDQm to be like what Elliott L tried doing for MHD in CP-ITI-891. That is, rather than duplicate the whole audit message table, reference the normal profile and express the delta.
* Remove RFC 4287 and 5005 around Atom feed (if they are listed)
* Check all search parameter types, they might have changed
** Assure _id search parameter is listed as a string type
* Nomenclature changed from "namespace" to "system"
* consistent handling of requested response type (mime-type)
* Use Appendix Z when possible
** When search parameter is token point at Z.2.2
** When search parameter is string point at Z.2.3
** etc...
* format
** Clients in queries CAN use _format
** Clients in queries SHALL use 
*** XML: application/xml+fhir
*** JSON: application/json+fhir
** Servers must support all mime-types as defined in FHIR
** Servers must support _format
...more TBD ('''feel free to edit this list...this page is not owned by one person''')

= Profile-specific =

In addition to the updates being doing consistently across profiles, some supplements will need profile-specific changes.

* Address open CPs for the supplement
** on the [https://docs.google.com/spreadsheets/d/1gdr_Y8xZBvbb326J4z67cqprxOexFgtkPj_VlD3rB9E/edit?usp=sharing ITI CP spreadsheet], on the 'Active CPs' tab, ensure that any Assigned CPs are completed as part of the DSTU2 revision to the document, or before.