The document provides an overview of the HL7 Version 3 Reference Models, which include the Reference Information Model (RIM), Data Type Specification, and Vocabulary Specification. The RIM is the foundational information model that all other HL7 models and specifications are derived from. It defines core classes like Entity, Role, Act, and Participation and their relationships. The RIM was developed over many years through a harmonization process and is now a stable standard.

1. Health Level Seven Version 3 Reference ModelsA Brief IntroductionAbdul-Malik ShakirPrincipal Consultant, Shakir ConsultingNovember 23, 2009

2. About MeAbdul-Malik ShakirPrincipal Consultant with Shakir ConsultingInformation Management Strategist with City of HopeHL7 Member since 1991Co-Chair of the HL7 Education WorkgroupMember of the HL7: Architectural Review BoardPublic Health and Emergency Response WorkgroupRegulated Clinical Research Information Management WorkgroupModeling and Methodology Workgroup

3. HL7 v3.0 Foundational ArtifactsReference ModelsReferenceInformationModelThe HL7 Reference Information Model is the information model from which all other information models and message specifications are derived.DatatypeSpecificationThe HL7 Datatype Specification defines the structural format of the data carried in an attribute and influences the set of allowable values an attribute may assume. VocabularySpecificationThe HL7 Vocabulary Specification defines the set of all concepts that can be taken as valid values in an instance of a coded attribute or data type property.

4. HL7 Version 3.0 Reference ModelsReference Information ModelData TypeSpecificationVocabularySpecification

5. HL7 Version 3.0 Reference Information ModelThe HL7 Reference Information Model is the information model from which all other information models and message specifications are derived.

6. The HL7 Reference Information ModelThe HL7 Reference Information Model (RIM) is a static model of health and health care information as viewed within the scope of HL7 standards development activities. It is the combined consensus view of information from the perspective of the HL7 working group and the HL7 international affiliates. The RIM is the ultimate source from which the information-related content of all HL7 version 3.0 protocol specification standards is drawn. The RIM is modeled using the modeling syntax defined by the Object Management Group’s Unified Modeling Language (UML).

7. HL7 RIM Class Diagram

8. Reference Information Model HistoryDevelopment of the HL7 Reference Information Model began in April 1996.The first draft of the RIM was created by consolidating data models developed by HL7 Technical Committees, contributed by HL7 Member Organizations, and published by national and international standards organizations and government bodies.The first release of the RIM (v0.80) was adopted by the HL7 Technical Steering Committee at the January 1997 working group meeting.The next two working group meetings focused on gaining familiarity with the draft RIM and implementing a process for obtaining and reconciling proposed enhancements to the model. The RIM maintenance process became known as "RIM harmonization.” The first RIM harmonization meeting was held July 1997 in Indianapolis, Indiana.

9. RIM Harmonization IllustrationABXBAB0..*10..*0..*0..*10..*10..*0..*0..*0..*CDCBGE0..*10..*10..*1DXFCA0..*0..10..*1Model IModel IIModel III

10. HL7 RIM Normative SpecificationNine harmonization meetings were held between 1998 and 2000 culminating in version 1.0 of the RIM ratified during the January 2001 HL7 Working Group Meeting.The RIM continues to be refined via ongoing harmonization meeting but has been extremely stable in its content since January 2001.Version 1.25 of the RIM was submitted for ballot in 2002.In June 2003 it was published as an American National Standard.

11. Major RIM Harmonization ThemesEnsure coverage of HL7 version 2.x. This set of change proposals introduced content to the draft model to ensure that it included all the information content of HL7 version 2.x.Remove unsubstantiated content from the model. This set of change proposals focused on removing content from the draft model that the steward technical committee did not originate and could find no rationale for retaining.Unified service action model. This set of change proposals introduced a concise, well-defined set of structures and vocabularies that address the information needs of a wide variety of clinical scenarios. This collection of proposals, known as USAM, involved the combined effort of multiple technical committees.Ensure quality. This set of change proposals addressed inconsistencies in the draft model and conflicts between the model and the modeling style guide. It began the practice of recording and tracking open issues in the model.Address the "left hand side" of the model. This set of change proposals introduced powerful structures and vocabularies for the non-clinical portions of the model (patient administration, finance, scheduling). Like the unified service action model, this proposal involved the combined effort of multiple technical committees.

12. USAM’s Influence on the RIMThe Universal Service Action Model (USAM) proposal was a major influence on the current style of the RIMUSAM was a joint project involving multiple HL7 Technical Committees and Special Interest GroupsThe USAM Material / Service construct is the predecessor to the current RIM Entity / Act constructUSAM introduced the concept of activity mood as a means of distinguishing between act instances, definition, plans, orders, and criterion.The RIM concepts of entity determiner and entity roles are based upon concepts first introduced in the USAM proposal.

13. The Unified Service Action Model

14. ActsRoleEntityParticipationThe RIM After USAMInfrastructure

15. Entity and ActEntityActEntity a physical thing or an organization/group of physical things capable of participating in Acts. This includes living subjects, organizations, material, and places.Act a discernible action of interest in the healthcare domain. An instance of Act is a record of that action. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act.

16. EntityActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : IIRIM Core ClassesEntity -a physical thing or an organization/group of physical things capable of participating in Acts. This includes living subjects, organizations, material, and places.Act – a discernible action of interest in the healthcare domain. An instance of Act is a record of that action. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act.0..*0..*

17. RoleclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IIEntityActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : IIRIM Core Classesplays0..*10..*0..*

18. 0..1plays0..*0..1scopes0..*Role –a classification/specialization of an Entity defined by the relationship of the playing Entity to a scoping Entity. An example of Role is “Employee”. An employee is a classification attributed to a person which has an employment relationship with an organization (Employer).EntityRoleActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IIclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II0..*0..*RIM Core Classes

19. 110..*0..*Participation –an association between a Role and an Act representing the function assumed by the Role within the context of the Act. A single Role may participate in multiple Acts and a single Act may have multiple participating Roles. A single Participation is always an association between a particular Role and a particular Act.EntityRoleParticipationActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IItypeCode : CStime : IVL<TS>statusCode : CSclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II0..10..*RIM Core Classesplays0..1scopes0..*

20. 0..*0..* 1 1110..*0..*Act relationship –an association between two Acts. This includes Act to Act associations such as collector/component, predecessor/successor, and cause/outcome. The semantics of the association is captured by the Act Relationship attributes.Act RelationshiptypeCode : CSEntityRoleParticipationActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IItypeCode : CStime : IVL<TS>statusCode : CSclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II0..10..*RIM Core Classesplays0..1scopes0..*

21. 0..*0..*0..*0..* 1 1 1 1110..*0..*Role Link –An association between two Roles. It is used to capture relationships that exists between Entities other than the scoping relationships. A single Role may have a Role Link with multiple other Roles. A single Role Link is always between two distinct instances of Role.Role LinkAct RelationshiptypeCode : CSeffectiveTime : IVL<TS>typeCode : CSEntityRoleParticipationActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IItypeCode : CStime : IVL<TS>statusCode : CSclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II0..1plays0..*RIM Core Classes0..1scopes0..*

22. Definition of RIM Core ClassesAct – a discernible action of interest in the healthcare domain. An instance of Act is a record of that action. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act.Act relationship –an association between two Acts. This includes Act to Act associations such as collector/component, predecessor/successor, and cause/outcome. The semantics of the association is captured by the Act Relationship attributes.Entity -a physical thing or an organization/group of physical things capable of participating in Acts. This includes living subjects, organizations, material, and places.Participation –an association between a Role and an Act representing the function assumed by the Role within the context of the Act. A single Role may participate in multiple Acts and a single Act may have multiple participating Roles. A single Participation is always an association between a particular Role and a particular Act.Role –a classification/specialization of an Entity defined by the relationship of the playing Entity to a scoping Entity. An example of Role is “Employee”. An employee is a classification attributed to a person which has an employment relationship with an organization (Employer).Role Link –An association between two Roles. It is used to capture relationships that exists between Entities other than the scoping relationships. A single Role may have a Role Link with multiple other Roles. A single Role Link is always between two distinct instances of Role.

23. 0..*0..*0..*0..* 1 1 1 1110..*0..*Role LinkAct RelationshiptypeCode : CSeffectiveTime : IVL<TS>typeCode : CSEntityRoleParticipationActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IItypeCode : CStime : IVL<TS>statusCode : CSclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II0..10..*RIM Backbone Classesplays0..1scopes0..*

24. RIM Backbone Classes110..*0..*EntityRoleParticipationActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IItypeCode : CStime : IVL<TS>statusCode : CSclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II0..1plays0..*0..1scopes0..*

25. RIM Backbone Classes11Living SubjectPlaceOrganizationMaterialLicensed EntityPatientAccessEmployeeObservationSupplyPatient EncounterProcedureDevice TaskSubstance AdministrationFinancial TransactionInvoice ElementFinancial ContractAccountWorking ListControl ActManaged Participation0..*0..*EntityRoleParticipationActclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IItypeCode : CStime : IVL<TS>statusCode : CSclassCode : CSmoodCode: CScode: CDstatusCode : CSeffectiveTime : GTSid : II1plays0..*1scopes0..*

26. HL7 RIM Class Diagram

27. RIM Core Attribute Value SetsObservation

28. Procedure

29. Supply

30. Substance AdminFinancial

31. ...

32. Living Subject

33. Person

34. Organization

35. Material

36. Place

37. ...

38. Patient

39. Provider

40. Employee

41. Specimen

42. Certified Practitioner...

43. Performer

44. Author

45. Witness

46. Subject

47. Destination

48. ...ActClass CodeEntityClass CodeRoleClass CodeParticipationType Code110..*0..*Definition

49. Intent

50. Order

51. Event

52. Criterion

53. ...

54. Kind

55. Instance

56. QuantifiedGroupEntityDeterminerCodeActMood CodeEntityRoleParticipationActclassCode : CCdeterminerCode : CSstatusCode : CScode: CEclassCode : CSeffectiveTime : IVL<TS>code: CEtypeCode : CStime : IVL<TS>statusCode : CSclassCode : CCmoodCode : CSstatusCode : CScode: CDeffectiveTime : GTS0..1plays0..*0..1scopes0..*

57. Act.classCode3.1.1.1 Act.classCode :: CS (1..1) MandatoryVocabulary domain: ActClass (CNE)Attribute description: A code specifying the major type of Act that this Act-instance represents.Constraints: The classCode domain is a tightly controlled vocabulary, not an external or user-defined vocabulary. Every Act-instance must have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used. The Act.classCode must be a generalization of the specific Act concept (e.g., as expressed in Act.code), in other words, the Act concepts conveyed in an Act must be specializations of the Act.classCode. Especially, the classCode is not a "modifier" or the Act.code that can alter the meaning of a class code. (See Act.code for contrast.)

58. Act.moodCode3.1.1.2 Act.moodCode :: CS (1..1) MandatoryVocabulary domain: ActMood (CNE)Attribute description: A code distinguishing whether an Act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc.Constraints: An Act-instance must have one and only one moodCode value. The moodCode of a single Act-instance never changes. Mood is not state. To describe the progression of a business activity from defined to planned to executed, etc. one must instantiate different Act-instances in the different moods and link them using ActRelationship of general type "sequel". (See ActRelationship.typeCode.)Discussion: The Act.moodCode includes the following notions: (1) event, i.e., factual description of an actions that occurred; (2) definition of possible actions and action plans (the master file layer); (3) intent, i.e., an action plan instantiated for a patient as a care plan or order; (4) goal, i.e., an desired outcome attached to patient problems and plans; and (5) criterion, i.e., a predicate used to evaluate a logical expression

59. Act.code3.1.1.4 Act.code :: CD (0..1)Vocabulary domain: ActCode (CWE)Attribute description: A code specifying the particular kind of Act that the Act-instance represents within its class.Constraints: The kind of Act (e.g. physical examination, serum potassium, inpatient encounter, charge financial transaction, etc.) is specified with a code from one of several, typically external, coding systems. The coding system will depend on the class of Act, such as LOINC for observations, etc. Conceptually, the Act.code must be a specialization of the Act.classCode. This is why the structure of ActClass domain should be reflected in the superstructure of the ActCode domain and then individual codes or externally referenced vocabularies subordinated under these domains that reflect the ActClass structure.