Post on 03-Dec-2021
transcript
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.
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 info@ihtsdo.org
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)
Page 3 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Page 4 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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.
Requirement Report - Details 25 October, 2019
Page 5 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Requirement Report - Details 25 October, 2019
Page 6 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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.
Requirement Report - Details 25 October, 2019
Page 7 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Requirement Report - Details 25 October, 2019
Page 8 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Requirement Report - Details 25 October, 2019
Page 9 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release 1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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..*
Requirement Report - Details 25 October, 2019
Page 10 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Service Delivery Feedback Report /
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»
Requirement Report - Details 25 October, 2019
Page 11 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Service Provider Locator
Patient
Patient Medical Record
Electronic Medical Record System
«flow»
«flow»
«flow»
«flow»
Requirement Report - Details 25 October, 2019
Page 12 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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 Instructions
Referral Authorization
Response
Relevant Clinical History
Service Referral
2.3 Is Pre-authorization
Required?Service Provider Profile / Selected
Serivce Provider
Referring Provider
Service Provider Locator
PatientElectronic Medical Record
System
2.5 Is ReferralAuthorized?
FlowFinal
Referral Gatekeeper
Referral Authorization
Request
ActivityFinal
ActivityInitial
«flow»«flow»
«flow»
«flow»
«flow»
[Pre-authorizationis Required]
«flow»
«flow»
[Otherwise]
[Otherwise]
«flow»
«flow»
«flow»
[Referral isAuthorized]
Requirement Report - Details 25 October, 2019
Page 13 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Relevant Clinical History
Health Status Assessment Findings
Referral Authorization
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
Unsuccessful Intake Notification
Service Treatment Plan
Patient Consents
3.2 Is Outreachsuccessful?
Electronic Medical Record System
ActivityInitial
ActivityFinal
3.A Report Intake Treatment Plan
Treatment Plan Report / Intake
Patient Medical Record
FlowFinal
«flow»[Patient is eligible]
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
[Otherwise]
[Outreach isSuccessful]
«flow»
[Otherwise]
«flow»
Requirement Report - Details 25 October, 2019
Page 14 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Service Treatment Plan
4.1 Schedule Patient Encounter Encounter /
ScheduledPatient Availability
Service Provider Availability
4.2 Is ScheduledEncounter Held?
4.3 Record Missed Encounter
Missed Encounter Notation
Electronic Medical Record System
Patient Medical Record
Relevant Clinical History
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
Missed Encounter Notification
Referring Provider
4.9 Provide Service Delivery Feedback
Service Delivery Feedback Report
4.8 Report Update to Treatment Plan
Treatment Plan Report / Updated
ActivityInitial
FlowFinal
«flow»
«flow»
[Otherwise]
«flow»
[Treatment Plan Updated]
«flow»
«flow»
[ScheduledEncounter is Held]
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
Requirement Report - Details 25 October, 2019
Page 15 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Relevant Clinical History
Service Delivery Feedback Report /
Intermediate
Service Delivery Feedback Report /
Final
Referral Instructions
Electronic Medical Record System
Missed Encounter Notification
Treatment Plan Report / Intake
Unsuccessful Intake Notification
Referring Provider
Serivce Provider
5.2 Treatment Incident Reporting
4.8 Report Update to Treatment Plan
Treatment Plan Report / Updated
Patient Medical Record
ActivityInitial ActivityFinal
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
Requirement Report - Details 25 October, 2019
Page 16 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Requirement Report - Details 25 October, 2019
Page 17 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
2.0 Patient Insurance
+ InsuranceCarrier
+ InsurancePolicyHolder
+ PatientInsurancePolicy
5.0 Patient Health Record
+ Administrative Item
+ Clinical Item
+ Health Record Entry
+ Medicinal Product
+ Observation
+ Patient Health Record
+ Procedure
+ Substance Adminitration
4.0 Patient Referral
+ 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
6.0 Health Record Entry Participant
+ Health Record Entry Patricipant
+ Material
+ Organization
+ Person
7.0 Patient Health Summary
+ 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
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
Requirement Report - Details 25 October, 2019
Page 18 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
• 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.
Requirement Report - Details 25 October, 2019
Page 19 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
PatientInsurancePolicy
Patient Referral
Patient Health Record
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
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
obtained from
1..*
+subject
1
0..*
providescoverage for
1
0..*
+subject
1
0..*
is associated with
1
Requirement Report - Details 25 October, 2019
Page 20 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
PatientInsurancePolicy
- 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
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 owned by
1
0..*
providescoverage for
1
1..*
is issued by
1
Requirement Report - Details 25 October, 2019
Page 21 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
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
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
Requirement Report - Details 25 October, 2019
Page 22 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Patient Health Summary
Instruction Line Item
- type: CD- value: ANY- valuetype: CD
Referral Feedback Report
- 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
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
0..*
0..*
0..*
0..*
1 0..*
includes
1
0..*
is issued by +source
1
0..*
is issued to +target
1
0..*
includes
1
Requirement Report - Details 25 October, 2019
Page 23 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
5.0 Patient Health Record
Figure 12: Patient Health Record
Health Summary Content
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
Health Record Entry Patricipant
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
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
0..*
1
1..*
0..*10..* 1
Requirement Report - Details 25 October, 2019
Page 24 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
6.0 Health Record Entry Participant Package in package 'BSeR Information Model'
Figure 13: 6.0 Health Record Entry Participant
Health Record Entry
Health Record Entry Patricipant
- 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
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
0..* 1
Requirement Report - Details 25 October, 2019
Page 25 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
7.0 Patient Health Summary Package in package 'BSeR Information Model'
Figure 14: 7.0 Patient Health Summary
Patient Referral
Patient Health Summary
- identifier: II- effectivePeriod: TS.DATE (IVL)- status: CD
Health Summary Content
- contentType: CD- identifier: II- effectivePeriod: TS.DATE (IVL)
Health Record Entry
Referral Feedback Report
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
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 Legend0..*
includes
1
0..*1 1..*
0..*includes
1
Requirement Report - Details 25 October, 2019
Page 26 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
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
Requirement Report - Details 25 October, 2019
Page 27 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot
• Weight (lbs.)
BSeR Data Element to Program Area Mapping
Requirement Report - Details 25 October, 2019
Page 28 of 28 HL7 CDA® R2 Implementation Guide: Bidirectional Services eReferrals (BSeR), Release
1
© 2018 Health Level Seven International. All rights reserved. September 2018 Ballot