Orthodontic Software Interoperability

Leveraging Open Standards

in Orthodontic Software

Sunday, May 5, 2024 9am – 10am CDT
AAO Annual Session in New Orleans, LA
Hilton New Orleans Riverside - Salon 4

toni magni, BME - afm@case.edu

ADA SC Working Group 11.6's Goals

Provide a place where doctors can interact with vendors to make sure their needs are met.
Define "functional requirements" for standards development and implementation.
Coordinate improvement of standards with other SDOs.
Help vendors with open-standards based i14y.

I'm talking about that interaction that was present and required at the initial development stage of a product. That interaction should continue, and this is a great place for it.
Family of Orthodontists, no clinical passion, biomedical engineer, IT, devops, software dev.
I attend the needs of the doctors (not the patients).
I attend the needs of the developers.
Exchange of medical data via open-standards becomes the norm.
Personal Goal: to bring orthodontic domain (and others outside of large institutions, and public health systems) to a level of interoperability in which making use of open-standards is given for granted, similarly to the way it is today for shipping containers.

Presentation Goals

Importance of open-standards based interoperability (i14y).
How to use open standards at your advantage.
Open standards implementation is an asset (not a liability).

Why are we meeting?

The AAO includes i14y in its Policy Manual: “The position of the AAO will be that developers of orthodontic software should implement open and non-proprietary standards for data interoperability when available. In addition, the development of new open, non-proprietary data standards by stakeholders is encouraged.”
The orthodontists want i14y to proliferate.
The developers are unaware of untapped potentials.

Types of i14y

Proprietary/custom
Open-Standards (DICOM, HL7, SNOMED, ...)

Why is i14y an important topic today

Required for AI to ingest, learn and process data
Required for scientific peer-reviewed articles with thousands of data points instead of < 100 patients
Required to integrate with larger HIEs (FSE in Italy), which might eventually become mandatory.
Required to reduce burn out and data loss.

The role of i14y in an AI driven world

What is it even needed for? AI could do all the conversion between devices.
True, but at high price:
- Training and Inference require time and resources (human, electrical, hardware).
- Accuracy is not guaranteed.

It is very hard to take completely unstructured data, or unknown structure structured data, and make sense of it with a very high precision/accuracy, one that will guarantee not to put patients at risk.

We can see this with self driving, where everyone can get a self-driving vehicle to perform extremely well 80% of the time. Its the last 20% or even 5% or even 1% that is the hardest. Humans are not willing to put up with any death caused by machine errors, even though we are willing to put up with deaths caused by human error.

Container example: Technically, today, in the robot era, we don't need a shipping container standard: we can have robots do all of the loading and unloading of oddly sized and shaped bags, boxes, crates, envelopes when unloading and loading trucks, ships and trains. But if you are en engineer, you would know that it is easier to build robots that only have to deal with one or two sized objects. Story: Websites which provide so much detail and limitations to generate secure passwords. What are they doing? They are effectively specifying a "standard" (even though custom/proprietary), for their password. This makes it a lot easier for hackers designing and performing brute-force attacks on these passwords: now they have a reduced/limited dataset of password to deal with. Why help hackers? Have them waste time going through all the easy passwords!

Free Pizza? Where?

Free medical resources and knowledge are usually very expensive

More Free Pizza

open-ortho

When the standards can't do what you need

Standards exist to help technology grow, not to impede it.

Take advantage of it as much as possible.
Extend the standard with whatever you need
Submit your additions to the standard developing committee (SDO).
Be prepared for changes.

When the standards can't do what you need. The standards are not here to slow down technology development, or to create obstacles for it. They are here to help foster it, to make it grow. Therefore, when the standard is not able to cover what you need to do, you should still use it! Do this: use the standard as far as you can, making use of the advantages. extend the standard with whatever you need, being as idiomatic as possible (to the best of your knowledge). All standards have one way or another to add more to them using some kind of "private" or "custom" fields/codes. This will not break the standard, but, yes, it will create a non-interoperable format. Sometimes this is just fine! Because you only need to encode this information for your internal products. If what you are adding needs to be something that should be exchanged with other vendors, submit your new format to the standard committee. SDOs will be very happy to move things forward when there is a direct application and imminent need for it. if you already have an integration lined up with another vendor, go ahead and work it out between the two, while the SDOs are reviewing, whatever you submitted. This way you can also test and provide even better feedback to the SDO. While using a temporary/custom version of the standard, you can organize your code in such a way that the temporary version is only created upon request, and not stored: this will facilitate any changes you might have to do, in order to take care of new versions.

Where to Start

📱 Identify the Product

⚡ Identify the Resources

💵 Quantify Savings

Identify the Product

Identify if there is a product you have which can benefit from adopting open-based standards. Most amount of time and money is saved when using the above mentioned resources at the beginning, or in the early stages of product development, but there are exceptions, e.g. data import from other systems. When designing a system to import data from other systems, passing through a solid standard format can save you headaches. Another example: data export to other systems. When designing an API to allow others to access, you can make use of existing ones, saving time for the design, testing and documentation of the API.

Identify the Resources

Identify the resources you can use for the product/project. Are there resources that your current developers can use today, without having to spend months learning something? Are there things you can do today, without having to hire super expensive consultants to understand which way to go?

Quantify the savings

Once a product and the resources have been identified, you have enough information to understand how much this is going to save you. You will need this value to convince management that this approach is the most convenient one. If you realize that implementing i14y will cost you, there is something you are missing: have you considered the quality? Implementing IHE profiles means ensuring your software complies with enterprise quality communication standards. If you don't implement them, is your solution really as good and complete?

FAQ

What's the point of using a standard if i have to customize it anyways?
Why do all the work? Let AI do the conversion.

Disclosure

Department of Orthodontics at Case
American Dental Association Standards Committee
American Association of Orthodontists
Orthodontic IT (ortocomputer)