OHIE Specification Release: Creative Commons License?

[jthomas]

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license
https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

[carl]

Hi Jamie and thanks for raising this.

To the Arch team:

I’m not a fan of that license for our narrative works here. It basically restricts commercial use of our documentation and takes out any incentive for implementing partners to build on. I’m much more inclined
for the much more permissive nature of the “by attribution” approach (https://creativecommons.org/licenses/by/4.0).

I really think of this as to what are we trying to do here. HIE’s for low resource settings are, just by pure economics and demand, limited in the total number that can be deployed and built so anything that
is excluding others from working with us – especially commercial teams and other groups who are not primarily open source will be very limiting in our community and restrict the “new blood” that is able to come in.

Why I prefer the CC-BY option is that it gives options to teams that don’t have the mandate to make their solutions open source to leverage our work as source and cite the original source. We do run the risk
of some group taking what we have done and then commercializing it and selling it to others, but this should drive us to excel more! If a country can pay a few $$ for a much better version of our specification document that what we offer / or a local firm
has chosen to contextualise our specifications for their use-case / environment then we should support that and it should drive us to adapt.

We want to see our investments used (appropriately) and I think it is more the relationships that build the share alike mentality than the license so I would say let be as open to play with all as possible
and let our relationships and community engagement be the draw card that allows others to share back their investments – but also allow others to create innovative business models off of the work that is aimed at bettering health for all.

To quote Parks and Recreation’s Ron Swanson: “End Speech”.

···

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477
skype: carl.fourie17

stay connected:@DigitalSQR**
|** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Jamie Thomas jt48@regenstrief.org
Date: Tuesday, 21 May 2019 at 22:01
To: OHIE list ohie-architecture@googlegroups.com
Subject: OHIE Specification Release: Creative Commons License?

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/E0030250-9506-4089-AC42-A0C5C9A6497F%40regenstrief.org.
For more options, visit
https://groups.google.com/d/optout.

[Craig_Appl]

Hi,

I second Carl’s recommendation. I have licensed online documentation with CC-BY in previous positions for the reasons outlined by Carl.

Craig

···

Craig Appl

Health Technical Lead

[dritz]

+1 to both Carl’s and Craig’s comments. In my view, CC-BY should be our preferred option.

···

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045

[justin-fyfe]

Hi All,

Apologies for inserting myself in the conversation thread.

I agree that CC-BY is a great option, and agree NC would be difficult to interest non-OSS parties to participate…

If there is a concern about having access to enhancements (to the specs themselves), then CC-BY-SA is another good option. It requires remixes of the original work be published under BY-SA while
permitting commercial use of the assets (INAL but that is my understanding - CC BY-SA 4.0 Deed | Attribution-ShareAlike 4.0 International | Creative Commons).

Cheers

-Justin

On Behalf Of Derek Ritz

···

+1 to both Carl’s and Craig’s comments. In my view, CC-BY should be our preferred option.

On Wed, May 22, 2019 at 7:33 AM Craig Appl cappl@ona.io wrote:

Hi,

I second Carl’s recommendation. I have licensed online documentation with CC-BY in previous positions for the reasons outlined by Carl.

Craig

On Wed, May 22, 2019 at 1:08 AM Fourie, Carl cfourie@path.org wrote:

Hi Jamie and thanks for raising this.

To the Arch team:

I’m not a fan of that license for our narrative works here. It basically restricts commercial use of our documentation and takes out any incentive for implementing
partners to build on. I’m much more inclined for the much more permissive nature of the “by attribution” approach (https://creativecommons.org/licenses/by/4.0).

I really think of this as to what are we trying to do here. HIE’s for low resource settings are, just by pure economics and demand, limited in the total number
that can be deployed and built so anything that is excluding others from working with us – especially commercial teams and other groups who are not primarily open source will be very limiting in our community and restrict the “new blood” that is able to come
in.

Why I prefer the CC-BY option is that it gives options to teams that don’t have the mandate to make their solutions open source to leverage our work as source
and cite the original source. We do run the risk of some group taking what we have done and then commercializing it and selling it to others, but this should drive us to excel more! If a country can pay a few $$ for a much better version of our specification
document that what we offer / or a local firm has chosen to contextualise our specifications for their use-case / environment then we should support that and it should drive us to adapt.

We want to see our investments used (appropriately) and I think it is more the relationships that build the share alike mentality than the license so I would
say let be as open to play with all as possible and let our relationships and community engagement be the draw card that allows others to share back their investments – but also allow others to create innovative business models off of the work that is aimed
at bettering health for all.

To quote Parks and Recreation’s Ron Swanson: “End Speech”.

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**
|** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged, confidential, or exempt from disclosure
  under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments, is strictly prohibited. If you
  have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

**From:**OHIE list ohie-architecture@googlegroups.com on behalf of Jamie Thomas jt48@regenstrief.org
Date: Tuesday, 21 May 2019 at 22:01
To: OHIE list ohie-architecture@googlegroups.com
Subject: OHIE Specification Release: Creative Commons License?

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/E0030250-9506-4089-AC42-A0C5C9A6497F%40regenstrief.org.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/2AE12E8B-12D1-4BCE-8546-6C5BB2A5672F%40path.org.
For more options, visit
https://groups.google.com/d/optout.

–

Craig Appl

Health Technical Lead

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/CAEGTrw42DvcNdNf5crVn6xfVapePkwRcVr0qkQqs2x0WqRhbRw%40mail.gmail.com.
For more options, visit
https://groups.google.com/d/optout.

–

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.

+1 (905) 515-0045

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/CAOe53S1wzZd9xOMJ5k_9S9kbJON2gV-YOKGck5mxEQQbVqWwWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ron_G_Parker]

Agreed.

Ron G Parker | mail: rgparker57@eastlink.ca | mobile: +1-902-222-7716 | skype: rongparker | timezone: ADT (UTC -3)

···

From: ohie-architecture@googlegroups.com ohie-architecture@googlegroups.com On Behalf Of Derek Ritz
Sent: May 22, 2019 12:05
To: Craig Appl cappl@ona.io
Cc: Fourie, Carl cfourie@path.org; ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

+1 to both Carl’s and Craig’s comments. In my view, CC-BY should be our preferred option.

On Wed, May 22, 2019 at 7:33 AM Craig Appl cappl@ona.io wrote:

Hi,

I second Carl’s recommendation. I have licensed online documentation with CC-BY in previous positions for the reasons outlined by Carl.

Craig

On Wed, May 22, 2019 at 1:08 AM Fourie, Carl cfourie@path.org wrote:

Hi Jamie and thanks for raising this.

To the Arch team:

I’m not a fan of that license for our narrative works here. It basically restricts commercial use of our documentation and takes out any incentive for implementing partners to build on. I’m much more inclined for the much more permissive nature of the “by attribution” approach (https://creativecommons.org/licenses/by/4.0).

I really think of this as to what are we trying to do here. HIE’s for low resource settings are, just by pure economics and demand, limited in the total number that can be deployed and built so anything that is excluding others from working with us – especially commercial teams and other groups who are not primarily open source will be very limiting in our community and restrict the “new blood” that is able to come in.

Why I prefer the CC-BY option is that it gives options to teams that don’t have the mandate to make their solutions open source to leverage our work as source and cite the original source. We do run the risk of some group taking what we have done and then commercializing it and selling it to others, but this should drive us to excel more! If a country can pay a few $$ for a much better version of our specification document that what we offer / or a local firm has chosen to contextualise our specifications for their use-case / environment then we should support that and it should drive us to adapt.

We want to see our investments used (appropriately) and I think it is more the relationships that build the share alike mentality than the license so I would say let be as open to play with all as possible and let our relationships and community engagement be the draw card that allows others to share back their investments – but also allow others to create innovative business models off of the work that is aimed at bettering health for all.

To quote Parks and Recreation’s Ron Swanson: “End Speech”.

Carl Fourie

Senior Technical AdvisorCape Town | South Africa

tel / whatsapp: +27.71.540.4477
skype: carl.fourie17

stay connected: @DigitalSQR ** |** digitalsquare.org

The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments, is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.

From: OHIE list ohie-architecture@googlegroups.com on behalf of Jamie Thomas jt48@regenstrief.org
Date: Tuesday, 21 May 2019 at 22:01
To: OHIE list ohie-architecture@googlegroups.com
Subject: OHIE Specification Release: Creative Commons License?

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/E0030250-9506-4089-AC42-A0C5C9A6497F%40regenstrief.org.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/2AE12E8B-12D1-4BCE-8546-6C5BB2A5672F%40path.org.
For more options, visit https://groups.google.com/d/optout.

–

Craig Appl

Health Technical Lead

–
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAEGTrw42DvcNdNf5crVn6xfVapePkwRcVr0qkQqs2x0WqRhbRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

–

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045

–
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S1wzZd9xOMJ5k_9S9kbJON2gV-YOKGck5mxEQQbVqWwWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alvin_Marcelo]

I agree with Justin on the CC-BY-SA.

···

On Thu, May 23, 2019, 12:40 AM Ron G. Parker, rgparker57@eastlink.ca wrote:

Agreed.

Ron G Parker | mail: rgparker57@eastlink.ca | mobile: +1-902-222-7716 | skype: rongparker | timezone: ADT (UTC -3)

From: ohie-architecture@googlegroups.com ohie-architecture@googlegroups.com On Behalf Of Derek Ritz
Sent: May 22, 2019 12:05
To: Craig Appl cappl@ona.io
Cc: Fourie, Carl cfourie@path.org; ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

+1 to both Carl’s and Craig’s comments. In my view, CC-BY should be our preferred option.

On Wed, May 22, 2019 at 7:33 AM Craig Appl cappl@ona.io wrote:

Hi,

I second Carl’s recommendation. I have licensed online documentation with CC-BY in previous positions for the reasons outlined by Carl.

Craig

On Wed, May 22, 2019 at 1:08 AM Fourie, Carl cfourie@path.org wrote:

Hi Jamie and thanks for raising this.

To the Arch team:

I’m not a fan of that license for our narrative works here. It basically restricts commercial use of our documentation and takes out any incentive for implementing partners to build on. I’m much more inclined for the much more permissive nature of the “by attribution” approach (https://creativecommons.org/licenses/by/4.0).

I really think of this as to what are we trying to do here. HIE’s for low resource settings are, just by pure economics and demand, limited in the total number that can be deployed and built so anything that is excluding others from working with us – especially commercial teams and other groups who are not primarily open source will be very limiting in our community and restrict the “new blood” that is able to come in.

Why I prefer the CC-BY option is that it gives options to teams that don’t have the mandate to make their solutions open source to leverage our work as source and cite the original source. We do run the risk of some group taking what we have done and then commercializing it and selling it to others, but this should drive us to excel more! If a country can pay a few $$ for a much better version of our specification document that what we offer / or a local firm has chosen to contextualise our specifications for their use-case / environment then we should support that and it should drive us to adapt.

We want to see our investments used (appropriately) and I think it is more the relationships that build the share alike mentality than the license so I would say let be as open to play with all as possible and let our relationships and community engagement be the draw card that allows others to share back their investments – but also allow others to create innovative business models off of the work that is aimed at bettering health for all.

To quote Parks and Recreation’s Ron Swanson: “End Speech”.

Carl Fourie

Senior Technical AdvisorCape Town | South Africa

tel / whatsapp: +27.71.540.4477
skype: carl.fourie17

stay connected: @DigitalSQR ** |** digitalsquare.org

The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments, is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.

From: OHIE list ohie-architecture@googlegroups.com on behalf of Jamie Thomas jt48@regenstrief.org
Date: Tuesday, 21 May 2019 at 22:01
To: OHIE list ohie-architecture@googlegroups.com
Subject: OHIE Specification Release: Creative Commons License?

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/E0030250-9506-4089-AC42-A0C5C9A6497F%40regenstrief.org.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/2AE12E8B-12D1-4BCE-8546-6C5BB2A5672F%40path.org.
For more options, visit https://groups.google.com/d/optout.

–

Craig Appl

Health Technical Lead

–
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAEGTrw42DvcNdNf5crVn6xfVapePkwRcVr0qkQqs2x0WqRhbRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

–

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045

–
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S1wzZd9xOMJ5k_9S9kbJON2gV-YOKGck5mxEQQbVqWwWg%40mail.gmail.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/000801d510bd%2414b901f0%243e2b05d0%24%40eastlink.ca.

For more options, visit https://groups.google.com/d/optout.

[eric]

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn
Chief Technology Officer
Alexandria Consulting LLC
St. Petersburg, Florida
727.537.9474
alexandriaconsulting.com

···

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license
https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

[Ron_G_Parker]

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

···

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn
Chief Technology Officer
Alexandria Consulting LLC
St. Petersburg, Florida
727.537.9474
alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license
https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

–

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[carl]

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

···

1. A reality check on “yes this could happen” or “no not a real world scenario”

2. Check how the -SA attribute impacts the outcome of the scenarios

3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477
skype: carl.fourie17

stay connected:@DigitalSQR**
|** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
For more options, visit
https://groups.google.com/d/optout.

[dritz]

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

···

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

For more options, visit https://groups.google.com/d/optout.

[bobj]

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed. The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

···

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[eric]

You know, thinking about it from a specification perspective, I want to also reverse my position on -SA. It would be problematic for reasons Carl mentioned. Even CC-BY could be problematic in scenarios, where a government or corporation wants to use something, and keep that use confidential. As was mentioned already, there are other ways to enforce compliance and cohesion than the license. The Homeless Management Information System (the other HMIS) API specs we publish as CC-Unlicense for this very reason. We want others to freely use the specs in any way they see fit. That doesn’t mean we have to adopt the other uses as “official”. Now, our code implementing these specs is copyleft Mozilla Public License v2, because we don’t want people to profit from it without sharing back improvements. But for the API specs, we don’t restrict what they do with it. -Eric

···

On Thu, May 23, 2019 at 8:47 AM Bob Jolliffe bobjolliffe@gmail.com wrote:

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed. The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[dritz]

I see no downside to CC-BY. Where our specs are being referenced, it makes sense (to me) that we be credited as the underlying source. Sorry, Eric, if I’m missing something in your description - but even a confidential spec could (and should, in my view) reference its sources. Do I misunderstand?

Thanks and warmest regards,

Derek

+1(905)515-0045

···

Sent from my mobile phone

On Thu, May 23, 2019, 11:41 AM Eric Jahn eric@alexandriaconsulting.com wrote:

You know, thinking about it from a specification perspective, I want to also reverse my position on -SA. It would be problematic for reasons Carl mentioned. Even CC-BY could be problematic in scenarios, where a government or corporation wants to use something, and keep that use confidential. As was mentioned already, there are other ways to enforce compliance and cohesion than the license. The Homeless Management Information System (the other HMIS) API specs we publish as CC-Unlicense for this very reason. We want others to freely use the specs in any way they see fit. That doesn’t mean we have to adopt the other uses as “official”. Now, our code implementing these specs is copyleft Mozilla Public License v2, because we don’t want people to profit from it without sharing back improvements. But for the API specs, we don’t restrict what they do with it. -Eric

On Thu, May 23, 2019 at 8:47 AM Bob Jolliffe bobjolliffe@gmail.com wrote:

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed. The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[eric]

Derek, I think I need to defer to an IP lawyer on that one. Not sure. It would seem to me attribution in a sealed context is not attribution at all, but I’m not a lawyer

···

On Thu, May 23, 2019 at 12:12 PM Derek Ritz derek.ritz@ecgroupinc.com wrote:

I see no downside to CC-BY. Where our specs are being referenced, it makes sense (to me) that we be credited as the underlying source. Sorry, Eric, if I’m missing something in your description - but even a confidential spec could (and should, in my view) reference its sources. Do I misunderstand?

Thanks and warmest regards,

Derek

Sent from my mobile phone
+1(905)515-0045

On Thu, May 23, 2019, 11:41 AM Eric Jahn eric@alexandriaconsulting.com wrote:

You know, thinking about it from a specification perspective, I want to also reverse my position on -SA. It would be problematic for reasons Carl mentioned. Even CC-BY could be problematic in scenarios, where a government or corporation wants to use something, and keep that use confidential. As was mentioned already, there are other ways to enforce compliance and cohesion than the license. The Homeless Management Information System (the other HMIS) API specs we publish as CC-Unlicense for this very reason. We want others to freely use the specs in any way they see fit. That doesn’t mean we have to adopt the other uses as “official”. Now, our code implementing these specs is copyleft Mozilla Public License v2, because we don’t want people to profit from it without sharing back improvements. But for the API specs, we don’t restrict what they do with it. -Eric

On Thu, May 23, 2019 at 8:47 AM Bob Jolliffe bobjolliffe@gmail.com wrote:

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed. The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[eric]

[thinking out loud, still not a lawyer since last email] I know I’ve read app license descriptions (like form Google) where they acknowledge use of an open source software library, but the Google code itself is closed source, and not thereby available, but of course the attribution is public. But what if an organization didn’t even want to publish that they used it, or acknowledge that the code exists? Maybe that’s something we wouldn’t accept?

···

On Thu, May 23, 2019 at 12:16 PM Eric Jahn eric@alexandriaconsulting.com wrote:

Derek, I think I need to defer to an IP lawyer on that one. Not sure. It would seem to me attribution in a sealed context is not attribution at all, but I’m not a lawyer

On Thu, May 23, 2019 at 12:12 PM Derek Ritz derek.ritz@ecgroupinc.com wrote:

I see no downside to CC-BY. Where our specs are being referenced, it makes sense (to me) that we be credited as the underlying source. Sorry, Eric, if I’m missing something in your description - but even a confidential spec could (and should, in my view) reference its sources. Do I misunderstand?

Thanks and warmest regards,

Derek

Sent from my mobile phone
+1(905)515-0045

On Thu, May 23, 2019, 11:41 AM Eric Jahn eric@alexandriaconsulting.com wrote:

You know, thinking about it from a specification perspective, I want to also reverse my position on -SA. It would be problematic for reasons Carl mentioned. Even CC-BY could be problematic in scenarios, where a government or corporation wants to use something, and keep that use confidential. As was mentioned already, there are other ways to enforce compliance and cohesion than the license. The Homeless Management Information System (the other HMIS) API specs we publish as CC-Unlicense for this very reason. We want others to freely use the specs in any way they see fit. That doesn’t mean we have to adopt the other uses as “official”. Now, our code implementing these specs is copyleft Mozilla Public License v2, because we don’t want people to profit from it without sharing back improvements. But for the API specs, we don’t restrict what they do with it. -Eric

On Thu, May 23, 2019 at 8:47 AM Bob Jolliffe bobjolliffe@gmail.com wrote:

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed. The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[dritz]

Eric, I’m also not an IP lawyer but (sadly) have a lot of prior (expensive!) experience in this area. Nothing about CC-BY prevents a party from citing our work product in, for example, a confidential procurement specification. It would mean they could not (legally) pass it off as their own… but I kinda like that aspect of it.

Warmest regards,

Derek

+1(905)515-0045

···

Sent from my mobile phone

On Thu, May 23, 2019, 12:17 PM Eric Jahn eric@alexandriaconsulting.com wrote:

Derek, I think I need to defer to an IP lawyer on that one. Not sure. It would seem to me attribution in a sealed context is not attribution at all, but I’m not a lawyer

On Thu, May 23, 2019 at 12:12 PM Derek Ritz derek.ritz@ecgroupinc.com wrote:

I see no downside to CC-BY. Where our specs are being referenced, it makes sense (to me) that we be credited as the underlying source. Sorry, Eric, if I’m missing something in your description - but even a confidential spec could (and should, in my view) reference its sources. Do I misunderstand?

Thanks and warmest regards,

Derek

Sent from my mobile phone
+1(905)515-0045

On Thu, May 23, 2019, 11:41 AM Eric Jahn eric@alexandriaconsulting.com wrote:

You know, thinking about it from a specification perspective, I want to also reverse my position on -SA. It would be problematic for reasons Carl mentioned. Even CC-BY could be problematic in scenarios, where a government or corporation wants to use something, and keep that use confidential. As was mentioned already, there are other ways to enforce compliance and cohesion than the license. The Homeless Management Information System (the other HMIS) API specs we publish as CC-Unlicense for this very reason. We want others to freely use the specs in any way they see fit. That doesn’t mean we have to adopt the other uses as “official”. Now, our code implementing these specs is copyleft Mozilla Public License v2, because we don’t want people to profit from it without sharing back improvements. But for the API specs, we don’t restrict what they do with it. -Eric

On Thu, May 23, 2019 at 8:47 AM Bob Jolliffe bobjolliffe@gmail.com wrote:

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed. The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[jthomas]

Hi All,

Thank you all for participating in this discussion! Your consideration of all the different scenarios and circumstances behind a license for the OHIE specification releases was extremely beneficial, appreciate your time on this. If I am
hearing correctly it seems we have a consensus that the
CC-BY 4.0 license is the way to go, which aligns with the creative commons licensing we have on the OpenHIE wiki and website. Glad to see we are still aligned here

···

**Jamie Thomas **|****Community Manager

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

From: “ohie-architecture@googlegroups.com” ohie-architecture@googlegroups.com on behalf of Derek Ritz derek.ritz@ecgroupinc.com
Date: Thursday, May 23, 2019 at 12:24 PM
To: Eric Jahn eric@alexandriaconsulting.com
Cc: “bobjolliffe@gmail.com” bobjolliffe@gmail.com, “Fourie, Carl” cfourie@path.org, Ron Parker rgparker57@eastlink.ca, “ohie-architecture@googlegroups.com” ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

Eric, I’m also not an IP lawyer but (sadly) have a lot of prior (expensive!) experience in this area.
Nothing about CC-BY prevents a party from citing our work product in, for example, a confidential procurement specification. It would mean they could not (legally) pass it off as their own… but I kinda
like that aspect of it.

Warmest regards,

Derek

Sent from my mobile phone
+1(905)515-0045

On Thu, May 23, 2019, 12:17 PM Eric Jahn eric@alexandriaconsulting.com wrote:

Derek, I think I need to defer to an IP lawyer on that one. Not sure. It would seem to me attribution in a sealed context is not attribution at all, but I’m not a lawyer

On Thu, May 23, 2019 at 12:12 PM Derek Ritz derek.ritz@ecgroupinc.com wrote:

I see no downside to CC-BY. Where our specs are being referenced, it makes sense (to me) that we be credited as the underlying source. Sorry, Eric, if I’m missing something in your description - but even a confidential spec could (and should,
in my view) reference its sources. Do I misunderstand?

Thanks and warmest regards,

Derek

Sent from my mobile phone
+1(905)515-0045

On Thu, May 23, 2019, 11:41 AM Eric Jahn eric@alexandriaconsulting.com wrote:

You know, thinking about it from a specification perspective, I want to also reverse my position on -SA. It would be problematic for reasons Carl mentioned. Even CC-BY could be problematic in scenarios, where a government or corporation
wants to use something, and keep that use confidential. As was mentioned already, there are other ways to enforce compliance and cohesion than the license. The Homeless Management Information System (the other HMIS) API specs we
publish as CC-Unlicense for this very reason. We want others to freely use the specs in any way they see fit. That doesn’t mean we have to adopt the other uses as “official”. Now, our code implementing
these specs is copyleft Mozilla Public License v2, because we don’t want people to profit from it without sharing back improvements. But for the API specs, we don’t restrict what they do with it. -Eric

On Thu, May 23, 2019 at 8:47 AM Bob Jolliffe bobjolliffe@gmail.com wrote:

I agree with all that forcing a share-alike is unreasonable.

Also that the most important aspect of attribution is not so much that credit is given to the original authors (that of course is polite good behaviour which should be encouraged), but rather that derivative works are clearly not endorsed.
The only real hazard we face is that the material is adapted incorrectly (perhaps a faulty translation) and we are somehow seen as responsible for errors in the derived work. To make thins simple, we could suggest some helpful text for downstream authors
along the lines of:

“This document is derived from/contains text from original work (link) from the OpenHIE project. The OpenHIE project are not responsible for any errors in the derived document.”

Beyond that suggestion for good behaviour, I am even quite happy with public domain, but CC-BY is the most appropriate CC licence if we are to go that route.

Cheers

Bob

On Thu, 23 May 2019 at 12:40, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Carl - thank you for pointing out these scenarios and the very real challenges they represent. The requirement to share alike is not as business-friendly as is the simple CC-BY. It also isn’t necessary, in my view. Our OpenHIE mission does
not include IP protection or value capture…we succeed more when our IP is more broadly taken up. CC-BY gives us credit for our contributions, and I don’t believe our mission calls for more than that.

Warmest regards,

Derek

On Thu, May 23, 2019, 2:46 AM Fourie, Carl cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”

1. Check how the -SA attribute impacts the outcome of the scenarios

1. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

***Scenario 1:***Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

·
Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived
work need only cite the fact that it is built off of the OHIE Spec as a base. For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification
or there is limited mandate for government specification documents to remain private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the
MOH how is this handled. Will the -SA flag allow the document to be handed over to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done
in the past or how we could provide guidance to teams and educate members (maybe it’s just me
) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve
a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels
a bit like “you must share – it’s the rules” vs “hey why don’t we work together on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking
to that this morning. But interested to hear what others think and how we address the scenarios above.

Cheers

Error! Filename not specified.

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

Error! Filename not specified.
stay connected:****Error! Filename not specified.@DigitalSQR**
|** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged, confidential, or exempt from disclosure
  under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments, is strictly prohibited. If you
  have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

**From:**OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information
and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit
you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information
is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/CAOe53S0FSdwnO9e9V9VLz350EDax0z5Mi1DvtqBRNMMY-B_Ovg%40mail.gmail.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/CAOe53S2JjwuB-dS64cPOC2jcgrPOvXqJg6XtqJ4uf4k5KHShFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alvin_Marcelo]

I am very interested in the answers/thoughts behind Carl’s scenarios.

As you’ll see in the DS OAP, we plan to create a policy and artifact generator for Digital health infrastructure in support of UHC. While I am unsure whether it will actually get funding, I found the OAP as a good platform for discussion and getting comments.

The idea of the policy generator is ask the MOH a series of questions after which the necessary policies and architectural artifacts are generated. As such, copyright becomes a very important facet of that project.

While we will be attributing the source artifacts, the generated derivative, now customized for the MOH, will then be a hybrid (a mix of MOH and other entity snippets). If there is proper attribution, can we just claim fair use for the inclusion of artifacts from OpenHIE? From DHIS2? And all other global goods for that matter…

Alvin

···

On Thu, May 23, 2019, 2:46 PM Fourie, Carl, cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

For more options, visit https://groups.google.com/d/optout.

[Leonard_Njeru_Njiru]

It is also extremely important to respect intellectual property rights of the institutions and individuals from where some artifacts are generated from.

This is especially so for the purportedly “financially constrained environments”. Financial constraints do not necessarily imply intellectual constraints.

More so for attributions, it’s intellectual dishonesty to insert names in source documents indiscriminately.

···

On Fri, May 31, 2019, 2:23 AM ‘Alvin Marcelo’ via OpenHIE Architecture ohie-architecture@googlegroups.com wrote:

I am very interested in the answers/thoughts behind Carl’s scenarios.

As you’ll see in the DS OAP, we plan to create a policy and artifact generator for Digital health infrastructure in support of UHC. While I am unsure whether it will actually get funding, I found the OAP as a good platform for discussion and getting comments.

The idea of the policy generator is ask the MOH a series of questions after which the necessary policies and architectural artifacts are generated. As such, copyright becomes a very important facet of that project.

While we will be attributing the source artifacts, the generated derivative, now customized for the MOH, will then be a hybrid (a mix of MOH and other entity snippets). If there is proper attribution, can we just claim fair use for the inclusion of artifacts from OpenHIE? From DHIS2? And all other global goods for that matter…

Alvin

On Thu, May 23, 2019, 2:46 PM Fourie, Carl, cfourie@path.org wrote:

Morning all

Thinking this through I wanted to run a few scenarios past the team to:

1. A reality check on “yes this could happen” or “no not a real world scenario”
2. Check how the -SA attribute impacts the outcome of the scenarios
3. Check my thinking and understanding

Basically – I have a way that I see the license impacting derivatives and wanted to get a consensus if we all see it the same way.

Scenario 1: Ministry of health runs a tender for the procurement / development of an HIE and includes the OpenHIE Specifications document as a reference to the tender.

• Alternative: OpenHIE specification has been slightly altered to include additional specifications for links to Finance systems and Payroll.

So my question is how is the “slightly altered” specification managed under the license? I see it as a derived work (?correct?). So under the CC-BA the derived work need only cite the fact that it is built off of the OHIE Spec as a base.
For the CC-BA-SA does this require the ministry to now publish this new document as an open document for all to access? What if there is confidential information in the specification or there is limited mandate for government specification documents to remain
private? Is it possible for the MoH to “not share the document” or create a version that they keep without sharing it?

If it is just in the tender as a “reference doc” then it is like citing a book and the tender doesn’t need to be opened and shared under the -SA option correct?

Scenario 2: Implementing partner develops and hands over an HIE for a particular solution to an MOH

If the implementing partner based the architectural spec of their HIE on the OpenHIE Spec and their contract with the MOH requires that all IP is ceded to the MOH how is this handled. Will the -SA flag allow the document to be handed over
to the MoH without them needing to share it (under what conditions is that possible?) or will this force the implementer to share the document?

I have a few more scenarios that look at but I think getting answers on the above would help me frame the rest of them in my head.

My basic concern is how do we manage a “forced share” clause in our documentation and design specs. I’d love to hear from others of how they have seen this done in the past or how we could provide guidance to teams and educate members (maybe
it’s just me ) on how a CC-BY-SA will play out in the above.

My prerequisite for any license that we put on our documents is that it enable countries to be in a better position to leverage our work and enable them to achieve a better outcome; that OpenHIE is recognised for its input.

I think relationships are a stronger way to manage a sharing and collaborative approach and I’m not sure if a license is the best way facilitate sharing. It feels a bit like “you must share – it’s the rules” vs “hey why don’t we work together
on this and get something better” (stick vs carrot). I am aware of the challenge of “stripping assets” from a global collective community and I don’t have a good way of talking to that this morning. But interested to hear what others think and how we address
the scenarios above.

Cheers

Carl Fourie

Senior Technical Advisor Cape Town | South Africa

tel / whatsapp: +27.71.540.4477

skype: carl.fourie17

stay connected:@DigitalSQR**

** digitalsquare.org

• The information in this message, including any attachments, is intended only for the designated recipient(s), and may be privileged,
  confidential, or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, alteration, dissemination, retention, distribution, or use in any way of this message, its contents, and any attachments,
  is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete this message.*

From: OHIE list ohie-architecture@googlegroups.com on behalf of Ron G Parker rgparker57@eastlink.ca
Date: Thursday, 23 May 2019 at 03:00
To: Eric Jahn eric@alexandriaconsulting.com
Cc: OHIE list ohie-architecture@googlegroups.com
Subject: Re: OHIE Specification Release: Creative Commons License?

The -SA seems very good, will encourage innovation while at the same time recognizing community contribution.

Ron G. Parker, Parker Digital Health Consulting, Halifax, NS +1-902-222-7716

On May 22, 2019, at 21:48, Eric Jahn eric@alexandriaconsulting.com wrote:

I agree with Justin and Alvin’s CC-BY-SA recommendation, preserving the BY-SA in derivative works.

Eric Jahn

Chief Technology Officer

Alexandria Consulting LLC

St. Petersburg, Florida

727.537.9474

alexandriaconsulting.com

On Tuesday, May 21, 2019 at 4:01:15 PM UTC-4, Jamie Thomas wrote:

Hi All,

At our last OHIE Architecture call we touched on the idea of a Creative Commons License for the OHIE Specification Release. Here is a link to the different license

https://creativecommons.org/licenses/.

I’d like to hear what people think about “Attribution-NonCommercial-ShareAlike”?

Jamie Thomas |* Community
Manager*

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org |
Skype: jamie.thomas5670 | Twitter: @Regenstrief

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any
retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

–
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/ebfc80a1-6ad5-40e2-8199-40fc3c0f2be2%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-architecture/3A57A4C5-6B61-4341-BD69-D68A3EA51C39%40eastlink.ca.
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/A9046750-6EAF-4F81-B351-70609FE58D3B%40path.org.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-architecture/CAHL8W3xJupyLXVE0kPTaT5WYB1zAZ%3DhkmKko_y9eAi84zApnRw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.