Composing EHR Modules: CPOE, Clinical Data & Scheduling

Posted in EHR/EMR

Building a CPOE module, clinical data repository (CDR), or custom scheduling module requires different development approaches. CPOE needs clinical safety checks and order routing. A CDR needs patient matching and data normalization. Custom scheduling needs booking rules and EHR synchronization. These requirements directly affect patient care. A 2013 systematic review and meta-analysis found that using CPOE reduced the likelihood of medication errors per prescription order by 48%. For healthcare product teams, development depends on the module’s components, clinical standards, integrations, and compliance requirements. This guide explains what each module needs, the teams involved, and the effort required to build it.

Why Build EHR Modules Separately?

CPOE, clinical data repositories, and scheduling modules share patient information, but each handles that information differently. Their development requirements depend on how they create, store, and update records.

• CPOE manages clinical orders. Once a clinician creates an order, the system checks it against safety rules, records the signature, and sends it to the appropriate department. The original order must remain available, along with a complete history of changes.
• A clinical data repository continuously receives information from different systems and combines it into one patient record. It also handles corrections and duplicate records. Scheduling manages appointments based on provider availability, rooms, equipment, and booking rules. When availability changes, the module must identify and update affected appointments.
• These different functions require different data models. CPOE needs protected, versioned order records. A CDR needs to support ongoing updates and patient matching. Scheduling needs to recalculate availability whenever booking conditions change.

Each module also has its own standards, integrations, and development requirements. Understanding these requirements helps product teams plan the architecture and determine the work involved.

What Does a CPOE Module Do?

A CPOE (computerized provider order entry) module allows clinicians to create medication, laboratory, imaging, and referral orders electronically. It checks orders against clinical safety rules before the clinician signs them and sends each order to the system responsible for completing it.

How CPOE Processes Medication Orders

When a clinician prescribes medication, the CPOE module follows seven steps:

1. Select the medication, dose, route, and frequency.
2. Check the patient’s recorded allergies and current medications.
3. Check the dose against the patient’s age, weight, and kidney or liver function, where recorded.
4. Check the medication against the organization’s formulary.
5. Display safety alerts and record the clinician’s response.
6. Capture the clinician’s signature.
7. Send the order to the pharmacy system.

The formulary is the organization’s list of approved medications. These checks help clinicians review possible interactions, allergies, and dosing concerns before completing an order.

Laboratory and imaging orders follow similar processes, with requirements specific to each department. A laboratory order must include specimen and collection details, and the laboratory system must return the test results. An imaging order needs a procedure code that the radiology system can recognize.

CPOE Functions in Existing EHRs

EHR platforms already provide these ordering functions through different applications. In Epic, clinicians place orders through the Orders activity. Willow supports pharmacy workflows, Beaker handles laboratory workflows, and Radiant manages imaging. Oracle Health provides ordering through PowerOrders within PowerChart.

A custom CPOE module manages the ordering process and connects with the pharmacy, laboratory, imaging, and other systems that carry out the orders. These connections are part of the development scope.

What Is a Clinical Data Repository?

A clinical data repository (CDR) is a central database that stores the clinical information needed during patient care. It brings together patient demographics, diagnoses, allergies, medications, laboratory results, clinical notes, encounters, and vital signs.

The information comes from EHRs, laboratories, medical devices, and other healthcare applications. The repository combines these records into one patient record that clinicians can access during a visit. Connected systems also continue updating it as new information becomes available.

CDR Compared with a Data Warehouse

A clinical data repository and a data warehouse serve different purposes. It stores current clinical information for individual patients and updates records as clinical events occur. Also, supports the information clinicians need during daily patient care.

A data warehouse stores historical information collected from many patients. It is commonly updated in batches and used for reporting, analytics, and research.

Healthcare platforms may need both. A CDR supports clinical workflows that require current information, while a data warehouse supports broader analysis across patients and time periods.

How a CDR Supports the EHR

The EHR provides the screens and applications clinicians use for documentation, ordering, and scheduling. The CDR holds the clinical information these applications use.

For example, Epic uses the Chronicles database, while Oracle Health Millennium has its own underlying data layer.

A healthcare software company may develop its own CDR when its platform needs to combine information from multiple EHRs, laboratories, medical devices, and internal applications into one patient record.

What Makes Scheduling Custom?

Custom scheduling is needed when an organization’s appointment requirements go beyond the standard configuration available in an EHR. These requirements often involve multiple resources, different booking methods, and information that must pass into other clinical workflows.

1. Multiple Resources and Locations

An appointment may require a particular physician, examination room, medical equipment, and an interpreter at the same time. The physician may only work at that location on certain days. The patient’s insurance may also cover a limited group of providers.

The scheduling module must check all these conditions before confirming an available slot. It needs to know which resources are required for each visit type and when those resources are available.

2. Different Types of Bookers

Appointments may be booked by administrative staff, patients, or referral teams. Each group uses the same appointment availability with different permissions.

Staff may need access to the complete schedule, while patients should only see the appointments available to them. Referral teams may follow additional rules based on the type of referral.

All booking methods must use the same availability information in real time. This keeps appointment records consistent and helps prevent double bookings.

3. Data the Booking Has to Carry

An appointment contains information that other EHR workflows need. The appointment type is linked to a visit type, which may determine the documentation template and procedure code used for billing.

The scheduling module must pass this information to the relevant systems so clinical and billing teams can continue their work using the same appointment details.

Custom scheduling usually runs alongside the EHR’s existing scheduling application. The integration that keeps appointments synchronized between both systems is part of the build.

Build Requirements Compared

CPOE, clinical data repositories, and custom scheduling have different development requirements. The following table compares the main components, standards, integrations, and expertise required for the first production release of each module.

The standards listed apply to healthcare software developed for the United States.

Requirement	CPOE	Clinical Data Repository	Custom Scheduling
Core problem	Safety checks and order routing	Data normalization and patient matching	Rules checking and synchronization
Primary standards	ONC certification criteria 170.315(a)(1) to (a)(4); NCPDP SCRIPT; HL7 v2 order and result messages; FHIR R4 ServiceRequest and MedicationRequest	USCDI; FHIR R4 with US Core profiles; HL7 v2 ADT and result messages; RxNorm, SNOMED CT, LOINC	HL7 v2 SIU scheduling messages; FHIR R4 Schedule, Slot, Appointment, AppointmentResponse
Licensed content	Commercial drug database (First Databank, Medi-Span, or Multum); order sets	SNOMED CT through the UMLS licence; LOINC and RxNorm at no cost	None required
Clinical decision support	Required: drug-drug, drug-allergy, and dose-range checks	Outside the module’s scope; the CDR supplies data to CDS	Outside the module’s scope
Connects to	Pharmacy, lab, and radiology systems; EHR ordering when embedded	EHR ADT, results, documents, medication feeds, and a master patient index	EHR provider, location, and visit-type records; two-way appointment sync
Certification	ONC Health IT Certification if the product claims it	None specific; HIPAA applies to the data store	None specific; HIPAA applies to PHI in bookings
Hardest part	Alert accuracy and the order data model	Data mapping and duplicate patient records	Cascading booking conflicts and two-way sync
Additional team members	Pharmacist or physician informaticist; certification tester if certifying	Terminology specialist; data engineer	Operations analyst responsible for scheduling rules
Relative effort	Highest due to safety checks, licensed content, and certification testing	High, depending on the number of source formats	Lowest without self-booking and EHR sync; medium with them

What It Takes to Build CPOE

A complete CPOE module has six main components. Development begins with the ordering and clinical safety functions, which are then connected to the order-entry screen used by clinicians.

1. Order Catalog

The order catalog contains everything a clinician can order, including medications, laboratory tests, imaging procedures, and referrals. Each item has a standard code and the information needed by the system that will process it.

Medications use RxNorm codes, laboratory tests use LOINC codes, and imaging procedures use CPT or local codes. Medication orders are represented through the FHIR MedicationRequest resource, while laboratory, imaging, and referral orders use ServiceRequest.

These order types need separate data structures because the receiving systems require different information. This allows developers to define the fields and processing rules appropriate for each order.

2. Drug Knowledge Base

The drug knowledge base provides the clinical information needed to check medication orders for possible safety concerns. It covers drug-drug interactions, drug-allergy cross-sensitivity, dose ranges, and dose adjustments for patients with kidney or liver conditions.

This information usually comes from a commercial drug database. Common providers in the United States include First Databank, Medi-Span from Wolters Kluwer, and Multum from Oracle Health.

The database requires licensing and regular content updates. Teams should arrange the license early in development so the safety checks can be built around the appropriate clinical information.

3. Safety Check Services

The CPOE module checks medication orders against clinical safety rules before they are signed. These checks cover allergies, drug interactions, dose ranges, duplicate therapy, and the organization’s formulary.

Each check should run as a separate service with its own settings. This allows the organization to change the severity of an alert or adjust an individual check without updating the entire order processing system.

Alert accuracy is also important. For example, the module should consider whether a patient has previously tolerated a medication. Using this information can help reduce unnecessary alerts and make important warnings more useful to clinicians.

4. Order Sets and Protocols

Order sets are groups of orders used for common clinical situations, such as hospital admissions and post-operative care. They may include medications, laboratory tests, default instructions, and required fields.

A physician or pharmacist informaticist should manage the clinical content. The module also needs a versioned editor so authorized staff can update order sets while keeping a record of earlier versions.

This allows clinical teams to maintain order sets as care protocols change, without requiring a new software release for each update.

5. Routing and Acknowledgment

After a clinician signs an order, the CPOE module sends it to the appropriate system. The integration standard depends on the order type and the system receiving it.

• Outpatient medication orders: NCPDP SCRIPT carries electronic prescriptions to pharmacies.
• Inpatient medication orders: HL7 v2 messages or FHIR connect with pharmacy systems.
• Laboratory orders: The laboratory system receives the order and returns results through HL7 v2 ORU messages or FHIR DiagnosticReport resources.
• Imaging orders: The radiology system receives the order with the required procedure code.

The module must also track each order’s status. It should show whether the receiving system has acknowledged the order, whether work is in progress, and whether the order has been completed or canceled.

6. Signing, Audit, and the Order Form

The CPOE module records the identity of the clinician who creates and signs an order. It also supports co-signature rules for residents and other providers who require supervision.

An unchangeable audit record must capture order activity and the clinician’s response to safety alerts. These records help maintain accountability and allow authorized teams to review how an order was handled.

Once the ordering, safety, and audit functions are in place, developers can build the order-entry screen that clinicians use to create, review, and sign orders.

ONC Certification

Products that claim ONC Health IT Certification must meet the applicable certification criteria. For CPOE, the relevant requirements include:

Criterion	Function
170.315(a)(1)	Medication orders
170.315(a)(2)	Laboratory orders
170.315(a)(3)	Diagnostic imaging orders
170.315(a)(4)	Drug-drug and drug-allergy interaction checks
170.315(b)(11)	Decision support interventions

Criterion 170.315(b)(11) covers how clinical decision support is configured and presented. Certification testing requires additional development and validation, which contributes to the higher effort involved in building a complete CPOE module.

CPOE Inside an Existing EHR

Some healthcare products only need to add a specific ordering function to an existing EHR. For example, a specialty application may provide an additional order set or clinical safety check.

Teams can deliver this functionality through a SMART on FHIR application or a CDS Hooks service. The EHR continues to manage its existing order catalog, drug database, and routing processes, while the new application provides the required functionality.

What It Takes to Build a CDR

A clinical data repository has five main components. Much of the development effort goes into collecting information from different systems, matching patient records, and converting the data into a consistent format before storing it.

1. Ingestion Adapters

Ingestion adapters receive information from healthcare systems. Each adapter handles a particular data format or connection and prepares incoming information for processing.

An HL7 v2 listener receives ADT messages for admissions, discharges, and transfers, ORU messages for clinical results, and MDM messages for medical documents. A FHIR client retrieves R4 data from Epic, Oracle Health, and other FHIR servers. File and API adapters collect information from medical devices and the platform’s own applications.

Each adapter validates the incoming information, adds a timestamp, and places it in a queue. Data transformation takes place in a separate component so the adapters can focus on receiving information correctly.

2. Patient Matching

A CDR may receive multiple records about the same patient from different healthcare systems. Each source may use its own patient identifier, so the repository needs a way to recognize which records belong together.

A master patient index (MPI) matches patient records using exact rules and probability-based matching. Exact matching compares known identifiers, while probability-based matching uses available patient details to estimate whether records belong to the same person.

The repository also needs workflows for merging duplicate records and separating records that were merged incorrectly. It must keep track of which source provided each identifier. Accurate patient matching is important because duplicate records can become difficult to correct after large amounts of clinical information have been stored.

3. Normalization and Terminology

Healthcare systems often use different names, codes, and formats for the same clinical information. Normalization converts this information into a common structure so the repository can use it consistently.

Incoming fields are mapped to USCDI data elements and standard healthcare terminology. The main coding systems include:

• RxNorm: Medications
• SNOMED CT: Clinical problems and procedures
• LOINC: Laboratory tests and observations

A terminology service maintains these code systems and value sets and supports code lookups.

For example, an older HL7 v2 feed and a current FHIR feed may both contain the same type of laboratory result. The mapping layer identifies them as the same LOINC-coded observation.

The mapping layer should remain separate from the ingestion adapters and application. USCDI is updated annually, and this separation allows teams to update the mapping rules in one place.

4. The Store

The store holds clinical information after it has been prepared and normalized. A FHIR R4 server using US Core profiles is a practical option because the EHR application, CPOE, and connected systems can all use the same standard data structure.

Available options include HAPI FHIR, Medplum, Google Cloud Healthcare API, and Azure Health Data Services. These platforms provide capabilities for storage, searching, and version management.

The incoming clinical information still needs to go through the normalization process. The FHIR server provides a standard format for storing and accessing the prepared data.

5. Access, Audit, and Retention

The repository must control who can access or change patient information. Different EHR modules and external SMART on FHIR applications may require different permissions, depending on the information they need.

The main requirements include:

• Scoped access: Controls which clinical information each application can access.
• Audit logging: Records data reads and writes as required by the HIPAA Security Rule.
• Provenance: Identifies the system that created or supplied each clinical resource.
• Retention rules: Keeps medical records according to applicable state laws.

These controls help protect patient information and maintain a record of how clinical data is accessed, updated, and retained.

6. Team

A CDR project requires people with experience in healthcare data integration. A data engineer develops the ingestion adapters and processing queues, while a terminology specialist manages clinical data mapping and standard codes. The team also needs someone experienced in operating a master patient index.

In the United States, SNOMED CT is available through the National Library of Medicine’s UMLS license at no cost. LOINC and RxNorm are also available at no cost.

Development effort increases with the number of data sources and formats the repository must support. Each new format may require an additional adapter and mapping work.

7. Build Order

When developing CPOE, a CDR, and scheduling for the same clinical platform, the repository should be built first. CPOE uses patient allergy and medication information from the repository, while scheduling uses patient and provider records.

Building the CDR first gives both modules a shared data structure and allows teams to develop their functions around consistent clinical information.

Building Custom Scheduling Modules

A custom scheduling module has five main components. The calendar provides the interface for users, while the underlying system manages resource availability, appointment rules, and connections with the EHR.

1. Resource and Rules Model

The module must maintain information about every resource needed for appointments. These may include providers, locations, examination rooms, equipment, and support staff. Each resource has its own availability schedule, and each visit type defines the resources required and the length of the appointment.

Scheduling rules may include which providers can handle particular visit types, which locations offer those visits, buffer times between appointments, advance booking requirements, double-booking policies, and overbooking limits.

The operations team should be able to manage these rules through an editor. This allows scheduling policies to be updated as operational requirements change, without requiring developers to release new code.

2. Availability and Rules Engine

The availability engine finds appointment slots that meet the booking requirements. It checks the requested visit type, patient information, time window, and availability of all required resources.

For example, an appointment can be offered when the physician, room, equipment, and support staff are available at the same time, and the booking meets the organization’s rules.

The module also needs to handle changes that affect existing bookings. If a room becomes unavailable or a provider runs late, the system must identify the affected appointments, support rescheduling, and notify patients where required.

Booking changes should be handled as transactions that can be rolled back if they cannot be completed. Checking all required resources together helps prevent double bookings and conflicting reservations.

3. Booking Workflows

Custom scheduling supports different booking methods, including staff booking, patient self-booking, referral intake, waitlists, cancellations, and rescheduling.

Administrative staff may need full schedule visibility, while patients should only see the appointments available to them. The patient-facing interface should keep private scheduling information hidden, including the reasons a particular slot is blocked.

All booking methods must use the same availability engine in real time. This keeps appointment information consistent across staff and patient-facing applications.

4. EHR Sync

Custom scheduling commonly runs alongside the EHR’s existing scheduling application. The two systems must exchange appointment information in both directions so changes remain consistent.

In hospitals and enterprise healthcare environments, HL7 v2 SIU messages are commonly used for scheduling updates. The main message types include:

• S12: New appointment
• S13: Rescheduled appointment
• S15: Canceled appointment

FHIR provides another integration method through Schedule, Slot, and Appointment resources. Epic, for example, supports Appointment $find and $book operations through its STU3 FHIR API for appointment booking from external applications.

The synchronization process must also handle situations where the same appointment is changed in both systems. Developers need rules to manage these conflicts and keep the appointment records consistent.

5. Downstream Data

Each appointment carries information needed by clinical and administrative workflows. This includes the visit type, expected procedure code, documentation template, and eligibility check result.

The module must make these details available during patient check-in, clinical documentation, and billing. Appointment reminders, confirmations, and no-show handling are also linked to the booking record.

Passing this information between systems helps clinical and administrative teams work from the same appointment details and reduces repeated data entry.

6. Team

A custom scheduling project needs an operations analyst who understands the organization’s booking rules. This person defines the rules and tests situations where one change affects multiple appointments. An integration engineer manages HL7 SIU or FHIR synchronization with the EHR.

A basic scheduling module without patient self-booking or EHR synchronization requires the least development effort of the three modules.

Adding self-booking and two-way EHR synchronization can roughly double the work. Much of the additional development involves handling booking conflicts and managing access to patient-facing availability.

Shared Compliance and Interoperability Work

CPOE, clinical data repositories, and scheduling modules share several technical requirements. Building these services once allows the three modules to use the same infrastructure and reduces repeated development work.

1. Identity and Access

The clinical platform needs a common identity provider to manage user authentication. Role-based access control defines what clinicians, administrative staff, and patients can see and do.

SMART on FHIR support allows modules to launch from Epic or Oracle Health and enables approved external applications to access information from the repository. This service should be developed early, so the individual modules can use a common approach to authentication and access.

2. Audit Logging

The HIPAA Security Rule requires audit controls for systems that handle electronic protected health information.

Each module needs to record different activities. CPOE maintains order history and alert overrides. The CDR records data access and Provenance information. Scheduling records who created, changed, or canceled appointments.

A shared audit service can collect these activities using a common event format, making it easier to manage audit records across the platform.

3. Terminology Service

All three modules use standard healthcare codes. The CDR needs terminology mapping to combine clinical information, CPOE uses standard codes in its order catalog, and scheduling links visit types to procedure codes.

A shared terminology service allows the modules to use the same code systems, value sets, and licenses. This also helps keep clinical terminology consistent across the platform.

4. Interface Layer

The interface layer manages connections between the clinical platform and external healthcare systems. An interface engine or integration service handles HL7 v2 messages for admissions, orders, clinical results, and scheduling.

It also manages FHIR client configurations for each EHR tenant. Individual modules can communicate through this shared interface layer instead of maintaining separate connections with each hospital system.

The HL7 v2 vs FHIR comparison explains which standard is commonly used for different types of healthcare data exchange.

All three modules also share security and hosting requirements. These include encryption at rest and in transit, a business associate agreement with the cloud provider, and SOC 2 reporting when required by customers.

Connect Your Clinical Applications with Existing EHR Systems

Folio3 Digital Health provides EHR integration services to help healthcare organizations connect custom clinical applications with Epic, Oracle Health, and other EHR platforms.

Our team supports integration with Epic’s ordering, pharmacy, laboratory, imaging, and scheduling workflows. Using HL7 v2, FHIR APIs, and SMART on FHIR, we enable clinical order exchange, patient data access, and appointment synchronization between connected systems.

We also help healthcare product companies extend existing EHR functionality through custom applications and CDS Hooks services, using the integration capabilities supported by each EHR.

Closing Note

The development effort for an EHR module depends on the clinical processes it supports and the systems it needs to connect with. Defining these requirements early gives product teams a clearer view of the components, expertise, and testing involved.

For platforms that need CPOE, a clinical data repository, and custom scheduling, the order of development also matters. Building the repository first provides a common patient record, while shared services for access, terminology, auditing, and integration support the other modules as they are developed. This approach gives teams a practical foundation for building clinical software that can support their current workflows and future requirements.

Frequently Asked Questions

1. Do you need ONC certification to build a CPOE module?

No. Building software does not need federal permission. Your customers will require it if they plan to use your module to take part in federal reimbursement programs.

2. Is a clinical data repository the same as a FHIR server?

No. A FHIR server stores and provides access to healthcare information using FHIR resources. A clinical data repository includes the FHIR server and the components that collect, match, and prepare the information.

These include ingestion adapters, patient matching, and terminology mapping. Setting up a server such as HAPI FHIR or Medplum is one part of developing a complete CDR.

3. Which drug database does a CPOE module need?

A CPOE module needs a commercial clinical drug database, such as First Databank, Medi-Span, or Multum. These databases provide information about drug interactions, allergies, and dosing requirements and receive regular updates.

RxNorm identifies medications using standard codes. The commercial drug database supplies the additional clinical information required for safety checks.

4. Can a custom scheduling module replace the EHR’s scheduling?

Yes. A custom scheduling module can replace an EHR’s scheduling application, although it commonly operates alongside the existing system. Appointments are synchronized through HL7 SIU messages or FHIR Appointment resources.

A complete replacement also needs to support the registration, check-in, and billing workflows that depend on the EHR’s schedule.

5. Does a CPOE module need clinical decision support?

Yes. Clinical decision support is an important part of CPOE. The module needs drug-drug interaction, drug-allergy, and dose-range checks to support safe medication ordering.

Additional functions, such as clinical protocol prompts and patient risk scores, can be added later through CDS Hooks services.

About the Author