Interdependent Registries - Domain Analysis Model (DAM)

Health Level Seven Domain Analysis Model Interdependent Registries - Domain Analysis Model (DAM) Draft for Review - Initial Ballot Submission March 3rd, 2011 Page 1

TABLE OF CONTENTS: Introduction... 5 Authors... 5 Domain Analysis Model (DAM)... 6 Future Work...7 Glossary of Terms... 8 UML Notation... 9 1. Use Case Analysis... 10 1: Use Case Analysis Overview... 10 1.1 System Roles and Use Cases... 10 1.1: System Roles... 11 EHR-S... 11 OrganizationDirectory...12 PatientRegistry... 12 EnrollPatient...12 PersonDirectory...13 PractitionerRegistry... 13 ProviderOrganizationRegistry... 14 1.2 Actors... 16 1.2: Business Actors and User Interactions Overview... 16 Clinician...16 Manage Organization... 16 Patient... 17 Program Administrator... 17 Query Organization... 17 2. Interdependent Registry Interactions Analysis... 18 3. Information Analysis... 19 3.1. Provider Registry Information Model...19 3.1.1 Practitioner Registry Information Model... 19 3.1.1: Generic Provider Registry Overview Diagram... 20 3.1.1.2 Deferred Classes... 21 Animal...21 Credential...22 PersonReference... 22 Practitioner... 22 ProviderOrganization... 22 Qualification... 22 TimeBasedCriterion... 22 3.1.3 Provider Organization Registry... 23 3.1.3: Organization Registry Information Analysis... 23 OrganizationEntity...23 3.2 Patient Registry...24 3.2: Patient Registry Overview... 24 Patient... 24 3.3 Person Directory... 25 3.3: Person Directory Information...25 LanguageCommunication... 25 Person... 25 Page 2

4. Service Functional Model Analysis...26 4: Services and Interfaces Overview...26 9. Annexes... 27 Annex A: Business Use Cases... 27 Annex B: Abbreviations and Related Terms... 28 Abbreviations:...28 Related Terms...29 Annex C: UML Notation Reference...30 C.1. HL7 Version 3 and UML Considerations... 30 C.2 Information Modeling Notation Overview...34 C.2.a: Class Diagram Notation...34 C.2.b: Class Diagram Notation and HL7 Reference Information Model Example...35 AirFlight... 35 Airline... 35 Assistant...36 Co-pilot...36 FlightSchedule... 36 Operator... 37 Person...37 Pilot... 37 Replaces... 37 schedule...37 C.3 Use Case and System Interactins Notation Overview... 39 C.3.a: Use Case Notation... 39 Page 3

LIST OF FIGURES: 1. Use Case Analysis 1: Use Case Analysis Overview Diagram...10 1.1: System Roles Diagram...11 1.2: Business Actors and User Interactions Overview Diagram... 16 2. Interdependent Registry Interactions Analysis 2: Overview Interdependent Registry Interactions Diagram... 3. Information Analysis 3.1.1: Generic Provider Registry Overview Diagram Diagram... 20 3.1.3: Organization Registry Information Analysis Diagram... 23 3.2: Patient Registry Overview Diagram...24 3.3: Person Directory Information Diagram... 25 4. Service Functional Model Analysis 4: Services and Interfaces Overview Diagram...26 9. Annexes C.2.a: Class Diagram Notation Diagram...34 C.2.b: Class Diagram Notation and HL7 Reference Information Model Example Diagram...35 C.3.a: Use Case Notation Diagram... 39 C.3.b: System Interactions Diagram... Page 4

Introduction The model described in this publication contains a harmonized analysis of the registries intended to collaborate to fulfill administrative and continuity of care use cases using electronic communication between information system rather than fax, paper, or telephone communication. This analysis identifies both the business use cases and underlying technical use cases along with the information needed to support the business needs of clinicians. This model is intended to harmonize the requirements and approaches used to describe provider, patient, organization, and person registries intended to operate in concert in order to support the clinicians. This specification is based on requirements identified by Canadian erefferal project and the US Direct Project in particular as well as best practices already developed by the Ministry of Health in New Zealand. Authors This specification was developed as the result of a joint project between Patient Administration and SOA work groups: 1. Patient Administration Co-Chair Gregg Seppala, U.S. Department of Veterans Affairs 2. SOA WG Co-Chair Galen Mulrooney, U.S. Department of Veterans Affairs 6. Modeling Facilitator Ioana Singureanu, U.S. Department of Veterans Affairs 8. Publishing Facilitator Gregg Seppala, U.S. Department of Veterans Affairs Page 5

Domain Analysis Model (DAM) A Domain Analysis Model (DAM) is an abstract representation of a subject area of interest designed to provide a generic representation of a class of system or capability and to suggest a set of approaches to implementation. In HL7 a DAM is complete enough to enable the development of downstream platform-independent models: HL7 RIM-based information and service models. A DAM may also be used to constrain other standards for use in healthcare (e.g. to constrain access control markup standards). The process used to create a DAM is documented in the HL7 Development Framework (HDF). The analysis model described here is the result of analyzing stakeholder requirements from US, Canada, and New Zealand. Page 6

Future Work The following section identifies future requirements: model. 1. Complete harmonization with IHE HPD. The IHE Healthcare Provider Directory provides basic metadata that should be reflected in this Page 7

Glossary of Terms The following is a glossary of terms used throughout this model: Directory A directory is a catalog in which entities may be listed with or without their owners overt participation or even their direct knowledge. Registry A registry is a catalog whose participants must request participation, either explicitly or as a by-product of organization membership, legal action, etc. Repository A repository, in general sense, is a database where information is stored. We refer to repositories as the back-end storage for implementing registries and directories. Note that the implementation of registries and directories is out of scope for the analysis in this model. Page 8

UML Notation This document makes use of UML2 class diagrams, use case diagrams, and sequence diagrams to provide a graphical representation of the model. Please refer to Annex C for a detailed description of the notation and conventions used throughout this document. Page 9

1. Use Case Analysis This section describe the use case analysis relevant to coordinating the operation of interdependent registries in order to support the exchange of information across organizational boundaries and between providers in order to better support transfer of care, consults, and referrals in an electronic/automated workflow. 1: Use Case Analysis Overview The following diagram identifies the logical system roles and use cases each system type will implement. The use cases shown here identify the scope for this analysis model as well the related business actors and system boundaries. Figure 1: Use Case Analysis Overview 1.1 System Roles and Use Cases The following section identifies the system roles and the use cases associated with each system role. The system roles identified here are both directories that list specific entity record and registries that support specific business uses of the directory entries. 1.1: System Roles Page 10

The following diagrams identifies the system roles required to support a set of interdependent registries that work in concert to enable the exhchange of information across organizational boundaries Figure 1.1: System Roles «SystemRole»EHR-S This represents the system that the clinicians interact directly. Note that registries are accessed by information system on behalf of end-users. EHR-S: operations referpatient (patient : <<role>> <Class> Patient [In], providerorganization : <<role>> <Class> ProviderOrganizationReference [In], practitioner : <<role>> <Class> Practitioner [In] ) This operation is invoked by the EHR-S that supports referral. The request is sent to a system that Page 11

routes the request to the appropriate provider organization and/or practitioner specified by the clinician, the end-user of the EHR-S. Operation Parameters Details: EHR-S: implemented use cases ReferPatient : uml:usecase This use case is based on both US and Canadian requirements to manage patient referrals electronically. Therefore a pre-requisite of successful referral is to identify the organization and the provider who may receive the referral. «SystemRole»OrganizationDirectory This system role is intended to organize the use cases dealing with managing a generic directory of organizations that may need to accessed electronically. These organizations may be providers, payers, etc. «SystemRole»PatientRegistry This system role is intended to organize the use cases dealing with enrollment, management, and querying of patient registries. A patient is a person who receives/received healthcare services and thus this registry will reference Provider Organizations and Practitioners managed by its complementary registries. EnrollPatient The patient may be enrolled in a program (e.g. HIE, healthcare program, etc.) and in addition to the patient-specific information, the patient may need to be addressed directly either via e-mail, postal mail, telephone or through an interim Personal Health record system. The patients enrolled may agree that their information may be exchanged electronically - based on their privacy consent - with other organizations for specific purposes. These registries may need to be used in conjunction with a highly available privacy consent service. The patient may enroll using a Personal Health Record system or through a EHR-S extension capability. PatientRegistry: operations findpatient (patient : <<role>> <Class> Patient [In], matchingpatient : <<role>> <Class> Patient [Return] ) parameter. This operation finds patients that match the properties of the patient object submitted as input Operation Parameters Details: PatientRegistry: implemented use cases Page 12

Query Patient : uml:usecase This use case covers the typical queries against the Patient Registry using patient identifying traits. This use case assumes that the patient may be identified using a set of identifiers and demographic traits. If the patient is queried by identifier the registry will return either a matching record or null. If the query uses a other demographic traits, the query may return multiple partial or full matches. «SystemRole»PersonDirectory This system role represents a basic Person Directory that implements basic directory operations (e.g. manage, query) and may be reused by a patient or provider registry. PersonDirectory: implemented use cases «SystemRole»PractitionerRegistry The PractitionerRegistry system role includes the use cases dealing with the human practitioners (both licensed and unlicensed). This registry specifies the basic service functionality for managing and referencing both licensed and unlicensed people who provide healthcare-related services. PractitionerRegistry: operations findproviderbyspecialty (providerorganization : <<role>> <Class> ProviderOrganizationReference [In], practitioner : <<role>> <Class> Practitioner [In] ) This operation returns candidate provider/practitioners with a specific speciality in the geographic area managed by the registry to which the query is sent. Operation Parameters Details: PractitionerRegistry: implemented use cases Enroll Provider : uml:usecase This use case is based on Canadian referral and US Direct Project user story. Both use cases require that providers may be electronically addressed with specific information (e.g. referral, consults, transfer of care). The provider organization or individual may be enrolled in the health information exchange including the electronic referral. The enrollment requires that the provider may be addressed and be available to receive information encrypted with the provider public key issued by a digital certificate authority. This use case includes changes to the underlying directory of providers. It will add the information required for enrollment including identifiers, the program references (e.g.health information exchange) and other address information (e.g. email, digital certificate). FindProvidersByOrganization : uml:usecase This use case supports the need to identify providers who have privileges to practice their Page 13

specialty in a specific organization. ManageProvider : uml:usecase This use case is intended to specify the directory management operation similar to the IHE Healthcare Provider Directory integration profile. It is also similar to the HL7 Version 3 Healthcare Provider Topic in the Personnel Management domain. This use case includes the basic/primitive operation required to manage the provider records including adding, revising provider records in the directory. This is a technical use case. QueryProvider : uml:usecase This is the technical use cases intended to support queries based on identifiers, demographics, or speciatly/services provided. «SystemRole»ProviderOrganizationRegistry this system role specifies the Provider Organization Registry that implements specific user cases intended to support the exchange of health information (e.g. referrals, continuity of care) across organizations. ProviderOrganizationRegistry: operations findproviderorganizationbyservice (providerorganization : <<role>> <Class> ProviderOrganizationReference [In], matchingprovider : <<role>> <Class> ProviderOrganizationReference [Return] ) This operation returns candidate provider organizations capable of providing a specific healthcare service in the geographic area managed by the registry to which the query is sent. Operation Parameters Details: ProviderOrganizationRegistry: implemented use cases EnrollOrganization : uml:usecase If the organization is capable of receiving referrals or other communication on behalf of its personnel, then the organization needs to be addressed using a unique certificate and qualified identifier. This use case includes changes to the underlying directory of organizations. It will add the information required for enrollment including identifiers, the program references (e.g.health information exchange) and other address information (e.g. email, digital certificate). FindOrganizationByIdentifiers : uml:usecase This is business use case that provides that organizations may be queried based on identifiers. This use case may be invoked after a previous query (e.g. 'FindOrganizationByService') return several candidate matches. FindOrganizationByService : uml:usecase Page 14

The Direct Project and the Canadian requirements indicate that for the purposes of referring a patient, it may be necessary to identify a provider organization that can provide a certain type of medical service (e.g. behavioral health, oncology) or procedure (e.g. CAT scan). Page 15

1.2 Actors model: This section describes the business actors involved in the business use cases analyzed for this 1.2: Business Actors and User Interactions Overview This diagrams focuses on the interactions of the authenticated and authorized end-users with the boundary systems and business registries. Figure 1.2: Business Actors and User Interactions Overview Clinician This actor represents the end-user who was authenticate by the EHR System and is authorized to perform an operation such as a referral or consult with a provider from another organization. Manage Organization Page 16

This technical use case addresses the management of a directory of organization entries. Patient In those cases when the patient takes an active role in their enrollment in a program (e.g. health information exchange). Program Administrator This actor represents the clerk that manages enrollment on behalf of the program in which a provider or patient needs to be enrolled. Query Organization This generic use case addresses the need to manage the organization entries. Page 17

2. Interdependent Registry Interactions Analysis This section focuses on the interactions between registries in order to support the user's needs. Page 18

3. Information Analysis This section documents the information analysis for the interdependent registries 3.1. Provider Registry Information Model The following analysis is based on the personnel registry analysis model that represent the basis for the HL7 Version 3 Provider domain. This analysis considers only organization and human providers as licensed providers. The analysis does not address devices or animals as practitioners. Please refer the 'Open issues' section for details. 3.1.1 Practitioner Registry Information Model The following analysis is based on the personnel registry analysis model that represent the basis for the HL7 Version 3 Provider domain. This analysis considers only organization and human providers as licensed providers. The analysis does not address non-licensed human provider, devices, or animals. Please refer the open issues section. 3.1.1: Generic Provider Registry Overview Diagram The following diagram illustrates the existing requirements for provider registry and it was reviewed by the Interdepenent Registry project in December 2010. The emphasis of this analysis is on the cross-registries references required to support their deployment in an interdepent mode. Page 19

Figure 3.1.1: Generic Provider Registry Overview Diagram Animal Provider The model does not consider an animal (e.g. Assistance animal) as a provider. Page 20

3.1.1.2 Deferred Classes ): This section contains information classes considered but deemed out-of-scope (see Open Issues «LivingSubject» Class: Animal This class is out of scope for now. Page 21

«Act» Class: Credential This class is used to specify certificates, licenses, education, and experience. It may correspond to the provider's specialty. «Person» Class: PersonReference This class specifies the person attributes used to identify providers. «Role» Class: Practitioner This class is used to specify an role that uses or issues an instance of a credential. Attribute 'Practitioner.electronicCommunicationAddress' of type ' TEL' with cardinality of [1] This attribute would be required for any 'enrolled' provider who can be referenced electronically. «Role» Class: ProviderOrganization This class is used to specify an role that uses or issues an instance of a credential. It may apply to a provider organization or a person. «Act» Class: Qualification This class is used to describe education, experience, etc. «ActRelationship»TimeBasedCriterion This association class is used to capture the characteristics of the association between a position help by a practitioner and their qualifications. Page 22

3.1.3 Provider Organization Registry The following section describes the metadata required to manage provider organizations. 3.1.3: Organization Registry Information Analysis The following diagram provides a view of the clases required to support organization registries. The emphasis of this analysis is on the cross-registries references required to support their deployment in an interdepent mode. Figure 3.1.3: Organization Registry Information Analysis «Organization» Class: OrganizationEntity This class is used to specify the organization entity. Page 23

3.2 Patient Registry The following section describes the information managed by the Patient Registry. This registry manges both human and animal patients. 3.2: Patient Registry Overview The following diagram provides a view of the clases required to support provider registries. The emphasis of this analysis is on the cross-registries references required to support their deployment in an interdepent mode. Figure 3.2: Patient Registry Overview «Role» Class: Patient This class is used to specify an role that uses or issues an instance of a credential. It may apply to a provider organization or a person. Attribute 'Patient.electronicCommunicationAddress' of type ' TEL' with cardinality of [1] The patient may be addressable using electronic means in addition to the postal mail and telephone. Page 24

3.3 Person Directory The following is an analysis of the information recorded in a directory of Person entities. See the 'Glossary' for a definition/distintion between registries and directories. 3.3: Person Directory Information Figure 3.3: Person Directory Information Class: LanguageCommunication Language communication is relevant to patients and to providers. «Person» Class: Person This class specifies the person attributes used to identify providers. Page 25

4. Service Functional Model Analysis The following section describes the service behavior as set of interfaces with methods. The service specifications described here are based on the System Roles identified during the use case analysis in section 1 of this document. 4: Services and Interfaces Overview The following diagram identifies the service and the interfaces they implement to meet the requirements contained the Use Cases analyzed in this document. Figure 4: Services and Interfaces Overview Page 26

9. Annexes The following annexes Annex A: Business Use Cases This annex references the stakeholder requirements. Note that the use cases were developed collaboratively by the Patient Administration and SOA Work Group. Note: These use cases are Informative and are provided as background material. They are not being submitted in this ballot for comment for approval. The use cases have already been approved and define the scope of the model. Page 27

Annex B: Abbreviations and Related Terms This annex includes additional terms and abbreviations referenced in this document: Abbreviations: The following abbreviations are introduced by ISO/IEC 15816 : 2001: ISO/IEC International Organization for Standardization/International Electrotechnical Commission OASIS Organization for the Advancement of Structured Information Standards SOA Service Oriented Architecture Page 28

Related Terms The following is a list of terms related to registries: Electronic Health Record (EHR) According to ISO 20514, an EHR is a repository of information regarding the health status of a subject of care in computer processable form, stored and transmitted securely, and accessible by multiple authorised users. It has a standardized or a commonly agreed logical information model which is independent of EHR systems. Its primary purpose is the support of continuing, efficient and quality integrated health care and it contains information which is retrospective, concurrent and prospective. Individually Identifiable Health Information (IIHI) IIHI refers to health data that is transmitted by or maintained in electronic media or any other form or medium that can be uniquely associated with an individual. The use of this term is without respect to any jurisdiction. Individually identifiable health information (IIHI) is a subset of Protected Information. Personal Health Record (PHR) A PHR is an electronic record (not a computer system) of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared and controlled by the individual. Personal Information Personal Information is defined by European Data Protection Directive (officially Directive 95/46/EC) as any information relating to an identified or identifiable natural person ( data subject ); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity; (art. 2 a). Protected Health Information (PHI) In the United States, Health Insurance Portability and Accountability Act (HIPAA) of 1996 defines PHI as individually identifiable health information that is transmitted by, or maintained in, electronic media or any other form or medium. This information must relate to: 1. the past, present, or future physical or mental health or condition of an individual; 2. provision of health care to an individual; or 3. payment for the provision of health care to an individual. If the information identifies or provides a reasonable basis to believe it can be used to identify an individual, it is considered individually identifiable health information. Page 29

Annex C: UML Notation Reference This annex is intended to provide a summary of the relevant UML notation used to create the various views of the model: C.1. HL7 Version 3 and UML Considerations An information model is a structured specification of the information within a specific domain of interest. It expresses the classes of information required and the properties of those classes, including attributes, relationships, constraints, and states. In HL7, the scope of a domain of interest ranges from the domain of the entire system of health services to the specific context of a set of information exchanges to meet a particular identified business purpose. This model relies on the following three HL7 Version 3 (V3) standards: the Reference Information Model (RIM), abstract data types and vocabulary specifications. The HL7 RIM is a critical component and is the root of all information models and structures developed as part of the V3 development process. The RIM consists of classes assigned to one or more subject area packages. Attributes, Relationships, and State Machines are associated with the classes. The following is a summary of these conventions based on the application of HL7 Version 3 design principles to the development of FHIM information domains. Note that HL7 RIM classes are color coded according their main class type or stereotype. 1. Class Each class within the RIM represents information about a concept that is documented and communicated within the health care environment. A class is an abstraction of things or concepts that are subjects of interest in a given application domain. Classes are the people, places, roles, things, and events about which information is kept. Classes have a name, description, sets of attributes, relationships, and states. The instances of classes are called objects. While classes represent categories of concepts, people and things, objects represent the individual things themselves. Classes relate to other classes in various ways. Such relationships are of two types: Generalization and Association. 2. Generalization A generalization relationship is a connection between classes (as opposed to objects). It is an association between two classes (a superclass and a subclass) in which the subclass is derived from the superclass (i.e., the superclass generalizes the subclass and the subclass is a specialization of the superclass). The subclass inherits all properties from the superclass, including attributes, relationships and states. Instances of a subclass are also instances of the superclass. In addition, the subclass has other properties that are unique to the subclass. Each subclass may in turn have subclasses of its own. Thus, a class can be both a subclass of its superclass and a superclass of its subclasses. A generalization usually has multiple specializations. However, not all of the conceptual specializations have to be represented in the model. Only the concepts that warrant special properties (e.g., attributes, relationships, states) are modeled as specialized classes. If all specializations are fully enumerated as subclasses in the model, the Page 30

superclass is considered to be an ' abstract' class. An abstract class is designed only as a parent class from which implementable child classes may be derived. Abstract classes are often used to represent abstract concepts or entities. The incomplete features of the abstract class are shared by a group of subclasses which add different variations of the missing pieces. An abstract class is never instantiated directly, but only through one of its specializations. 3. Association An association defines a relationship between a class to another class or to itself, or a connection between two objects (instances of classes). Associations in the HL7 information models have at least two ends (source and target). The target end of an association must contain an end name (endname) and the multiplicity/cardinality of the relationship. Associations may be directed (one way) or bi-directional. If the association is directed, the association line has an arrow at the target end of the association. If the association is bi-directional, both association end names must be specified (on source and target), but no arrows are included on the association. Each end of the association instance connects with one and only one object. However, one object may be associated with more than one object of the same class by the same association. In this case, multiple association instances exist, each connecting exactly two objects. The number of instances of an association that can connect to one object is regulated by the multiplicity/cardinality of the association. An association multiplicity/cardinality specifies the minimum and maximum number of objects of each class participating in the association. Multiplicity/cardinality is usually expressed as a pair of numbers on the end of the association e.g., [minimum..maximum]. The lower bound minimum is usually zero or one. The upper bound maximum is greater or equal to minimum, but is usually one, or unlimited. To specify that an association (or attribute) can repeat any number of times, the asterisk (*) notation is used. The default is [1..1] if not otherwise specified. In the UML diagrams included within this publication, multiplicity is displayed without the [square brackets] on association endnames, but within the classes themselves, the square bracket notation is used to describe the multiplicity on attributes. 4. Attribute Class attributes are the core components of an information model. The attributes are the source for all the information content of HL7. The majority of attributes are descriptive and depict aspects of classes that are important for communication between healthcare systems. Beside the descriptive attributes, there are four special kinds of attributes in the information model of note: identifier, classifier, structural and state attributes. a. Identifier Attributes: Identifier attributes can be used to identify an instance of a class. (Sometimes more than one attribute may be needed to identify an instance of a class.) Identifier attributes always have a value and the values of identifier attributes are unique among all instances of the class. Since identity is static, values of identifier attributes never change. Identifier attributes are assigned the set of instance identifier data type and generally have the name 'id' which allow for multiple identifiers to be specified. Examples of identifier attributes from the RIM include Entity.id and Act.id, which uniquely identify a particular Entity or Act respectively. In each case, the identifier attributes are a set of instance identifiers. This indicates that there may be multiple, unique identifiers for an Entity or Act. Entity identifiers might include device serial numbers, social security numbers, driver license numbers, and others. Act identifiers might include placer accession numbers, filler accession Page 31

numbers, and others. b. Classifier Attributes: The classifier attributes are a critical aspect of classes forming the backbone of the RIM (Entity, Role, Act, Participation, ActRelationship and RoleLink classes). Classifier attributes are named 'classcode'. The classifier attributes provide a great flexibility and extensibility in the information model. The vocabulary for classifier attributes include an entry for each specialization of the backbone class. For example, the vocabulary domain specified for Entity.classCode includes living subject, organization, place and material. The vocabulary domain may also include entries that are not explicitly expressed as classes in the model. For example, group is a valid Entity classcode (or specialization of Entity) but does not appear in the RIM as a class. c. Structural Attributes: Structural attributes are attributes whose coded values are needed to fully interpret the classes they classify. They are four mandatory attributes and include the classifier attribute, ClassCode described in the previous paragraph. The other three are moodcode, typecode and determinercode. All four are not found in every class (neither Acts or Entities use determinercode). There is a bounded vocabulary managed by HL7 for each use of a structural attribute. For instance, for Act, there is an actmood vocabulary. d. State Attributes: A state attribute is used in subject classes (subject classes are those that a Technical Committee designates as the central focus of a collection of messages). A state attribute contains a value that indicates the current state (named condition) of the class. A subject class must have only one state attribute. The state attribute must be assigned the data type ' set of code value' that allows multiple state flags to be specified. State attributes are named status_cd and are associated with vocabulary domains defined by HL7 that correspond to the state machine defined for the subject class. For example, Act.status_cd has the domain values which include active, suspended, cancelled, completed, and aborted. 5. Stereotypes based on HL7 V3 RIM Classes A stereotype is one of three types of extensibility mechanisms in the Unified Modeling Language (UML). They allow designers to extend the vocabulary of UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular problem domain or otherwise specialized usage. The nomenclature is derived from the original meaning of stereotype, used in printing. For example, when modeling a network we could symbols for representing routers and hubs. By using stereotyped nodes you can make these things appear as primitive building blocks. Graphically, a stereotype is rendered as a name enclosed by guillemets ( ) and placed above the name of another element. In addition or alternatively it may be indicated by a specific icon. The icon image may even replace the entire UML symbol. We will use the «guillemets» notation in this publication. 6. Terminology Binding The HL7 vocabulary model allows a coded attribute to be associated with either a coded concept, a coding system or a coding system and a value set consisting of allowable coded concepts. An important aspect of both the FHIM and HL7 models is that they explicitly link ' coded concepts' to their corresponding vocabularies. This is necessary for two reasons: first because external terminologies (such as SNOMED) already exist and must be referenced by the model; and second, because to model those terminologies in UML would be both redundant and overly complex. It is far more efficient to simply link to the existing terminology. The structural model, expressed in UML, and the terminology are two sides of the same coin; one cannot fully describe the relevant concepts without having both models. Both models must be Page 32

designed to complement each other. 7. Constraints Constraints narrow the set of possible values that an attribute can take on. Constraints include vocabulary domain constraints (e.g., this attribute must be a LOINC code), range constraints (e.g., this attribute must be a floating point number between 0 and 1), etc. While the term ' constraint' has the connotation of restricting and limiting, the objective in defining constraints is to provide guidance in the proper use of a class or attribute. 8. Act-Role-Entity Pattern The ' back-bone' of the RIM is used to express the clinical and administrative content of health care, and is comprised of six classes: Act which represents the actions that are executed and must be documented as health care is provided. Act classes are depicted in pale Red on the UML diagrams; Participation which expresses the context for an act in terms such as who performed it, for whom it was done, where it was done, etc. Participation classes are depicted in Blue on UML diagrams; Entity which represents the physical things and beings that are of interest to, and take part in health care. Entity classes are depicted in Green on the UML diagrams; Role which establishes the roles that entities play as they participate in health care acts. Role classes are depicted in Yellow on the UML diagrams; ActRelationship which represents the binding of one act to another, such as the relationship between an order for an observation and the observation event as it occurs. ActRelationships may only appear as stereotyped associations between classes; and RoleLink which represents relationships between individual roles. RoleLink classes are depicted in pale Yellow/Green on UML diagrams. Three of these classes Act, Entity and Role are further represented by a set of specialized classes or sub-types. Page 33

C.2 Information Modeling Notation Overview This section is intended to provide an overview of the Unified Modeling Language (UML) used throughout the FHIM to describe the information contained within the Domain Analysis model. C.2.a: Class Diagram Notation The following diagram illustrates how the classes in the model are related to each other. Figure C.2.a: Class Diagram Notation C.2.b: Class Diagram Notation and HL7 Reference Information Model Example Figure C.2.b shows how the UML graphical notation elements for class diagrams (e.g. class, associations, attributes) are used to represent a specific set of data (e.g. air flight scheduling and operation) using the HL7 Version 3 Reference Information Model (RIM) pattern and associated conventions specified by the FHIM model. Note that the HL7 RIM classes are color coded according their main class type or stereotype. Entities play a Role (patient, provider, person, etc.) as they participate in Acts (planned or unplanned events or actions). A Participation is an association between an Act and a Role. The Entity playing the Role is the actor. Each Entity involved in an Act is linked to the Act by one Participation-instance. Entities are depicted in green, Roles in yellow, Acts in light red and Participation in blue. A description for additional HL7 Version 3 stereotypes are included in the description of the illustrative classes and attributes included in the diagram below. Page 34

Figure C.2.b: Class Diagram Notation and HL7 Reference Information Model Example «Act» Class: AirFlight This class represents an example 'Act' class declaration as indicated by the stereotype «Act». The HL7 Version Reference Information Model specifies the attributes of any classes intended to as 'a record of something that is being done, has been done, can be done, or is intended or requested to be done. For example, in this case an Act class is used to document an air flight. Attribute 'AirFlight.effectiveTime' of type ' PointInTime' with cardinality of [0..1] This is an example attribute declaration. As seen here the attribute name is 'effectivetime' and the type of that attribute is 'PointInTime'. PointInTime is a concrete/implementable class defined in the FHIM Datatypes package. The Class notation identifies that PointInTime is a UML class. FHIM domain models reuse the data types defined the HL7 Abstract Data Type specification. The stereotype «TS» specifies that the PointInTime class uses the extensions required for an HL7 TS abstract data type. The [0..1] notation specifies the cardinality/multiplicity allowed for the effectivetime attribute by specifying the minimum and maximum number of occurrences for this attribute (e.g. minimum 0 and maximum 1 in this case). To specify that an attribute or association can repeat any number of time, the * notation is used for example [0..*] would specify that a an attribute may be omitted or it may be repeated without a predefined limit. The Default is a cardinality is [1..1] if not otherwise specified. Association 'AirFlight.flightSchedule' of type ' FlightSchedule' with cardinality of [1] This represents an association of an AirFlight to a FlightSchedule. The association will appear as a property of a class (AirFlight) and named for the far end of the association. «Organization» Class: Airline This class represents an entity which is defined as 'a physical thing, group of physical things or an Page 35

organization capable of participating in Acts while playing a specific role'. The Organization stereotype is a specialization of an Entity class and represents a formalized group of persons or other organizations with a common purpose and the infrastructure to carry out that purpose. «RoleLink»Assistant The HL7 Version 3 definition for the RoleLink stereotype is a connection between two roles expressing a dependency between those roles and permitting the authorization or nullification of a dependent role based on status changes in its causal or directing role.' This association class describes a type of relationship between roles (not between people or other entities). People (or other Entities) are primarily related by the player/scoper relationships for player's Role and more generally through their interactions (i.e. their participations in acts). The associations of RoleLink are source (Co-pilot) and target (Pilot). An association class is rendered by a dashed line from the association to the class rectangle. Each link in the association is an object of the association class. «Role» Class: Co-pilot This class illustrates how a role (specified by the «Role» stereotype and color coded according to the HL7 RIM convention) is specified in an information model. A role is specified in the HL7 Version 3 RIM as 'a competency of the Entity that plays the Role as identified, defined, guaranteed, or acknowledged by the Entity that scopes the Role'. «Act» Class: FlightSchedule This is an example act class that is used to specify the properties of a flight schedule. Association 'FlightSchedule.airFlight' of type ' AirFlight' with cardinality of [1] This represents an association of a FlightSchedule to an AirFlight. The association will appear as a property of a class (FlightSchedule) and named for the far end of the association. Attribute 'FlightSchedule.airlineCode' of type ' Code' with cardinality of [1] Vocabulary Binding: Code System: AirlineCodeSystem, Code System Id: 1.2.4.78.43.1 (Airline Codes for Scheduling) May 2010 Value Set: AirlineCodeValueSetMay 2010, Value Set Id: 1.2.4.78.43.2 Concept Domain: Airline This is an example coded attribute with an identified binding to a coding system. In this case, it represents the codes assigned to various airlines which can then be associated to a particular flight schedule. If the coding system is not specified here it may be specified runtime. This example shows how a coding system, coded concept, and value set may be assigned to a coded attribute. Note that if only a coding system is specified, then the graphical representation for the vocabulary binding will identify the coding system (preceded by the prefix 'C:' on the diagram). If however, a specific value set is assigned, then the value set will be identified on the class diagram (preceded by the prefix 'V:'). Page 36

«Participation»Operator The HL7 Version 3 definition for Participation class is an association between an Act and a Role. The Entity playing the Role is the actor. In this example, the Entity Pilot is participating in the Act of an AirFlight in the Role of operator of an AirFlight. A Participation represents performance of an Act. «Person» Class: Person This is an entity class with a stereotype of «Person». Other entity stereotypes describe other types of physical objects: materials, organizations, etc. In UML stereotypes are used to specify extensions. The stereotypes used in this sample diagram are based on the HL7 RIM profile for UML developed by the Open Health Tools MDHT project. «Role» Class: Pilot This class is used to specify the role of pilot in relation to an scheduled flight. Association 'Pilot.player' of type ' Person' with cardinality of [0..1] The association to the entity (Person) that plays the role specified by the 'Pilot' role class is identified by the association end. This notation indicates that the entity Person is played by the Role Pilot. Association 'Pilot.scoper' of type ' Airline' with cardinality of [0..1] The association to the entity (Airline) that defines the role specified by the 'Pilot' role class is identified by the association end. This notation indicates that the entity Airline scopes the role of the entity Person played by the Role Pilot. «ActRelationship»Replaces This association class represents an example ActRelationship that used to associate two FlightSchedule instances. «ActRelationship»schedule This ActRelationship describes the relationship between FlightSchedule and AirFlight. ActRelationship is a directed association between a source Act and a target Act (in this case it is a bi-directional association) as specified by the HL7 V3 RIM. The relationships associated with an Act are considered properties of the source act object. This means that the author of an Act-instance is also considered the author of all of the act relationships that have this Act as their source, (though not necessarily of the target Acts of those relationships). There are no exceptions to this rule. The meaning and purpose of an ActRelationship is specified in the ActRelationship.typeCode attribute. Every ActRelationship instance is like an arrow with a point (headed to the target) and a butt (coming from the Page 37

source). The functions that source and target Acts play in that association are defined for each ActRelationship type differently. For instance, in a composition relationship, the source is the composite and the targets are the components. In a reason-relationship the source is any Act and the target is the reason or indication for the source-act. Page 38

C.3 Use Case and System Interactins Notation Overview The following is a brief summary of the UML Use Case Diagram notation used to describe the information contained within this document. C.3.a: Use Case Notation Figure C.1.a shows the use of the UML diagram to identify actors, systems and use cases. As seen here, the actor uses a capability implemented by a system. The capabilities supported by the system are directly based on the business use cases analyzed as a part of the domain analysis. Use cases that require interoperability are further elaborated and described using sequence diagrams. Figure C.3.a: Use Case Notation Page 39