Workflow name changes

Legacy ohie-architecture
1

All,

After reviewing each of the workflows, their names have been revised to clarify their purpose and (hopefully) make them more consumable to a less-initiated reader.

You can see the list of workflows and their revised names here:

https://wiki.ohie.org/display/documents/OpenHIE+Workflows

Please let us know your thoughts on the updated names - your feedback is greatly appreciated!

Additionally, please stay tuned for a few additional suggested updates to the workflows documentation over the next few weeks.

Thanks for all your hard work, and Happy Holidays!

Best,

Shaun

···

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

2

Hi Shaun – I like where you’re going with this; I think the new names are definitely more descriptive and helpful. Here’s something I couldn’t help noticing, tho: i think there is a difference in how we use our verbs re: patient demographics versus patient encounters. For example – if one were SAVE a new encounter it would “create” a new record… unless of course one were to SAVE an encounter that referenced an existing one, it which case it would replace that record and deprecate the old one – effectively updating it. Either way, we have only a “save” verb.

On the one hand, there is a lot to be said for having a simplified set of verbs. Using encounters as our model, we would have 2 simple verbs: SAVE and QUERY. The behaviour (e.g. save new or update) would depend on the content in the message payload. However, if one knows ahead of time whether the saved record is new, or updating an existing one, then the error trapping can be commensurately more precise and helpful. Years ago (quite a while before the RESTful nomenclature became populat) I used to refer to interfaces as PLUGs (each interface would expose 4 methods: PUT, LIST, UPDATE and GET).

My dev days are long behind me so, to be honest I really don’t care which way we do it. I’m sure there are sound arguments to be made for each approach and the talented folks that DO write our code can, I’m sure, determine what is the “right” answer for OpenHIE. My point is that we should maybe plan to use the same granularity across all of our interfaces. My sense is that we’ll be well served to have a common “posture” on this across the entirety of the OpenHIE communities.

My $0.02…

DJ

Of course – another simplifying assumption might be to adopt a single OpenHIE workflow per IHE transaction

···

On Monday, 15 December 2014 17:10:03 UTC-5, sgrannis wrote:

All,

After reviewing each of the workflows, their names have been revised to clarify their purpose and (hopefully) make them more consumable to a less-initiated reader.

You can see the list of workflows and their revised names here:

https://wiki.ohie.org/display/documents/OpenHIE+Workflows

Please let us know your thoughts on the updated names - your feedback is greatly appreciated!

Additionally, please stay tuned for a few additional suggested updates to the workflows documentation over the next few weeks.

Thanks for all your hard work, and Happy Holidays!

Best,

Shaun

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

3

Derek,

Thanks for the comments – we may want to contemplate some minor changes to the verbs. I’m a ran of create, update, query.

Let’s review on an upcoming architecture call in earl 2015.

Shaun

···

From: Derek Ritz derek.ritz@ecgroupinc.com

Date: Monday, December 15, 2014 at 8:47 PM

To: “ohie-architecture@googlegroups.com” ohie-architecture@googlegroups.com

Subject: Re: Workflow name changes

Hi Shaun – I like where you’re going with this; I think the new names are definitely more descriptive and helpful. Here’s something I couldn’t help noticing, tho: i think there is a difference in how we use our verbs re: patient demographics
versus patient encounters. For example – if one were SAVE a new encounter it would “create” a new record… unless of course one were to SAVE an encounter that referenced an existing one, it which case it would replace that record and deprecate the old one
– effectively updating it. Either way, we have only a “save” verb.

On the one hand, there is a lot to be said for having a simplified set of verbs. Using encounters as our model, we would have 2 simple verbs: SAVE and QUERY. The behaviour (e.g. save new or update) would depend on the content in the message payload. However,
if one knows ahead of time whether the saved record is new, or updating an existing one, then the error trapping can be commensurately more precise and helpful. Years ago (quite a while before the RESTful nomenclature became populat) I used to refer to interfaces
as PLUGs (each interface would expose 4 methods: PUT, LIST, UPDATE and GET).

My dev days are long behind me so, to be honest I really don’t care which way we do it. I’m sure there are sound arguments to be made for each approach and the talented folks that DO write our code can, I’m sure, determine what is the “right” answer for
OpenHIE. My point is that we should maybe plan to use the same granularity across all of our interfaces. My sense is that we’ll be well served to have a common “posture” on this across the entirety of the OpenHIE communities.

My $0.02…

DJ

Of course – another simplifying assumption might be to adopt a single OpenHIE workflow per IHE transaction

On Monday, 15 December 2014 17:10:03 UTC-5, sgrannis wrote:

All,

After reviewing each of the workflows, their names have been revised to clarify their purpose and (hopefully) make them more consumable to a less-initiated reader.

You can see the list of workflows and their revised names here:

https://wiki.ohie.org/display/documents/OpenHIE+Workflows

Please let us know your thoughts on the updated names - your feedback is greatly appreciated!

Additionally, please stay tuned for a few additional suggested updates to the workflows documentation over the next few weeks.

Thanks for all your hard work, and Happy Holidays!

Best,

Shaun

Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

4

All,
In an environment where decision makers and implementation teams are comprised of a diverse set of individuals (e.g. health care professionals, government employees, administrators and information technologists), we need to create a way for non-programmers to understand the basic interaction between PoCs and the HIE. We need an approach that facilitates communication with a broader audience, while still conveying the technical details to those who need them. Based upon this, I’m advocating that we think about the verbs that are most native to the system users/implementers. My two cents is that the workflow names and the diagram of the interaction should be readable by a non-technical person. The tables supporting the diagrams should be where the technical details live.

My two cents on an approach for thinking about the names and workflow documentation.

Jennifer

Jennifer E. Shivers

jennifer.e.shivers@gmail.com

317.797.1200

Skype: jennifer.shivers

···

On Dec 18, 2014, at 9:45 PM, Grannis, Shaun J sgrannis@regenstrief.org wrote:

Derek,

Thanks for the comments – we may want to contemplate some minor changes to the verbs. I’m a ran of create, update, query.

Let’s review on an upcoming architecture call in earl 2015.

Shaun

From: Derek Ritz derek.ritz@ecgroupinc.com

Date: Monday, December 15, 2014 at 8:47 PM

To: “ohie-architecture@googlegroups.com” ohie-architecture@googlegroups.com

Subject: Re: Workflow name changes

Hi Shaun – I like where you’re going with this; I think the new names are definitely more descriptive and helpful. Here’s something I couldn’t help noticing, tho: i think there is a difference in how we use our verbs re: patient demographics
versus patient encounters. For example – if one were SAVE a new encounter it would “create” a new record… unless of course one were to SAVE an encounter that referenced an existing one, it which case it would replace that record and deprecate the old one
– effectively updating it. Either way, we have only a “save” verb.

On the one hand, there is a lot to be said for having a simplified set of verbs. Using encounters as our model, we would have 2 simple verbs: SAVE and QUERY. The behaviour (e.g. save new or update) would depend on the content in the message payload. However,
if one knows ahead of time whether the saved record is new, or updating an existing one, then the error trapping can be commensurately more precise and helpful. Years ago (quite a while before the RESTful nomenclature became populat) I used to refer to interfaces
as PLUGs (each interface would expose 4 methods: PUT, LIST, UPDATE and GET).

My dev days are long behind me so, to be honest I really don’t care which way we do it. I’m sure there are sound arguments to be made for each approach and the talented folks that DO write our code can, I’m sure, determine what is the “right” answer for
OpenHIE. My point is that we should maybe plan to use the same granularity across all of our interfaces. My sense is that we’ll be well served to have a common “posture” on this across the entirety of the OpenHIE communities.

My $0.02…

DJ

Of course – another simplifying assumption might be to adopt a single OpenHIE workflow per IHE transaction

On Monday, 15 December 2014 17:10:03 UTC-5, sgrannis wrote:

All,

After reviewing each of the workflows, their names have been revised to clarify their purpose and (hopefully) make them more consumable to a less-initiated reader.

You can see the list of workflows and their revised names here:

https://wiki.ohie.org/display/documents/OpenHIE+Workflows

Please let us know your thoughts on the updated names - your feedback is greatly appreciated!

Additionally, please stay tuned for a few additional suggested updates to the workflows documentation over the next few weeks.

Thanks for all your hard work, and Happy Holidays!

Best,

Shaun

Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-architecture+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.