"Get patient" and "Query patients" workflows

Legacy ohie-architecture
1

All,

On the last architecture call we discussed combining two workflows: 1) the “get patient workflow”, and 2) the “query patients workflow”:

After review, despite returning one-versus-multiple patients, we believe these workflows can leverage the same transactions.

If they leverage the same transactions, then do we need two separate workflows, or should we collapse “Get patients” and “Query patients” into a single workflow?

We’re leaning toward combining the two workflows into one. Is it necessary to keep them separate? Do we have real-world examples (e.g., Rwanda) where it’s necessary to do so?

Thanks,

Shaun & Odysseas

2

Hi Shaun,

The main reason that this was done in Rwanda is that the two workflow have different purposes. The “get” always returns a single patient uniquely identified by an ID. The “query” returns a list of suggested matches.

I think it is ok to merge these as long as we keep the same sort of interactions. If the new workflow can accept an ID and return a unique patient or just query demographics and return multiple patients, then I don’t see why this can’t be merged.

Cheers,

Ryan

···

On Fri, Mar 21, 2014 at 5:41 PM, Shaun Grannis sgrannis@gmail.com wrote:

All,

On the last architecture call we discussed combining two workflows: 1) the “get patient workflow”, and 2) the “query patients workflow”:

After review, despite returning one-versus-multiple patients, we believe these workflows can leverage the same transactions.

If they leverage the same transactions, then do we need two separate workflows, or should we collapse “Get patients” and “Query patients” into a single workflow?

We’re leaning toward combining the two workflows into one. Is it necessary to keep them separate? Do we have real-world examples (e.g., Rwanda) where it’s necessary to do so?

Thanks,

Shaun & Odysseas

–

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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

3

to update the group re: this conversation…

···

On Tue, Mar 25, 2014 at 3:39 PM, Shaun Grannis sgrannis@gmail.com wrote:

Derek,

Thanks again for your response. what are your thoughts specifically regarding merging the “Get” and “Query” patient workflows?

Best,

Shaun

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

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)

On Fri, Mar 21, 2014 at 3:15 PM, Derek Ritz derek.ritz@gmail.com wrote:

Hi all.

I’ve attached the IHE ITI technical framework v2.b doc. Pages 11-83 go through a large number of the use cases supported by transactions ITI-30 and ITI-31. I think it would help us to map what we’re expecting to support to these use cases and the transaction details that support them. (A number of them map very closely to our RHEA use cases, for instance).

I’ve also attached the v2.a of the ITI TF. Page 56 (PIX query) and page 150 (PDQ query) are the two profiles we most talk about. To answer the question Shaun has posited, tho, I think it is important to delve into the underlying transactions within those profiles that we’re planning to support. The PIX transactions (ITI-9 and ITI-10) are for managing IDs only. We need to do this – but we need to do more than just this. The core PDQ transaction (ITI-21) is used to retrieve demographic information. We need to be able to do this, too – and I think it is important for us to work out when we will be using each of these specific transactions.

For example, there are a set of transactions for doing merge/split – and we know this to be something important for our RHEA work right now. (these are in ITI-30, i think). There are also specific cases regarding what to do when there are multiple patients returned as part of a demographic query (these are in v2.a on page 160 and following). In all cases, there is clear guidance regarding what is written to the audit logs and how it is formatted; I’m not sure we’re following these conventions presently.

My point is that the profiles contain multiple transactions within them and my sense is that we should map these transactions independently; they each have their own use cases. I also worry that we have not (yet) mapped our OHIE CR transactions to the very mature interactions described in the PIX, PDQ and PAM profiles. Doing so will, I think, very clearly delineate which specific interactions we should expect to use and for what purposes.

My $0.02…

Warmest regards,

Derek.

PS: as an FYI, I’ve also attached the ITI TF vol-1 since this is where a number of the profiles are described in terms of their use cases and “business process” viewpoints.

On Fri, Mar 21, 2014 at 11:41 AM, Shaun Grannis sgrannis@gmail.com wrote:

All,

On the last architecture call we discussed combining two workflows: 1) the “get patient workflow”, and 2) the “query patients workflow”:

After review, despite returning one-versus-multiple patients, we believe these workflows can leverage the same transactions.

If they leverage the same transactions, then do we need two separate workflows, or should we collapse “Get patients” and “Query patients” into a single workflow?

We’re leaning toward combining the two workflows into one. Is it necessary to keep them separate? Do we have real-world examples (e.g., Rwanda) where it’s necessary to do so?

Thanks,

Shaun & Odysseas

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.