Why a Dosing Service Needs a Data-Source Inventory
A dosing model may be technically sound and still be unusable if the service cannot establish where its inputs come from, who is responsible for them, or how often they are refreshed. A data-source inventory makes those dependencies explicit. It is a practical catalogue of the sources a specified dosing use case may rely on, with enough detail to support discussion between clinical, data, and technical teams.
The inventory is not itself a data-quality assessment, a mapping specification, or a description of how records are joined. Those are separate tasks. Here the focus is narrower: identify relevant medication, laboratory, demographic, and administration sources; document their owners and update patterns; and state what each source is intended to contribute to dosing support. Begin with the use-case specifications: they indicate which inputs the service needs, while the inventory records where those inputs may be obtained.
What Each Inventory Entry Should Capture
A useful entry identifies a source at a practical level. “Medication data” is too broad: an electronic medication order, a pharmacy dispensing record, and a medication administration record are distinct sources with different meanings and owners. Likewise, “laboratory results” should identify the system or operational dataset that supplies results, not just the general category.
At minimum, record the source name and domain, the data it contains, the accountable owner, the operational steward or contact, the access route, its update pattern, and its intended use. The owner is the organizational role or group accountable for the source and its use; the steward is the person or team that can answer day-to-day questions about its operation. They may be the same, but should not be assumed to be. An interface or reporting platform may provide access without owning the underlying clinical data.
Describe update patterns in operationally useful terms. A refresh schedule says how often a dataset or feed is updated; latency says how long after a relevant event its information is generally available. If known, document both. “Daily” is ambiguous unless the inventory says whether that means a once-daily batch, an overnight refresh, or a daily review by a person. Avoid claiming a precise service guarantee when only an informal expectation is known.
Intended use should be specific enough to prevent a source from being treated as suitable for every purpose. For example, a medication-order source may provide the prescribed regimen, while an administration record may provide doses documented as given. A laboratory source may provide measured concentrations for model updating, while a demographic source may provide age or body-size covariates. State relevant exclusions too: an order source alone does not establish that a dose was administered.
| Inventory field | What to record | Why it matters |
|---|---|---|
| Source and domain | Named system or dataset; medication, laboratory, demographic, or administration | Distinguishes sources that contain different kinds of records |
| Owner and steward | Accountable group and operational contact | Establishes who can approve use and resolve source questions |
| Access route | Interface, curated extract, or other supported route | Distinguishes the data source from the mechanism used to obtain it |
| Update pattern | Refresh cadence, expected latency, and known service expectations | Allows assessment of whether information is available when needed |
| Intended use and limits | Model input or workflow purpose; important exclusions | Prevents unsupported interpretations of a source |
| Review details | Last reviewed date, reviewer, and next review trigger | Keeps the catalogue current as systems and responsibilities change |
Build the Inventory From the Use Case
The inventory should be scoped to a dosing service and its intended workflow, rather than attempting to catalogue every clinical dataset in an organization. For each required input, list candidate sources, then document what each can support. A source can be relevant without being approved for operational use; make that status explicit. This prevents a preliminary possibility from being mistaken for a validated dependency.
A practical inventory can use one row per source, with separate rows when one system contains operationally distinct datasets or feeds. It should not collapse an order and an administration record into one entry merely because both concern medication. Nor should it combine results and demographic covariates into a generic “patient data” row. The entry should let a reviewer locate the right owner and ask a focused question about the data’s availability and purpose.
Worked Example: Inventorying Sources for Tacrolimus Dosing Support
Hypothetical service. A transplant clinic plans a tacrolimus dosing-support workflow that uses a prescribed regimen, documented administrations, a measured tacrolimus concentration, and selected patient covariates. The following candidate sources and operational details are hypothetical.
Medication orders. The inpatient/outpatient electronic health record (EHR) medication-order dataset is owned by the clinical informatics group, with medication operations as its steward. It is refreshed every 15 minutes. Its intended use is to identify the prescribed regimen. The inventory notes that an order is not proof that the dose was taken or administered.
Administration records. The EHR medication administration record (MAR) is owned by nursing operations, with the MAR application team as steward. It is updated when administration documentation is entered, with a typical 10-minute delay. Its intended use is to supply documented administration events; its limits include that the record reflects documentation and may not independently establish ingestion.
Laboratory results. The laboratory information system (LIS) result feed is owned by laboratory operations, with the interface team as steward. It refreshes every 30 minutes, and the laboratory estimates results are generally available within 20 minutes after verification. Its intended use is to supply verified tacrolimus concentrations for individual model updating. The inventory should not describe preliminary results as equivalent to verified results.
Demographics. The EHR registration dataset is owned by health information management, with the registration data team as steward. It refreshes nightly. Its intended use is to supply selected demographic covariates, such as date of birth, subject to the use case’s requirements. The nightly schedule is recorded because it differs from the more frequent medication and laboratory feeds.
The resulting entries identify four distinct sources, owners, stewards, update patterns, and uses. They also prevent two consequential assumptions: that the prescription is the administered dose, and that all EHR information has the same refresh schedule. The inventory does not yet define how the records are semantically aligned or checked for clinical quality.
Assessing Whether an Update Pattern Fits the Intended Use
An inventory is more useful when it relates update information to the use case’s stated need. Suppose a decision requires a verified laboratory result to be available no later than 12 hours after verification. If a source refreshes every 6 hours and its documented processing delay is at most 2 hours, a conservative upper bound on availability delay is 8 hours, assuming the refresh schedule is reliable and the delay estimate applies to this feed.
Under those assumptions, the source’s expected delay fits the 12-hour requirement, with 4 hours of margin. This is a feasibility check, not evidence that every result will arrive within 8 hours. If the schedule is only typical, not guaranteed, the inventory should say so and the service team should not treat the calculated bound as a formal service level. If the requirement is tighter than the expected delay, record the mismatch rather than quietly treating the source as suitable.
Worked Example: Comparing Candidate Laboratory Sources
Hypothetical requirement. A dosing workflow needs a verified concentration available within 4 hours after verification. Two candidate feeds provide the same type of result. Feed A refreshes every 1 hour, with a documented processing delay of up to 30 minutes. Feed B refreshes every 6 hours, with a processing delay of up to 30 minutes. Assume each refresh schedule is reliable, and use the conservative bound of refresh interval plus processing delay.
For Feed A, the bound is \(1\text{ h}+0.5\text{ h}=1.5\text{ h}\). Because \(1.5\text{ h}<4\text{ h}\), its documented update pattern is compatible with the stated availability requirement, under the assumptions given.
For Feed B, the bound is \(6\text{ h}+0.5\text{ h}=6.5\text{ h}\). Because \(6.5\text{ h}>4\text{ h}\), its documented update pattern does not meet that requirement. Feed B might still serve a different purpose, such as retrospective analysis, but the inventory should not label it suitable for this time-sensitive use.
This comparison depends on the stated schedule and delay being credible for the relevant feed. It does not establish that either source contains correct or complete results; it only evaluates the availability constraint described in the hypothetical use case.
Ownership, Maintenance, and Review
A source catalogue loses value when its entries are not maintained. Assign responsibility for reviewing each entry and specify practical review triggers: a system replacement, a change in feed schedule, a change in source ownership, or a new dosing use that depends on different information. Record the date and outcome of each review. An entry with an unknown owner or undocumented update pattern is not complete merely because a system name is present.
Ownership should be documented at the level that can act. “Hospital” is usually too broad; “laboratory operations” or a named data stewardship team is more actionable. Where accountability is split, record both roles and what each is responsible for. For example, laboratory operations may own the result source while an integration team maintains the access route. This distinction helps identify whom to contact about data meaning versus feed operation without confusing one responsibility for the other.
Worked Example: Recording a Change in an Administration Feed
A hypothetical clinic inventory lists a MAR feed owned by nursing operations, stewarded by the EHR medication-record team, and refreshed every 10 minutes. The clinic is told that a planned system change will move this feed to an hourly batch. The dosing workflow’s stated requirement is that administration information be available within 30 minutes.
Before the change, the listed 10-minute refresh is consistent with the 30-minute requirement, assuming no additional delay. After the change, the refresh interval alone is 60 minutes, and \(60\text{ min}>30\text{ min}\). The inventory therefore needs review before the new schedule is treated as suitable for that use. The owner and steward should confirm the new operating details; the service team should record the changed cadence, the relevant requirement, and the resulting status.
This process does not decide how to resolve individual records or whether the clinical workflow should change. It makes a dependency change visible and directs it to accountable people before an outdated inventory entry is relied upon.
Common Failure Modes and Alternatives
A common mistake is to list only system names: “EHR,” “LIS,” and “pharmacy system.” The wrong reasoning is that a familiar system name is enough to identify the source. It is not: one system may contain orders, administration documentation, and registration data with different owners, update schedules, and uses. The correction is to catalogue the relevant dataset or feed, not merely the vendor or application.
Other warning signs include an owner field that names only a technical interface team, an update entry that says “real time” without a defined meaning, and an intended-use field that says only “dosing.” These omissions make it difficult to judge accountability or operational fit. Use an explicit unknown when a detail has not been confirmed, and assign a person or group to resolve it; do not replace uncertainty with an unverified claim.
A spreadsheet is often a suitable starting format for a small, stable use case: it is easy to review and can expose gaps quickly. For a larger service with many teams or frequent changes, a governed data catalogue or service registry may support ownership and review more reliably. A full enterprise catalogue can be unnecessarily broad for an initial dosing workflow, while an informal spreadsheet can become stale if no one owns it. Choose the lightest approach that supports clear accountability and planned maintenance.
An inventory has limits. It describes what teams believe a source provides and how it is expected to operate; it does not prove that the source is clinically fit, that a feed always meets its schedule, or that records from separate sources can be interpreted together. Those questions require further implementation work. Keep the catalogue focused on source provenance, accountability, availability expectations, and intended use so that it remains a usable operational reference.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A dosing service uses an EHR medication order and an EHR administration record. Why should these be separate inventory entries?
- A laboratory feed refreshes every 2 hours and has a documented processing delay of up to 45 minutes. What conservative availability-delay bound follows from the stated assumptions?
- A source entry lists “IT” as owner and “real time” as its update schedule. Name two clarifications needed before relying on it.
- A demographic dataset is updated nightly. What should the inventory state if the intended use requires information to be available within 2 hours of a change?
Solutions. (1) The sources represent different kinds of records and support different claims: an order describes a prescribed regimen, while an administration record documents a dose as given. Their owners, update patterns, and intended uses may also differ. (2) The conservative bound is \(2\text{ h}+0.75\text{ h}=2.75\text{ h}\), assuming the refresh interval and processing-delay estimate apply reliably to that feed. (3) Identify the accountable organizational owner and an operational steward or contact; define what “real time” means, including the update pattern and any known latency. (4) Record the nightly cadence and the 2-hour requirement, flag the schedule as not shown to meet that need, and assign confirmation or escalation to the accountable owner. Do not mark it suitable solely because the data are available in the system.