HI300 Unit 4 Interface Analysis Example

What Has to Cross the Wire: A Unit 4 Interface Analysis of the Messages Passing Between a Fetal Surveillance System and the Hospital Record, From Admission to the Newborn's First Identifier

[Student Name]

Purdue University Global

HI300: Information Systems for Health Care

Unit 4 Interface Analysis

[Instructor Name]

[Date]

The hospital, its systems and the message volumes are composite; the message standards and the sources cited are real.

Scope

The composite hospital runs a main electronic health record for registration, orders, results and documentation outside labor and delivery, and is adding a fetal surveillance system that displays and stores tracings and nursing annotations on the labor unit. The two systems must agree on who the patient is, where she is, what has been ordered and what has been documented. Most hospitals still pass this kind of information through HL7 version 2 messages, a standard that defines message types by the event that triggers them (Benson & Grieve, 2021). This analysis covers six flows and leaves billing out of scope.

The Six Flows

Flow 1: registration to surveillance. When a patient is registered to the labor unit, the main record sends an admission message, ADT A01, carrying the patient's name, medical record number, encounter number, date of birth, attending provider and room. The surveillance system must not create a patient on its own; it waits for this message. If the message fails, the nurse sees a monitor tracing with no name, and the unit's procedure is to call the registration desk rather than type a name. Flow 2: transfers. When the patient moves from a labor room to the operating room for a cesarean birth, the main record sends a transfer message, ADT A02. The surveillance system must move the same patient and her tracing to the new location without starting a new record. During the composite hospital's test, a transfer sent before the room was set up in the surveillance system created a second patient, the duplicate census entry the nurses had already seen on paper. Flow 3: orders. Oxytocin infusion orders and the order for continuous monitoring travel from the main record to the surveillance system as order messages, ORM, so the nurse can document against them at the bedside. Flow 4: results. Laboratory results relevant to labor, such as blood type, antibody screen and group B streptococcus status, travel as result messages, ORU, and display in the surveillance system's summary. Flow 5: documentation back to the record. Nursing annotations and the delivery summary travel from the surveillance system to the main record as result or document messages at set intervals and at discharge, so that the legal record holds them. The tracing itself is usually stored in the surveillance system and linked from the main record rather than copied. Flow 6: the newborn. At birth, the newborn needs an identity in both systems. The main record creates the baby's registration, often with a temporary name such as Baby Girl and the mother's surname, and sends an admission message. The surveillance system must link the newborn to the mother's encounter. Two of the six flows fail in the same way: a real event happens before the system that should announce it has done so. The transfer reaches a room that does not exist yet, and the baby is born before anyone registers her.

Failure Points and Mitigations

The transfer failure is a configuration problem. The fix is to build every operating room and recovery bay as a location in both systems before go-live and to test each transfer path with a composite patient. The interface team also agreed that an unmatched transfer should stop in a queue for a person to resolve, not create a new patient. The newborn failure is a workflow problem. In the test, registration of the newborn happened about forty minutes after birth, and in the meantime nurses had no place to record the first assessments. The recommended mitigation is a pre-registration of an expected newborn at the mother's admission, activated at birth, a practice many birthing hospitals use. Without it, delivery details get written on paper and entered twice, which is where errors in identification begin. Patient identification failures are among the most common harms tied to health IT, and interface design is one of their sources (Ash et al., 2004).

What Must Survive the Trip

For every flow, four identifiers must arrive unchanged: medical record number, encounter number, patient location and, for the newborn, the link to the mother. Timestamps must carry the time zone and come from one source, since the evaluation of products had already found a monitor clock ninety seconds off. The interface team will test each flow with composite patients for normal events and for three abnormal ones: a message sent twice, a message out of order and a message for a patient who has been discharged. Monitoring the interface queue daily during the first month after go-live is part of the plan, because errors in message traffic tend to surface as wrong-patient or missing-data events weeks later rather than as alarms (Sittig & Singh, 2010).

References

Ash, J. S., Berg, M., & Coiera, E. (2004). Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. Journal of the American Medical Informatics Association, 11(2), 104-112. https://doi.org/10.1197/jamia.M1471

Benson, T., & Grieve, G. (2021). Principles of health interoperability: FHIR, HL7 and SNOMED CT (4th ed.). Springer.

Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality and Safety in Health Care, 19(Suppl 3), i68-i74. https://doi.org/10.1136/qshc.2010.042085