Authenticating and authorizing service account

[Roger_Friedman]

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.” It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

···

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions. Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally, and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group , r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription) transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however, RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4, r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment before she starts. Or the Head of Nursing might cover and we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[derek.ritz]

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

···

On Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.” It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently) any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting “access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf) “HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR. I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph (below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions. Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally, and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group , r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription) transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however, RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4, r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment before she starts. Or the Head of Nursing might cover and we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[ryan]

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

Cheers,

Ryan

···

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.” It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently) any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting “access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf) “HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR. I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph (below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions. Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally, and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group , r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription) transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however, RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4, r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment before she starts. Or the Head of Nursing might cover and we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ohie-architecture+unsubscribe@googlegroups.com.

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

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Carl_Leitner]

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

···

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[pbiondich]

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

···

On Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[ryan]

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   Cheers,

Ryan

···

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Scott_Teesdale]

Hi All,

I wanted to pass along a few notes from our dev team and share some of the scenarios currently unfolding with the Tanzania implementation of the FR that I think can point to larger patterns in OHIE about how we handle authorization and authentication.

Tanzania is really proving as a good example currently as there are now local developers actively writing apps against a service (e.g., UIs for data maintenance and curation workflows). We have separated these aspects from the facility registry and implemented them from the FR perspective; so we now have a FR that has ‘torn off’ that functionality working well in staging, the Tanzania group effectively comfortable coding to an external ‘authentication authority’ which is neither their code nor the FR. So in terms of “red, green, refactor” we have the first two stages and this now seems to be a perfect time to see how to merge it w/ this dialogue.

As a result of this in TZ we are moving forward with the:

• Implementation of OpenID as an AuthN authority.
• Implementation of different oAuth 2.0 workflows to allow delegated or “service accounts” from trusted apps (any app that uses the service account pattern has to be trusted/whitelisted (as so) as it implies it won’t abuse the privileges of that account). Still working on the more common permission granting oAuth mechanism though (for example).

One next step we are interested to discuss and see evolve is how the Provider Registry can drive the authentication authority (e.g., specifically debating whether the relationship between a PR and an authN authority is a “IS A” or “MANAGES A”). Could we include this as a topic in the next architecture call? I would be happy to arrange for some of our devs to give a more in-depth summary of these updates as well.

Best,

Scott

*** Ed, Nico, Martin, feel free to jump and add any other relevant details or clarifications as well.

···

On Wed, Oct 23, 2013 at 3:36 AM, Ryan Crichton ryan@jembi.org wrote:

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[derek.ritz]

Hi Scott.

Did the team get a chance to look at the IHE profile for this? Sorry…don’t remember what it’s called, but it completed ballot last year and profiled the use OAuth in a healthcare setting. The authors of the profile are engaged with the OAuth development group somehow.

DJ

···

On Wed, Oct 23, 2013 at 3:36 AM, Ryan Crichton ryan@jembi.org wrote:

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Scott_Teesdale]

Hi Derek,

I would venture to say we haven’t looked into it closely enough given our relatively recent engagement with IHE. If you have any links for that profile or contact details for those involved they could be helpful as we move forward.

Best,

Scott

···

On Wed, Nov 6, 2013 at 2:30 PM, Derek Ritz (gmail) derek.ritz@gmail.com wrote:

Hi Scott.

Did the team get a chance to look at the IHE profile for this? Sorry…don’t remember what it’s called, but it completed ballot last year and profiled the use OAuth in a healthcare setting. The authors of the profile are engaged with the OAuth development group somehow.

DJ

Sent from my iPad

On Nov 6, 2013, at 10:33 AM, Scott Teesdale steesdale@instedd.org wrote:

Hi All,

I wanted to pass along a few notes from our dev team and share some of the scenarios currently unfolding with the Tanzania implementation of the FR that I think can point to larger patterns in OHIE about how we handle authorization and authentication.

Tanzania is really proving as a good example currently as there are now local developers actively writing apps against a service (e.g., UIs for data maintenance and curation workflows). We have separated these aspects from the facility registry and implemented them from the FR perspective; so we now have a FR that has ‘torn off’ that functionality working well in staging, the Tanzania group effectively comfortable coding to an external ‘authentication authority’ which is neither their code nor the FR. So in terms of “red, green, refactor” we have the first two stages and this now seems to be a perfect time to see how to merge it w/ this dialogue.

As a result of this in TZ we are moving forward with the:

• Implementation of OpenID as an AuthN authority.
• Implementation of different oAuth 2.0 workflows to allow delegated or “service accounts” from trusted apps (any app that uses the service account pattern has to be trusted/whitelisted (as so) as it implies it won’t abuse the privileges of that account). Still working on the more common permission granting oAuth mechanism though (for example).

One next step we are interested to discuss and see evolve is how the Provider Registry can drive the authentication authority (e.g., specifically debating whether the relationship between a PR and an authN authority is a “IS A” or “MANAGES A”). Could we include this as a topic in the next architecture call? I would be happy to arrange for some of our devs to give a more in-depth summary of these updates as well.

Best,

Scott

*** Ed, Nico, Martin, feel free to jump and add any other relevant details or clarifications as well.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, 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 Wed, Oct 23, 2013 at 3:36 AM, Ryan Crichton ryan@jembi.org wrote:

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Eduardo_Jezierski]

Hi - you mean ATNA?

I have, and looks promising. We are starting with the User authentication area - as the audit trail is a relatively easier issue and cert-based 2 way authN between nodes is also a common practice for the few select ‘super trusted services’ living in the HIE.

We want to implement a mechanism that shows it is compatible to use web standards (oAuth, OpenID) with ATNA. ATNA does not mandate a user authentication approach, and therefore things like oAuth (which is a standard for delegated user authentication) would fit in as well.

After that, the audit trail (which shows up as an “activity stream” in resmap) can be refactored into the same service.

I would love it if we can contribute this work into the HIM package. It has already shown immense value working in Tanzania where a local company is doing their own tool to manage the data curation, approval and edition process and they have been able to do this without managing an alternate set of users, permissions, etc.

For the node to node authentication between HIE components, the HIM could include an admin tool that simplifies the certificate request and deployment process needed the profile. sysadmin tools that do this are common, but having a “how to” guide to make sure the SSL connections between the components are 2 way authenticated may come in handy for LMICs.

~ ej

···

On Wed, Nov 6, 2013 at 2:30 PM, Derek Ritz (gmail) derek.ritz@gmail.com wrote:

Hi Scott.

Did the team get a chance to look at the IHE profile for this? Sorry…don’t remember what it’s called, but it completed ballot last year and profiled the use OAuth in a healthcare setting. The authors of the profile are engaged with the OAuth development group somehow.

DJ

Sent from my iPad

On Nov 6, 2013, at 10:33 AM, Scott Teesdale steesdale@instedd.org wrote:

Hi All,

I wanted to pass along a few notes from our dev team and share some of the scenarios currently unfolding with the Tanzania implementation of the FR that I think can point to larger patterns in OHIE about how we handle authorization and authentication.

Tanzania is really proving as a good example currently as there are now local developers actively writing apps against a service (e.g., UIs for data maintenance and curation workflows). We have separated these aspects from the facility registry and implemented them from the FR perspective; so we now have a FR that has ‘torn off’ that functionality working well in staging, the Tanzania group effectively comfortable coding to an external ‘authentication authority’ which is neither their code nor the FR. So in terms of “red, green, refactor” we have the first two stages and this now seems to be a perfect time to see how to merge it w/ this dialogue.

As a result of this in TZ we are moving forward with the:

• Implementation of OpenID as an AuthN authority.
• Implementation of different oAuth 2.0 workflows to allow delegated or “service accounts” from trusted apps (any app that uses the service account pattern has to be trusted/whitelisted (as so) as it implies it won’t abuse the privileges of that account). Still working on the more common permission granting oAuth mechanism though (for example).

One next step we are interested to discuss and see evolve is how the Provider Registry can drive the authentication authority (e.g., specifically debating whether the relationship between a PR and an authN authority is a “IS A” or “MANAGES A”). Could we include this as a topic in the next architecture call? I would be happy to arrange for some of our devs to give a more in-depth summary of these updates as well.

Best,

Scott

*** Ed, Nico, Martin, feel free to jump and add any other relevant details or clarifications as well.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, 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 Wed, Oct 23, 2013 at 3:36 AM, Ryan Crichton ryan@jembi.org wrote:

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[ryan]

Hi all,

I think the profile that Derek is referring to may be this one: http://wiki.ihe.net/index.php?title=Internet_User_Authorization

It is great to hear that the Tanzania work has provided some real needs for this discussion. I’d love to talk about this in more detail and hear what you guys are planning to implement.

@Ed, It would be great if you could contribute some of this work to the OpenHIM. How exactly do you see this being included in the OpenHIM? How would oAuth work in this case? Would the OpenHIM provide the authentication service?

I agree that the HIM could provide a simplified UI to generate and manage certificates for managing mutual TLS connections. We’ve been thinking about this a little bit as well internally at Jembi. It seems like a good area that could benefit from some simplification for LMIC.

Cheers,

Ryan

···

On Thu, Nov 7, 2013 at 1:42 AM, Eduardo Jezierski edjez@instedd.org wrote:

Hi - you mean ATNA?
I have, and looks promising. We are starting with the User authentication area - as the audit trail is a relatively easier issue and cert-based 2 way authN between nodes is also a common practice for the few select ‘super trusted services’ living in the HIE.

We want to implement a mechanism that shows it is compatible to use web standards (oAuth, OpenID) with ATNA. ATNA does not mandate a user authentication approach, and therefore things like oAuth (which is a standard for delegated user authentication) would fit in as well.

After that, the audit trail (which shows up as an “activity stream” in resmap) can be refactored into the same service.

I would love it if we can contribute this work into the HIM package. It has already shown immense value working in Tanzania where a local company is doing their own tool to manage the data curation, approval and edition process and they have been able to do this without managing an alternate set of users, permissions, etc.

For the node to node authentication between HIE components, the HIM could include an admin tool that simplifies the certificate request and deployment process needed the profile. sysadmin tools that do this are common, but having a “how to” guide to make sure the SSL connections between the components are 2 way authenticated may come in handy for LMICs.

~ ej

On Nov 6, 2013, at 11:35 AM, Scott Teesdale steesdale@instedd.org wrote:

Hi Derek,

I would venture to say we haven’t looked into it closely enough given our relatively recent engagement with IHE. If you have any links for that profile or contact details for those involved they could be helpful as we move forward.

Best,

Scott

–

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 Wed, Nov 6, 2013 at 2:30 PM, Derek Ritz (gmail) derek.ritz@gmail.com wrote:

Hi Scott.

Did the team get a chance to look at the IHE profile for this? Sorry…don’t remember what it’s called, but it completed ballot last year and profiled the use OAuth in a healthcare setting. The authors of the profile are engaged with the OAuth development group somehow.

DJ

Sent from my iPad

On Nov 6, 2013, at 10:33 AM, Scott Teesdale steesdale@instedd.org wrote:

Hi All,

I wanted to pass along a few notes from our dev team and share some of the scenarios currently unfolding with the Tanzania implementation of the FR that I think can point to larger patterns in OHIE about how we handle authorization and authentication.

Tanzania is really proving as a good example currently as there are now local developers actively writing apps against a service (e.g., UIs for data maintenance and curation workflows). We have separated these aspects from the facility registry and implemented them from the FR perspective; so we now have a FR that has ‘torn off’ that functionality working well in staging, the Tanzania group effectively comfortable coding to an external ‘authentication authority’ which is neither their code nor the FR. So in terms of “red, green, refactor” we have the first two stages and this now seems to be a perfect time to see how to merge it w/ this dialogue.

As a result of this in TZ we are moving forward with the:

• Implementation of OpenID as an AuthN authority.
• Implementation of different oAuth 2.0 workflows to allow delegated or “service accounts” from trusted apps (any app that uses the service account pattern has to be trusted/whitelisted (as so) as it implies it won’t abuse the privileges of that account). Still working on the more common permission granting oAuth mechanism though (for example).

One next step we are interested to discuss and see evolve is how the Provider Registry can drive the authentication authority (e.g., specifically debating whether the relationship between a PR and an authN authority is a “IS A” or “MANAGES A”). Could we include this as a topic in the next architecture call? I would be happy to arrange for some of our devs to give a more in-depth summary of these updates as well.

Best,

Scott

*** Ed, Nico, Martin, feel free to jump and add any other relevant details or clarifications as well.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, 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 Wed, Oct 23, 2013 at 3:36 AM, Ryan Crichton ryan@jembi.org wrote:

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Eduardo_Jezierski]

Ryan -

Of course!  we need to coordinate a dev meeting to see what are the projects, the shared needs and how things could be packaged and contributed into the HIM.

Re. TLS in LMICs; as an example we have over a thousand TLS secured connections going into clinics around South Africa connecting them to the cloud right now as we speak; all of those were provisioned by a simple opt-in from end users with no tech knowledge. So from there to having a simple tool for sysadmins should it be a much simpler job and probably one that there's plenty of open source toolkits to start from.

Maybe Scott and Martin can propose some times that work to have that call (im out next week)

~ ej

···

On Thu, Nov 7, 2013 at 1:42 AM, Eduardo Jezierski edjez@instedd.org wrote:

Hi - you mean ATNA?
I have, and looks promising. We are starting with the User authentication area - as the audit trail is a relatively easier issue and cert-based 2 way authN between nodes is also a common practice for the few select ‘super trusted services’ living in the HIE.

We want to implement a mechanism that shows it is compatible to use web standards (oAuth, OpenID) with ATNA. ATNA does not mandate a user authentication approach, and therefore things like oAuth (which is a standard for delegated user authentication) would fit in as well.

After that, the audit trail (which shows up as an “activity stream” in resmap) can be refactored into the same service.

I would love it if we can contribute this work into the HIM package. It has already shown immense value working in Tanzania where a local company is doing their own tool to manage the data curation, approval and edition process and they have been able to do this without managing an alternate set of users, permissions, etc.

For the node to node authentication between HIE components, the HIM could include an admin tool that simplifies the certificate request and deployment process needed the profile. sysadmin tools that do this are common, but having a “how to” guide to make sure the SSL connections between the components are 2 way authenticated may come in handy for LMICs.

~ ej

On Nov 6, 2013, at 11:35 AM, Scott Teesdale steesdale@instedd.org wrote:

Hi Derek,

I would venture to say we haven’t looked into it closely enough given our relatively recent engagement with IHE. If you have any links for that profile or contact details for those involved they could be helpful as we move forward.

Best,

Scott

–

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 Wed, Nov 6, 2013 at 2:30 PM, Derek Ritz (gmail) derek.ritz@gmail.com wrote:

Hi Scott.

Did the team get a chance to look at the IHE profile for this? Sorry…don’t remember what it’s called, but it completed ballot last year and profiled the use OAuth in a healthcare setting. The authors of the profile are engaged with the OAuth development group somehow.

DJ

Sent from my iPad

On Nov 6, 2013, at 10:33 AM, Scott Teesdale steesdale@instedd.org wrote:

Hi All,

I wanted to pass along a few notes from our dev team and share some of the scenarios currently unfolding with the Tanzania implementation of the FR that I think can point to larger patterns in OHIE about how we handle authorization and authentication.

Tanzania is really proving as a good example currently as there are now local developers actively writing apps against a service (e.g., UIs for data maintenance and curation workflows). We have separated these aspects from the facility registry and implemented them from the FR perspective; so we now have a FR that has ‘torn off’ that functionality working well in staging, the Tanzania group effectively comfortable coding to an external ‘authentication authority’ which is neither their code nor the FR. So in terms of “red, green, refactor” we have the first two stages and this now seems to be a perfect time to see how to merge it w/ this dialogue.

As a result of this in TZ we are moving forward with the:

• Implementation of OpenID as an AuthN authority.
• Implementation of different oAuth 2.0 workflows to allow delegated or “service accounts” from trusted apps (any app that uses the service account pattern has to be trusted/whitelisted (as so) as it implies it won’t abuse the privileges of that account). Still working on the more common permission granting oAuth mechanism though (for example).

One next step we are interested to discuss and see evolve is how the Provider Registry can drive the authentication authority (e.g., specifically debating whether the relationship between a PR and an authN authority is a “IS A” or “MANAGES A”). Could we include this as a topic in the next architecture call? I would be happy to arrange for some of our devs to give a more in-depth summary of these updates as well.

Best,

Scott

*** Ed, Nico, Martin, feel free to jump and add any other relevant details or clarifications as well.

–

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, 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 Wed, Oct 23, 2013 at 3:36 AM, Ryan Crichton ryan@jembi.org wrote:

@Carl L, that sounds promising. I’d be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I’m not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don’t think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry’s data store.
   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.

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Tue, Oct 22, 2013 at 4:11 PM, Paul Biondich pbiondic@regenstrief.org wrote:

After reading through this thread, I’m left with a few questions/observations:

1. I think we should be clear on what we mean by “human users”. There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE. I’m pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that’d include provider registry based central authority for management application user lists. Do people agree with this?

2. There’s a presumption in the thread that for “nodes” to access the HIE, that they need to be authenticated via PKI. My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them. There are a whole bunch of other models of authentication I’ve seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3. I think it’s worth exploring whether registry “maitenance applications” are any different than nodes below the network. I think they likely are, but Derek brings up a good point. Is this a useful distinction, and as such… do they get a “different interaction rule set”?

-Paul

–

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 Tue, Oct 22, 2013 at 9:39 AM, Carl Leitner cleitner@capacityplus.org wrote:

Hi Ryan,
This is fine with me. It seems like we have a consensus.

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model. There are extension points built into CSD we can take advantage of. Something like:

<providerDirectory>

    <provider oid='2.25.1231231232112328988979888312321321'>

         <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

            <!-- DETAILS ON AUTHORIZATION GO HERE-->

        </extension>

   </provider>

There are two oids here. The first is the “enterprise provider ID” if you like. It is unique for each provider in the directory.

The second is for the extension point. I would suggest that we put all “OpenHIE” extensions to CSD (whether for provider, facility, etc.) under extensions point with the same OID. The one I generated above, 2.25.309768652999692686176651983274504471835,
comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs

For the type=‘authorization’ we have some flexibility here on how to best use the type attribute, as well as in defining the <–DETAILS ON AUTH–>. I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community. Wiki? Github or other VCS? Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level
  of detail? If not, how should we best do this?

Cheers,

-carl

On Oct 22, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven’t heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will
need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

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.

On Fri, Oct 18, 2013 at 3:26 PM, Derek Ritz
derek.ritz@gmail.com wrote:

Thanks, Roger. I didn’t realize I’d not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing – but you correct that those are certainly “pillars” of the community.

–

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 Fri, Oct 18, 2013 at 8:15 AM, r.friedman@mindspring.com wrote:

Derek, it appears your comment missed the list. I don’t want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by “primary PoS and registry products.”
It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE. I could be wrong about this.

-----Original Message-----

From: Derek Ritz

Sent: Oct 17, 2013 3:59 PM

To: r.friedman@mindspring.com

Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let’s pace thru them. First – you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize
registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently)
any IHE profile. This is a gap… and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is “designed for OpenMRS” as its PoS. To do so would fundamentally undermine the HIE’s value
proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage “HPD” than that we leverage iHRIS and, as things evolve, it may be more accurate to say we’re leveraging CSD than DHIS (or Resource
Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for
HPD, is still pretty nascent – but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting
“access rights”. As is noted in IHE’s HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf )
“HPD does not support attributes intended directly for Access Control”.

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR.
I would contend, however, that this is because we are early in the evolution of this infrastructure – not because that is all the infrastructure is designed to do. I don’t share the view that we need to fundamentally rethink how our puzzle pieces operate
or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace
the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph
(below).

The crawl, walk, run strategy was not an unsound one… and it doesn’t mean that all our HIE knows how to do is crawl…

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Thu, Oct 17, 2013 at 9:16 AM, r.friedman@mindspring.com wrote:

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense. We would have to adopt existing types of transactions and/or create a transaction
definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level). Standardizing transactions can take a lot of time. The ONC Continuity of Care Document definition process addresses what I think is a core
function for the SHR and AFAIK has no concrete output. To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added. For OpenMRS, the
transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records). HL7/CDA would provide a transport
protocol. For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies. Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.
Certainly if we put permissions in the PR, we will be rolling our own message. This work would have to be funded.

This architecture takes us away from our experience. From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility’s EMR. And the most developed HIEs involve lab results, which have few transaction
types and disease-or-condition program-related issues. I don’t see an incremental way of moving from what we have to Derek’s approach.

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs. The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined
analytical datasets. Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset. The analytical datasets could be de-identified or aggregated and made available
to AVR software. There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated
PoS instances. Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format. The analytical datasets and PoS formats could be defined incrementally,
and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz

Sent: Oct 16, 2013 11:01 PM

To: ohie-architecture@googlegroups.com

Cc: Provider Registry Google Group ,
r.friedman@mindspring.com
Subject: Re: Authenticating and authorizing service account

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each
clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription)
transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process
all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea).

As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however,
RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend
we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

On Wednesday, October 16, 2013 3:36:05 PM UTC-4,
r.fri...@mindspring.com wrote:

My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization
for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained
by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address
only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority
for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment
before she starts. Or the Head of Nursing might cover and
we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

–

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

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

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

–

Derek Ritz

---

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.