You're all invited to give feedback to IHE profiles!

Hi all -
Derek Ritz, Scott Teesdale and I had a call last Friday where we discussed how to best help the IHE profile efforts ongoing that relate to facility registries. Derek, feel free to add to the bullet points below. I’ve tried to simplify and paraphrase what we discussed

What is IHE?

The IHE effort takes existing standards or combinations and subsets of them and establishes ‘profiles’. Each profile describes an exchange of information that different actors can support. For example, there could be an actor that needs to be able to answer questions about facilities, and IHE would describe the requirements for those queries (at a logical level, like “query facilities filtering by province”) and then specifies a physical data exchange over the wire to implement it.

What are we giving feedback on?

There is currently a profile being developed called Care Services Discovery, or CSD. It purposefully tries to blend querying across organizations, providers and facilities to answer questions like “when is the antenatal care service available in facilities nearby” or “where would dentist services be available on Tuesday” sort of queries.

Why would we care to give feedback?

Our collaborative journey defining the OHIE-FR API brought multiple players together and we were able to design and implement something together that demonstrates this little community will not put interoperability burdens on countries as they deploy the plethora of tools available for ehealth and mhealth that deal with facilities. Giving feedback to IHE is in a way an extension to this commitment, as the playing field for SOA services expands and supporting ratified profiles of standards may become a trending requirement (this depends on funders and governance). We want to influence IHE because if the profiles are useful and good, we can implement them and consume them easily; and because if they are not good, they will place a complexity and design burden on in-country implementations and API implementers and users.

How are we giving feedback?

To facilitate the feedback process to IHE from this whole community, I have created an issue-tracking Repository in Github where we can post and follow the status of different issues. Derek is our proxy to the IHE process and he will be able to comment on those, ask clarifying questions, and collaborate on shaping the IHE profile further.

Issues kept here: https://github.com/facilityregistry/ihe/issues

—> —> Please make sure you log onto github and 'Watch" the repository so that you get emails notifications of the issues.

Tips for submitting or commenting on issues:

  1. Be pragmatic - see where concrete field requirements would be assisted or hampered by the spec and reference those in your feedback.

  2. Keep it technical & objective. Provide references to background docs, specs and reading where helpful. Let’s help CSD espouse good architecture, design and implementation patterns.

  3. Be constructive - if the means to attain a goal of CSD is suboptimal, suggest other means and approaches that meet the constraints you see, and keep them simple!

The current CSD spec is being worked on realtime and kept here:

ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr11-2013-2014/Technical_Cmte/WorkItems/CareServicesDiscovery/ --> look for the filename that looks latest.

Copies of files exchanged are also kept here : https://github.com/facilityregistry/ihe/tree/master/CSD

(if you want to add files just send me a pull request if you’re not already an admin)

How will this affect our technologies and the OHIE-FR (FRED) API?

While CSD is not a semantic overlap with the FRED API (they differ in goals and approaches), CSD will be an endpoint supported in our reference implementation. This will make our Reference Implementation a viable actor for specific roles in the IHE specification, alongside other standards-group ratified or community-group endorsed APIs already implemented (GeoJson, GeoRSS, FRED, etc). In simpler words, Resource Map will support CSD as an API.

Please reply if you have any questions!

Thanks - Derek and ourselves are looking forward to your input.

···

===

Scott & Edjez

Hi all.

I would like to add an open invitation to the FR team to participate directly with the current CSD profile development, public comment and approval (voting) process. IHE membership is free and their technical committee processes are completely open and transparent. At present, a number of our teammates are already IHE members, including: ecGroup (my company), Mohawk, Apelon (OHIE TS lead), IntraHealth (OHIE PR lead), Regenstrief (OHIE executive lead) as well as CDC (OHIE funder, through Cardno).

My fear is that a role for me, as “proxy”, might incorrectly imply that facility registry community participation vs. direct IHE participation is an either/or proposition. This isn’t so. In fact, our impact is significantly increased when we directly participate and add our voices to the conversations at the IHE committee level. Every IHE member casts a single vote. That means ecGroup (my one-person company) casts one vote… and IBM (433k employees) casts one vote.

Information about joining IHE can be found here: http://www.ihe.net/governance/index.cfm. I wholeheartedly encourage us all to sign on… oh, and did I mention each of our organizations gets one vote, no matter how small?

Thanks and warmest regards,

Derek.

···

On Wednesday, May 29, 2013 8:19:44 PM UTC-4, Eduardo Jezierski wrote:

Hi all -
Derek Ritz, Scott Teesdale and I had a call last Friday where we discussed how to best help the IHE profile efforts ongoing that relate to facility registries. Derek, feel free to add to the bullet points below. I’ve tried to simplify and paraphrase what we discussed

What is IHE?

The IHE effort takes existing standards or combinations and subsets of them and establishes ‘profiles’. Each profile describes an exchange of information that different actors can support. For example, there could be an actor that needs to be able to answer questions about facilities, and IHE would describe the requirements for those queries (at a logical level, like “query facilities filtering by province”) and then specifies a physical data exchange over the wire to implement it.

What are we giving feedback on?

There is currently a profile being developed called Care Services Discovery, or CSD. It purposefully tries to blend querying across organizations, providers and facilities to answer questions like “when is the antenatal care service available in facilities nearby” or “where would dentist services be available on Tuesday” sort of queries.

Why would we care to give feedback?

Our collaborative journey defining the OHIE-FR API brought multiple players together and we were able to design and implement something together that demonstrates this little community will not put interoperability burdens on countries as they deploy the plethora of tools available for ehealth and mhealth that deal with facilities. Giving feedback to IHE is in a way an extension to this commitment, as the playing field for SOA services expands and supporting ratified profiles of standards may become a trending requirement (this depends on funders and governance). We want to influence IHE because if the profiles are useful and good, we can implement them and consume them easily; and because if they are not good, they will place a complexity and design burden on in-country implementations and API implementers and users.

How are we giving feedback?

To facilitate the feedback process to IHE from this whole community, I have created an issue-tracking Repository in Github where we can post and follow the status of different issues. Derek is our proxy to the IHE process and he will be able to comment on those, ask clarifying questions, and collaborate on shaping the IHE profile further.

Issues kept here: https://github.com/facilityregistry/ihe/issues

—> —> Please make sure you log onto github and 'Watch" the repository so that you get emails notifications of the issues.

Tips for submitting or commenting on issues:

  1. Be pragmatic - see where concrete field requirements would be assisted or hampered by the spec and reference those in your feedback.
  1. Keep it technical & objective. Provide references to background docs, specs and reading where helpful. Let’s help CSD espouse good architecture, design and implementation patterns.
  1. Be constructive - if the means to attain a goal of CSD is suboptimal, suggest other means and approaches that meet the constraints you see, and keep them simple!

The current CSD spec is being worked on realtime and kept here:

ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr11-2013-2014/Technical_Cmte/WorkItems/CareServicesDiscovery/ --> look for the filename that looks latest.

Copies of files exchanged are also kept here : https://github.com/facilityregistry/ihe/tree/master/CSD

(if you want to add files just send me a pull request if you’re not already an admin)

How will this affect our technologies and the OHIE-FR (FRED) API?

While CSD is not a semantic overlap with the FRED API (they differ in goals and approaches), CSD will be an endpoint supported in our reference implementation. This will make our Reference Implementation a viable actor for specific roles in the IHE specification, alongside other standards-group ratified or community-group endorsed APIs already implemented (GeoJson, GeoRSS, FRED, etc). In simpler words, Resource Map will support CSD as an API.

Please reply if you have any questions!

Thanks - Derek and ourselves are looking forward to your input.

===

Scott & Edjez