Stream: implementers
Topic: FHIR tracking
Jefferson (Dec 15 2020 at 17:59):
What type of tracking do you guys have in place where you version what client are hitting and eventually retire older version right?
Lloyd McKenzie (Dec 15 2020 at 18:43):
I'm not really following the question...
Cooper Thompson (Dec 15 2020 at 18:51):
Are you asking about tracking versions of your implementation of FHIR? Like what was discussed in this topic.
Jefferson (Dec 16 2020 at 14:11):
Yes like you guys talked about . Currently we have two EHR in production and one in Testing. The one in testing is requesting small changes that will require a new version . Once this EHR moves into production somehow we need to send that EHR the version they need. As well as the other two EHR. So I would think I need a method of tracking what EHR is using what version.
Yunwei Wang (Dec 16 2020 at 15:57):
Excel? :grinning:
I don't quite get the question. Do you provide client or server application?
Lloyd McKenzie (Dec 16 2020 at 16:32):
Instances can indicate what profiles they comply with (including what version). Though it's generally poor practice to require that.
Cooper Thompson (Dec 16 2020 at 18:08):
I still think API implementation versioning is a big nasty problem that is mostly unsolved in the FHIR space. There dozens or hundreds of API versioning issues that can break integrations that happen below the profile or IG level, and right now the FHIR spec doesn't offer a solution, so it may end up being a per-vendor thing.
Cooper Thompson (Dec 16 2020 at 18:09):
Or an upcoming WGM thing?
Jefferson (Dec 21 2020 at 13:42):
I am thinking to use your idea with the HTTP header and lets a client specify which FHIR version they need,
Yunwei Wang (Dec 28 2020 at 14:49):
Are you talking about FHIR version or API version? I thought you asked API versioning. For FHIR versioning, you can take a look of this page: http://build.fhir.org/versioning.html
Last updated: Apr 12 2022 at 19:14 UTC
