FHIR Chat · DSTU2 vs DSTU3

Happy Friday! It looks like many on this list are already implementing DSTU3. Is there any concern of implementing something from DSTU3 that may change before the cutoff date? In other words, we are doing mobile application refactoring to utilize a HAPI FHIR API and FHIR-based database structure using DSTU2. Could we actually be using DSTU3 now? We were initially concerned with doing this given things could change. Please redirect me if I am missing something in terms of risk of implementing DSTU2 vs DSTU3 given DSTU3 will be finalized in March 2017 hopefully. Thanks in advance for your comments!

Vadim Peretokin (Feb 10 2017 at 17:43):

I can't speak for everyone, but one usecase I know of that is driving people to implement an STU3 snapshot is that the resources have changed significantly since DSTU2, and/or have not been as usable in DSTU2, so going with DSTU2 would have been a bit of a waste

May Terry (Feb 10 2017 at 17:43):

I have the same question as @Lauren Wolejsza except our engineers are focusing on the FHIR server requirements for our EHR to meet the ONC 2015 Patient API data category - much appreciated if anyone can address.

Lauren Wolejsza (Feb 10 2017 at 17:45):

Yes, exactly. We are certainly encountering quite a few limitations. We are very early in our development so choosing to move to DSTU3 at this point would be better than more rework later. Hesitation from our client is DSTU3 is not yet "finalized" so to speak.

Vadim Peretokin (Feb 10 2017 at 17:49):

It might be easier for them to know that it's no longer Draft, so it's STU3. There also national-level implementations of STU3 at this point - Australia for example hosts a terminology server for the entire nation that's based on FHIR 1.4.0 (https://www.healthterminologies.gov.au/ncts/#/tools?content=nts). I'm sure there are other examples.

Lauren Wolejsza (Feb 10 2017 at 17:50):

@May Terry We are doing patient-generated health data (PGHD) from mobile applications so lots of open text data to be pointed to a FHIR resource field. Certainly having some challenges in doing this kind of mapping.

Dave Carlson (Feb 10 2017 at 18:01):

Lauren, I agree with Vadim's comment that it would be a waste of time to start new implementation using DSTU2 at this time. Changes to the STU3 resoruces will be frozen by end of February, and most substative changes have already been applied. For development and testing prior to end of March, there are numerous servers, including HAPI, that support FHIR 1.8.0 (Jan 2017 freeze). See the STU3 publication timeline at http://wiki.hl7.org/index.php?title=FHIR_Ballot_Prep

Lauren Wolejsza (Feb 10 2017 at 18:09):

@Dave Carlson This is a great point. Now to try to see what we can do. At the time of the decision, we did not know the timeline for release of DSTU3. Now, I know differently. Thank you!

May Terry (Feb 10 2017 at 18:11):

Thanks Dave and Lauren! This is super-helpful!

Dave Carlson (Feb 10 2017 at 18:19):

Lauren and May, for immediate development and prototyping (before end of March), I suggest using FHIR 1.8.0 specifications and HAPI (or other) servers that currently support this version, see http://hl7.org/fhir/2017Jan/index.html. When making longer-term design choices, compare with the Continuous Integration build specs until finalized with STU3 publication, see http://build.fhir.org/index.html