RE: VRRS Teleconference

[Dennis Ballance]

Sorry for the late reminder – we have a meeting today.

 

Stuart – do you happen to have notes from last time?

 

--Dennis

Dennis Ballance, DVM

Director of Health Technology Integration

VCA-Antech

 

O: 310-571-6542 | C: 408-497-8295 | F: 928-492-8290

 

 

-----Original Appointment-----
From: Dennis Ballance
Sent: Tuesday, March 29, 2011 10:35 AM
To: Dennis Ballance; 'vr...@googlegroups.com'; 'ot...@asteris.biz'
Cc: McCarthy, Patrick; Stuart Turner; 'Erin Kilpatrick, DVM'; mma...@clemson.edu; Litchfield, Ben; Erin Kilpatrick, DVM; Kevin Grant; Paul Fisher; Peterson, Kris; 'Mark Skeels'; 'Greer, Bob'; 'Schofield, Donald'; Santamaria, Suzanne; and...@vetrocket.com; Aerik Sylvan (ae...@vetrocket.com); Alma Tisher
Subject: VRRS Teleconference
When: Thursday, August 01, 2013 10:00 AM-11:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where:

 

 

Updating the contact info – we have a Gotomeeting account available.

 

1. Please join my meeting.

https://global.gotomeeting.com/meeting/join/234719277

2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

 

United States: +1 (773) 897-3016

Access Code: 234-719-277

Audio PIN: Shown after joining the meeting

Meeting ID: 234-719-277

GoToMeeting®

Online-Meetings made easy®

 

 

 

 

 

 

[Stuart Turner]

sorry, be there in a few

-- 
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.
 
 

[Stuart Turner]

Here's a good example of use case design in an environment I'm familiar with[1]. Note the existence of simple use cases and workflows and designs intended to facilitate initial design (inception) to the enterprise view ("the way most users probably think of it") to system use cases ("specific mapping to technology solutions") [2]. 

This is laid within the Services Aware Interoperability Framewwork environment at NCI/HL7[3], specifically the model driven architecture (MDA) parts ot it. It uses storyboards, simple UML use cases diagrams, textual use cases and concept maps as well as "cartoons" (not based on a formal design model, profile or stereotype). They are helpful at various levels of development and to end-users of various technical sophistication.

To note, the language used in the in the MDA downstream design in this reference here is outdated.

   Conceptual Model

   Logical Model (= Platform Independent Model)

   Implementable Model (= Platform Specific Model)

The activity this morning is falling into the early conceptual design phase. I see VRRS moving downstream via refinement and constraint and publishing at the Logical Level but with support for the documentation of Implementation Level artifacts in concert with one or more developers working on one or more specific transport mechanisms and workflows after this early work is completed (or somewhat in parallel). 

BTW, this is the kind of framework (informative) that I'm proposing for the AVI Design Program/Foundation proposal. A clearinghouse and set of best practices for the broader AVI community in support of incubator projects and standards development.

[1] https://wiki.nci.nih.gov/display/Imaging/Clinical-Imaging+Enterprise+Use+Case

[2] https://wiki.nci.nih.gov/display/Imaging/Structure+of+the+Documentation

[3] http://en.wikipedia.org/wiki/HL7_Services_Aware_Interoperability_Framework

~ Stuart

On Aug 1, 2013, at 10:04 AM, Dennis Ballance wrote:

[Stuart Turner]

To extend a bit more from our earlier discussion today regarding bringing in a domain expert (radiologist) into the early requirements phase of this new workflow, the following is an I wrote[1] showing two examples of putting a simple tool in the hands of a clinician who then works with an informaticist or developer to refine the design.

Concept Map Developed by a Domain Expert

https://wiki.nci.nih.gov/display/SAIF/Concept+Map+Developed+by+a+Domain+Expert

<recursive iteration>

Concept Map Refined by a Business Analyst (e.g. Dennis, Mike or Jason)

https://wiki.nci.nih.gov/pages/viewpage.action?pageId=43356628

[1] https://wiki.nci.nih.gov/display/SAIF/Concept+Map+and+Refined+Concept+Map

~ Stuart

[Dennis Ballance]

I have put up minutes from yesterday’s meeting here (https://sites.google.com/site/vetradiologyreportstandards/home/minutes-1/minutes---2013-08-01).

 

Key action items:

·         VRRS is collecting use cases for a transport protocol. We have discussed at length whether or not to delve into defining a transport protocol. It appears that, despite the semantic interoperability value that the document structure provides, there is a degree of discomfort in leveraging the document without also having a standardized transport to use as well.  A key challenge with this is that more than one telemedicine provider already have transport structures in place or under development, and so have a vested interest in having a “standard” reflect as closely as possible what is already used.  My thought with a standardized transport is that VRRS may be late to the party, and thus not all implementations will leverage it, and that’s OK.  Just as with DICOM, this will be around for a while so when the time comes to revise software, VRRS will be there to be leveraged. And, even if the transport layer isn’t used, the document still can be.

·         Is there a radiologist who would be interested in participating in the use case definition process? A link to the document is provided in the minutes.

 

--Dennis

[Dennis Ballance]

Mike Martin shared this very helpful suggestion with me on how to approach a request protocol technology specification. I now share with you:

 

“You get as many providers as possible to put their solutions out there and look for least common denominators.  Then you ask consumers, also on the committee, to ask if the least common denominator meets all their needs.  If not, you try to find a common way to meet those needs.”

 

Ideally, the consumer needs are captured by our use cases.

 

--Dennis

[David Clunie]

Hi Dennis

I haven't said anything before, but I really think you guys
might be getting a bit carried away.

Now that HL7 CDA is free for use, as long as the VRRS document
is not incompatible with CDA, then you can leverage an entire
family of tools and infrastructure related to CDA production.

Likewise, for CDA (and potentially) VRRS transport, there are a
whole range of existing mechanisms available, ranging from
content agnostic file transfer mechanisms like email, http,
and ftp, through content-aware transfer mechanisms that make
use of "meta data" related to the content.

A case in point is IHE XDS, which is a rather heavy-weight,
SOAP-based web service means to transfer context with medical
meta data indexing. If one looks at the XDS metadata and
how various other "content profiles" specify specialized
behavior for that metadata (e.g., procedure, anatomy, modality
in the XDS-I) case, then the veterinary parallels are obvious.

If one doesn't like SOAP-based web services then one could
make use of potential "RESTful" alternatives to XDS, and one
that comes to mind is HL7 FHIR. See for example, Keith's
posts at:

http://motorcycleguy.blogspot.com/search/label/FHIR

Even if the VRRS document is not very like CDA any more, these
transport mechanisms are both relatively agnostic to the payload
anyway, and can transport any kind of file, theoretically, as
long as there is a source of the necessary meta-data (even
if it doesn't come from the document header).

For push use cases rather than pull, there are all sorts of
standards and tools to, like DIRECT (just secure email with a
trust infrastructure), and XDR (and XDM).

I am no great fan of CDA or XD-* or FHIR or DIRECT personally,
but I would use them if I had to in preference to developing
something else, and I think it would be crazy for the veterinary
community to develop its own peculiar protocols for transfer of
documents, or define its own specific meta-data that didn't build
on what already exists. It would be just as crazy as defining
a new transport mechanism for DICOM images that was veterinary
specific.

I would suggest that at the very least, you do a gap analysis
with XDS, FHIR, etc., against whatever your requirements are,
assuming you haven't already, and then fill the gaps rather than
start afresh. And you may find the FHIR developers responsive
to your specific needs if you find any, since they are keen
to get their foot firmly in the door.

Whatever any existing veterinary telemedicine providers happen
to have already implemented, if they aren't based on some kind
of existing standard, they should just be ignored in terms of
implementation details (though obviously lessons learned from
functionality should be incorporated). As long as any proprietary
implementation can push your documents around, it is harmless,
as long as there are standard mechanisms too.

I would expect that just as the human IT community is struggling
with "picking" a single mechanism and sticking with it, for all
sorts of reasons, not the least of which is the proliferation of
mobile devices, I can't see the veterinary community having an
easier time of it, so I would plan to be flexible and adaptable
and be prepared to implement a variety of transports until which
is to become ubiquitous becomes clear.

I know it is really fun to make up completely new standards and
have total control, and occasionally one can get away with it
like Grahame Grieve has so far with FHIR, but you have to be in
the right place at the right time (as he was with a lightweight
buzzword compliant and well though out solution at a time when
HL7 was in a panic after the total demise of V3 messaging). And
you have to have a lot of spare time on your hands.

But once you start talking about layers and models and service
architectures, you are doomed ...

Just get a very limited set of critical metadata defined that
satisfies 90% of the use cases, and use or adapt something off
the shelf.

David

PS. HL7 SAIF is probably too high a level of abstraction to worry
about, and I gather is struggling to incorporate (and perhaps take
control of and complicate) FHIR.

On 8/2/13 11:58 AM, Dennis Ballance wrote:
> Mike Martin shared this very helpful suggestion with me on how to approach a
> request protocol technology specification. I now share with you:
>
>
>
> "You get as many providers as possible to put their solutions out there and
> look for least common denominators. Then you ask consumers, also on the
> committee, to ask if the least common denominator meets all their needs. If
> not, you try to find a common way to meet those needs."
>
>
>
> Ideally, the consumer needs are captured by our use cases.
>
>
>
> --Dennis
>
>
>
> From: Dennis Ballance [mailto:dwbal...@gmail.com]
> Sent: Friday, August 02, 2013 8:41 AM
> To: vr...@googlegroups.com
> Subject: RE: [VRRS] RE: VRRS Teleconference
>
>
>
> I have put up minutes from yesterday's meeting here
> (https://sites.google.com/site/vetradiologyreportstandards/home/minutes-1/mi
> nutes---2013-08-01).
>
>
>
> Key action items:
>

> . VRRS is collecting use cases for a transport protocol. We have

> discussed at length whether or not to delve into defining a transport
> protocol. It appears that, despite the semantic interoperability value that
> the document structure provides, there is a degree of discomfort in
> leveraging the document without also having a standardized transport to use
> as well. A key challenge with this is that more than one telemedicine
> provider already have transport structures in place or under development,
> and so have a vested interest in having a "standard" reflect as closely as
> possible what is already used. My thought with a standardized transport is
> that VRRS may be late to the party, and thus not all implementations will
> leverage it, and that's OK. Just as with DICOM, this will be around for a
> while so when the time comes to revise software, VRRS will be there to be
> leveraged. And, even if the transport layer isn't used, the document still
> can be.
>

> . Is there a radiologist who would be interested in participating in

> Sorry for the late reminder - we have a meeting today.
>
>
>
> Stuart - do you happen to have notes from last time?

>
>
>
> --Dennis
>
> Dennis Ballance, DVM
>
> Director of Health Technology Integration
>
> VCA-Antech
>
>
>
> O: 310-571-6542 | C: 408-497-8295 | F: 928-492-8290
>
>
>
>
>
> -----Original Appointment-----
> From: Dennis Ballance
> Sent: Tuesday, March 29, 2011 10:35 AM
> To: Dennis Ballance; 'vr...@googlegroups.com'; 'ot...@asteris.biz'
> Cc: McCarthy, Patrick; Stuart Turner; 'Erin Kilpatrick, DVM';
> mma...@clemson.edu; Litchfield, Ben; Erin Kilpatrick, DVM; Kevin Grant;
> Paul Fisher; Peterson, Kris; 'Mark Skeels'; 'Greer, Bob'; 'Schofield,
> Donald'; Santamaria, Suzanne; and...@vetrocket.com; Aerik Sylvan
> (ae...@vetrocket.com); Alma Tisher
> Subject: VRRS Teleconference
> When: Thursday, August 01, 2013 10:00 AM-11:00 AM (UTC-08:00) Pacific Time
> (US & Canada).
> Where:
>
>
>
>
>

> Updating the contact info - we have a Gotomeeting account available.

>
>
>
> 1. Please join my meeting.
>
> <https://global.gotomeeting.com/meeting/join/234719277>
> https://global.gotomeeting.com/meeting/join/234719277
>
> 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or,
> call in using your telephone.
>
>
>
> United States: +1 (773) 897-3016
>
> Access Code: 234-719-277
>
> Audio PIN: Shown after joining the meeting
>
> Meeting ID: 234-719-277
>

> GoToMeetingR
>
> Online-Meetings made easyR
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[Dennis Ballance]

David,

I haven't fully digested your suggestions, but thank you for sending them!
This definitely qualifies under the action item "look at prior art". ;) More
questions to come, I'm sure...

--Dennis

[Michael Martin]

Thanks David,

Leveraging CDA is exactly what we have done. It drove some of our group crazy that we didn't start with an abstract information model. But other than the fact that Patient in CDA is restricted to Person and we had to use an extension namespace to allow NonHumanLivingSubject, we found everything we needed (for the report) in the pure CDA. The schema we publish comes with an XSLT transform to convert to normative CDA with that one legal extension. (OK, one attribute is not yet translated: "Image Delivery Time." Help accepted.) So we are for most purposes a "Green CDA" just to make it easier for developers who don't know CDA to work on documents.

I agree with you we want to use existing mechanism(s) for document transport and not picking one. You make a very clear and convincing argument for that.

I really like the idea of FHIR for the message/service scale things. I put a very graphic slide in my presentation to AVI last month pushing the FHIR concept. We would likely have to develop specific FHIR resources but, again, not starting from scratch! The required structures undoubtedly exist but for some species over-specificity. ;-)

I do not completely agree with one point. "But once you start talking about layers and models and service architectures, you are doomed ..." That kind of analysis has some value. But I think this level belongs off in the ivory tower where it can shed light on the more practicable layers below. Where we have gone wrong is in subjecting prospective implementers to this level of over-abstraction.

Mike

> https://wiki.nci.nih.gov/display/Imaging/Clinical-Imaging+Enterprise+U
> se+Cas
> e
>
> [2]
> https://wiki.nci.nih.gov/display/Imaging/Structure+of+the+Documentatio
> n
>
> [3]
> http://en.wikipedia.org/wiki/HL7_Services_Aware_Interoperability_Frame
> work
>
>
>

[Stuart Turner]

Hi David

You wrote:

I am no great fan of CDA or XD-* or FHIR or DIRECT personally,
but I would use them if I had to in preference to developing
something else, and I think it would be crazy for the veterinary
community to develop its own peculiar protocols for transfer of
documents, or define its own specific meta-data that didn't build
on what already exists. It would be just as crazy as defining
a new transport mechanism for DICOM images that was veterinary
specific.

Exactly. We have essentially been trying to move in the direction you've suggested and to avoid starting completely anew - by better understanding how the veterinary use cases are aligned or are in parallel with existing specifications or standards and how they may be modified (if needed even) to work in this environment. This is why documenting them is suggested to at least bring focus and to expose a shared a common understanding by everyone. At least for me, I've been unable to provide cogent advice unless we better circle the wagons and document things.

There are several independently created exchange "products" that exist or are in development and the concern has been cohesion and awareness of what already exists. The discourse recently has recommended looking at the considerable prior art as you've mentioned, including XDS. There is a veterinary vendor newly implementing an XDS environment for example.

The other as you mention is this separation of concerns - decoupling the VRRS document (or any other structured document specification developed in our realm) from its exchange method and maintaining that agnosticism by viewing it as a payload with a number of options.

While I share Charlie Mead's vision for SAIF (and I've worked on it a bit), I agree that we should not recommend any terse conformance to it in this community right now. This is because it's too nascent and the inherent complexity within this space. I mentioned it to essentially convey the spirit (by example) of using more engineering rigor to identify the unique information and behavioral aspects of veterinary medicine at the logical level (something this appropriate for this group to work on ) and how this may be used to inform the myriad of options at the implementation level (for those that exist or for anyone who wants to proffer something new).

As you know there is considerable inertia and anxiety about reuse of existing standards or specifications in veterinary informatics. For example, a recent discussion on the AVI list and our recent annual meeting was about potential gaps of existing SNOMED CT subsets developed from requirements in another environment and how (paraphrasing) "it doesn't meet our needs, we may just have to use the whole shebang (all of SNOMED CT) and that's too complicated right now".

We seem to introduce these false dilemmas often. The option not mentioned is to create discrete value sets scoped to a particular clinical objective, include more than one terminology source if it meets local needs and share them in a repository for exchange. Not only do the specifications already exist (CTS2, the ISO 21090 CD data type, shared value sets (SVS) by IHE, etc.), but so does the tooling.

We are actually in a better position to cherry pick and mashup the good parts from existing standards because we have so little standards-based implementation baggage. I'd like to see us better embrace SemWeb technologies (RDF/RDFa, schema.org) for example. And Grahame Grieve has reached out to veterinary medicine (as have you and others), but we haven't done a very good job to respond with open arms.

~ Stuart