The Trustworthy Technology & Innovation Consortium (TTIC) was co-founded by Sherri Douville and Mitch Parker around a practical problem they had seen repeatedly in healthcare: increasingly consequential technology crosses organizational and professional boundaries, while responsibility for making it trustworthy remains fragmented.
CIOs see infrastructure and enterprise technology. CISOs see security and technical risk. Physicians see clinical consequences. Engineers see architecture and system behavior. Lawyers see liability, privacy, compliance obligations, and accountability. Executives see organizational, financial, strategic, and operational consequences. Each perspective is necessary. None is sufficient on its own.
TTIC was created to bring together the stakeholders required to build, deploy, integrate, implement, maintain, monitor, and advance trustworthy technology, thereby helping take IEEE/UL 2933 from a standard into real-world practice and market adoption.
Its role is deliberately bounded: convene cross-disciplinary expertise, advance standards and shared frameworks, publish principles and thinking, and help define what trustworthy technology requires across its lifecycle. TTIC is not positioned as a training organization, consulting practice, or implementation services organization.
It started with a book that did not exist
TTIC began with a question asked in a bookstore.
At HIMSS, Sherri Douville went looking for Ed Marx at a book signing. He had been called into an emergency meeting at Cleveland Clinic, where he was Chief Information Officer, and never made it to the table. Rather than leave, she asked the person hosting the store whether they carried anything on mobility in medicine. They did not, and the host said she wished they did. The person she was asking was Kris Mednansky, an editor at Taylor & Francis, who became her publisher.
What followed was not luck. She wrote a proposal and assembled a roster. Ed Marx sponsored an unknown and unproven author through a first-time publishing process, spending his own standing on someone who had not yet earned it. That produced Mobile Medicine, then Advanced Health Technology, then a book series.
Editing those books is where the founding problem became visible. A book on clinical mobility cannot be written by one profession. It requires the CIO, the CISO, the physician, the engineer, the lawyer, and the executive to agree on what is true, in one document, with their names on it. Doing that repeatedly showed how rarely those professions had ever been asked to do it, and how much depended on their being able to.
TTIC is that work continued in a form that does not end when a book is published.
Trust is the price of entry
Trust is the price of entry in medicine. It cannot be bought, and it does not transfer from another industry.
That constraint determined TTIC's form. The question was never how to persuade physicians that AI governance matters. It was how medicine already decides what to trust.
Medicine answers that with accreditation. Every physician's continuing education is accredited, and that accreditation does not check whether the teaching is correct. It checks how it was made: who was in the room, what their interests were, how disagreements were settled, who could object.
Accredited standards development runs on the same machinery. Not every document called a standard is made that way, and accreditation is what separates the ones that are. TTIC was built as a standards consortium rather than as a think tank, an advisory practice, or a research institute because that is the only form medicine already has a reason to trust.
Trust is a system property. No single profession can make advanced technology trustworthy.
Notes for particular readers
Each profession has its own way of deciding what to trust. These notes address three of them.
A note for technical colleagues
Most engineers already build on IEEE standards daily without thinking about it. 802.11 for wireless, 754 for floating point, 1588 for time synchronization. Nobody argues about whether wireless should have a standard, because the alternative is obvious: nothing interoperates and nothing can be relied on.
Medicine adds one requirement on top of that. When software is wrong in most domains, the cost is a defect report. In clinical care the cost can be a person, and someone will later be asked to account for what happened. That moves the bar from whether it works to whether you can show how it works, who authorized it, and what it was tested on.
Accreditation is the machinery that makes that showable. It does not certify that an answer is correct. It certifies that the process producing it was balanced, disclosed, and documented, and that someone could object. That is the same reason accredited continuing medical education carries weight with physicians, and it is why standards are the currency of trust in this market rather than benchmarks or demos.
IEEE/UL 2933 applies that to clinical AI data. Its TIPPSS framework, covering trust, identity, privacy, protection, safety, and security, is the contract that lets systems built by different teams be relied on together. Writing and maintaining that kind of contract, with the people who have to live under it in the room, is what TTIC does.
A note for security practitioners
A fair objection: most of this looks like status. Committees, titles, attestations nobody tests.
Often true. A standard requiring that a policy exist is theater. A standard constraining what a record must contain, who may authorize a decision, and what evidence counts is an engineering constraint.
IEEE is probably not in your standards universe, but a standards body already is. ISO 27001 is a standard, issued by a standards body, with accredited certification bodies auditing against it. NIST, CIS, OWASP, and MITRE are frameworks and knowledge bases: voluntary, useful, and not certifiable in the same way.
That distinction is the bridge. IEEE/UL 2933 is a standard in the same institutional sense as 27001, from a peer body. What it specifies is different. ISO 27001 governs your information security management system, meaning which processes you run and how you run them. IEEE/UL 2933 specifies what clinical data and devices must carry as they move between systems, under a framework called TIPPSS: trust, identity, privacy, protection, safety, and security. Identity and provenance become requirements on the data itself, not on your documentation of it.
The practical difference: a management system standard tells you what to have and how to operate it. An interoperability standard tells you what has to be true at the boundary, where your system hands something to someone else's.
The test for whether any of this is real is whether the people claiming it have published findings against themselves. Attestations are cheap. Adversarial results on your own production system are not. That test applies to TTIC as much as to anyone it convenes.
A note for colleagues in research
Standards development and accredited continuing medical education are both parallel process-accreditation regimes. Neither adjudicates whether a conclusion is correct. Both impose requirements on how it was reached: balance of interests among participants, disclosure, defined consensus thresholds, documented due process, and a route of appeal. ANSI accredits standards developers on those grounds. ACCME accredits CME providers on grounds that closely parallel them.
Peer review belongs to the same family. A finding carries warrant because of the procedure that produced it, not because a reviewer reproduced the result. All three locate trustworthiness in procedure. They differ mainly in which procedure they recognize.
Which is also why standards work is nearly invisible to academic instruments. IEEE/UL 2933 and ANSI/HSI 2800 carry document numbers rather than DOIs, accumulate no citations, and give no outward sign that a single clause took three years to settle. The two fields reward opposite things: scholarship rewards novelty, standards reward durability, and a novel standard is usually a bad one. The review is not lighter for it. Consensus has to satisfy competitors who would prefer the clause did not exist, implementers who have to build it, and counsel who will read it back in a dispute.
There is now a substantial literature on AI governance that does not cite the documents that actually govern. Two communities working the same problem, with almost no contact surface between them. TTIC exists in part to be one.
Editorial boundaries
TTIC is not positioned as a training organization, consulting practice, or implementation services organization.