1. ecGroup Inc. RHEA Client Registry Mapping user stories to openHIM transactions… V0.1 Draft for discussion (2012-07-09)

2. ecGroup Inc. Characters  Abel – registration clerk; openMRS.A user  Baker – registration clerk; openMRS.B user  Charlie – client 2

3. ecGroup Inc. 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 3

4. ecGroup Inc. 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 4

5. ecGroup Inc. 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 5

6. ecGroup Inc. 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 6

7. ecGroup Inc. 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 7

8. ecGroup Inc. 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! 8

9. ecGroup Inc. 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.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 9

10. ecGroup Inc. 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 10

11. ecGroup Inc. 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.A 3. Charlie’s two records are merged into one record in openMRS.A 4. There are 2 records for Charlie in the CR; these are merged into one CR record 5. Charlie’s shared health record is retrieved and updates his record in openMRS.A 6. Charlie is seen by the clinician; a transaction regarding the clinical visit is logged in openMRS.A 7. Charlie’s SHR is updated 11

12. ecGroup Inc. 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) 12

13. ecGroup Inc. 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 CR 4. 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 13

14. ecGroup Inc. 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” 14

15. ecGroup Inc. Combinations Local openMRSClient RegistryWhat happens? 0 Charlie Create Charlie in openMRS; create Charlie in CR 1 Charlie0 CharlieCreate Charlie in CR “2” Charlies0 CharlieMerge Charlies in openMRS; create Charlie in CR 0 Charlie1 CharlieCreate Charlie in openMRS 1 Charlie “2” Charlies1 CharlieMerge Charlies in openMRS 0 Charlie“2” CharliesMerge Charlies in CR; create Charlie in openMRS 1 Charlie“2” CharliesMerge Charlies in CR “2” Charlies Merge Charlies in openMRS; merge Charlies in CR 15

16. ecGroup Inc. 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 16

17. ecGroup Inc. 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! 17