Download
1 / 40
400 likes | 525 Views
HITSP Data Architecture Proposed Bottom Up Approach to Constructing an Information Model
E N D
HITSP Data Architecture Proposed Bottom Up Approach to Constructing an Information Model A Health IT Business Architecture can be modeled as clinical stakeholders and their workflow-orchestration of system-functions, defined by the HL7 EHR System Functional Model. HITSP Capabilities group and specify system roles, information exchanges and system interfaces to support one-or-more system functions with standards-based data models and standards-based interface specifications, which may be implemented as services. An Information Model, for aproject or enterprise, can be created from the capability data models of a Business Architecture, categorized using the HL7 RIM foundation classes. 13 Nov 09 | Version H, last updated 22 Nov 09, Current version available at http://hssp.wikispaces.com/Reference+Architecture Nancy.Orvis@tma.osd.mil Stephen.Hufnagel.ctr@tma.osd.mil
HITSP Data ArchitectureTable of Contents BACKGROUND: HITSP Harmonization Framework Overview 1- 4 HITSP Data Architecture 6-14 HL7 Reference Information Model 15 Summary 16 Building an Information Model for a Business Architecture 17-20 BACKUP SLIDES EXAMPLE: HITSP C154 Data Dictionary entry for Person 22-25 Assumptions: Framing the issue on Data Dictionary 26 Requirements: Framing the issue on Data Dictionary 27 Framing the issue on Data Dictionary 28-31 Key HITSP Reference Documents 32-33 HITSP Constructs for Eligibility & Authorization 34 Six HL7 RIM Foundation Classes 35-38 Basic UML Legend 38
HITSP Harmonization Framework IS = Interoperability Specification Addressing Business Needs Available for Independent Implementation Providing Infrastructure, Security, Privacy Defining Information Content Data Architecture
Observation • Implementing HITSP Specifications • ISs typically broad and complex, seldom adopted in entirety. • Capabilities and Service Collaborations intended to be the “bottom level” independently implementable constructs. • Individual Transactions, Transaction Packages, and Components too narrow. • Primary organizing logic for capabilities • Distinct business need, that could be understood by Policy and Business Analysts • Should not overlap at the business level. • To help implementer, business analyst, or policy maker “find” the right Capabilities that contain things of interest to them
EXAMPLE: HITSP/CAP141 Communicate Referral Authorization Capability
HITSP Capability Conformance • A HITSP Capability addresses a focused business need for secure interoperable Information Exchanges in support of stakeholder requirements and business processes. A Capability is defined at a level relevant to policy and business decisions. It specifies the use of HITSP constructs to address requirements and options for the information content (e.g., format, structure, vocabulary, and coding) as well as the infrastructure, Security and Privacy for the needed information exchanges. A Capability identifies two or more System Roles to address each information exchange required for the business need. • A Capability System Role is assigned the responsibility to initiate or respond to one or more information exchanges the Capability supports. System Role is an abstraction defined to enable a Capability to be implemented by many different types of systems. Example System Roles are Order Placer; Order Filler; Specimen Analyzer. • A HITSP Interoperability Specification (IS) assigns systems to one or more of a Capability’s System Roles. For a System to implement a Capability, it must implement one or more of the Capability’s System Roles. • Either an IS use or a System implementation is conformant to the Capability if, for each of the assigned Capability System Roles: • The use or implementation supports the System Role responsibilities, including all interfaces specified by the underlying HITSP constructs according to the conditions specified for the System Role. • If a Capability option is addressed, the implementation must conform to the Capability’s specifications for that option.
HITSP Documents are available at www.HITSP.org Detailed HITSP Data Architecture is available online at www.USHIK.org HITSP Data Architecture within HITSP Harmonization Framework GREEN indicates reusable elements
Data Requirements (DRs) and Exchange Contents (ECs) • ECs and DRs are unique and numbered globally for reuse and described in a reference document • ECs and DRs are Requirements that map to Design • ECs map to a single HITSP Component. A single Component may have multiple Exchange Contents mapped to it. • DRs map to one or more Data Modules defined in C154 - HITSP Data Dictionary. A Data Module may map to multiple DRs. • Relationship between ECs, DRs, and Data Elements • An EC has unique set of DRs, DRs may be used in multiple ECs • DRs have multiple data elements, data elements may appear in multiple DRs • When ECs and DRs used, constraints can be used to eliminate data elements in a DR or DRs in an EC
HITSP Data Architecture: allows HITSP to identify similar data elements used in various relevant standards and consistently constrain its expression across those standards to maximize reuse and interoperability.
HITSP Clinical Document Constructs HITSP Reuse Paradigm: With the HITSP Communication of Structured Documents Capability (HITSP/Capability 119), a CDA clinical note can be composed, from any group of C83 data modules, and then it can be communicated. Benefit is agile system interoperability.
Simplified HL7 RIM: Foundation Classes Participation Role link Act relationship Language / communication The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility) The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages [see backup slides 31-34 for details].
Summary Object Oriented Analysis (OOA), Object-Oriented Design (OOD), Component-based Architectures (CA) and Service Oriented Architecture (SOA) encapsulate data and bind Methods (e.g., functions, actions) to data. The HL7 Reference Information Model (RIM) categorizes and relates Entities (data), Roles and Actions (e.g., Methods, Functions). The HL7 EHR System Functional Model (EHR-S) categorizes, relates and provides requirements for System Functions (e.g., methods, Actions) HITSP defines a data architecture to support its Capabilities (e.g., Information Exchanges, System Roles, System Interfaces) CONCLUSION: We can create an Information Model (IM) using RIM class categorization of the HITSP Data Architecture elements (e.g., RIM Entities), HITSP Capability System Roles (e.g., RIM Roles) and HL7 EHR-S FM System Functions (e.g., RIM Actions).
Building an Information Model for a Business Architecture A HITSP Capability (CAP) is an implementable business service that specifies interoperable Information Exchanges between systems using HITSP constructs. A Capability supports stakeholder requirements and business processes, information content, communications and associated secure infrastructure [HITSP TN904]. A Health IT Business Architecture (BA) can be modeled as clinical stakeholders and their workflow-orchestration of system-functions, defined by the HL7 System Functional Model. HITSP Capabilities group and specify system roles, information exchanges and system interfaces to support one-or-more system functions with standards-based data models and standards-based interface specifications, which may be implemented as services. An Information Model, for aproject or enterprise, can be created from the Capability data models of a Business Architecture, categorized using the HL7 RIM foundation classes.
Business ArchitectureSpecificationUsing HL7-EHR-S FM, HL7-RIM and HITSP Capabilities Slide 18
Putting it all together For Project Information, see http://hssp.wikispaces.com/Reference+Architecture Slide 19
Backup EXAMPLE: HITSP C154 Data Dictionary entry for Person Assumptions: Framing the issue on Data Dictionary Requirements: Framing the issue on Data Dictionary Framing the issue on Data Dictionary Key HITSP Reference Documents HITSP Constructs for Eligibility & Authorization HL7 RIM 6 Foundation Classes Basic UML Legend
HITSP C154 Data Dictionary Entry for Person (1 of 4) The personal information module contains the name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of the person. See the HL7 Continuity of Care Document Section 2.5 for constraints applicable to this module. Table 2‑3 Person Information Data Mapping Table – Definitions
HITSP C154 Data Dictionary Entry for Person (2 of 4) Table 2‑4 Person Information Data Mapping Table – Definitions Patient Information Event Entry
Framing the issue on Data Dictionary Assumptions • Different subject areas (e.g., Population vs Emergency Responder vs Admin/Finance vs IS01) have need for differing levels of data elements (e.g., vital signs for Provider, blood pressure for population, systolic blood pressure for clinical research). • Different standards have similar data elements but • Respond to different requirements (e.g., business, level of representation, …) • May have representational or intensional definitions that differ
Framing the issue on Data Dictionary - Suggested requirements based on assumptions • A master dictionary lists all data elements – it is C154 • Subject areas can look at just their subset of the data elements – more complex issue to be discussed • Traceability is provided to identify where data elements are used – more complex issue to be discussed • Users • HITSP developers and SDOs • End-users of HITSP specifications, such as • Users, implementers, and integrators mof EHRs and other Health IT Systems • Developers of clinical practice developing guidelines • Policy-makers and influencers with respect to interoperable Information Exchange,
Framing the issue on Data Dictionary Questions (1 of 4) • While different levels of detail should be permitted, are there levels where vocabulary should take over? • For example, vital signs is a collection of observations of which Blood Pressure is one. Vocabulary can deal with some finer details. We don’t want the HITSP data dictionary to become as detailed as LOINC (which contains over 30,000 elements). • HITSP Data Dictionary is a mapping tool meant to harmonize across standards, not replace the standards. Should definitions be at a higher level than SDO definitions to deal with different representational and detailed definitions?
Framing the issue on Data Dictionary Questions (2 of 4) • Enabling subject areas to look at their subset of Data Dictionary is inconsistent with current Word approach. • Each data dictionary element can be classified/categorized in a number of different ways but current HITSP Data Dictionary is a Word Document with inherent sequential/hierarchical approach. • Should we have the HITSP Data Dictionary capitalize on a registry such as USHIK to enable “slicing and dicing” by various viewpoints? • Should we focus on data elements used by HITSP or look for a harmonized approach across relevant standards bodies and attempt to involve the SDOs in supporting that Data Dictionary?
Framing the issue on Data Dictionary Questions (3 of 4) • For traceability between data elements and where used in HITSP Components: • Is it sufficient for the Data Dictionary to identify what HITSP data element is used in what Component, or must it identify which corresponding standard’s version of that data element? • Should the Data Dictionary use a coherent standard (e.g., RIM) as the target for definition across HITSP? • The Data Dictionary does not use a coherent standard (e.g., RIM) as the target for definition across HITSP, it harmonizes 4 key data dictionaries - X12, NCPDP, HL7 V2 and HL7 RIM. Is this sufficient and appropriate?
Framing the issue on Data Dictionary Questions (4 of 4) • Should we focus on data elements used by HITSP or look for a harmonized approach across relevant standards bodies • Current focus is on data elements identified by Harmonization Requests, since business requirements necessary to identify the terms needed in the data dictionary. This is much more constrained effort in time and resources than the broader harmonization effort. • Should the broader harmonization effort should be continued in discussions between HITSP Foundations and the SCO? • Should we have a precedence rule to assert where to look first, second, … in some alternative areas • Is there a need for exceptions to some of these rules?
HITSP Data Architecture Component Constructs • C80 -Clinical Document and Message Terminology ComponentThe Clinical Document and Message Terminology Component defines the vocabularies and terminologies utilized by HITSP specifications for Clinical Documents and Messages used to support the interoperable transmission of information. • C83 - CDA Content Modules ComponentThe CDA Content Modules Component defines the content modules for document based HITSP constructs utilizing clinical information. These Content modules are based on IHE PCC Technical Framework Volume II, Release 4. That technical framework contains specifications for document sections that are consistent with all implementation guides for clinical documents currently selected for HITSP constructs. • C154 - HITSP Data DictionaryThe HITSP Data Dictionary defines the library of Data Elements that may be used by HITSP constructs in standards based exchanges. The Data Elements are organized into modules to simplify navigation, such as Medications, Advance Directives, Immunizations, etc. Available at www.HITSP.org
Key HITSP Technical Notes • TN901 - Technical Note for Clinical DocumentsThe Technical Note for Clinical Documents serves as the top-level reference for the HITSP constructs using the HL7 Clinical Document Architecture (CDA) Release 2.0. It includes a design map of existing standards and specifications that are used to meet the stated requirements of the AHIC Use Cases. As additional Use Cases are provided to HITSP, the Technical Note will be updated to address consequent updates to the design and relationship of the associated HITSP constructs. • TN903 - Data Architecture Technical NoteThe HITSP Technical Note describes the HITSP Data Architecture and the related processes and tools that HITSP uses to identify the data elements, templates and value sets used in Information Exchanges. It explains how within HITSP Specifications: base and composite standards are related to the data architecture: data elements are harmonized across various standards: constraints are applied within HITSP Specifications: and metadata registries support development and implementation. • TN904 - Harmonization Framework and Exchange Architecture Technical NoteThe Harmonization Framework and Exchange Architecture (HF&EA) Technical Note (TN) defines the terms, concepts, relationships, and associations that are realized in the artifacts that comprise the primary work product of the Panel, e.g., an Interoperability Specification (IS), Capability (CAP), Component (C), Transaction (T), Transaction Package (TP) and Service Collaboration (SC). Further, it organizes the terms and concepts into a HITSP model based on information exchanges specific to data, context, business process, and workflow. The Exchange Architecture defines the fundamental topologies that can be used in implementing the HITSP Interoperability Specifications in configurations such as EHR systems directly connected or connected to Health Information Exchanges (HIEs). Available at www.HITSP.org
HITSP Constructs for Eligibility & Authorization • CAP140 - Communicate Benefits and EligibilityThis Capability addresses interoperability requirements that support electronic inquiry and response about a patient’s eligibility for health insurance benefits. The information exchanged includes the following: • A patient’s identification (e.g., name, date of birth, and the health plan’s member identification number) • Communication of a member’s status of coverage and benefit information and financial liability • Access to information about types of services, benefits and coverage for various medical care and medications This Capability provides clinicians and healthcare providers with information about their patient’s health insurance coverage and benefits. • CAP141 - Communicate Referral AuthorizationThis Capability addresses interoperability requirements that support electronic inquiry and response to authorizing a patient (health plan member) to be referred for service by another provider or to receive a type of service or medication under the patient’s health insurance benefits. The Capability supports the transmittal of a patient’s name and insurance identification number with the request for the type of service. It also includes the following optional requirements: • Identification of the type of service or medication requested for benefit coverage (does not guarantee payment by insurance provider) • Communication of a referral notification number or authorization number from the Payer System to the Provider System It provides clinicians and pharmacists with information about each patient’s medical insurance coverage and benefits. It may include information on referral or authorization permission. • T68 - Patient Health Plan Authorization Request and Response TransactionThe Patient Health Plan Authorization Request and Response Transaction provides a mechanism for a healthcare provider (other than a retail pharmacy) to request approval from a health plan to authorize certain healthcare services, when required by the patient’s health plan contract. The information exchanged includes, but is not limited to, approval status for coverage, allowed service provider(s), and certification dates for services that are included in the patient’s health plan benefits. The response from the health plan indicates that the health plan has determined that the particular service(s) will or will not be covered, and what is the level of coverage if that information is available from the health plan. • T79 - Pharmacy to Health Plan Authorization Request and Response TransactionThe Pharmacy to Health Plan Authorization Request and Response Transaction provides a mechanism for a pharmacy to request approval from a health plan to authorize certain healthcare products and services, as required by the patient’s health plan contract. The health plan responds to the pharmacy’s request for the approval of products and/or services. The information exchanged includes, but is not limited to, approval status for coverage of the products and/or services that are included in the patient’s health plan benefits and/or authorization limitations. Available at www.HITSP.org
Definitions of the Six Core Rim Classes • Act - An Act is an action of interest that has happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. An act is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. An Act instance is a record of such an intentional action. • Entity - An Entity is a class or specific instance of a physical thing or an organization/group of physical things capable of participating in Acts; an artifact. This includes living subjects, organizations, material, and places. The Entity hierarchy encompasses human beings, organizations, living organisms, devices, pharmaceutical substances, etc. It does not include events/acts/actions, the definition of things, or the roles that things can play (e.g. patient, provider). • Role - A Role is a categorization of competency of the Entity that plays the Role as defined by the Entity that scopes the Role. An Entity, in a particular Role, can participate in an Act. Note that a particular entity in a particular role can participate in an act in many ways. Thus, a Person in the role of a practitioner can participate in a patient encounter as a rounding physician or as an attending physician. The Role defines the competency of the Entity irrespective of any Act, as opposed to Participation, which is limited to the scope of an Act. Each role is 'played' by one Entity (the Entity that is in the role) and is usually 'scoped' by another. Thus the Role of 'patient' is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, the employer scopes an Employee role. • Participation - A Participation is an association between a Role and an Act. The Participation represents the involvement of the Entity playing the Role with regard to the associated 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. Participation is limited to the scope of the Act, as opposed to Role, which defines the competency of an Entity irrespective of any Act. • Act_relationship - An Act_relationship is an association between a pair of Acts. This includes Act to Act associations such as collector/component, predecessor/successor, and cause/outcome. The class has two associations to the Act class, one named "source" the other named "target". .... Since the relationships associated with an Act are considered properties of the source act object. That means that the originator of the information reported in an act object is not only responsible for the attribute values of that object, but also for all its outgoing relationships. The rule of attribution is that all act relationships are attributed to the responsible actor of the Act at the source of the Act_relationship (the "source act".) • Role_link - A Role_link is a connection between two roles expressing a dependency between those roles.
The Rationale Behind the RIM's Design • The HL7 RIM identifies two major "high-level" concepts that are fundamental to understanding the world of healthcare information: intentional "actions" or "services" (Acts), and "people, places and things" that are of interest in the world of healthcare (Entities). • The concept "Act" (and its subclasses) represents all of the intentional actions documented by a healthcare professional in either a clinical or administrative context. The presence of the Act class as one of the core RIM classes is a reflection of HL7's view that "from a messaging/system communication perspective, healthcare consists of a series of attributed, intentional actions."" Thus, instances of the class/concept Act include both clinical observations (e.g. patient temperature) and interventions (e.g. administer medication), and administrative actions (e.g. admit patient). Note that in this "act-centered" view of healthcare, the act of an observation takes on two seemingly contradictory meanings: "the act of recognizing and documenting a particular fact," and "the description of the thing observed." In other words, an instance of an Observation Act represents both the attributed act of observing and the results of the observation. Both aspects of this expanded definition of an Observation Act are captured by specific attributes of the class Act or its subclass Observation. • The concept "Entity" (and its subclasses) includes all living subjects (e.g. persons, animals), organizations (e.g. formal and informal), materials (e.g. durable and non-durable goods, food, tissue, containers,), and places that may be of interest in a healthcare messaging context. It should be noted that the concept of "collection of information" (e.g. a medical record) is not a instance or subclass of Entity, but is instead considered as a collection of attributed Acts. • The RIM places two additional classes - Role and Participation - between Act and Entity. The Role class models several important concepts that are prevalent in the healthcare delivery domain. First, Role captures the fact that the various "static" entities may "temporally" assume one or more "roles" (e.g. patient, primary care physician, responsible party, Registered Nurse etc.) in a particular healthcare context. Second, the concepts of "capability" (e.g. Advanced Cardiac Life Support) and "certification" (e.g. Licensed Practical Nurse) are also modeled using instances of the Role class. Finally, careful examination of the multiplicity (0..1) and names (is_scoped_by, is_played_by) of the two associations between Entity and Role reveals that the Role class can be used to "group" instances of Entity. • It is important to distinguish the concept of Entity-in-a-Role from the Act-specific concept of "the function-based role played by an Entity-in-a-Role in the context of a specific Act." These semantics are modeled using instances of the Participation class. For example, an Anesthesia Resident (Entity-in-a-Role) administers anesthesia (Participation as "provider" in the Act "administer anesthesia") to a patient (Participation as a 'recipient" in the Act "administer anesthesia." Note that the absence of a direct association between the Participation and Entity classes is a manifestation of an underlying HL7 RIM assumption that all instances of Entity involved in an Act are participating in the Act in a particular Role. • In summary, both the Participation and the Role classes are necessary to fully model the complex semantics that exist between instances of Entity and Act, and a concise summary of the HL7 RIM's view of healthcare can be stated as follows: At the highest level of abstraction, healthcare consists of a series of intentional, attributed Acts performed to, by, on behalf of, utilizing or in some way involving one or more instances of a Participating ("as primary provider," etc.) Entity-in-a-Role ("John Smith in the role of Patient"). • The two remaining classes in the RIM - Act_relationship and Role_link - are used to "associate" or "link" instances of the class with which it is associated. The class Role_link is used to establish a "dependency-based link" (e.g. accountability, chain-of-trust, etc.) between two instances of an Entity-in-a-Role. The semantics of Act_relationship are explained below.
Linking Acts Together: The Semantics of Act_relationship An understanding of the semantics and application of Act_relationship begins with, an understanding of the "fractal" or "robotic arm" nature of a set of Acts. This perspective is, in turn, best viewed from the overarching framework of the categorization of three types of "collecting relationships" represented by instances of Act_relationship: whole/part (e.g. lab or test batteries (see the discussion of the "robotic arm" below); rule-based (e.g. care plans, protocols, etc.); and cognitive actions (e.g. judgment, renaming, replacement, subsumption, supported by/reason for, etc.). Regarding the "fractal" or "robotic arm" discussion, As mentioned above, instances of Act_relationship can be used to model the "fractal" or "robotic arm" notion behind a "whole/part" relationship. Consider a surgical procedure such as a laparoscopic cholecystectomy. The procedure may be represented as a single instance of Act, or, alternatively, as a "collection" of (partially ordered) instances of Act each of which is a finer granularity than the entire procedure, e.g. obtain consent, administer pre-op medication, administer anesthesia (throughout the surgical procedure), make the incision, etc. In turn, for any of the more finely granulated actions just mentioned, further granulation/decomposition may occur. The degree of granularity is clearly dependent on the context of the action(s) and the interest level/perspective of the party performing (or not performing) the decomposition. Figure 1 shows a "surgeon's-eye view" of some of the instances of Act and Act_relationship for the exemplar cholecystectomy.. [Example of sequential plan construction for laparoscopic cholecystectomy. Edged boxes are Act instances (all in definition, or 'master' mood.) Rounded boxes are Act_relationship instances of type: has-component. The sequence_nbr attribute orders the relationships into a sequence. Each act can in turn be decomposed into plan-components.] In summary, the classes Act and Act_relationship have been designed to allow for representing the rich semantics of each of three types of collections mentioned above at whatever coarseness or fineness of granularity is appropriate to the specific messaging context. In addition, the various of types of collections and levels of granularity represented by instances of Act_relationship can (and will) be expected to be used to collectively capture the complex semantics of clinical reasoning, e.g. an instance of Act_relationship (e.g. "supported by") could be used to form a link from an instance of an observation Act representing a specific lab test (e.g. sedimentation rate = 48 to an instance of an observation Act representing a particular diagnosis (e.g. DX = Systemic Lupus Erythematosus). From: Version: V 01-14 (3/9/2002) ModelID: RIM_0114 [ http://www.hl7.org/library/data-model/RIM/C30114\rim.ht
