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