1. Ewout Kramer, Furore CIM-based CRUD storage

2. Architectural context CDR Service v3v2 ? MEPD KN ICIP v3-R v2 AORTA v3

3. The nasty CS->RP route...

4. What we needed A generic way to store a Hl7v3 message in a pre-existing database based on RIM.... It seemed simple, but in januari while discussing it we realized it merited to be a RIMBAA issue...

5. Object Trees & Nets Message: hierarchical versus Storage: cyclic net

6. Example EHR - stored instances

7. Example “update” message

8. Merge away! Maybe not probable but a generic algorithm should handle it Still...we “feel” this interaction goes beyond its scope RMIMs are not designed to Update/Replace/Delete specific children & attributes

9. A generic merger needs... To understand intention of the interaction (activate/revise/record) Additional hints hidden in prose of implementation manuals/Ballot Know mapping to your EHR-model Update context

10. Query Encounter, select Act with code “ENC”. With mood EVN. Which clone in which interaction do you mean? A_Encounter CMET A certain template (collection of CIM’s?)

11. Domain-Driven Design by Eric Evans “How do we know where an object made up of other objects begins and ends?” “How do we know where an object made up of other objects begins and ends?” “In any system with persistent storage of data, there must be a scope for a transaction that changes data and a way of maintaining the consistency of the data” “In any system with persistent storage of data, there must be a scope for a transaction that changes data and a way of maintaining the consistency of the data” Scope of queries en updates

12. Aggregates Define small CIMs with tight/safe scope, context and semantics Define enough CIM’s to cover required domains and no more Map interactions to “service level” CRUD operations with these CIMs

13. Storage model Unit of storage –Lock, create, read, update, delete as a whole –CRUD-services Only the “root” is public Explicit references to other data –Feels like “identifiable” CMET stereotype Scope of context conduction Unit of documentation

14. Interpret interactions & disassemble! Encounter CareProv Consent Observation Ass. Entity Patient Location RelatedPsn Organization Person Place

15. We might end up with

16. Building blocks Explicit (CMET) and implicit re-use of structures –Every domain uses implicit picture of a full-fledged “EHR” DMIM. At best, each domain consistently uses this “EHR” DMIM. –Only differ in domain constraints, clonenames Reverse-engineer this mega-DMIM, split into more generic “aggregates” which are the building blocks of a CDR.

17. E_Person universal

18. E_Person – “related persons”

19. E_Person – “Group membership”

20. R_Patient

21. R_Patient – “Administrative Observations”

22. Patient Adm DMIM – “Identity verification”

23. Patient Admin DMIM Lots of overlap with Administrative Registries!

24. R_RelatedParty

25. E_ProductKind

27. A_Encounter

28. A_CareStatement (detail)

29. E_Person – Storage model

30. R_Patient – Storage model