All,
While we haven’t explicitly discussed this topic on previous architecture calls, currently there is an implicit assumption that OpenHIE component reference software will exhibit backwards compatibility.
That is, a particular OpenHIE workflow will be supported into the future until that particular workflow version is explicitly declared to be unsupported.
Is this consistent with everyone’s understanding? Alternate views?
Thank you for your sharing your opinions!
Best,
Shaun
···
Shaun J. Grannis, MD MS FACMI FAAFP
Interim Director, The Regenstrief Institute Center for Biomedical Informatics
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
Hi,
Can we tease out the versioning a bit more. Some of the IHE profiles that we are using are in Trial Implementation status and have gone through some Change Proposals (CPs). Some of these have been breaking (e.g. with an early CP to CSD). We didn’t do a version number bumping of the OpenHIE workflow when this happened.
Since things were in Trial Implementation, breaking changes are considered to be “OK” from the IHE perspective. We have been working, I think, under an implicit assumption that we are using the most recently published Trial Implementation profile. Perhaps we just need to be explicit about this. Related to this is the version of FHIR that we are considering using…
Cheers,
-carl
···
Shaun J. Grannis, MD MS FACMI FAAFP
Interim Director, The Regenstrief Institute Center for Biomedical Informatics
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
Thanks Carl,
One point I hear from your reply is that we should document the version of each IHE profile used within OpenHIE workflows. This makes good sense and I agree we should do this.
Another issue that I think you raised is how to manage updates to IHE profiles. This raises a number of questions for me, and would be good to discuss on an upcoming architecture call. For example, if an IHE profile is updated and that profile is used by an OpenHIE workflow, should we automatically adopt the updated profile? Must we automatically adopt that profile? Can we continue to use the older profile? Would be helpful to clarify these issues, from my perspective.
Best,
Shaun
···
On Mon, Nov 14, 2016 at 11:14 AM, Carl Leitner litlfred@gmail.com wrote:
Hi,
Can we tease out the versioning a bit more. Some of the IHE profiles that we are using are in Trial Implementation status and have gone through some Change Proposals (CPs). Some of these have been breaking (e.g. with an early CP to CSD). We didn’t do a version number bumping of the OpenHIE workflow when this happened.
Since things were in Trial Implementation, breaking changes are considered to be “OK” from the IHE perspective. We have been working, I think, under an implicit assumption that we are using the most recently published Trial Implementation profile. Perhaps we just need to be explicit about this. Related to this is the version of FHIR that we are considering using…
Cheers,
-carl
On Nov 10, 2016, at 2:03 PM, Shaun Grannis sgrannis@gmail.com wrote:
All,
While we haven’t explicitly discussed this topic on previous architecture calls, currently there is an implicit assumption that OpenHIE component reference software will exhibit backwards compatibility.
That is, a particular OpenHIE workflow will be supported into the future until that particular workflow version is explicitly declared to be unsupported.
Is this consistent with everyone’s understanding? Alternate views?
Thank you for your sharing your opinions!
Best,
Shaun
Shaun J. Grannis, MD MS FACMI FAAFP
Interim Director, The Regenstrief Institute Center for Biomedical Informatics
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
In some of the cases OpenHIE community members are responsible for the CPs. We likely would want to adopt those 
But more generally, I think we should aim to keep up to date with the profiles. I don’t think this needs to necessarily be the responsibility of the individual software components though - we can also leverage the interoperability layer.
Cheers,
-carl
···
On Mon, Nov 14, 2016 at 11:14 AM, Carl Leitner litlfred@gmail.com wrote:
Hi,
Can we tease out the versioning a bit more. Some of the IHE profiles that we are using are in Trial Implementation status and have gone through some Change Proposals (CPs). Some of these have been breaking (e.g. with an early CP to CSD). We didn’t do a version number bumping of the OpenHIE workflow when this happened.
Since things were in Trial Implementation, breaking changes are considered to be “OK” from the IHE perspective. We have been working, I think, under an implicit assumption that we are using the most recently published Trial Implementation profile. Perhaps we just need to be explicit about this. Related to this is the version of FHIR that we are considering using…
Cheers,
-carl
On Nov 10, 2016, at 2:03 PM, Shaun Grannis sgrannis@gmail.com wrote:
All,
While we haven’t explicitly discussed this topic on previous architecture calls, currently there is an implicit assumption that OpenHIE component reference software will exhibit backwards compatibility.
That is, a particular OpenHIE workflow will be supported into the future until that particular workflow version is explicitly declared to be unsupported.
Is this consistent with everyone’s understanding? Alternate views?
Thank you for your sharing your opinions!
Best,
Shaun
Shaun J. Grannis, MD MS FACMI FAAFP
Interim Director, The Regenstrief Institute Center for Biomedical Informatics
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
Carl I like what you are proposing here. Since the mediator library is available and hopefully the framework is easier to “get going” with I think each community could “own” their workflows-mediators and keep those updated
···
On Thu, Nov 17, 2016 at 7:59 PM, Carl Leitner litlfred@gmail.com wrote:
In some of the cases OpenHIE community members are responsible for the CPs. We likely would want to adopt those But more generally, I think we should aim to keep up to date with the profiles. I don’t think this needs to necessarily be the responsibility of the individual software components though - we can also leverage the interoperability layer.
Cheers,
-carl
On Nov 17, 2016, at 8:15 AM, Shaun Grannis sgrannis@gmail.com wrote:
Thanks Carl,
One point I hear from your reply is that we should document the version of each IHE profile used within OpenHIE workflows. This makes good sense and I agree we should do this.
Another issue that I think you raised is how to manage updates to IHE profiles. This raises a number of questions for me, and would be good to discuss on an upcoming architecture call. For example, if an IHE profile is updated and that profile is used by an OpenHIE workflow, should we automatically adopt the updated profile? Must we automatically adopt that profile? Can we continue to use the older profile? Would be helpful to clarify these issues, from my perspective.
Best,
Shaun
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Regards
Carl Fourie
Senior Program Manager | Digital Health Division
Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org
Email Disclaimer:
This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
On Mon, Nov 14, 2016 at 11:14 AM, Carl Leitner litlfred@gmail.com wrote:
Hi,
Can we tease out the versioning a bit more. Some of the IHE profiles that we are using are in Trial Implementation status and have gone through some Change Proposals (CPs). Some of these have been breaking (e.g. with an early CP to CSD). We didn’t do a version number bumping of the OpenHIE workflow when this happened.
Since things were in Trial Implementation, breaking changes are considered to be “OK” from the IHE perspective. We have been working, I think, under an implicit assumption that we are using the most recently published Trial Implementation profile. Perhaps we just need to be explicit about this. Related to this is the version of FHIR that we are considering using…
Cheers,
-carl
On Nov 10, 2016, at 2:03 PM, Shaun Grannis sgrannis@gmail.com wrote:
All,
While we haven’t explicitly discussed this topic on previous architecture calls, currently there is an implicit assumption that OpenHIE component reference software will exhibit backwards compatibility.
That is, a particular OpenHIE workflow will be supported into the future until that particular workflow version is explicitly declared to be unsupported.
Is this consistent with everyone’s understanding? Alternate views?
Thank you for your sharing your opinions!
Best,
Shaun
Shaun J. Grannis, MD MS FACMI FAAFP
Interim Director, The Regenstrief Institute Center for Biomedical Informatics
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.