Skip to end of metadata
Go to start of metadata

Overview

Description:

Workflow for a point of service application to query the Info Manager for health workers, facilities and/or the services provided by each.

Sponsor:  Carl Leitner & Martin Verzilli

Status: Tested with OpenHIE V1.0

Referenced Standards:

Actors:

  • IL = Interoperability Layer to handle data governance and security issues, CSD Services Finder
  • POS = Point of Service Application, CSD Services Finder
  • ILR InfoMan = Interlinked Registries CSD InfoManager
  • HWR =  Health Worker Registry HWR, CSD Services Directory
  • FR =  Facility Registry FR, CSD Services Directory

Last Modified:  02/17/2014

 

 

Technical details

RefInteractionEndpointDataTransaction Specification
0initiated according to timing set by jurisdictionEndpoint for the "cache and merge" policy (arrows 1-4) are jurisdiction specific.  It will be a path under http(s)://<<ILR_BASE_ADDR>>/HTTP GET Request.  No query parameters required. 
1 
http(s)://<<FR_BASE_ADDR>>/careServicesRequest
POST SOAP wrapped message with last time service directory was polled[ITI-74] Query for Updated Services Transaction
2  SOAP wrapped CSD document with updates to services (facilities)[ITI-74] Query for Updated Services Transaction
3 
http(s)://<<HWR_INFOMAN_BASE_ADDR>>/careServicesRequest
SOAP wrapped message with last time service directory was polled[ITI-74] Query for Updated Services Transaction
4 
 
SOAP wrapped CSD document with updates to services (health workers)[ITI-74] Query for Updated Services Transaction
5 
 
Merge caches of FR and HWR according to jurisdiction specific data governance/conflict resolution policy 
6  HTTP 200 Response on success. 
HTTP 500 Response on failure
 
7 
 http(s)://<<IL_BASE_ADDR>>/careServicesRequest
POST careServicesRequest document defined in CSD.xsd[ITI-73] Find Matching Services (Ad-Hoc and Stored)
8 
 
@uuid attribute in careServicesRequest document for stored queries is used for validation

Validation is defined according to country specific

data governance policies in accessing the InfoMan

9 
http(s)://<<ILR_INFOMAN_BASE_ADDR>>/careServicesRequest
POST careServicesRequest document defined in CSD.xsd[ITI-73] Find Matching Services (Ad-Hoc and Stored)
10  Result of executing stored referencced by uuid/ad-hoc xquery. Usually a CSD document but
can have any content-type depending on the query requested.
[ITI-73] Find Matching Services (Ad-Hoc and Stored)
11 
 

Result of executing stored referencced by uuid/ad-hoc xquery. Usually a CSD document but

can have any content-type depending on the query requested.

[ITI-73] Find Matching Services (Ad-Hoc and Stored)
  • No labels

5 Comments

  1.  

    Carl, I don't understand the layering of this, it could easily be my misunderstanding.  I thought that communications within the HIE could be in private APIs, therefore I don't understand why InfoMan is using external-type messaging.  This is particularly true if we look at the recent discussions about whether every FR should come wrapped with an InfoMan, which would definitely obviate the need for a SOAP transaction between the InfoMan and FR.

  2. Hi Roger,

    Here is my understanding.  The IHE-ITI committee considers the "Query for Updated Services" transaction as one of the the back-office processes, as it is primarily for communication within the HIE .  Many of the IHE profiles leverage SOAP for back office processes so within the IHE community there is a a lot of tooling around SOAP already built.   If I recall the discussion, they were in particular interested in the use of SOAP allows for some more complicated routing on the back-end (load-balancing between servers, message forwarding and what have you).

    My take on the private APIs, is that (reading private=proprietary) allows us to inter-change the back-end system.  In particular that keeps us honest about creating artificial software dependencies.  As an example, we are actively going forward with two HWRs that conform to the CSD standard are based on OpenInfoMan with BaseX as the technology stack.  Keeping conformant to the standard "external style" API, let's someone come in and more readily replace the OpenInfoMan with a different technology solution.

    One other thing to note is that the design and relationship between the InfoMan and ServiceDirectory actors allows them to be linked together relatively easily.  In particular if the piece of software you are using to implement the InfoMan actor also implements the Service Directory actor you can imagine several different architectures:

    • Have an internal facing InfoMan and an external facing InfoMan.  The external facing InfoMan is a cache (via ITI-74) of the internal one.   This reduces system load and risk on the internal InfoMan.  Moreover, a different set/subset of stored queries on the external InfoMan can be put of the external InfoMan to more clearly protect a subset of the data in the InfoMan from public access (e.g. home contact information)
    • Have an InfoMan for a "Health Worker Registry" that is charge of merging various Service Directories (e.g. one for each professional council, one for a public sector HRIS, one for an FBO HRIS).  You could then have a another InfoMan that would pull from the HWR (now acting as a Services Directory) and the FR (as a Services Directory).    As an aside, one might imagine that, in the case of multiple authorities for the management of a facilities (e.g the MOH for public sector facilities and a Private License Bureau for private sector facilities, or even something like a ECOWAS-region federated FR) that a similar setup as to the HWR may be useful.
    • (As you indicated).  Have a FR acting as a ServicesDirectory with an InfoMan sitting in front of it.  The primary role of this, in my mind, would be to allow the FR+InfoMan to answer more complicated queries based on the CSD data model than just the simple ITI-74 one about "give me the updated services since X"

    In particular, my point is that this allows us more flexibility when we take the OpenHIE architecture and adapt it to meet a country's implementation needs. 

     

    I hope that helps give some context and has answered, at least partially, your question.  I am happy to discuss further.

    Cheers.

    -carl

     

     

     

     

     

     

    1. Thanks, Carl.  I think I am still missing something because I don't see a "system of record" in your description, rather a bunch of separate systems thrashing away at an uncoordinated shared DB. 

      As I understand this Data Access Framerwork, there is a desire to support service access via both SOAP and REST; I don't doubt that REST is capable of load balancing as much as SOAP. 

      Also, I am not yet convinced that the use of xquery within the message is a good idea.  The CSD data model should be a conceptual model that relates to message design, it should be agnostic as to the physical data model.  This was what I understood the private APIs to be for.  For example, when performance is important, such as when facility data is joined with patient data for reporting, there ought to be a faster interface, perhaps as low level as jdbc.

      I am trying to read old documents to understand how we got to where we are, if you could point me to some of the earlier discussions perhaps I would understand better. 

  3. Hi Roger,

    I think you should read that each Service Directory is a system of record for business domain that they are responsible for.    I think perhaps some of the confusion may be to the use of the InfoMan terminology.  It has been used (as in the diagram) as the name of box in the architecture diagram, as well as short hand for the actor in CSD, InfoManager.  I think a more descriptive label for the InfoMan box in the above diagram is "Interlinked Registries InfoMan" as it plays the role of combining the FR and HWR business domains and exposing them to the HIE.

    The role of the Health Worker Registry, acting as a CSD-InfoManager,  is to amalgamate each of the Services Directories in the health worker information systems domain to produce the national HWR .   This is largely driven by two policy/data-governance considerations:

    • What is the minimum data set of health worker information that each source system must present on the HW (assuming that it collects this information)
    • Which of Service Directories is the authority for each of these data elements

    To be a bit concrete, here is a proto-typical example :

    • A Nursing Council is a system of record for approved nursing and midwifery credentials for a country
    • A Medical council is a system of record for the approved medical credential for a country
    • etc.
    • A MOH HRIS is a system of record for health worker deployment information information in public sector facilities within the geographic domain over which the MOH operates

    As these details are policy driven, they are, to my mind, out-of-scope for these workflow documentations.   However I think it is far from the case that that there is "a bunch of separate systems thrashing away at an uncoordinated shared DB."

     

     

    Note that the ITI-74 transaction was originally a REST style, but was changed after committee discussion to the SOAP style for the reasons as I cited above.   As I have no particular preference in regards to SOAP vs REST, I was merely an observer of that discussion.   If you think that there is a need to support a REST-like interface for ITI-74, than it may be worth while for you to submit a CP to IHE (referencing the DAF). 

    There is nothing in the CSD standard that requires any of the actors to support XQuery.  There is an optional ad-hoc version of the ITI-73 which allows a Services Finder to request that an InfoMan execute an xquery.   So, to your point, low-level access via jdbc is certainly within the bounds of being compliant with CSD.  

    One other issue of XQuery in the CSD standard is that it is a component in defining a way to publish what should be a new stored queries to InfoMan actors  (the other component is the XForms Core Module to constrain submission parameters).   This is distinct from saying that the InfoMan must implement this stored query using xquery – it is perfectly acceptable to have a "human intervention" process to translate the xquery into whatever underlying technology that the InfoMan actor deploys.     It is a convenience, but not a requirement, that this XQuery be executed.

    I think rather, that the point of these stored queries, is that a library of them could be developed for a specific domain to be executed against multiple InfoMan actors.   For example, one could have (and we do) a stored query to that produces for DHIS2 a DXF file containing the number of health workers in a facility by cadre.   The role of the xquery in this case is to specify how one should extract from an the CSD data model the needed number of hws for DHIS2.    

     

     

     

  4. I think this would be easier for end users to understand if the workflow were split into two.  Right now, it's confusing because there are two starting points.  The first part of the interaction diagram is probably an "internal" or "administrative" HIE workflow and the second part is the actual workflow that can be used by  a pos application.