Yapay zekâ araçlarını sağlık kayıtlarına bağlamak

Bu yazı şu anda yalnızca İngilizce olarak mevcuttur. İncelenmiş Türkçe çevirisi daha sonra eklenecektir.

It is common to hear that a clinical AI tool “worked in the pilot” and then stalled. When you look closer, the model is rarely the problem. The problem is where the tool sits: in a separate window, with a separate login, needing data copied in and results copied out.

Every extra step is friction, and clinicians already spend a large share of their working day in the EHR. An event-log study of 142 family physicians found nearly six hours of EHR work in an 11.4-hour day. A tool that adds clicks to that day has to save a great deal to break even. That is why we think integration should be designed first, not bolted on at the end.

What good integration means

Integration is not a single thing. It has at least four layers.

Data in. The tool must read the data it needs, from the systems where it lives, at the time it is needed. For clinical systems that often means EHR data. For operations it means databases such as PostgreSQL and ERP-connected sources.

Context. The tool must know who is using it and for which patient or case, without asking the user to re-enter either. That context is also what enforces permissions.

Results out. Outputs must land where work happens: a draft note in the EHR’s note editor, a pedigree in the genetics record, a report in the operations review. Outputs that live only in the AI tool are outputs someone will forget to copy.

Workflow. The tool must fit the order in which people actually work. A note drafted after the next patient has already been seen is less useful than one ready before.

What standards solve

HL7 FHIR (Fast Healthcare Interoperability Resources) defines a common way to represent and exchange clinical data, such as patients, observations, medications, and documents, through modern web APIs. It gives tools a shared vocabulary for data in and results out.

SMART on FHIR adds a standard way for apps to launch from within an EHR, receive the current user and patient context, and be authorised using web standards. The SMART project began in 2010 at Harvard Medical School and Boston Children’s Hospital with the goal of apps that could be written once and run unmodified across different health IT systems; it adopted FHIR as its data layer, as Mandel and colleagues describe.

Together, these standards address much of the “data in”, “context”, and “results out” layers, where they are implemented.

What standards don’t solve

Standards reduce integration work, but they don’t remove it:

• Coverage varies. Not every EHR exposes every resource, and not every institution enables every capability.
• Local meaning varies. Two hospitals can both use FHIR and still code the same concept differently. Mapping and validation are still needed.
• Workflow isn’t standardised. A standard can say how a document is stored; it can’t say when in a clinic day a clinician wants to review it.
• Operations systems follow different patterns. Production and ERP data usually sit in relational databases with their own schemas. There, integration means understanding the schema, metadata, and relationships, which is why Operus reads them before answering any question.

How we approach it

We start every engagement by mapping workflows, integrations, and success metrics before building. In practice that means:

1. Trace the work. Where does the information originate, who touches it, and where does it need to end up?
2. Choose the least disruptive entry point. Launching inside the existing system is usually better than a new destination.
3. Carry identity through. Use the institution’s identity and role model end to end, so permissions hold everywhere.
4. Write results back in place. Outputs should arrive where people already look, clearly marked as drafts where they are drafts.
5. Plan for failure. If an integration is down, the clinical workflow must still work without the tool.

Why this comes before the model

A slightly better model in a poorly integrated tool helps no one. A well-integrated tool with a good-enough model can change a working day. The intelligence matters, but it only reaches patients and teams through the interface. So we design the interface first.

Kaynaklar

1. Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. J Am Med Inform Assoc. 2016;23(5):899–908. doi.org/10.1093/jamia/ocv189
2. HL7 International. FHIR (Fast Healthcare Interoperability Resources) specification. hl7.org/fhir/
3. Arndt BG, Beasley JW, Watkinson MD, et al. Tethered to the EHR: Primary Care Physician Workload Assessment Using EHR Event Log Data and Time-Motion Observations. Ann Fam Med. 2017;15(5):419–426. doi.org/10.1370/afm.2121