Abridged summary of ohie-architecture@googlegroups.com - 3 Messages in 1 Topic

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

···

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

···

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

···

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

···

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Good discussion. So, from what has been said do we actually want to support multiple standards in the long run? This would allow an implementing country to make the decision on what they would like to implement and we don’t ‘push’ particular standards onto them.

Obviously, we would have to choose something to start with and then build additional support as need be. From what it sounds like here we should probably start with standards in an ecosystem where we are welcome to participate. I know IHE does allow us to easily participate, I’m not so sure about the HL7 process though.

Another problem I see when thinking of choosing between the IHE ecosystem and the HL7 ecosystem is their fundamentally different approach. IHE produces profile for specific use cases and for sharing specific data. HL7 on the other hand produces more general standards that allow you to represent the data that the user needs to for a particular use case. From what I’ve seen of IHE CDA profiles they collect very specific data that often didn’t map to data that we were collecting (for example in Rwanda). I’m not sure what the solution to this would be. Would we have to profile our own CDA in this case? For HL7 they provide the generic structures to transmit the data that a user needs, but the user has to define what that data would be. Are these concerns true or are their other ways around this? I’d like to hear from those that have a more in depth understanding of these standards.

Cheers,

Ryan

···

On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Are we talking about supporting multiple standards between our nodes, or with edge applications?

The second seems like an easier goal. We’d have to at least have a default for internal communication so we know what happens when we deploy a vanilla OpenHIE.

Chris
(via Android)

···

On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Thanks Chris, good distinction. I’d agree it would be easier to have a known internal format between our nodes.

Paul and Derek, what do you think about this? When we say we don’t want to push standards choices onto countries do we mean at the edge applications, between our nodes or both? I’d imagine that we mean is we should not impose upon edge application and what is used in for internal communication is not of consequence. Is this a correct assumption?

Cheers,

Ryan

···

On Thu, Aug 8, 2013 at 10:00 AM, Chris Ford christophertford@gmail.com wrote:

Are we talking about supporting multiple standards between our nodes, or with edge applications?

The second seems like an easier goal. We’d have to at least have a default for internal communication so we know what happens when we deploy a vanilla OpenHIE.

Chris
(via Android)

On Aug 8, 2013 10:50 AM, “Ryan Crichton” ryan@jembi.org wrote:

Good discussion. So, from what has been said do we actually want to support multiple standards in the long run? This would allow an implementing country to make the decision on what they would like to implement and we don’t ‘push’ particular standards onto them.

Obviously, we would have to choose something to start with and then build additional support as need be. From what it sounds like here we should probably start with standards in an ecosystem where we are welcome to participate. I know IHE does allow us to easily participate, I’m not so sure about the HL7 process though.

Another problem I see when thinking of choosing between the IHE ecosystem and the HL7 ecosystem is their fundamentally different approach. IHE produces profile for specific use cases and for sharing specific data. HL7 on the other hand produces more general standards that allow you to represent the data that the user needs to for a particular use case. From what I’ve seen of IHE CDA profiles they collect very specific data that often didn’t map to data that we were collecting (for example in Rwanda). I’m not sure what the solution to this would be. Would we have to profile our own CDA in this case? For HL7 they provide the generic structures to transmit the data that a user needs, but the user has to define what that data would be. Are these concerns true or are their other ways around this? I’d like to hear from those that have a more in depth understanding of these standards.

Cheers,

Ryan

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Hi Ryan,

No, I don’t think I’m saying that.

Again, standards development organizations come with all different sorts of approaches to this.

We are leaning pretty heavily towards IHE now, because they allow for various base standards to be “composed together”, and there seems to be a pretty healthy level of interest amongst their leadership to allow us to evolve existing standards to meet our demonstrated real world needs. Of course, that needs to be tested and we all need to be comfortable with that.

Remember, the HL7 organization produces base standards, that can be wholly used and specified within IHE profiles. Profiles simply further how base standards are used for a specific use case (like sending a antenatal visit, etc).

I think we need to have our inaugural “architecture committee” phone call here soon, as there seems to be some misunderstandings amongst folks about how some of these organizations work. This could be the first topic.

-Paul

···

On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the
distinction between data, message and interface standards. LOINC and SNOMED CT
are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards
and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically,
message standards describe buckets (or structures of buckets) and data
standards describe what goes into the buckets. Interface standards describe how
the messages can be exchanged between actors, but this distinction often gets
fuzzy.

The point is that just saying you want a stack of standards is
not sufficient. Especially looking at a national program, the whys of standards
are just as important as the whats. Governments that try to go too far, I’ll
suggest the UK’s NPfIT as a poster child, have not been successful. As one
example, it’s relatively easy to test conformance to data and message
standards, harder with interface standards.

Jack

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

  Hi Derek,

Do you think it needs to be as black and white as that? That we can only

use a single standards stack? I understand that for particular domains

within the exchange it makes sense to use
…more
Back to top.

“Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

  Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a

national MOH standpoint. That is why I referred to this as an “ecosystem”

choice.

  [...more](http://groups.google.com/group/ohie-architecture/msg/c55959a5047ccdf3)

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

  Different people refer to "standards" with differing meanings and levels of

granularity in their minds, so I think it might be useful to clarify things

a bit in this conversation.

  [...more](http://groups.google.com/group/ohie-architecture/msg/293932a048513843)

Back to top.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

Hi all.

The standards “ecosystem” includes more than just the governing standards (or profiling) body – it includes the health informatics communities, IT communities, vendor communities (both tools and products), etc. The choice of an eHealth standard has implications for all of these ecosystem stakeholders in a country (and vice versa!). Paul has pointed out a crucial distinction – there is a big difference between profiling existing standards for deployment in a context and writing new base standards. Our “low-resource” use cases and requirements require us to do much more of the former than the latter.

Can we accomplish what we need to accomplish using XDS/MHD, HPD, PIX/PDQ and other IHE profiles? Yes… almost entirely. But addressing the “almost” is important to us. And as Paul has also pointed out – so far, our experience with them (the IHE technical committees and leadership) has been a success, but it certainly has had its bumps, especially early on. Would we need to profile CDAs for some use cases that have not been on their committee radar so far? Absolutely. In fact, we should expect that this would likely be a national-level configuration for each country. But these CDAs are built from a collection of templates and we should make sure all the templates we need are there (and they aren’t, yet). We’ll need to know that we can get IHE’s attention and that they will support that kind of effort. These conversations are ones we’ve not yet had with them, but I hope we will soon.

Do we need to use the same standards for internal messaging as for external messaging? Architecture is the answer to that. If we expose our “above the HIM” assets, then yes. If we abstract them, then no. But that doesn’t mean we aren’t standards-based within our own datacentre, it just means we can relax some of the burdensome elements that are part of message exchange in the wild (such as authentication, authorization, firewall-routable enveloping, etc.). At Mohawk, for example, their Canadian-conformant system speaks HL7v3 to the wild, but internally in the ESB it speaks a boiled down message spec they call RIMMISH that does not include the overhead that would otherwise slow it down. We could employ a similar pattern and would do it (if we do it) for the same reason – speed.

The inaugural architecture call is one I’m looking forward to, too. In this, our year of engineering, I think we are to the point where these issues have to be answered – for us all as a community of communities. The evaluations so far have been diligent. We understand these issues well. I also know we can “win” with any one of the credible candidates we’re looking at, so it is now just a matter of picking one.

My $0.05… (we just abolished the penny in Canada… so we have to round up…)

Warmest regards,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

···

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Paul Biondich
Sent: August 8, 2013 8:38 AM
To: ohie-architecture@googlegroups.com; openhie-shr@googlegroups.com
Subject: Re: Abridged summary of ohie-architecture@googlegroups.com - 3 Messages in 1 Topic

Hi Ryan,

No, I don’t think I’m saying that.

Again, standards development organizations come with all different sorts of approaches to this.

We are leaning pretty heavily towards IHE now, because they allow for various base standards to be “composed together”, and there seems to be a pretty healthy level of interest amongst their leadership to allow us to evolve existing standards to meet our demonstrated real world needs. Of course, that needs to be tested and we all need to be comfortable with that.

Remember, the HL7 organization produces base standards, that can be wholly used and specified within IHE profiles. Profiles simply further how base standards are used for a specific use case (like sending a antenatal visit, etc).

I think we need to have our inaugural “architecture committee” phone call here soon, as there seems to be some misunderstandings amongst folks about how some of these organizations work. This could be the first topic.

-Paul

On Thu, Aug 8, 2013 at 3:50 AM, Ryan Crichton ryan@jembi.org wrote:

Good discussion. So, from what has been said do we actually want to support multiple standards in the long run? This would allow an implementing country to make the decision on what they would like to implement and we don’t ‘push’ particular standards onto them.

Obviously, we would have to choose something to start with and then build additional support as need be. From what it sounds like here we should probably start with standards in an ecosystem where we are welcome to participate. I know IHE does allow us to easily participate, I’m not so sure about the HL7 process though.

Another problem I see when thinking of choosing between the IHE ecosystem and the HL7 ecosystem is their fundamentally different approach. IHE produces profile for specific use cases and for sharing specific data. HL7 on the other hand produces more general standards that allow you to represent the data that the user needs to for a particular use case. From what I’ve seen of IHE CDA profiles they collect very specific data that often didn’t map to data that we were collecting (for example in Rwanda). I’m not sure what the solution to this would be. Would we have to profile our own CDA in this case? For HL7 they provide the generic structures to transmit the data that a user needs, but the user has to define what that data would be. Are these concerns true or are their other ways around this? I’d like to hear from those that have a more in depth understanding of these standards.

Cheers,

Ryan

On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the distinction between data, message and interface standards. LOINC and SNOMED CT are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically, message standards describe buckets (or structures of buckets) and data standards describe what goes into the buckets. Interface standards describe how the messages can be exchanged between actors, but this distinction often gets fuzzy.

The point is that just saying you want a stack of standards is not sufficient. Especially looking at a national program, the whys of standards are just as important as the whats. Governments that try to go too far, I’ll suggest the UK’s NPfIT as a poster child, have not been successful. As one example, it’s relatively easy to test conformance to data and message standards, harder with interface standards.

Jack

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

Today’s Topic Summary

Group: http://groups.google.com/group/ohie-architecture/topics

§ Standard for the SHR [3 Updates]

Standard for the SHR

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

Hi Derek,

Do you think it needs to be as black and white as that? That we can only
use a single standards stack? I understand that for particular domains
within the exchange it makes sense to use …more

Back to top.

"Derek Ritz (ecGroup)" derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a
national MOH standpoint. That is why I referred to this as an “ecosystem”
choice.

…more

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

Different people refer to “standards” with differing meanings and levels of
granularity in their minds, so I think it might be useful to clarify things
a bit in this conversation.
…more

Back to top.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi

···

Some brief thoughts on Derek’s post

On 8 August 2013 14:15, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

The standards “ecosystem” includes more than just the governing standards (or profiling) body – it includes the health informatics communities, IT communities, vendor communities (both tools and products), etc. The choice of an eHealth standard has implications for all of these ecosystem stakeholders in a country (and vice versa!). Paul has pointed out a crucial distinction – there is a big difference between profiling existing standards for deployment in a context and writing new base standards. Our “low-resource” use cases and requirements require us to do much more of the former than the latter.

I am not sure this is always true. There is more to a low-resource setting than the lowness of its resources. There is a relationship between quantity and quality whereby at a certain point quantitative change is transformed to qualitative (following Paul down the trail of dialectics …)… So the “lowness” of resources doesn’t just imply lesser participation in otherwise expensive processes, or more restricted or more simplified use of the same “universal” base standards. Often times it actually implies the need for qualitatively different forms.

A good example is human address standards. There are assumptions about address that are commonplace in Europe and North America and even find themselves embedded in other vertical domain standards which simply don’t apply very well to, for example, the billions of the world’s urban informal settlers. There is great work that was being done by human geographers in South Africa and Brazil around address standards. Its a while since I was involved with that effort but I am sure it is ongoing within ISO. But the point is that it is precisely because of the low resource setting that qualitatively different forms can become necessary to address different challenges. Not simply more or less of the same.

Can we accomplish what we need to accomplish using XDS/MHD, HPD, PIX/PDQ and other IHE profiles? Yes… almost entirely.

Derek I am not as confident as you are about this. Partly because I have nothing like the confidence in knowing what it is we need to accomplish.

As you and some others know, I have grave misgivings about the centrality of the individual health record as the immediate challenge facing ministries of health around the world. And there is a driving logic behind the likes of PIX/PDQ and XDS/MHD which raise these as the challenges of central importance. I see the immediate solvable, but generally unsolved, challenges hinge around things like not having a clue where my doctors and nurses are deployed, cold chain management, where my health facilities are, what their catchment areas are, what the burden of disease looks like in those catchments etc. But its an old argument and I would certainly concede that our approaches are not mutually exclusive. My point is just that I don’t see the above bag of letters accomplishing what I think we need to accomplish at all. Not even close.

And sadly I don’t see many standards which are directed at what does need to be accomplished. SDMX-HD for the exchange of aggregate data is an example of an effort by WHO which has since been steam-rollered by the new wave of HL7 and friends dominating the standards discourse in WHO.

Anyway, forgive me, I’m venting on declining nicotine levels in my body. It is a good starting point to look at what needs to be accomplished. The fact that we don’t always agree on that doesn’t change the fact that it is the right place to start.

Bob

PS. Sometimes it seems to me that what we need more is not so much standards (or things pretending to be standards), but rather something more like patterns and pattern languages for the domain in our various contexts. Some of which might well even end up being standardised. I should throw that challenge out to Ed … what about starting to compile PLOP-Health?

But addressing the “almost” is important to us. And as Paul has also pointed out – so far, our experience with them (the IHE technical committees and leadership) has been a success, but it certainly has had its bumps, especially early on. Would we need to profile CDAs for some use cases that have not been on their committee radar so far? Absolutely. In fact, we should expect that this would likely be a national-level configuration for each country. But these CDAs are built from a collection of templates and we should make sure all the templates we need are there (and they aren’t, yet). We’ll need to know that we can get IHE’s attention and that they will support that kind of effort. These conversations are ones we’ve not yet had with them, but I hope we will soon.

Do we need to use the same standards for internal messaging as for external messaging? Architecture is the answer to that. If we expose our “above the HIM” assets, then yes. If we abstract them, then no. But that doesn’t mean we aren’t standards-based within our own datacentre, it just means we can relax some of the burdensome elements that are part of message exchange in the wild (such as authentication, authorization, firewall-routable enveloping, etc.). At Mohawk, for example, their Canadian-conformant system speaks HL7v3 to the wild, but internally in the ESB it speaks a boiled down message spec they call RIMMISH that does not include the overhead that would otherwise slow it down. We could employ a similar pattern and would do it (if we do it) for the same reason – speed.

The inaugural architecture call is one I’m looking forward to, too. In this, our year of engineering, I think we are to the point where these issues have to be answered – for us all as a community of communities. The evaluations so far have been diligent. We understand these issues well. I also know we can “win” with any one of the credible candidates we’re looking at, so it is now just a matter of picking one.

My $0.05… (we just abolished the penny in Canada… so we have to round up…)

Warmest regards,

Derek.


Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Paul Biondich
Sent: August 8, 2013 8:38 AM
To: ohie-architecture@googlegroups.com; openhie-shr@googlegroups.com
Subject: Re: Abridged summary of ohie-architecture@googlegroups.com - 3 Messages in 1 Topic

Hi Ryan,

No, I don’t think I’m saying that.

Again, standards development organizations come with all different sorts of approaches to this.

We are leaning pretty heavily towards IHE now, because they allow for various base standards to be “composed together”, and there seems to be a pretty healthy level of interest amongst their leadership to allow us to evolve existing standards to meet our demonstrated real world needs. Of course, that needs to be tested and we all need to be comfortable with that.

Remember, the HL7 organization produces base standards, that can be wholly used and specified within IHE profiles. Profiles simply further how base standards are used for a specific use case (like sending a antenatal visit, etc).

I think we need to have our inaugural “architecture committee” phone call here soon, as there seems to be some misunderstandings amongst folks about how some of these organizations work. This could be the first topic.

-Paul

On Thu, Aug 8, 2013 at 3:50 AM, Ryan Crichton ryan@jembi.org wrote:

Good discussion. So, from what has been said do we actually want to support multiple standards in the long run? This would allow an implementing country to make the decision on what they would like to implement and we don’t ‘push’ particular standards onto them.

Obviously, we would have to choose something to start with and then build additional support as need be. From what it sounds like here we should probably start with standards in an ecosystem where we are welcome to participate. I know IHE does allow us to easily participate, I’m not so sure about the HL7 process though.

Another problem I see when thinking of choosing between the IHE ecosystem and the HL7 ecosystem is their fundamentally different approach. IHE produces profile for specific use cases and for sharing specific data. HL7 on the other hand produces more general standards that allow you to represent the data that the user needs to for a particular use case. From what I’ve seen of IHE CDA profiles they collect very specific data that often didn’t map to data that we were collecting (for example in Rwanda). I’m not sure what the solution to this would be. Would we have to profile our own CDA in this case? For HL7 they provide the generic structures to transmit the data that a user needs, but the user has to define what that data would be. Are these concerns true or are their other ways around this? I’d like to hear from those that have a more in depth understanding of these standards.

Cheers,

Ryan

On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:

Man, Bob… very, very, very well said.

I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. :slight_smile:

I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.

This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together? :slight_smile:

-Paul

On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Paul, I am impressed with your command of the marxist dialectic between form and function :slight_smile:

I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:

(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or

(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.

I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.

Bob

On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:

Totally agreed here, Jack… it’s been my instincts and experience as well.

I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.

On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.

Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.

These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.

Does everyone that’s pitched into this thread agree with that?

-Paul

On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:

Another spin on the “dimensions” of this discussion is the distinction between data, message and interface standards. LOINC and SNOMED CT are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards and CTS2 is an interface standard. [Your definitions may vary :wink: ]. Simplistically, message standards describe buckets (or structures of buckets) and data standards describe what goes into the buckets. Interface standards describe how the messages can be exchanged between actors, but this distinction often gets fuzzy.

The point is that just saying you want a stack of standards is not sufficient. Especially looking at a national program, the whys of standards are just as important as the whats. Governments that try to go too far, I’ll suggest the UK’s NPfIT as a poster child, have not been successful. As one example, it’s relatively easy to test conformance to data and message standards, harder with interface standards.

Jack

On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:

** Today’s Topic Summary**

Group: http://groups.google.com/group/ohie-architecture/topics

§ Standard for the SHR [3 Updates]

Standard for the SHR

Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200

Hi Derek,

Do you think it needs to be as black and white as that? That we can only
use a single standards stack? I understand that for particular domains
within the exchange it makes sense to use …more

Back to top.

"Derek Ritz (ecGroup)" derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400

Hi Ryan (and all).

I think it is a matter of perspective. I’m looking at this issue from a
national MOH standpoint. That is why I referred to this as an “ecosystem”
choice.

…more

Back to top.

Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400

Different people refer to “standards” with differing meanings and levels of
granularity in their minds, so I think it might be useful to clarify things
a bit in this conversation.
…more

Back to top.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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