FW: Dispensing Use Case

Hi all – this PPT deck (attached) tries to describe a high-level architecture for supporting care delivery, supply chain, insurance, and CRVS. It was originally developed for UNICEF (hence the “architecture for children” label) – but it was intended to be generally applicable. The example use case story is focused on an immunization workflow.

I hope this is helpful as a conversation-starter… :blush:

Warmest regards and happy holidays!

Derek

17-11-11 Digital Architecture for Children.pptx (1.34 MB)

···

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,

I want to share that we brainstormed and documented our thoughts following the outline you provided in this document. Please feel free to review the brainstorm at Log In - OpenHIE Wiki. We will discuss it in our next call.

Craig

···

On Friday, December 21, 2018 at 9:13:56 AM UTC-8, derek.ritz wrote:

Hi all – this PPT deck (attached) tries to describe a high-level architecture for supporting care delivery, supply chain, insurance, and CRVS. It was originally developed for UNICEF (hence the “architecture for children” label) – but it was intended to be generally applicable. The example use case story is focused on an immunization workflow.

I hope this is helpful as a conversation-starter… :blush:

Warmest regards and happy holidays!

Derek

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.

Thanks, Craig.

I’m sorry to say that I’ll miss this Friday’s call; I have a conflicting meeting that I can’t move or miss.

I looked at the “brainstorm” page. Here are some comments related to it:

  • As a matter of managing scope – I would advocate for identifying and documenting the “interfaces” between the HIE and the supply chain systems. In my view, we would be better-served by loosely-coupling the care-delivery architecture and the SCM architecture rather than trying to combine them into a single, very-large, quite-complicated architecture. Supply chain management is, in my experience, a non-trivial domain in its own right with its own enterprise architecture.
  • Related to this latter point – we might want to, separately, come up with a family of engineering artefacts to describe our supply chain EA. There are some mature information models, for e.g., that we can leverage and which may be helpful to us. I say this because I worry that there are some important nuances we seem to be missing; for e.g. regarding item part numbers and the one-to-many relationship between these and GTINs. As an example – 500mg Acetaminophen tablets would have an item part number. Every packaging configuration available from every vendor would have its own GTIN… but they are all functionally equivalent… and they all represent inventory levels of the same thing: 500mg Acetaminophen tablets. Our interface between the HIE and the SCM system will need to be able to translate item consumption (e.g. pharma dispense of 500mg Acetaminophen tablets) into GTIN consumption… and that might not always be simple to do.
  • Also related to this “separation of concerns” idea – I think we would do well to separate out the transactions and workflows that our supply chain architecture needs to support from the significantly-smaller subset of transactions that operationalize the “interfaces” between the HIE and the SCM systems.
    My kudos to the brainstormers… there is a lot there for us to digest and work through. I’m sorry to miss Friday’s call, but look forward to contributing to the ongoing efforts as we continue to progress our work.

Warmest regards,

Derek

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,

I want to share that we brainstormed and documented our thoughts following the outline you provided in this document. Please feel free to review the brainstorm at https://wiki.ohie.org/display/SUB/Architecture+Brainstorm. We will discuss it in our next call.

Craig

On Friday, December 21, 2018 at 9:13:56 AM UTC-8, derek.ritz wrote:

Hi all – this PPT deck (attached) tries to describe a high-level architecture for supporting care delivery, supply chain, insurance, and CRVS. It was originally developed for UNICEF (hence the “architecture for children” label) – but it was intended to be generally applicable. The example use case story is focused on an immunization workflow.

I hope this is helpful as a conversation-starter… :blush:

Warmest regards and happy holidays!

Derek

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 Supply Chain” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-supply-chain+unsubscribe@googlegroups.com.
To post to this group, send email to openhie-supply-chain@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhie-supply-chain/dd51b07f-22b6-4975-8b20-f54db279299a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.