This 3-slide PPT deck (attached) is intended to illustrate the idea of expressing the mHero workflow as a “POS” workflow that connects to OpenHIE via existing transactions. The illustrated workflow is intended to operate in a manner that is functionally identical to Workflow Option 0 found here: https://wiki.ohie.org/display/documents/mHero+Workflow/ .
Recasting the workflow in this way illustrates a clear boundary between OpenHIE’s infrastructure and the infrastructure of the companion service (the “POS”). This particular example also illustrates a case where a POS application’s database might, itself, act as an underlying directory to the interlinked registry (ILR). We have this situation, now; in many implementations, iHRIS is both an HR application and an underlying directory of HWR content.
Obviously, a “POS” can, in its own right, be a nationally-deployed, cloud-based eHealth service. The intent of the diagram is to show how logical delineations might help us see where we need to make changes to OpenHIE vs. cases where we are adding implementation-specific functionality that can leverage and extend OpenHIE without needing to alter its underlying architecture.
I hope this clarifies what I meant on today’s call by “recasting as a POS workflow”; I look forward to discussion on these ideas.
Warmest regards,
Derek.
PS: In case it might be helpful, I also attached the websequence diagram pseudocode that generated the diagram.
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.
Hi Derek,
Thanks for sharing this. One consequence is that there is no ATNA logging between the PoS and the mHero Data Collector. If we start carrying clinical data on this (and I think this is fairly likely if it hasn’t already happened) then that’s a drawback.
Related to this, I think that the generic way that the DHIS2 Mobile Tracker app communicates to the DHIS2 server could perhaps be represented in a similar workflow (though we wouldn’t necessarily call it mHero). This would definitely carry some PHI which could be intercepted by the IL and sent to a SHR, for example.
This 3-slide PPT deck (attached) is intended to illustrate the idea of expressing the mHero workflow as a “POS” workflow that connects to OpenHIE via existing transactions. The illustrated workflow is intended to operate in a manner that is functionally identical to Workflow Option 0 found here: https://wiki.ohie.org/display/documents/mHero+Workflow/ .
Recasting the workflow in this way illustrates a clear boundary between OpenHIE’s infrastructure and the infrastructure of the companion service (the “POS”). This particular example also illustrates a case where a POS application’s database might, itself, act as an underlying directory to the interlinked registry (ILR). We have this situation, now; in many implementations, iHRIS is both an HR application and an underlying directory of HWR content.
Obviously, a “POS” can, in its own right, be a nationally-deployed, cloud-based eHealth service. The intent of the diagram is to show how logical delineations might help us see where we need to make changes to OpenHIE vs. cases where we are adding implementation-specific functionality that can leverage and extend OpenHIE without needing to alter its underlying architecture.
I hope this clarifies what I meant on today’s call by “recasting as a POS workflow”; I look forward to discussion on these ideas.
Warmest regards,
Derek.
PS: In case it might be helpful, I also attached the websequence diagram pseudocode that generated the diagram.
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.