I do stuff for a while, and as I do it, eventually I realize that I develop a method. Over time, my method evolves into what I consider to be a set of best practices and principles. Often I've internalized these without even thinking about it. And then somebody says something, and words come out of my mouth explaining why I do it this way. At which point I finally realize that there is a method to my madness which I've just shared with myself and others, sometimes to my own surprise.
Yesterday, in discussing the Remote Read workflow being developed in IHE Radiology, I was asked a question about the infrastructure being used for XDW. "We know the infrastructure is XDS," I said, "but I ignore that when crafting the workflow. IT Infrastructure is presently working on making XDW work with XCA and XDR (and maybe even XDM). We don't want to get caught up in the infrastructure"
Later: "So your tasks should always have as inputs everything they need to complete, even if you don't always use them. This is because you might not have an XDS infrastructure to go back to get information about a preceding task in the workflow. So the task needs to know everything when it gets notified."
And "We don't put any Service Level agreements in this workflow, that's policy stuff we enable with it. Implementers can argue about it later. That's not our problem."
Then there was my morning realization today: The main point of an IHE workflow profile is independent of the underlying implementation technology altogether. It's the definition of the tasks, roles, and inputs and outputs that is critical. If well defined, a workflow task can be integrated with multiple technologies, and still work. In other words, an IHE Workflow profile should be able to stand by itself, without needing an infrastructure like XDW to be implemented.
Like IHE Content profiles, which can work with IHE profiles like XDS, XCA, XDR and XDM, but which can also work with technologies like Direct and Blue Button + and FHIR; IHE workflow profiles also need to be designed to be technology independent. Yes, we expect to apply them over XDW, and there will be defined rules for how to do that. But we can also apply them over other technologies. If IHE workflow profiles are really to have value in the industry, we should design them so that they work in other environments too.
Yesterday, in discussing the Remote Read workflow being developed in IHE Radiology, I was asked a question about the infrastructure being used for XDW. "We know the infrastructure is XDS," I said, "but I ignore that when crafting the workflow. IT Infrastructure is presently working on making XDW work with XCA and XDR (and maybe even XDM). We don't want to get caught up in the infrastructure"
Later: "So your tasks should always have as inputs everything they need to complete, even if you don't always use them. This is because you might not have an XDS infrastructure to go back to get information about a preceding task in the workflow. So the task needs to know everything when it gets notified."
And "We don't put any Service Level agreements in this workflow, that's policy stuff we enable with it. Implementers can argue about it later. That's not our problem."
Then there was my morning realization today: The main point of an IHE workflow profile is independent of the underlying implementation technology altogether. It's the definition of the tasks, roles, and inputs and outputs that is critical. If well defined, a workflow task can be integrated with multiple technologies, and still work. In other words, an IHE Workflow profile should be able to stand by itself, without needing an infrastructure like XDW to be implemented.
Like IHE Content profiles, which can work with IHE profiles like XDS, XCA, XDR and XDM, but which can also work with technologies like Direct and Blue Button + and FHIR; IHE workflow profiles also need to be designed to be technology independent. Yes, we expect to apply them over XDW, and there will be defined rules for how to do that. But we can also apply them over other technologies. If IHE workflow profiles are really to have value in the industry, we should design them so that they work in other environments too.
0 comments:
Post a Comment