Re: VRRS - couple of questions

[Aerik Sylvan]

A few more (more mundane) thoughts:

Mike, you said, "For a veterinary clinical transport mechanism, I see a number of good proprietary and open-source  solutions out there... At this point it may make sense to allow them to compete.  That does make it somewhat harder for implementers.  But it may be better than us pretending to be able to pick the winner."

I can't find any fault in that reasoning whatsoever.  

But on the question of the *request* structure, let me play Socrates for a moment and ask this:  Shouldn't "any" information (I'm thinking of information relevant to the  medical history, patient, stuff like that) in the request document be reflected in the report generated for that request?  Obviously an off topic sideband conversation could happen, and it would be irrelevant, but let's assume only relevant information is contained in a request.

If that's the case, then isn't thinking of a request as a subset of a report a very logical option?  (I'm not suggesting request be *required* to be represented as a subset of VRRS - only that if a structured request is necessary for someone's workflow, that it is a sensible option.)

Additionally, if <order> is a required field, then doesn't that place some constraints around how the request is handled?  Or does <order> map to a study or studies?  I saw it maps to "inFullfillmnentOf" and read that section in the "Implementation Guide..." but still don't quite understand it.

And on that note, I've been digging deeper into the documents I find on the website to try to understand some of the details in the document spec.  What is the relationship of the "Implementation Guid for Veterinary Imaging Reports.docx" to the "VRRS Diagnostic Imaging Report Requirements Document"?  Is there another place I should look if I'm trying to understand the intention of certain fields (like ./order or  ./order/imageDeliveryTime ?)

Best Regards,

Aerik

On Thu, Jul 25, 2013 at 8:30 PM, Stuart Turner <turner...@gmail.com> wrote:

My take on this, FWIW

Not to beat a dead horse, but VRRS is a non-normative structured document specification. It's not at a stage that would qualify it as an open standard nor is the VRRS group a Standards Development Organization. It now has the capacity to meet minimum information exchange needs such as provenance metadata (patient demographics, provider, etc.) within the context of a radiology report. It needs to be iteratively refined by an early adopter and I grok the need to do this with support for establishing the exchange environment. But VRRS remains independent of workflow (orders) and I second Mike's suggestion about pointing to other prevailing standards and methods for doing this, but with my qualifications discussed below. 

VRRS shares the vision, in-part based on its HL7 CDA genetic constitution, of eventually exposing more explicitly (and interestingly) the richer semantics embodied in a report for machine processing. An impression or radiographic diagnosis can extend beyond human readability to be computationally processed so that it may be merged with a dynamic list of patient observations or problems in an EHR where they are semantically annotated with one or more shared ontologies (e.g. SNOMED CT, RadLex, Foundational Model of Anatomy, Animals in Context Ontology and/or LOINC) for clinical decision support. It becomes an agent to augment and improve the quality of patient care. While this 2013 paradigm of electronic interchange of blobs of clinical content greatly improves upon the fax machine, VRRS's ultimate goal is about the semantics intrinsic to a radiology report. 

To realize this vision, the exchange mechanism needs to 'eventually' support some of these semantics as well (among other things), but it remains a distinctly separate endeavor. We need to avoid the muddling and admixing of an exchange specification that is too narrowly scoped to the current needs (in vivo imaging). It should be cross-cutting and informed by other domains (clinical and anatomic pathology, surgery) and among the array of their document exchange needs (including discharge summaries or the more longitudinally scoped continuity of care record). VRRS is just one entity that helps to inform the design of "one to many" open exchange methods. It should not be the parent entity that develops it alone. Constraining VRRS to build an exchange specification is moving in the wrong direction (downward). More so, using the CDA DNA for this purpose doesn't make sense to me anyway.

There are technology agnostic requirements that are more immutable that need to be surfaced and placed at a higher level (logical) than a given technology stack or emergence of a popular exchange provider or software. From a shared interoperability perspective, this discussion should continue at an appropriate level (logical, to partially implementable, layers of abstraction). We encourage multiple solutions and we need to provide a method of conformance testing for whoever wishes to build upon this.

The veterinary informatics community should continue marching forward, independent, but informed, by VRRS, by describing the requirements for many things, such as: a) privacy (client/clinician/organizational expectations regarding exposure and reuse); b) confidentiality (how assertions embodied in these artifacts via a confidentiality code for example are compared to the privacy conformance statements in a); and c) security (where methods to ensure a and b are met). 

Therefore, privacy falls under the domain of the veterinary informatics, business and ethics community (the domain experts). Confidentially falls within those developing specifications/standards (the architects). Security is the responsibility of those doing implementations. 

There is also file integrity (comparing hashes to evaluate for tampering or lossy transmission), non-repudiation, de-duplication, target assurance (probabilistic and deterministic matching of patients in a federated environment), concurrency and its effect on safety (knowing if the the document you are reading is current, stale or obsolete) and context (is there enough information carried in the document alone for me to understand what this is really all about?). Yes, there's probably more.

This is not about a difference between the medical community and technology. Every piece of this complicated puzzle needs to be cognizant of the medical environment for which it operates. We are not talking about an API for 6-second videos or who is the current mayor of Starbucks at Hollywood and Vine. This is a deeply complicated, potentially medico-legally contentious environment. Most importantly, this environment must absolutely ensure patient safety and efficient evidence-informed outcomes, and ultimately improve upon it. Legal risk is not only dependent on extant law. It also entails risk due to the ability to convince a jury otherwise. I would point to the brilliant work of Osler, Hoskin and Harcourt (1992) in the "10 Commandments of Computerization" @ http://www.cips.ca/resources?q=practices . 

Serializations and web services methodology change constantly. Mike is right to convey the importance and review of the prior art and the weight of a significant number of implementations of HL7 version 2.x. If v2 was not around today, would we do it this way again? Hell no. I'll say it again: HELL TO THE NO!. Despite the brilliance and good intentions of its designers, it's turned out to be a messy and painfully inelegant morass (my curmudgeonly glass half-empty perspective). But this body work is compelling and there is some expertise within the veterinary community.

Will something like JSON-LD or Turtle be a better paradigm for the future? I have no idea, but I hope so. Will RDF (RDF/XML) become the canonical exchange language? Maybe. Do we need to wax on about the nuances of WSDL vs. WADL? There will be always be a technology du jour and painful regret and self-deprecation for choosing the last one. Some of us despair over watching everyone take a left-turn behind us.

Regarding Dennis's note about Github, we are working on the feasibility of what is provisionally (temporarily?) entitled the "AVI Design Foundation" (it's early, ideas welcome; note that "software" and "standards" were intentionally not used). This would be modeled similar to the Apache Foundation where AVI supports small boutique open standards development projects like VRRS, starting them off with a provisional incubator status until they become self-sufficient. It would require adequate governance with a minimum number of precepts such as recommendations for open licensing (separate for content, source and data), tools for issue/project tracking (Redmine), collaborative documentation (Mediawiki), an open versioning repository (Github) and one or more funding models (e.g. from Kickstarter to Payswarm).  The project would enjoy the broader support of AVI for championing the projects during the organizations interactions with other groups, presuming we can collectively get our act together. Your feedback is greatly needed. We will be standing up a proof-of-concept project within this environment. I'll broadcast this shortly if we have sufficient interest by the various stakeholders (it regards Context-Aware Information/Knowledge Retrieval).

Speaking for AVI, we support anyone in this space, including VetRocket and hopefully as an organization we can provide sufficient resources and guidance and become more agile and responsive. While I can't speak for VRRS, I support Dennis's notion of "doing" more than "proposing" as well.

Lastly, I'm excited about this these discussions and this thread in particular, but don't be shy. They really should occur openly on the list. 

~ Stuart

On Jul 25, 2013, at 12:53 PM, Dennis Ballance wrote:

Aerik,

 

An effective proof-of-concept that leverages existing open standards should be easier to promote and adopt than something proprietary. Also, I see a difference between what you are doing and what Asteris is proposing (mainly in the fact that you are “doing” while they are “proposing”).  I also agree that the full loop would be an ideal end point, though the lack of a solution on the human side for generic request-making creates a much tougher slope to climb for us. ;)

 

Have you considered publishing elements of your work-in-progress to the VRRS list? If you got others contributing, it would be much more of a community-generated solution than a proprietary solution that VetRocket is trying to push for market advantage. In fact, we can set up a github for this now at AVI’s new github site, and make it available as it is growing.

 

--Dennis

 

From: Aerik Sylvan [mailto:asy...@gmail.com] 
Sent: Thursday, July 25, 2013 11:57 AM
To: Michael Martin
Cc: Dennis Ballance
Subject: Re: VRRS - couple of questions

 

Thanks for the links - I've looked at his code and also found a couple of other scripts that generate OIDs from UUIDs.

 

Regarding "documents" and requests, etc.  I understand the scope of VRRS - it it strikes me that scope is largely from the perspective of the medical communitiy.

 

The perspective I'm taking is more from an IT standpoint - specifically, looking at the big picture from the viewpoint of customers who want end-to-end solutions.  

 

If "The aim of the VRRS are to develop an open document exchange structure for transmitting telemedicine reports between computer systems" then one can certainly take the position that the transport of the report and the structure of the request is out of scope as the problem you're trying to solve is for people to have a standard report structure so that it can be parsed by different systems... But the very *next* problems are the transport and the request document [using document in a more generic sense of the word, not the stricter medical record sense].

 

If we have customers who want to send requests and reports around, we could definitely create a closed system with a function that generates a VRRS document at the end, which they could then forward on to whomever via whatever means.  

 

But if we do that, we're just creating another silo.

 

I am interested in (and Vet Rocket is too) creating a flexbile, open solution that will help prevent silos.  Even if it's not part of VRRS, and even if VRRS doesn't officially endorse it, I want to create something such that people say, "Rather than reinvent the wheel, let's use that.  It's free, it's simple, it's flexible, and it works."

 

To that end, I myself am trying to invent as little as possible.  Thus the proposal for a RESTful document transfer protocol (it has a few features, but I felt they were critical and generic).  I also do not want to invent a request... it seems to me that a) a request is a subset of a report and b) implementers who already need to parse and generate VRRS documents will have an easier time developing solutions if they can parse and generate requests using much of the same code. 

 

So, in a nutshell, I'm going to recommend that we use a subset of VRRS as a request document - even if there's nothing official in doing so.

 

Thanks again for all your help.

 

Aerik

 

 

 

On Thu, Jul 11, 2013 at 5:12 AM, Michael Martin <mma...@clemson.edu> wrote:

Aerik,

 

I think the key point Dennis is making is that VRRS is a “document” standard.  You really need to think about what constitutes a “document” as part of a complete medical record.  Radiology reports are documents, surgical reports are documents, referral reports are documents.  Nursing notes, care plans, individual orders, records of substance administrations, are not.  They are other kinds of entries. 

 

While VRRS is based on CDA which is HL7 version 3, I would suggest looking at version 2 for orders and order responses.  The kind of “Do this,” “To do that I would need this,” “OK then do this other thing,” “I’m finding this, should I do this additional thing” “Yes go ahead and do that.” Conversation normally takes place as a series of messages of type order and order response.  Now that HL7 standards are free to read and use, you can go to www.hl7.org, agree to the IP policy and download the appropriate version.  If you also deal with human public health or healthcare I would look at 2.5.1.  If purely veterinary get 2.6 or if you want to be cutting edge 2.7.  Most of the human world can’t get past 2.5.1 because so many regulations are written around it.  Look at Chapter 4, Orders.  ORM and ORR for general orders, OML and ORL for lab orders and OPL and OPR for lab orders on a population or location basis such as accessions of Brucellosis or Avian Flu Herd/Flock tests.  Whether you end up using the standard or not, there is a lot to learn from 20 years of experience that is reflected in those standards.

 

If you wanted to use the HL7 standard, you wouldn’t just say, “Send an ORM message.”  The next step is to build a profile and an implementation guide.  That step does require HL7 membership.  But then anyone using your IG can do so by simply agreeing to the HL7 IP policy.

 

I’m not sure on the UUID/OID issue.  In every case I’ve run into UUIDs or OIDs are either specified in an implementation guide or managed off of an organizationally maintained arc which is then referenced through a resource set up by the group setting up the messaging.  For example the NAHLN has an OID registry run by Iowa State for OIDs generated off the arc issued to us by HL7.  For use in Document ID, UUIDs are prohibited.  So the issue just becomes how to issue a known unique OID to each document.  I have suggested that VRRS obtain an arc and issue OIDs to participants.  Each document then just gets a new final integer group on the OID. The recipient need not “understand” the Document ID, they just need to know that it identifies one and only one document in the universe.

 

Say VRRS gets 2.840.1.2.3 from ITU or somebody

Practice A gets 2.840.1.2.3.1 from VRRS

Practice B gets  2.840.1.2.3.2

Practice B’s 1 millionth report gets  2.840.1.2.3.2.1000000

(Actually if I was practice B I’d put an intermediate step in there  2.840.1.2.3.2.1.1000000 in case I wanted to create other kinds of OIDs in the future. But that is up to practice B.)

And so on

 

If your documents ALREADY have UUIDs, then the issue of translation would or could come in.

 

I see that David Clunie has a class in his software package that does the translation.  It looks like simple bit twiddling added to the arc 2.25 that is specifically for translated UUIDs.  David’s software is open source so you could reverse engineer it or just use David’s Java code. (With proper attribution and license inclusion, of course.) http://www.pixelmed.com/index.html#PixelMedJavaDICOMToolkit

 

Mike

[Michael Martin]

 

 

From: vr...@googlegroups.com [mailto:vr...@googlegroups.com] On Behalf Of Aerik Sylvan
Sent: Monday, July 29, 2013 2:35 PM
To: vr...@googlegroups.com
Subject: [VRRS] Re: VRRS - couple of questions

 

But on the question of the *request* structure, let me play Socrates for a moment and ask this:  Shouldn't "any" information (I'm thinking of information relevant to the  medical history, patient, stuff like that) in the request document be reflected in the report generated for that request?  Obviously an off topic sideband conversation could happen, and it would be irrelevant, but let's assume only relevant information is contained in a request.

 

I would see more opportunity for standardization around a request message format.  It turns out to be trickier than the results in most cases.  Seems backwards but that is what we find.

 

If that's the case, then isn't thinking of a request as a subset of a report a very logical option?  (I'm not suggesting request be *required* to be represented as a subset of VRRS - only that if a structured request is necessary for someone's workflow, that it is a sensible option.)

 

Additionally, if <order> is a required field, then doesn't that place some constraints around how the request is handled?  Or does <order> map to a study or studies?  I saw it maps to "inFullfillmnentOf" and read that section in the "Implementation Guide..." but still don't quite understand it.

 

The way HL7 CDA is modeled makes some simple things look really complicated.  inFullfillmentOf is really just used to contain an order “number”, type, and priority, so the report can be married back up to the order whether electronic or otherwise.

 

And on that note, I've been digging deeper into the documents I find on the website to try to understand some of the details in the document spec.  What is the relationship of the "Implementation Guid for Veterinary Imaging Reports.docx" to the "VRRS Diagnostic Imaging Report Requirements Document"?  Is there another place I should look if I'm trying to understand the intention of certain fields (like ./order or  ./order/imageDeliveryTime ?)

 

We should really do a human-readable implementation guide that would include that level of explanation.  Since this is an all-volunteer effort some of those things get pushed back.  The Requirements document was more of a development tool to try to be sure we included from CDA all the elements that would be needed for VRRS.

--
You received this message because you are subscribed to the Google Groups "Veterinary Radiology Report Integration Work Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vrrs+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.