OpenHIE IHE profiles for coordinated communication

ryan · October 23, 2013, 8:39am

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

OpenHIE Interoperability standards.png

···

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

Carl_Leitner · October 23, 2013, 11:50am

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

···

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

ryan · October 28, 2013, 7:26am

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

···

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

Hannes_Venter · October 28, 2013, 10:51am

Hi,

Just to mention for everyone not involved in RHEA that we are currently storing the administrative units for Rwanda in the TS:

http://ts.jembi.org/browse.php?namespaceId=32808

and it does seem like a good place for it.

Although the export to the provider registry was just plain csv.

If we do use the TS, then I don’t think it would preclude us from using SVS.

SVS would be the “how” rather than the “where”, at least from my understanding.

Although any standards we do decide to use for the TS (CTS2?) could be provide the necessary functionality as well in this case.

Cheers

Hannes

···

On 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

Carl_Leitner1 · October 28, 2013, 11:55am

Dear Hannes,

Sorry for my ignorance, but does the FR in Rwanda pull from the TS? Are there other IHE profiles besides SVS for a TS? Am I right in understanding that CTS2 is coming from HL7?

Cheers

-carl

···

On 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

ryan · October 28, 2013, 1:00pm

Hi Carl,

Just to add my 0.02c, I don’t think any registry is automatically pulling the admin units from the TS in Rwanda. I haven’t been able to find any terminology profiles under IHE that we could use other than the SVS as you mentioned. CTS seems to be the defacto standards for communicating with terminology servers and, yes, it is an HL7 standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=10.

Cheers,

Ryan

···

On Mon, Oct 28, 2013 at 1:55 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Hannes,
Sorry for my ignorance, but does the FR in Rwanda pull from the TS? Are there other IHE profiles besides SVS for a TS? Am I right in understanding that CTS2 is coming from HL7?

Cheers

-carl

On Oct 28, 2013, at 6:51 AM, Hannes Venter hannes@jembi.org wrote:

Hi,

Just to mention for everyone not involved in RHEA that we are currently storing the administrative units for Rwanda in the TS:

http://ts.jembi.org/browse.php?namespaceId=32808

and it does seem like a good place for it.

Although the export to the provider registry was just plain csv.

If we do use the TS, then I don’t think it would preclude us from using SVS.

SVS would be the “how” rather than the “where”, at least from my understanding.

Although any standards we do decide to use for the TS (CTS2?) could be provide the necessary functionality as well in this case.

Cheers

Hannes

–

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 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

Hannes_Venter · October 28, 2013, 1:39pm

Yeah I believe that’s right: no registry is pulling anything automatically.

The PR used the admin units from a csv export that was auto-generated by the TS (so an indirect interaction).

Cheers

Hannes

···

On 28 October 2013 15:00, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Just to add my 0.02c, I don’t think any registry is automatically pulling the admin units from the TS in Rwanda. I haven’t been able to find any terminology profiles under IHE that we could use other than the SVS as you mentioned. CTS seems to be the defacto standards for communicating with terminology servers and, yes, it is an HL7 standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=10.

Cheers,

Ryan

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Mon, Oct 28, 2013 at 1:55 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Hannes,
Sorry for my ignorance, but does the FR in Rwanda pull from the TS? Are there other IHE profiles besides SVS for a TS? Am I right in understanding that CTS2 is coming from HL7?

Cheers

-carl

On Oct 28, 2013, at 6:51 AM, Hannes Venter hannes@jembi.org wrote:

Hi,

Just to mention for everyone not involved in RHEA that we are currently storing the administrative units for Rwanda in the TS:

http://ts.jembi.org/browse.php?namespaceId=32808

and it does seem like a good place for it.

Although the export to the provider registry was just plain csv.

If we do use the TS, then I don’t think it would preclude us from using SVS.

SVS would be the “how” rather than the “where”, at least from my understanding.

Although any standards we do decide to use for the TS (CTS2?) could be provide the necessary functionality as well in this case.

Cheers

Hannes

–

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 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

Scott_Teesdale · October 28, 2013, 1:43pm

Hi All,

I can confirm that FR in Rwanda also is not pulling the admin units from the Terminology Service. It is an issue that has come up several time though that a service to provide this data would be of value.

Best,

Scott

···

On Mon, Oct 28, 2013 at 9:39 AM, Hannes Venter hannes@jembi.org wrote:

Yeah I believe that’s right: no registry is pulling anything automatically.

The PR used the admin units from a csv export that was auto-generated by the TS (so an indirect interaction).

Cheers

Hannes

–

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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On 28 October 2013 15:00, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Just to add my 0.02c, I don’t think any registry is automatically pulling the admin units from the TS in Rwanda. I haven’t been able to find any terminology profiles under IHE that we could use other than the SVS as you mentioned. CTS seems to be the defacto standards for communicating with terminology servers and, yes, it is an HL7 standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=10.

Cheers,

Ryan

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Mon, Oct 28, 2013 at 1:55 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Hannes,
Sorry for my ignorance, but does the FR in Rwanda pull from the TS? Are there other IHE profiles besides SVS for a TS? Am I right in understanding that CTS2 is coming from HL7?

Cheers

-carl

On Oct 28, 2013, at 6:51 AM, Hannes Venter hannes@jembi.org wrote:

Hi,

Just to mention for everyone not involved in RHEA that we are currently storing the administrative units for Rwanda in the TS:

http://ts.jembi.org/browse.php?namespaceId=32808

and it does seem like a good place for it.

Although the export to the provider registry was just plain csv.

If we do use the TS, then I don’t think it would preclude us from using SVS.

SVS would be the “how” rather than the “where”, at least from my understanding.

Although any standards we do decide to use for the TS (CTS2?) could be provide the necessary functionality as well in this case.

Cheers

Hannes

–

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 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

Carl_Leitner1 · October 28, 2013, 1:53pm

I dug in a bit more and SVS does not support hierarchical data (although it was tentatively planned for future revision, there are no current work items on it). Does CTS or CTS2 support hierarchy?

Just putting this out there: GraphML and GXL could readily encapsulate the hierarchy data:

http://en.wikipedia.org/wiki/GraphML

http://en.wikipedia.org/wiki/GXL

Cheers.

-carl

···

On 28 October 2013 15:00, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Just to add my 0.02c, I don’t think any registry is automatically pulling the admin units from the TS in Rwanda. I haven’t been able to find any terminology profiles under IHE that we could use other than the SVS as you mentioned. CTS seems to be the defacto standards for communicating with terminology servers and, yes, it is an HL7 standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=10.

Cheers,

Ryan

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Mon, Oct 28, 2013 at 1:55 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Hannes,
Sorry for my ignorance, but does the FR in Rwanda pull from the TS? Are there other IHE profiles besides SVS for a TS? Am I right in understanding that CTS2 is coming from HL7?

Cheers

-carl

On Oct 28, 2013, at 6:51 AM, Hannes Venter hannes@jembi.org wrote:

Hi,

Just to mention for everyone not involved in RHEA that we are currently storing the administrative units for Rwanda in the TS:

http://ts.jembi.org/browse.php?namespaceId=32808

and it does seem like a good place for it.

Although the export to the provider registry was just plain csv.

If we do use the TS, then I don’t think it would preclude us from using SVS.

SVS would be the “how” rather than the “where”, at least from my understanding.

Although any standards we do decide to use for the TS (CTS2?) could be provide the necessary functionality as well in this case.

Cheers

Hannes

–

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 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

Hannes_Venter · October 28, 2013, 3:35pm

Hi Carl,

Well I’m sure somebody like @Jack could answer far more authoritatively than I can

But yes CTS2 does support hierarchy (which would be a type of association).

Just on a pragmatic note: I believe the next version of Apelon DTS (currently in beta) will have support for CTS2.

Cheers

Hannes

···

On 28 October 2013 15:53, Carl Leitner litlfred@gmail.com wrote:

I dug in a bit more and SVS does not support hierarchical data (although it was tentatively planned for future revision, there are no current work items on it). Does CTS or CTS2 support hierarchy?

Just putting this out there: GraphML and GXL could readily encapsulate the hierarchy data:

http://en.wikipedia.org/wiki/GraphML

http://en.wikipedia.org/wiki/GXL

Cheers.

-carl

On Oct 28, 2013, at 9:39 AM, Hannes Venter hannes@jembi.org wrote:

Yeah I believe that’s right: no registry is pulling anything automatically.

The PR used the admin units from a csv export that was auto-generated by the TS (so an indirect interaction).

Cheers

Hannes

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On 28 October 2013 15:00, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Just to add my 0.02c, I don’t think any registry is automatically pulling the admin units from the TS in Rwanda. I haven’t been able to find any terminology profiles under IHE that we could use other than the SVS as you mentioned. CTS seems to be the defacto standards for communicating with terminology servers and, yes, it is an HL7 standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=10.

Cheers,

Ryan

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Mon, Oct 28, 2013 at 1:55 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Hannes,
Sorry for my ignorance, but does the FR in Rwanda pull from the TS? Are there other IHE profiles besides SVS for a TS? Am I right in understanding that CTS2 is coming from HL7?

Cheers

-carl

On Oct 28, 2013, at 6:51 AM, Hannes Venter hannes@jembi.org wrote:

Hi,

Just to mention for everyone not involved in RHEA that we are currently storing the administrative units for Rwanda in the TS:

http://ts.jembi.org/browse.php?namespaceId=32808

and it does seem like a good place for it.

Although the export to the provider registry was just plain csv.

If we do use the TS, then I don’t think it would preclude us from using SVS.

SVS would be the “how” rather than the “where”, at least from my understanding.

Although any standards we do decide to use for the TS (CTS2?) could be provide the necessary functionality as well in this case.

Cheers

Hannes

–

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 28 October 2013 09:26, Ryan Crichton ryan@jembi.org wrote:

Hi Carl,

Sorry for the delayed response.

I agree that seems to be a common problem. Previously we have discussed using the terminology service for something like this. I wonder if that is a appropriate? What do others think, should we include a separate component to store this sort of common value sets or is this something the TS could incorporate?

@Derek, perhaps you have some experience about how this has been solved before?

Cheers,

Ryan

–

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.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

On Wed, Oct 23, 2013 at 1:50 PM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
On the facility registry call last week an issue came up with metadata related to the facility. Specifically looking at how to best encode to which sector that each facility is assigned (Rwanda context). In turn, each sector should be assigned a district,
and each district a province.

This geographic is needed for both the facility registry, the provider registry as well as the sources of provider information (such as the iHRIS installations). I think we are missing a component of the HIE which will be authoritative for this type
of meta-data. One place perhaps to start looking is the “Sharing Value Sets” profile:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_SVS_Rev2-1_TI_2010-08-10.pdf

which handles key-value pairs. I am not sure if this will be enough to manage the hierarchical relationship between sectors and districts, but it could be the place to manage the lists of the sectors, the lists of districts, etc. In any case we should
probably review this in more detail for its applicability.

In the provider registry context, we also have some coded values that should be managed some places else, for example provider type or cadre.

Cheers,

-carl

On Oct 23, 2013, at 4:39 AM, Ryan Crichton ryan@jembi.org

wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there
may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ryan@jembi.org

derek.ritz · October 29, 2013, 2:21am

Hi Ryan.
I think code sets are maintained in the TS but will confirm with colleagues. The one who will have the best insights on this is Jack. Specifically, we should find out how Apelon is deployed in Alberta (one of Canada's provinces). They were an early Apelon reference site.
Derek.

ryan · October 29, 2013, 7:25am

Just including Jack in case he is not on the architecture group. @Jack, see below, there have been a few questions about terminology and Apelon DTS on this thread that I’m sure you can help answer for us

Cheers,

Ryan

···

On Tue, Oct 29, 2013 at 4:21 AM, Derek Ritz derek.ritz@gmail.com wrote:

Hi Ryan.

I think code sets are maintained in the TS but will confirm with colleagues. The one who will have the best insights on this is Jack. Specifically, we should find out how Apelon is deployed in Alberta (one of Canada’s provinces). They were an early Apelon reference site.

Derek.

–

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

jack.bowie · October 29, 2013, 2:51pm

Hi, all. In general, a TS can be used as the “source of truth” for any number of code sets/code systems/ontologies, etc. (pick your favorite term). Different organizations Canadian provinces, US States, etc., all have their own policies, but centralization of these “reference sets” seems to be a good idea. DTS, for example, has a very robust data model that seems to be able to represent a broad set of data representations. CTS 2 is about the only TS API standard that encompases a wide enough set of capabilities to be generally useful, but it is also very complex (lots of methods) and doesn’t even specify the format of some payloads. There are not very many commercial implementations, mostly just the Mayo “reference” implementation.

To respond to Hannes’ comment, we have demonstrated some very preliminary CTS 2 interfaces for DTS V4 (our new version) but this is currently incomplete. A moderate development effort would be required to produce an operational interface.

Jack

···

On Tuesday, October 29, 2013 3:25:06 AM UTC-4, Ryan Crichton wrote:

Just including Jack in case he is not on the architecture group. @Jack, see below, there have been a few questions about terminology and Apelon DTS on this thread that I’m sure you can help answer for us

Cheers,

Ryan

On Tue, Oct 29, 2013 at 4:21 AM, Derek Ritz derek...@gmail.com wrote:

Hi Ryan.

I think code sets are maintained in the TS but will confirm with colleagues. The one who will have the best insights on this is Jack. Specifically, we should find out how Apelon is deployed in Alberta (one of Canada’s provinces). They were an early Apelon reference site.

Derek.

–

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-architect...@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: ry...@jembi.org

bobj · October 29, 2013, 10:18pm

First off I would concur with what most people seem to be saying on this thread. Effective interoperability almost always requires the exchange of common codelists, value lists and the like. The case of the facility registry in Rwanda is a case in point. There are a number of implicit codelists (facility type, ownership, etc) which need to be made visible to users of the data.

For each application using controlled vocabularies to have to make those codelists browseable or otherwise publicly available might be seen as excessively cumbersome (I haven’t completely made my mind up on this). Certainly within a domain scope such as national ministry of health, WHO, Pepfar or what have you, it makes very good sense to me to have central repositories of such structural metadata.

What such a repo might look like could vary considerably … the bottom of the pile being a static web page with links to csv files.

Unfortunately the apparent simplicity of coded vocabularies (terminologies?) as flat lists, as we have seen, are often not adequate. Two typical challenges to represent are selections of subsets and the encoding of hierarchy. Some of the attempts at addressing this domain that have crossed my radar include

genericode
topic maps
skos (and rdf-datacube)
cts2

(The first two are maybe slightly exotic and dated, but lots of good ideas in both)

CTS2 seems really well worked and also with a strong health heritage. I share to an extent Jack’s caution that, even with the hl7 and omg connections, all the action does seem to have been driven from one company. Something like Metadata Technologies with SDMX. Its a good niche market.

My sense would be to look primarily at user base and eco-system of FOSS supportive tools if I were to try and implement something in country. An xml database with skos codelists might be one approach which is easy to implement. There are no doubt others.

What I know least about is the data model for the apelon DTS. Is there a good link for that and is there any consensus building process around it?

Regards

Bob

···

On 29 October 2013 14:51, Jack Bowie jack.bowie@gmail.com wrote:

Hi, all. In general, a TS can be used as the “source of truth” for any number of code sets/code systems/ontologies, etc. (pick your favorite term). Different organizations Canadian provinces, US States, etc., all have their own policies, but centralization of these “reference sets” seems to be a good idea. DTS, for example, has a very robust data model that seems to be able to represent a broad set of data representations. CTS 2 is about the only TS API standard that encompases a wide enough set of capabilities to be generally useful, but it is also very complex (lots of methods) and doesn’t even specify the format of some payloads. There are not very many commercial implementations, mostly just the Mayo “reference” implementation.

To respond to Hannes’ comment, we have demonstrated some very preliminary CTS 2 interfaces for DTS V4 (our new version) but this is currently incomplete. A moderate development effort would be required to produce an operational interface.

Jack

On Tuesday, October 29, 2013 3:25:06 AM UTC-4, Ryan Crichton wrote:

Just including Jack in case he is not on the architecture group. @Jack, see below, there have been a few questions about terminology and Apelon DTS on this thread that I’m sure you can help answer for us

Cheers,

Ryan

On Tue, Oct 29, 2013 at 4:21 AM, Derek Ritz derek...@gmail.com wrote:

Hi Ryan.

I think code sets are maintained in the TS but will confirm with colleagues. The one who will have the best insights on this is Jack. Specifically, we should find out how Apelon is deployed in Alberta (one of Canada’s provinces). They were an early Apelon reference site.

Derek.

–

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-architect...@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: ry...@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.

jack.bowie · October 31, 2013, 1:37pm

Regarding DTS information, DTS is an open source project/product currently managed by Apelon. We have tried over the years to build an active developer community like OpenMRS, but most development is still done internally. Historical information (including source base) can be found at apelon-dts.sourceforge.net. We are completing work on a new version which we are hosting at ApelonDTS.org. (Sourceforge was not providing some of the management mechanisms we wanted.)

We still stuggle with good “high level” descriptions of things like the data model, but here’s a simplified diagram that I hope gives you some sense of the representation ability. So far, we have been able to represent any of the national/international terminologies/code systems folks have thrown at us. DTS also fully represents DL-based terminologies like SNOMED CT.

Hope this helps.

Jack

Simplified DTS Data Model - Thesaurus.ppt (37 KB)

···

On Wednesday, October 23, 2013 4:39:46 AM UTC-4, Ryan Crichton wrote:

Hi all,

I’d like to start a thread to discuss how the components of OpenHIE will communicate and form an HIE. To do this we need to support some standard interfaces that provide certain functionality. Due to our involvement with IHE these should be IHE profiles.

I have put together a diagram depicting the functions that I envisage each registry to perform and the associated standard that seems most likely to use to expose this. Note, this only includes the functions that are useful within the HIE, I’m sure there may be others that are not mentioned here.

I don’t know of an IHE standard that deals with terminology, however there is the HL7 Common Terminology Services standard that could be used.

Please let me know what you think of this and feel free to pull it apart

Cheers,

Ryan

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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