ecGroup Inc.

RHEA Client Registry

Mapping user stories to openHIM transactions…V0.1 Draft for discussion (2012-07-09)

ecGroup Inc. 2

Characters

Abel – registration clerk; openMRS.A user Baker – registration clerk; openMRS.B user Charlie – client

ecGroup Inc. 3

Story #1

1. Charlie arrives at the clinic; Abel attempts to lookup Charlie in openMRS.A

2. Charlie has his NID card and his NID matches a single client record in openMRS.A

3. Charlie’s shared health record is retrieved and updated into openMRS.A

4. Charlie is seen by the clinician; a transaction regarding the clinical visit is logged in openMRS.A

5. Charlie’s SHR is updated

ecGroup Inc. 4

Story #1 – discussion

This is the happy case – and the one we hope will be (by far!) the most common Deterministic matching by NID One local ID record One ECID

ecGroup Inc. 5

Story #2

1. Charlie arrives at the clinic; Abel attempts to lookup Charlie in openMRS.A

2. Charlie does not have his NID card and does not know his NID. Charlie’s demographic details match a single client record in openMRS.A

3. Charlie’s demographic details match a single record in the CR; Charlie’s shared health record is retrieved and updated into openMRS.A

4. Charlie is seen by the clinician; a transaction regarding the clinical visit is logged in openMRS.A

5. Charlie’s SHR is updated

ecGroup Inc. 6

Story #2 – discussion

This is the next most happy case – and one we hope will be less common Successful fuzzy matching by demographic

details One local ID record One ECID

If the fuzzy search returns multiple records, but not too many, and only one of them is Charlie, this is still the happy case

ecGroup Inc. 7

Story #3

1. Charlie arrives at the clinic; Abel attempts to lookup Charlie in openMRS.A

2. Charlie does not have his NID card and does not know his NID. Charlie’s demographic details do not match any client record in openMRS.A

3. Charlie’s demographic details match a single client record in the CR

4. Charlie’s shared health record is retrieved; a new record is created for Charlie in openMRS.A

5. Charlie is seen by the clinician; a transaction regarding the clinical visit is logged in openMRS.A

6. Charlie’s SHR is updated

ecGroup Inc. 8

Story #3 – discussion

This is another very happy case; it defines the heart of the value of a shared health record No local ID record One ECID

The local record is “bootstrapped” with the shared health record – Yayy! Great continuity of care!

ecGroup Inc. 9

Story #4

1. Charlie arrives at the clinic; Abel attempts to lookup Charlie in openMRS.A

2. Charlie does not have his NID card and does not know his NID. Charlie’s demographic details do not match any client record in openMRS.A

3. Charlie’s demographic details do not match any client record in the CR

4. A new record is created for Charlie in openMRS.A5. Charlie is seen by the clinician; a transaction

regarding the clinical visit is logged in openMRS.A6. Charlie’s SHR is updated

ecGroup Inc. 10

Story #4 – discussion

This is how we will “onboard” new clients; it is a bread and butter use case

We need to be sensitive to the fact that this is also our primary “error-creating” use case We will not find Charlie’s record based on our

fuzzy demographic search… but the record is there and we are not finding it because something has changed since it was created

This error case is mitigated by using deterministic rather than fuzzy searches

ecGroup Inc. 11

Story #5

1. Charlie arrives at the clinic; Abel attempts to lookup Charlie in openMRS.A

2. Charlie’s details match two client records in openMRS.A3. Charlie’s two records are merged into one record in

openMRS.A4. There are 2 records for Charlie in the CR; these are

merged into one CR record5. Charlie’s shared health record is retrieved and updates

his record in openMRS.A6. Charlie is seen by the clinician; a transaction regarding

the clinical visit is logged in openMRS.A7. Charlie’s SHR is updated

ecGroup Inc. 12

Story #5 – discussion

This is how we mitigate errors arising from story #4

If we have multiple local Charlies, we will likely also have multiple Charlies in the CR (in fact, unless another clinic has found and fixed the issue, we will have)

It is not explicitly described, but any merge of client IDs implies a merge of the indexed health records as well (local, and shared)

ecGroup Inc. 13

Story #6

1. Charlie arrives at the clinic; Baker attempts to lookup Charlie in openMRS.B

2. Charlie’s details do not match any client records in openMRS.B

3. Charlie’s details match two records in the CR4. Charlie’s two CR records are merged; Charlie’s

(merged) shared health record is retrieved and creates a new record in openMRS.B

5. Charlie is seen by the clinician; a transaction regarding the clinical visit is logged in openMRS.B

6. Charlie’s SHR is updated

ecGroup Inc. 14

Story #6 – discussion

Although Abel may have inadvertently created duplicate records for Charlie, Baker may find this issue and fix it

The end case is that Abel’s local database may be still in an error state (multiple Charlies) but the CR will now be “fixed”

This opens the door to a potential issue, since Abel’s connection to the “old” (deprecated) Charlie record on the CR will return an exception – and we need to make sure this exception causes Abel to fix/merge his local database… and not to create yet another Charlie in the CR because “no active match is found for that ID”

ecGroup Inc. 15

Combinations

Local openMRS Client Registry What happens?

0 Charlie 0 Charlie Create Charlie in openMRS; create Charlie in CR

1 Charlie 0 Charlie Create Charlie in CR

“2” Charlies 0 Charlie Merge Charlies in openMRS; create Charlie in CR

0 Charlie 1 Charlie Create Charlie in openMRS

1 Charlie 1 Charlie

“2” Charlies 1 Charlie Merge Charlies in openMRS

0 Charlie “2” Charlies Merge Charlies in CR; create Charlie in openMRS

1 Charlie “2” Charlies Merge Charlies in CR

“2” Charlies “2” Charlies Merge Charlies in openMRS; merge Charlies in CR

ecGroup Inc. 16

Types of Errors

Type 1 – there is more than one Charlie (shown in red text) Type 2 – there is a local Charlie and no Charlie in the CR

(shown as highlighted in yellow) Synch error – there are more local Charlies than in the CR

(this is the cautionary tale from Story #6… and is one we need to look for in our error trapping on the local systems)

Type 3 – there is an erroneous/inadvertent “merge” of records that needs to split This is a “big deal” to do in any kind of automated way and it is

recommended that it be done manually using administrator tools, both locally and in the shared health record

The challenge is that it is very difficult to know where to make the split

ecGroup Inc. 17

Notes…

Just like there should never be more than one Charlie in the local openMRS, there should never be more than one Charlie in our enterprise CR

Our RHEA EMPI design is for a single (unfederated) CR; this is a useful simplification and we should make use of it!