Antepartum Record

Introduction

This is a draft of the Antepartum Record Profile (AR) supplement to the PCC Technical Framework. This draft is a work in progress, not the official supplement or profile.

Profile Abstract

The Antepartum Record Profile (AR)

The Antpartum Record continues the description of the content structures for the ACOG Antepartum Record Forms as begun in the Antepartum Summary Profile.

1. Forms A&B - The initial assessment and physical
2. Forms C&F - Update records and progress notes
3. Form D - Laboratory Evaluations
4. Form E - Education Assessment
5. Form G - Progress Notes

The ACOG Form also includes:

1. An Obstetric Medical History
2. A Postpartum form

A sample may be found at target: http://www.acog.org/acb-custom/aa128.pdf

This profile defines the implementation of HL7 CDA documents to represent the data elements from forms A, B, D, and E, along with the XDS, XDR and XDM bindings. This profile also defines mechanisms to group them into a single logical folder.

Glossary

Term

Definition

Issue Log

Open Issues

1. Issue
2. Issue

Volume I

Add the following bullet to the list of profiles

• Antepartum Record - One sentence

Dependencies

Add the following row(s) to the list of dependencies

Integration Profile	Dependency	Dependency Type	Purpose
Antepartum Record

Profile Name

The Antepartum Record Profile (AR)

Obstetric patients in labor and admitted to Labor and Delivery must have a complete summary of their antepartum ambulatory care available at the time of admission to evaluate and / or ameliorate risk. This same data is required at any visit to Labor and Delivery for any other problems or special needs a patient may require.

During the 40 weeks of a typical pregnancy duration, the patient will have an initial History and Physical Examination, followed by repetitive office visits with multiple laboratory studies, imaging (usually ultrasound) studies, and serial physical examinations with recordings of vital signs, fundal height, and the fetal heart rate. As the patient is seen over a finite period in the office, aggregation of specific relevant data important to the evaluation of the obstetric patient upon presentation to Labor and Delivery is captured on paper forms. The antepartum record contains the most critical information needed including the ongoing Medical Diagnoses, the Estimated Due Date, outcomes of any prior pregnancies, serial visit data on the appropriate growth of the uterus and assessments of fetal well being, authorizations, laboratory and imaging studies. This data must all be presented and evaluated upon entry to the Labor and Delivery Suite to ensure optimal care for the patient and the fetus.

Although the patient and her care provider may plan for a vaginal (natural) method of delivery, there is a substantive chance the delivery route may be surgical, requiring anesthesia and post-surgical care.

Current practice is to copy the patient's (paper) chart at various times during the pregnancy (as at 28 weeks and at 36 weeks of completed gestation), and transport the copies of the chart to the hospital the patient intends to use for delivery. Should the patient arrive prior to the chart copy arriving, or if the chart (or information within the chart) is missing on presentation of the patient to Labor and Delivery (a frequent occurrence), the staff or clinicians repeat laboratory or imaging studies. This results in unwarranted and duplicative tests, is wasteful of time and resources, and leads to dissatisfied patients. Further, missing or incomplete information about the patient’s clinical status may create a situation where critical information is unavailable to clinicians, which may ultimately result in an injury, inadequate aftercare or other undesirable outcome.

Significantly, a large portion of patients arrive in L&D without complete documentation. In one recent U.S. study , ~70% of patients (with paper charts) arrived in L&D without their current medical record being available. While only one hospital was involved in this study, one can see the extent of the issue, with pregnant patients possibly going to a different hospital than planned (preterm labor, rapid labor and unable to make it to the planned delivery hospital, or visiting a distant city), moving mid-care, or with a covering physician (rather than the primary obstetrician) on call.

In a Swedish study done in the 1990’s, critical data on paper records were incomplete from 45 to 87.5% of the time. Thus, availability of current medical records remains a significant problem for most hospital Labor and Delivery units; availability of key information electronically will significantly enhance patient safety.

Use Cases

Use Case Name 1

One or more paragraphs describing a clinical scenario.

Use Case Name 2

One or more paragraphs describing a clinical scenario.

Actors/Transaction

There are two actors in this profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile. A Document Source or a Portable Media Creator may embody the Content Creator Actor. A Document Consumer, a Document Recipient or a Portable Media Importer may embody the Content Consumer Actor. The sharing or transmission of content or updates from one actor to the other is addressed by the use of appropriate IHE profiles described by section 3.7 Content Bindings with XDS, XDM and XDR found in the Patient Care Coordination Technical Framework

Antepartum Record Actor Diagram

Options

Antepartum Record Options

Actor	Option	Section
Content Consumer	View Option (1) Document Import Option (1) Section Import Option (1) Discrete Data Import Option (1)	PCC TF-1: 2.13.1 PCC TF-1: 2.13.2 PCC TF-1: 2.13.3 PCC TF-1: 2.13.4
Content Creator	Referral Option (1) Discharge Summary Option (1)	PCC TF-1: 2.13.5 PCC TF-1: 2.13.6

Note ¹: The Actor shall support at least one of these options.

Grouping

Content Bindings with XDS, XDM and XDR

It is expected that the transfers of care will occur in an environment where the physician offices and hospitals have a coordinated infrastructure that serves the information sharing needs of this community of care. Several mechanisms are supported by IHE profiles:

• A registry/repository-based infrastructure is defined by the IHE Cross Enterprise Document Sharing (XDS) and other IHE Integration Profiles such as patient identification (PIX & PDQ), and notification of availability of documents (NAV).
• A media-based infrastructure is defined by the IHE Cross Enterprise Document Media Interchange (XDM) profile.
• A reliable messaging-based infrastructure is defined by the IHE Cross Enterprise Document Reliable Interchange (XDR) profile.
• All of these infrastructures support Security and privacy through the use of the Consistent Time (CT) and Audit Trail and Node Authentication (ATNA) profiles.

For more details on these profiles, see the IHE IT Infrastructure Technical Framework.

Content profiles may impose additional requirements on the transactions used when grouped with actors from other IHE Profiles.

Cross Enterprise Document Sharing, Media Interchange and Reliable Messages

Actors from the ITI XDS, XDM and XDR profiles embody the Content Creator and Content Consumer sharing function of this profile. A Content Creator or Content Consumer must be grouped with appropriate actors from the XDS, XDM or XDR profiles, and the metadata sent in the document sharing or interchange messages has specific relationships to the content of the clinical document described in the content profile.

Notification of Document Availability (NAV)

A Document Source should provide the capability to issue a Send Notification Transaction per the ITI Notification of Document Availability (NAV) Integration Profile in order to notify one or more Document Consumer(s) of the availability of one or more documents for retrieval. One of the Acknowledgement Request options may be used to request from a Document Consumer that an acknowledgement should be returned when it has received and processed the notification. A Document Consumer should provide the capability to receive a Receive Notification Transaction per the NAV Integration Profile in order to be notified by Document Sources of the availability of one or more documents for retrieval. The Send Acknowledgement option may be used to issue a Send Acknowledgement to a Document Source that the notification was received and processed.

Document Digital Signature (DSG)

When a Content Creator Actor needs to digitally sign a document in a submission set, it may support the Digital Signature (DSG) Content Profile as a Document Source. When a Content Consumer Actor needs to verify a Digital Signature, it may retrieve the digital signature document and may perform the verification against the signed document content.

Content Modules

Content modules describe the content of a payload found in an IHE transaction. Content profiles are transaction neutral. They do not have dependencies upon the transaction that they appear in.

Process Flow

Antepartum Record Process Flow

More text about process flow

Actor Definitions

Actor

Definition

Transaction Definitions

Transaction

Definition

Volume II

Antepartum Record Content

Standards

CDAR2

Clinical Document Architecture, Release 2, 2005 HL7

CRS

Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm), 2006, HL7.

CCD

ASTM/HL7 Continuity of Care Document (Draft)

Data Element Index

Antepartum Record Data Elements

Data Elements	Other Reference	LOINC Section or CDA Element
Data Element 1
Data Element 2
Data Element 3

Document Specification

Antepartum Record Constraints

Data Element	Opt	Section	Template ID
Data Element 1	R		1.3.6.1.4.1.19376.1.5.3.1.3.X
Data Element 2	R2		1.3.6.1.4.1.19376.1.5.3.1.3.Y
Data Element 3	O		1.3.6.1.4.1.19376.1.5.3.1.3.Z

Section Template 1

TemplateID	1.3.6.1.4.1.19376.1.5.3.1.3.X
Parent Template	1.3.6.1.4.1.19376.1.5.3.1.3.Y
General Description	This section shall ...
LOINC Code	Opt	Description
#####-#	R	Description
Entries	Opt	Description
1.3.6.1.4.1.19376.1.5.3.1.4.A	O	Description
Sub-sections	Opt	Description
1.3.6.1.4.1.19376.1.5.3.1.3.D	R	Description

Header Template 1

<entry>An XML Example</entry>

entry

Description of the entry element.

Entry Template 1

<entry>An XML Example</entry>

entry

Description of the entry element.