Bidirectional Services eReferrals

HL7_DAM_BSER_R1_I1_2018SEP

HL7 Domain Analysis Model: Bidirectional Services eReferrals (BSeR), Release 1

September 2018

HL7 Informative Ballot

Sponsored by:

Public Health and Emergency Response Work Group

Copyright © 2017 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is

strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health

Level Seven International. Reg. U.S. Pat & TM Off.

Use of this material is governed by HL7's IP Compliance Policy.

http://www.hl7.org/legal/ippolicy.cfm?ref=nav

Page 2 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1

© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot

IMPORTANT NOTES:

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm. If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material. Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with, the foregoing. Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability. Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology Owner/Contact

Current Procedures Terminology (CPT) code set

American Medical Association http://www.ama-assn.org/ama/pub/physician-resources/solutions-managing-your-practice/coding-billing-insurance/cpt/cpt-products-services/licensing.page?

SNOMED CT International Healthcare Terminology Standards Development Organization (IHTSDO) http://www.ihtsdo.org/snomed-ct/get-snomed-ct or [email protected]

Logical Observation Identifiers Names & Codes (LOINC)

Regenstrief Institute

International Classification of Diseases (ICD) codes

World Health Organization (WHO)

NUCC Health Care Provider Taxonomy code set

American Medical Association. Please see 222.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

http://www.ihtsdo.org/snomed-ct/get-snomed-ct

http://www.ihtsdo.org/snomed-ct/get-snomed-ct



Table of Contents

BSeR Domain Analysis Model ........................................................................................................................................... 4 Introduction ..................................................................................................................................................................... 4

Background ................................................................................................................................................................ 4 Project Scope ............................................................................................................................................................. 5 BSeR Use Case Definitions ....................................................................................................................................... 5 BSeR Use Case Actors ............................................................................................................................................... 6 Project Approach........................................................................................................................................................ 8

BSeR FHIR Implementation Guide .............................................................................................................................. 8

BSeR CDA Implementation Guide ................................................................................................................................ 9

BSeR DAM Activity Model .......................................................................................................................................... 10

1.0 Service Provider Selection ..................................................................................................................................... 11 2.0 Service Provider Referral ................................................................................................................................... 12 3.0 Referred Patient Intake ....................................................................................................................................... 13 4.0 Referral Service Provisioning ................................................................................................................................ 14 5.0 Service Outcome Reporting ............................................................................................................................... 15

BSeR Information Model ............................................................................................................................................. 16

1.0 Patient .................................................................................................................................................................... 19 2.0 Patient Insurance .................................................................................................................................................... 20 3.0 Provider ................................................................................................................................................................. 21 4.0 Patient Referral ...................................................................................................................................................... 22 5.0 Patient Health Record ............................................................................................................................................ 23 6.0 Health Record Entry Participant ............................................................................................................................ 24 7.0 Patient Health Summary ........................................................................................................................................ 25

BSeR Data Elements ..................................................................................................................................................... 26

Requirement Report - Details 25 October, 2019



BSeR Domain Analysis Model Introduction This specification is a conceptual model of the functional and information requirements of Bidirectional Services eReferrals (BSeR). BSeR involves the exchange of information between clinical care Electronic Health Records (EHRs) and principally extra-clinical program service systems that reside in community services, lifestyle change, public health, and other organizations. It also involves the return of information from the service programs to clinical care.

The facilitation of referrals to principally extra-clinical chronic disease prevention and management is becoming increasingly important. These referrals require the exchange of specific, limited, program specific clinical care data with the extra-clinical program and the return of status and progress information to the initiating provider. Without common standards for these extra-clinical referrals, they will, individually, make divergent requests to EHR vendors or will not be able to take advantage of electronic information exchange and processable data at all. New standards approaches can facilitate the automated segmentation and delivery of program-specific data making EHR implementation much easier.

BSeR Data Exchange Standards Development Project

The BSeR Data Exchange Standards Development Project is conducted in three phases. This Domain Analysis Model specification is the primary output from phase 1, data requirements gathering and analysis. Phase 2 will make use of the BSeR DAM to develop implementation guides for using FHIR and CDA as a means of fulfilling the information exchange scenarios expressed in this DAM. The DAM and the FHIR and CDA implementation guides will be balloted as Health Level Seven (HL7) standards for trial use (STU) and informative specifications, respectively.

Health Level Seven defines a Domain Analysis Model (DAM) as:

“A representation of the static and/or dynamic semantics of a subject-area-of-interest (i.e., domain) in a

manner that enables harmonization of the various perspectives of the stakeholders in the domain while also

providing the foundations required to create logical platform-independent and implementation platform-

dependent models of information artifacts and/or applications whose semantics involve concepts from the

domain"

In keeping with that definition, the BSeR DAM includes both an information viewpoint and a dynamic viewpoint. The

information viewpoint provides the static semantics of the data classes and information objects of interest to the BSeR

domain. The dynamic viewpoint provides the dynamic semantics of the use cases and process flows of interest to the

BSeR domain.

Background The requirements outlined in this specification were driven primarily by the needs of multiple community and social

services and lifestyle change programs at local and state levels as well as programs in the National Center for Chronic

Disease Prevention and Health Promotion (NCCDPHP), a division within the Centers for Disease Control and Prevention

(CDC). Chronic diseases—such as heart disease, cancer, chronic lung diseases, stroke, and type 2 diabetes—account for

most deaths in the United States and globally. They are the major causes of sickness, disability, and health care costs in

the nation. Chronic diseases are responsible for 7 in 10 deaths among Americans each year and most of health care costs.




Chronic diseases are common, costly, and debilitating, and they can often be prevented. By choosing healthy behaviors—

like avoiding tobacco, eating and drinking healthy foods and beverages, and getting regular physical activity and enough

sleep—people can reduce their chance of getting a chronic disease or improve their health and quality of life if they

already have a chronic disease.

Project Scope The goal of the BSeR project is to streamline and enhance the efficacy of the exchange of health information between healthcare providers and community services organizations involved in addressing chronic health conditions by establishing program specific information exchange standards for electronic referrals and referral outcome reporting. Figure 1 - BSeR Use Case Diagram reflects the scope of the BSeR project.

Figure 1 - BSeR Use Case Diagram

The five use cases depicted in Figure 1 - BSeR Use Case Diagram define the scope of the Requirements Gathering and Analysis performed and documented in this Domain Analysis Model Specification. Use Case 2.0 Service Provider Referral and 5.0 Service Outcome Reporting are the scope of the information exchange needs to be addressed by the HL7 STU BSeR CDA and FHIR Implantation Guides.

BSeR Use Case Definitions

The five uses cases of the BSeR DAM are defines as follows:

1.0 Service Provider Selection

In this use case, the patient works in conjunction with a service provider locator and referring provider to identify, evaluate, and select a service provider based upon the health needs of the patient, candidate service provider profiles, referring provider recommendations, and patient preferences.

2.0 Service Provider Referral

In this use case, the referring provider works in conjunction with the patient, service provider, and referral gatekeepers to assemble relevant clinical data, obtain necessary consents and authorizations, prepare referral instructions, and submit a service referral.

3.0 Referred Patient Intake




In this use case, the service provider works in conjunction with the patient, referring provider, and referral gatekeepers to conduct an initial health assessment, confirm patient eligibility, obtain necessary consents and approvals, prepare a plan of treatment, and report the outcome of patient intake to the referring provider.

4.0 Referral Service Provisioning

In this use case the service provider works in conjunction with the patient and referring provider to render the requested services in accordance with the agreed to plan of treatment, record objective and subjective outcomes of services provided along with patient-reported outcomes, update the plan of treatment as needed, and report interim and final service provisioning outcomes to the referring provider.

5.0 Service Outcome Reporting

In this use case, the service provider engages in preparing feedback for the referring provider regarding the patient intake outcome, referral service provisioning, and final referral outcome. Service outcome reporting practices vary by disease area, service provider capabilities, and practice, and referring provider requests. The referral instructions from the referring provider are a major determiner of the reporting practices followed. Service outcome reporting fall into three broad areas: intake, milestone/incidental, and final.

BSeR Use Case Actors The following actors have primary, secondary and contributing roles regarding their participation in the BSeR Use Cases:

1.0 Patient – This is the person with the chronic health condition that needs to be addressed by being referred to a specialist other than their routine healthcare provider.

2.0 Service Provider Locator – This is the person, organization, or system that assists in identifying, evaluating, and selection of a service provider. The service provider locator is the maintainer and provider of service provider profiles used by the patient and referring provider in the evaluation and selection of service providers.

3.0 Referring Provider – This is the medical professional responsible for the overall health and wellbeing of the patient. The referring provider can be an individual clinician, a member of a provider group, or a participant in a large healthcare system. The referring provider is the author of the referral and the recipient of referral service outcome reports.

4.0 Service Provider – This is the individual or organization responsible for providing the services requested by the referring provider on behalf of the patient. The service provider may or may not be a covered entity as defined by the U.S. Department of Health and Human Services (HHS) in the HITECH privacy provisions of the American Recovery and Reinvestment Act. Service providers include licensed and unlicensed professionals accredited to provide lifestyle behavioral health advice and interventions designed to prevent, treat, or reduce the impact of chronic disease conditions.

5.0 Referral Gatekeeper – This is the person, or more typically organization, responsible for adjudicating the appropriateness and authorization worthiness of a referral. Large health systems and other provider organizations use internal referral gatekeeper to ensure that provider referrals are in keeping with the organization's goals and objectives. Service providers use referral gatekeepers as a means of pre-screening and evaluating patients and to assist in obtaining pre-authorization from payers and other funding sources related to referrals. Payer organizations and funding sources used referral gatekeepers as a means of monitoring utilization, enforcing appropriate use criteria, and to assist in care coordination.

6.0 Health Record System – This is the Electronic Medical Record System (EMR) or Paper Chart used to encode the medical and treatment histories of patients. The BSeR Project assumes that a least one of the participants in the exchange of electronic referrals and referral outcome reports is an EMR. However, the DAM is agnostic as to what form the Health Record System takes. It presumes that in some cases the paper chart may be all that is available, especially within smaller community-based service providers. EMRs enhance the capabilities of referring providers by allowing access to evidence-based tools that can use to assist in clinical decision making and through automation streamline provider workflow.

Primary and secondary actors are involved in decision-making activities. The primary actor is responsible and accountable for the decisions made. The secondary actor is a major stakeholder in the outcome of decisions made. Contributing actors are information providers. Information provided, and decisions made by contributing actors are used as input to the larger decisions made by primary and secondary actors involved in use cases. Table 1 - Actor Roles depicts the roles played by each actor participating in the BSeR use cases.




Table 1 - Actor Roles

Use Case

Actor

Patient Service

Provider Locator

Referring Provider

Service Provider

Referral Gatekeeping

Health Record System

1.0 Service Provider Selection

Primary Contributing Secondary Contributing

2.0 Service Provider Referral

Contributing Primary Secondary Contributing Contributing

3.0 Referred Patient Intake

Secondary Contributing Primary Contributing Contributing

4.0 Referral Service Provisioning

Secondary Contributing Primary Contributing

5.0 Service Outcome Reporting

Secondary Primary Contributing




Project Approach

The requirements gathering, and analysis approach taken by the BSeR project was to conduct interviews with chronic disease programs and recognized service providers. Interviews were held with program and service representatives involved with the following health conditions: arthritis, diabetes prevention, early childhood nutrition, hypertension, obesity, and tobacco use cessation. The interviews focused on gaining an understanding of the current workflow, especially areas of the workflow that involves the inter-enterprise exchange of health information. A potential future-state workflow was used to assist in provoking out-of-the-box thinking and to solicit feedback regarding pain points and process change feasibility.

The BSeR DAM is a record of the findings and analysis stemming from subject matter expert interviews. The DAM presents a generic process flow incorporating and abstracting key aspects of each of the chronic condition program area specific workflow. Not all aspects of the process flow depicted in the DAM is applicable to all programs. Similarly, the information model portion of the DAM is comprised of a set of shared or common program data and a set of program-specific data. Data modeling was used to harmonize information requirements and to express data in the data model using an abstract conceptual framework conducive to reuse across programs and portable to existing HL7 CDA and FHIR standard data structures. Balloting this specification as an informative document is the chosen means of validating it as a specification of the requirement for all stakeholders in the BSeR community of users.

The BSeR DAM is the authoritative specification of a harmonized set of the discovered workflow and information requirements related to bi-directional services electronic referrals. The BSeR DAM is used as a foundation to design, specify, and implement BSeR information exchange using the HL7 FHIR and HL7 CDA information exchange standards. Concurrent with the development and ratification of the BSeR DAM the BSeR project created implementation guides for using FHIR and CDA as exchange mechanisms for use case 2, service provider referral; and 5, service outcome reporting.

BSeR FHIR Implementation Guide The BSeR FHIR implementation guide provides guidance for using the HL7 Fast Healthcare Interoperability Resources (FHIR) standard as an exchange format for Bidirectional Services eReferral (BSeR). It is a collection of FHIR resource profiles designed for use in information exchanges supporting service provider referral and service outcome reporting.

A key concept adopted in the design of the BSeR FHIR Profiles is the concept of parsimony. Program area referral and feedback transactions contain common transaction data and program specific data. A critical design requirement is to limit the exchange of clinical information to program areas to only that data that pertain to the program. Transaction participant data such as Patient, Referring Provider, and Servicing Provider are common to both referral and feedback transactions. The data content of each transaction type is partitioned into common and program specific data items. Some program-specific data items pertain to multiple program areas; others are specific to a single subject area. The following diagram illustrates the partitioning of the FHIR profile content into common and programs specific data items:

Common Transaction

Participant Data

Referral Transaction Data

Referral Feedback Transaction Data

Common Referral Data Items

Program Specific Referral Data Items

Common Feedback Data Items

Program Specific Feedback Data

Items

Multi-Program Specific Referral

Data Items

Single-Program Specific Referral

Data Items

Multi-Program Specific Feedback

Data Items

Single-Program Specific Feedback

Data Items




The BSeR IG FHIR profiles are all based upon the FHIR STU3 specification. Profiles from the US Core Implementation Guide are reused as a baseline for BSeR IG profiles where applicable.

BSeR CDA Implementation Guide The BSeR CDA implementation guide provides guidance for using the HL7 Clinical Document Architecture (CDA) standard as an exchange format for Bidirectional Services eReferral (BSeR). It is a collection of CDA section and entry templates design for use in information exchanges supporting service provider referral and service outcome reporting.

The BSeR CDA IG defines two document types, a service provider referral, and a service outcome report. The headers for each document type inherit from a common BSeR document header based upon the US Realm Header template specified in the HL7 Consolidated Clinical Document Architecture (C-CDA) implementation guide. Document sections and entry-level templates from the C-CDA IG are reused as a baseline for BSeR section and entry templates where applicable.

Achieving parsimony in the data content of referral and outcome documents regarding program area specific data elements was more difficult to achieve using CDA than it was with FHIR. The BSeR CDA IG makes judicious use of program-specific section and organizer templates to facilitate the partitioning of data content based upon relevant program areas. Common data are contained in the document header and section structures of the two document types. Entry level templates are clustered in program specific organizers and reused across programs for common data content.

The following diagram illustrates the design of the template hierarchy in the BSeR CDA IG:

BSeR Document Header«Record Target»Patient

«Author»Referring Provider

«Information Recipient»Referred Provider

BSeR Referral Document Header

BSeR Feedback Document Header

«Author»Referred Provider

«Information Recipient»Referring Provider

Common Referral SectionProgram Specific Referral Section

Common Feedback Section Program Specific Feedback Section

Program Specific Referral Organizers

Program Specific Feedback Organizers

Common Referral Entries Common Feedback EntriesProgram Specific Referral Entries

Program Specfic Feedback Entries

0..1 0..*

1..*

0..*

1

1

1..* 1..*

1

1..*

11

1..*

0..1

1..*


Page 10 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release

1


BSeR DAM Activity Model Figure 2 - BSeR Overall Activity Model Diagram is a high-level process flow of the entire BSeR Domain. The activities included in the model are reflective of the BSeR use cases. The activity model expands upon the use case diagram by including the flow of information and two use case actors and between use case activities.

The activity model diagram uses standard Unified Modeling Language (UML) notation1, with a little poetic license to assist in reaching a non-technical audience.

• Information flows to and from actors are typically reflected in UML activity diagrams using horizontal or vertical swim lanes to represent the actors. We decided to use the stick figure notation for the actor, traditionally reserved for use case diagrams, to represent actors and their related information flows.

• Data objects are used to represent the content of information flows to and from activities. The use of data object helps to facilitate the semantic linkage between information flows depicted in the dynamic process viewpoint and information classes depicted in the static information viewpoint of the BSeR DAM.

• Stereotype guillemets (<<…>>) include the name of the primary actor for an activity. This helps to provide context for the processes and sub-processes including in the activity diagram and extends the representation of information flows between actors.

Figure 2 - BSeR Overall Activity Model Diagram

The activities contained in Figure 2 - BSeR Overall Activity Model Diagram are further described in subsequent activity model diagrams described in the sections that follow. Each section begins with the activity process flow diagram followed by a description of the processes contained in the diagram. Actors and data objects are reused across diagram boundaries and carry the same descriptive text regardless of diagram placement.

Activities in the BSeR overall activity model are named using gerunds, verbal nouns, as a means of differentiating them from the processes in lower level process flow models that are named using active verbs followed by a noun. The nouns

1 Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed.). Addison-Wesley. ISBN 0-321-19368-7.

«Referring Provider»1.0 Service Provider

Selection

«Referring Provider»2.0 Service Provider

Referral

«Service Provider»3.0 Referred Patient Intake

«Service Provider»4.0 Referral Service

Provisioning

«Service Provider»5.0 Service Outcome

Reporting

Patient Medical Record

Service Provider Profile

Referring Provider Recommendations

Patient Preferrences

Service Provider Profile / Selected

Patient Consents

Service Referral

Relevant Clinical History

Service Treatment Plan

Service Delivery Feedback Report

Service Delivery Feedback Report /

Final


Intermediate

Treatment Plan Report / Updated

Treatment Plan Report / Intake

Unsuccessful Intake Notification

Missed Encounter Notification

Electronic Medical Record System

Patient

Referring Provider

Service Provider Locator

Serivce Provider

Referral Instructions

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»



1


used in activity process names used in the dynamic process viewpoint are consistent with nouns used for information classes in the static information viewpoint.

1.0 Service Provider Selection In this process flow, the patient works in conjunction with a service provider locator and referring provider to identify, evaluated, and select a service provider based upon the health needs of the patient, candidate service provider profiles, referring provider recommendations, and patient preferences.

Figure 1: 1.0 Service Provider Selection

1.1 Assess Patient Referral Service Requirements

1.2 Identify Candidate Service Providers

1.3 Evaluate Candidate Service Providers

1.4 Select Preferred Service Provider

ActivityInitial

Patient Referral Needs Assessment

Service Provider Profile

Service Provider Profile / Candidate

Service Provider Evaluation

Service Provider Profile / Selected

Patient Preferrences

Referring Provider Recommendations

ActivityFinal

Referring Provider


Patient



«flow»

«flow»

«flow»

«flow»



1


2.0 Service Provider Referral In this process flow, the referring provider works in conjunction with the patient, service provider, and referral gatekeepers to assemble relevant clinical history, obtain necessary consents and authorizations, prepare referral instructions, and submit a service referral.

Figure 2: 2.0 Service Provider Referral

2.1 Obtain Required Patient Consents

2.2 Assemble Relevant Cliniical History

2.6 Prepare Referral Instructions

2.7 Submit Servce Referral2.4 Request Referral Authorization

Patient Consents Patient Medical Record


Referral Authorization

Response


Service Referral

2.3 Is Pre-authorization

Required?Service Provider Profile / Selected

Serivce Provider

Referring Provider


PatientElectronic Medical Record

System

2.5 Is ReferralAuthorized?

FlowFinal

Referral Gatekeeper


Request

ActivityFinal

ActivityInitial

«flow»«flow»

«flow»

«flow»

«flow»

[Pre-authorizationis Required]

«flow»

«flow»

[Otherwise]

[Otherwise]

«flow»

«flow»

«flow»

[Referral isAuthorized]



1


3.0 Referred Patient Intake In this process flow, the service provider works in conjunction with the patient, referring provider, and referral gatekeepers to conduct an initial health assessment, confirm patient eligibility, obtain necessary consents and approvals, prepare a plan of treatment, and report the outcome of patient intake to the referring provider.

Figure 3: 3.0 Referred Patient Intake

3.4 Evaluate Patient Eligibility

3.8 Prepare Treatment Plan

3.9 Obtain Required Patient Consents

3.1 Conduct Patient Outreach

3.7 Conduct Health Status Assessment

Service Referral


Health Status Assessment Findings


Response

Eligibility Accessment

Findings

3.5 Is PatientEligible?3.6 Report Unsuccessful

Intake

3.3 Complete Intake Questionaire Intake

Questionaire / Completed

Intake Questionaire / Blank

Patient

Referral Gatekeeper

Referring Provider



Patient Consents

3.2 Is Outreachsuccessful?


ActivityInitial

ActivityFinal

3.A Report Intake Treatment Plan



FlowFinal

«flow»[Patient is eligible]

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

[Otherwise]

[Outreach isSuccessful]

«flow»

[Otherwise]

«flow»



1


4.0 Referral Service Provisioning In this process flow the service provider works in conjunction with the patient and referring provider to render the requested services in accordance with the agreed to plan of treatment, record objective and subjective outcomes of services provided along with patient-reported outcomes, update the plan of treatment as needed, and report interim and final service provisioning outcomes to the referring provider.

Figure 4: 4.0 Referral Service Provisioning


4.1 Schedule Patient Encounter Encounter /

ScheduledPatient Availability

Service Provider Availability

4.2 Is ScheduledEncounter Held?

4.3 Record Missed Encounter

Missed Encounter Notation




4.7 Update Relevant Clinical History

4.5 Perform Service Related Activity

Service Related Activity Outcome

4.6 Obtain Patient Reported Outcomes

Patient Reported Outcome /

Uninterpeted

Patient Reported Outcome / Interpeted

Patient Serivce Provider

ActivityFinal

4.4 Report Missed Encounter


Referring Provider

4.9 Provide Service Delivery Feedback

Service Delivery Feedback Report

4.8 Report Update to Treatment Plan


ActivityInitial

FlowFinal

«flow»

«flow»

[Otherwise]

«flow»

[Treatment Plan Updated]

«flow»

«flow»

[ScheduledEncounter is Held]

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»



1


5.0 Service Outcome Reporting In this process flow, the service provider engages in preparing feedback for the referring provider regarding the patient intake outcome, referral service provisioning, and final referral outcome. Service outcome reporting practices vary by disease area, service provider capabilities, and practice, and referring provider requests. The referral instructions from the referring provider are a major determiner of the reporting practices followed. Service outcome reporting fall into three broad areas: intake, milestone/incidental, and final.

Figure 5: 5.0 Service Outcome Reporting

5.1 Patient Intake Outcome Reporting

5.3 Intermediate Treatment Milestone

Reporting

5.4 Service Termination Reporting

3.6 Report Unsuccessful Intake

4.4 Report Missed Encounter

3.A Report Intake Treatment Plan

4.9 Provide Service Delivery Feedback



Intermediate


Final






Referring Provider

Serivce Provider

5.2 Treatment Incident Reporting

4.8 Report Update to Treatment Plan



ActivityInitial ActivityFinal

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»



1


BSeR Information Model

Figure 6: BSeR Information Model

Patient

birthDate: TS.DATEname: EN.PNethnicGroup: CDemailAddress: TEL.EMAILidentifier: IIpostalAddress: ADtelephoneNumber: TEL.PHONEpreferredLanguage: CDrace: CDsex: CDemploymentStatus: CDeducationLevel: CD

Patient Contact

name: EN.PNemailAddress: TEL.EMAILidentifier: IIpatientRelationship: CDpostalAddress: ADcontactType: CDtelephoneNumber: TEL.PHONE

InsuranceCarrier

name: EN.ONemailAddress: TEL.EMAILidentifier: IIpostalAddress: ADtelephoneNumber: TEL.PHONE

PatientInsurancePolicy

planName: STcoverageType: CDidentifier: IIeffectivePeriod: TS.DATE (IVL)

InsurancePolicyHolder

name: EN.PNemailAddress: TEL.EMAILidentifier: IIpatientRelationship: CDpostalAddress: ADtelephoneNumber: TEL.PHONE

Service Provider

name: EN.PNspecialty: CDemailAddress: TEL.EMAILidentifier: IIpostalAddress: ADtelephoneNumber: TEL.PHONE

Provider Organization

name: EN.ONemailAddress: TEL.EMAILidentifier: IIpostalAddress: ADtelephoneNumber: TEL.PHONE

Healthcare ServiceProvider

licenceNumber: II

Patient Referral

referralType: CDidentifier: IIeffectiveDate: TS.DATEreferralText: ED.TEXTstatus: CD

Provider Organization Contact

name: EN.PNemailAddress: TEL.EMAILidentifier: IIjobTitle: STpostalAddress: ADcontactType: CDtelephoneNumber: TEL.PHONE

Requested Service

serviceType: CDidentifier: IIeffectivePeriod: TS.DATE (IVL)status: CD

Instruction

instructionType: CDidentifier: IIeffectivePeriod: TS.DATE (IVL)instructionText: ED.TEXT

Patient Health Summary

identifier: IIeffectivePeriod: TS.DATE (IVL)status: CD

Health Summary Content

contentType: CDidentifier: IIeffectivePeriod: TS.DATE (IVL)

Patient Health Record

identifier: IIeffectivePeriod: TS.DATE (IVL)

Health Record Entry

entryType: CDidentifier: IIeffectivePeriod: TS.DATE (IVL)status: CDtext: ED.TEXT

Administrative Item

administrativeItemType: CD

Clinical Item

clinicalItemType: CD

Instruction Line Item

type: CDvalue: ANYvaluetype: CD

Observation

value: ANYmethod: CDtargetSite: CDinterpetation: CD

Substance Adminitration

route: CDapproachSite: CDdose: PQ (IVL)rate: PQ (IVL)administrationUnit: CD

Procedure

approachSite: CDmethod: CDtargetSite: CD

Medicinal Product

typeCode: CDidentifier: II [1..*]name: ST

Health Record Entry Patricipant

participationType: CDidentifier: IIparticipantType: CDeffectivePeriod: TS.DATE (IVL)status: CDparticipantRole: CDdescription: ED.TEXTquantity: PQname: EN

Person

birthDate: TS.DATEname: EN.PNemailAddress: TEL.EMAILpatientRelationship: CDpostalAddress: ADtelephoneNumber: TEL.PHONEsex: CD

Organization

name: EN.ONemailAddress: TEL.EMAILpostalAddress: ADtelephoneNumber: TEL.PHONE

Material

materialType: CDname: ST

Service Location

name: STemailAddress: TEL.EMAILidentifier: IIpostalAddress: ADtelephoneNumber: TEL.PHONE

Referral Feedback Report

feedbackReportType: CDidentifier: IIeffectivePeriod: TS.DATE (IVL)feedbacklText: ED.TEXTstatus: CD

Patient Consent

value: ANYconsentType: CDidentifier: IIconsentText: ED.TEXTeffectivePeriod: TS.DATE (IVL)

Name: BSeR Information ModelAuthor: AbdulMalikVersion: 1.0Created: 6/8/2018 12:00:00 AMUpdated: 6/14/2018 7:35:57 AM

1.0 Patient

2.0 Patient Insurance

3.0 Provider

4.0 Patient Referral

5.0 Patient Health Record

6.0 Health Record Entry Participant

7.0 Patient Health Summary

Foriegn Class

BSeR Information Model Legend

1..*

is issued by

1

0..*

providescoverage for

1

0..*

0..*

is associated with

1

0..*

1

0..*

0..* 1

0..*

10..*

1

1..*

subject

1

0..*

0..*

includes

1

0..*

subject

1

obtained from

1..*

is owned by

1

0..*1

1..*

0..*

0..*

is a member of

1

0..*

1

0..*

includes

1

1..*

0..*

source 0..1

0..*

is issued totarget

1

0..*

is issued by source

1



1


BSeR Subject Area Model diagram Package diagram in package 'BSeR Information Model'

Figure 7: BSeR Information Model

Subject Area Specification

Each subject area specification includes a class diagram followed by a detailed specification for each class in the subject area. The subject area class diagrams use standard Unified Modeling Language (UML) notation. Classes display their native attributes and inherited attributes. Associative relationships are labeled with a prepositional phrase adorned with an arrowhead indicating the direction from which the relationship is defined. Relationships to classes outside the subject area are attached to an instance of the foreign class. Attributes of the foreign class instances are suppressed in the subject area diagram and the foreign class is shaded gray.

Class Specification

Each class specification includes

• the class name,

• descriptive text,

• a list of relationship assertions,

• a list of native attributes,

• a list of inherited attributes.

Relationship Assertions

Relationship assertions are intended to assist subject matter experts that may not be well-versed in UML notation. They are written using the following sentence pattern:

Each <source className> {always | sometime} <relationship predicate> {one | one or more} <target className>.

Attribute Specification

Each attribute specification includes descriptive text, a data type designation, and a list of cross-references to relevant data collection form locations.

Datatype Designation

The datatype designations are a subset drawn from the HL7 Version 3 Standard: Data Types - Abstract Specification, Release 2.

The subset of datatypes used in this specification include:

1.0 Patient

+ Patient

+ Patient Consent

+ Patient Contact


+ InsuranceCarrier

+ InsurancePolicyHolder

+ PatientInsurancePolicy


+ Administrative Item

+ Clinical Item

+ Health Record Entry

+ Medicinal Product

+ Observation

+ Patient Health Record

+ Procedure

+ Substance Adminitration


+ Instruction

+ Instruction Line Item

+ Patient Referral

+ Referral Feedback Report

+ Requested Service

3.0 Provider

+ Healthcare ServiceProvider

+ Provider Organization

+ Provider Organization Contact

+ Service Location

+ Service Provider


+ Health Record Entry Patricipant

+ Material

+ Organization

+ Person


+ Health Summary Content

+ Patient Health Summary

Name: BSeR Information ModelAuthor: AbdulMalikVersion: 1.0Created: 6/8/2018 8:43:25 PMUpdated: 6/13/2018 9:32:19 AM

1.0 Patient


3.0 Provider





Foriegn Class


http://www.hl7.org/implement/standards/product_brief.cfm?product_id=264

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=264



1


• AD - Postal Address

• BL - Boolean

• CD - Concept Descriptor

• ED - Encapsulated Data

• II - Instance Identifier

• INT - Integer

• PN - Person Name

• PQ - Physical Quantity

• ST - String

• TS - Point in Time Specification

The concept descriptor datatype (CD) is used in this specification to represent concepts that “may” be coded. In some cases, the code for the concept may yet to have been assigned and in such a case the original text portion of the CD datatype would contain a free-text expression of the concept.



1


1.0 Patient

Figure 8: Patient

Patient

- birthDate: TS.DATE- name: EN.PN- ethnicGroup: CD- emailAddress: TEL.EMAIL- identifier: II- postalAddress: AD- telephoneNumber: TEL.PHONE- preferredLanguage: CD- race: CD- sex: CD- employmentStatus: CD- educationLevel: CD

Patient Contact

- name: EN.PN- emailAddress: TEL.EMAIL- identifier: II- patientRelationship: CD- postalAddress: AD- contactType: CD- telephoneNumber: TEL.PHONE


Patient Referral


Patient Consent

- value: ANY- consentType: CD- identifier: II- consentText: ED.TEXT- effectivePeriod: TS.DATE (IVL)

Name: PatientAuthor: Salimah ShakirVersion: 1.0Created: 6/8/2018 12:00:00 AMUpdated: 6/13/2018 9:32:16 AM

1.0 Patient


3.0 Provider





Foriegn Class


obtained from

1..*

+subject

1

0..*


1

0..*

+subject

1

0..*

is associated with

1



1


2.0 Patient Insurance Package in package 'BSeR Information Model'

Figure 9: Patient Insurance

Patient

InsuranceCarrier

- name: EN.ON- emailAddress: TEL.EMAIL- identifier: II- postalAddress: AD- telephoneNumber: TEL.PHONE


- planName: ST- coverageType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)

InsurancePolicyHolder

- name: EN.PN- emailAddress: TEL.EMAIL- identifier: II- patientRelationship: CD- postalAddress: AD- telephoneNumber: TEL.PHONE

Name: Patient InsuranceAuthor: Salimah ShakirVersion: 1.0Created: 6/8/2018 12:00:00 AMUpdated: 6/13/2018 9:32:18 AM

1.0 Patient


3.0 Provider





Foriegn Class


1..*

is owned by

1

0..*


1

1..*

is issued by

1



1


3.0 Provider Package in package 'BSeR Information Model'

Figure 10: Provider

Service Provider

- name: EN.PN- specialty: CD- emailAddress: TEL.EMAIL- identifier: II- postalAddress: AD- telephoneNumber: TEL.PHONE

Provider Organization

- name: EN.ON- emailAddress: TEL.EMAIL- identifier: II- postalAddress: AD- telephoneNumber: TEL.PHONE

Healthcare ServiceProvider

- licenceNumber: II

Patient Referral

Provider Organization Contact

- name: EN.PN- emailAddress: TEL.EMAIL- identifier: II- jobTitle: ST- postalAddress: AD- contactType: CD- telephoneNumber: TEL.PHONE

Health Record Entry

Clinical Item

Service Location

- name: ST- emailAddress: TEL.EMAIL- identifier: II- postalAddress: AD- telephoneNumber: TEL.PHONE

Name: ProviderAuthor: Salimah ShakirVersion: 1.0Created: 6/8/2018 12:00:00 AMUpdated: 6/13/2018 9:32:15 AM

1.0 Patient


3.0 Provider





Foriegn Class


0..*

1

0..*

0..*

+source 0..1

0..*

is a member of

1

0..*

is issued to +target

1

0..*

1

0..*

is issued by +source

1



1


4.0 Patient Referral Package in package 'BSeR Information Model'

Figure 11: Patient Referral

Service Provider

Patient Referral

- referralType: CD- identifier: II- effectiveDate: TS.DATE- referralText: ED.TEXT- status: CD

Requested Service

- serviceType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)- status: CD

Instruction

- instructionType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)- instructionText: ED.TEXT


Instruction Line Item

- type: CD- value: ANY- valuetype: CD


- feedbackReportType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)- feedbacklText: ED.TEXT- status: CD

Name: Patient ReferralAuthor: Sallimah ShakirVersion: 1.0Created: 6/8/2018 12:00:00 AMUpdated: 6/13/2018 9:32:14 AM

1.0 Patient


3.0 Provider





Foriegn Class


0..*

0..*

0..*

0..*

1 0..*

includes

1

0..*

is issued by +source

1

0..*

is issued to +target

1

0..*

includes

1



1



Figure 12: Patient Health Record



- identifier: II- effectivePeriod: TS.DATE (IVL)

Health Record Entry

- entryType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)- status: CD- text: ED.TEXT

Administrative Item

- administrativeItemType: CD

Clinical Item

- clinicalItemType: CD

Observation

- value: ANY- method: CD- targetSite: CD- interpetation: CD

Substance Adminitration

- route: CD- approachSite: CD- dose: PQ (IVL)- rate: PQ (IVL)- administrationUnit: CD

Procedure

- approachSite: CD- method: CD- targetSite: CD

Medicinal Product

- typeCode: CD- identifier: II [1..*]- name: ST


Name: Patient Health RecordAuthor: Salimah ShakirVersion: 1.0Created: 6/8/2018 12:00:00 AMUpdated: 6/13/2018 9:32:13 AM

1.0 Patient


3.0 Provider





Foriegn Class


0..*

1

1..*

0..*10..* 1



1


6.0 Health Record Entry Participant Package in package 'BSeR Information Model'

Figure 13: 6.0 Health Record Entry Participant

Health Record Entry


- participationType: CD- identifier: II- participantType: CD- effectivePeriod: TS.DATE (IVL)- status: CD- participantRole: CD- description: ED.TEXT- quantity: PQ- name: EN

Person

- birthDate: TS.DATE- name: EN.PN- emailAddress: TEL.EMAIL- patientRelationship: CD- postalAddress: AD- telephoneNumber: TEL.PHONE- sex: CD

Organization

- name: EN.ON- emailAddress: TEL.EMAIL- postalAddress: AD- telephoneNumber: TEL.PHONE

Material

- materialType: CD- name: ST

Name: 6.0 Health Record Entry ParticipantAuthor: Salimah ShakirVersion: 1.0Created: 6/10/2018 12:00:00 AMUpdated: 6/13/2018 9:32:12 AM

1.0 Patient


3.0 Provider





Foriegn Class


0..* 1



1


7.0 Patient Health Summary Package in package 'BSeR Information Model'

Figure 14: 7.0 Patient Health Summary

Patient Referral


- identifier: II- effectivePeriod: TS.DATE (IVL)- status: CD


- contentType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)

Health Record Entry


Name: 7.0 Patient Health SummaryAuthor: Salimah ShakirVersion: 1.0Created: 6/10/2018 12:00:00 AMUpdated: 6/14/2018 7:35:54 AM

1.0 Patient


3.0 Provider





Foriegn Class

BSeR Information Model Legend0..*

includes

1

0..*1 1..*

0..*includes

1



1


BSeR Data Elements Referral Data Elements

• Allergies (Y/N)

• Baby's Birthdate

• Baby's Height/Length (cm)

• Baby's Name

• Baby's Sex

• Baby's Weight (kgs.)

• bestDayToCall

• bestTimeToCall

• BMI (cm/KG)

• Date last BP taken

• Diagnosis code ICD10 (6)

• Diagnosis code text (6)

• HA1c date taken

• HA1c done (Y/N)

• HA1c percent

• Height (inches)

• identifier

• Is Baby Latching

• Last BP taken

• Last taken BP diastolic

• Last taken BP systolic

• Last taken BP systolic/diastolic

• leaveMessageIndicator

• Medication dose

• Medication frequency

• Medication History

• Medication name

• Mom's BMI (cm/kg)

• Mom's Height (inches)

• Mom's Main Concerns

• Mom's Weight (lbs.)

• NicotineReplacementTherapyAuthorization

• Nipple shield Use

• referralDateTime

• referralNote

• referralReason

• referralType

• smoking status

• Weight (lbs.)

Feedback Data Elements

• % of sessions Attended

• activity status

• activityStatusReason

• Appropriate use of medications

• BMI (cm/kg)

• BP Diastolic

• BP Systolic

• BP systolic/diastolic

• breastfeeding challenges/symptoms

• cessation medications

• cessationMedicationUseIndicator

• feedbackReportDate

• feedbackReportNote

• Healthy eating

• Height (inches)

• improving strength, flexibility, and endurance

• lactation support

• Medications

• Pain Management

• pain, fatigue, frustration, and isolation

• quitDateSetIndicator

• referralIdentifier

• referralStatus

• referralType

• sessionsAttendedQuantity

• session type

• tobaccoFreeDuration

• Tongue-tie and lip-tie assessment



1


• Weight (lbs.)

BSeR Data Element to Program Area Mapping



1


Documents

Bidirectional Services eReferrals