NHIN Direct Abstract Model version 2.0

[Brett Peterson]

Changes were made to the NHIN Direct Abstract Model (resulting in
version 2.0) based on the output of the Abstract Model Workgroup call
for consensus. The abstract model may be found here:

http://nhindirect.org/NHIN+Direct+Abstract+Model

The diffs for the 2.0 changes may be seen here:

http://nhindirect.org/page/diff/NHIN+Direct+Abstract+Model/134625937

Many of the changes were relatively minor in nature, but two to note
include:

1) The term Health Service Provider (HSP) was changed to Health
Information Service Provider (HISP). Based on feedback from workgroups
and wiki discussions, the term HSP was deemed to be too confusing.
Folks coming in new to nhindirect.org were interpreting HSP to be
equivalent to a clinician (doctor or therapist).

2) All "example" language was removed from the abstract model.
Examples were being seen as containing bias or assumptions about
deployment or implementation choices. However, because examples are
an important tool for communication, a separate Abstract Model
Examples wiki page (still under construction) was created and linked
off of the abstract model page.

The suggestions in the comment area of the Implementation Group call
for consensus on version 1.1 of the Abstract Model will be discussed
on the wiki and in the Abstract Model workgroup potentially leading to
further model updates. The call for consensus comments may be found
at the bottom of the Abstract Model wiki page:

http://nhindirect.org/NHIN+Direct+Abstract+Model

Brett

[David Tao]

Changing HSP to HISP was a good decision. I was going to suggest
changing HSP, but hadn't done so when you beat me to the punch.
David

On Apr 15, 11:43 am, Brett Peterson

[Boone, Keith W (GE Healthcare)]

This is the first of two e-mails you will receive. This e-mail contains
an IHE XDM format ZIP file as an attachment. Normally this e-mail might
be accompanied by a quick summary of the reason it was sent and a quick
explaination of what to do with the content. I'm going to skip that to
see if you can figure that out. The next e-mail will just be a
collection of documents with the same content.

Keith

P.S. This message conforms to transaction 32 described in the IHE ITI
Technical Framework, Volume 2b

[Jason Mitchell]

You would think that this patient's otitis media would have resolved in over 2000 years?!

It may be a pet peeve of mine, but health information examples that contain outlandish, or even inconsistent data, are a real deal breaker for me. It proves that the engineers have no regard for the clinical data or its significance, only the engineering. A technical error at the magnitude of this clinical data error would be inexcusable. 

If you are going to put data in a CCD, make it meaningful. We really shouldn't be hand-coding CCDs anymore. I thought it was a mature technology?

Sorry to go off topic. Let's return to your point.

Jason

--
You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
To post to this group, send email to nhindirec...@googlegroups.com.
To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhindirect-discuss?hl=en.

[Richard Braman - EHR Doctors]

Keith, Dr Jason raised some valid concerns about this CCD, and
sorry to go off topic again, but I also had some questions about this
CCD you are spreading around...

Q1: Is this generated from CAPMedPHR, or something you did by hand?
Its certainly not something generated from Centricity is it?

Q2: I also noticed that the author here used the following to encode
the problem name.

<value xsi:type="CD">
<originalText>
<reference
value="#ref_99b1de770a8642c9a9fa4a1e8a20b092_phrCondition_Name_Active_1" /
>
</originalText>
</value>

which refers the machine reader back to the narrative <text> element
of the section to get the problem name.

instead of coding it like:
<value xsi:type="CD" code="251166008"
codeSystem="2.16.840.1.113883.6.96" displayName="AV Nodal Reentry
Tachycardia" />

(like the CCDs released by HL7)

and referring to the text section (if needed) like this inside the
problem observation template
<text>
<reference value="#prob1" />
</text>

Is there a reason for this strange encoding, because it forces a
machine reader/level 3 stylesheet to go back to the text to get data?

Is this CCD attempting to be IHE PCC compliant?
Because I also noticed that the sections contained templateID root #'s
from the IHE PCC spec, but failed to leave out the parent root. I
don't think that can be omitted because again it would break a machine
reader(stylesheet) that was matching sections on the templateId

From the IHE PCC Docs Volume 2 (page 13,para 435-440)

Thus, a document content module shall contain as constraints:
The template identifier of the parent content module when there is
one.

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_50_Vol_2_2009-08-10.pdf

So problem should have templateIDs like this:
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6" />
<templateId root="2.16.840.1.113883.10.20.1.11"/>

I must admit, I am relatively new to the IHE PCC spec, so please
correct me if I misunderstand.

The IHE spec for 1.3.6.1.4.1.19376.1.5.3.1.3.6 ,
http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.3.6
seems to indicate the Parent Template which leads me to believ this
should be included.

On Apr 15, 3:57 pm, Jason Mitchell <jmmitchel...@gmail.com> wrote:
> You would think that this patient's otitis media would have resolved in over
> 2000 years?!
>
> It may be a pet peeve of mine, but health information examples that contain
> outlandish, or even inconsistent data, are a real deal breaker for me. It
> proves that the engineers have no regard for the clinical data or its
> significance, only the engineering. A technical error at the magnitude of
> this clinical data error would be inexcusable.
>
> If you are going to put data in a CCD, make it meaningful. We really
> shouldn't be hand-coding CCDs anymore. I thought it was a mature technology?
>
> Sorry to go off topic. Let's return to your point.
>
> Jason
>
> On Thu, Apr 15, 2010 at 2:31 PM, Boone, Keith W (GE Healthcare) <
>

> keith.bo...@ge.com> wrote:
> > This is the first of two e-mails you will receive.  This e-mail contains
> > an IHE XDM format ZIP file as an attachment.  Normally this e-mail might
> > be accompanied by a quick summary of the reason it was sent and a quick
> > explaination of what to do with the content.  I'm going to skip that to
> > see if you can figure that out.  The next e-mail will just be a
> > collection of documents with the same content.
>
> >   Keith
>
> > P.S.  This message conforms to transaction 32 described in the IHE ITI
> > Technical Framework, Volume 2b
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhindirect-discuss" group.
> > To post to this group, send email to nhindirec...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nhindirect-disc...@googlegroups.com<nhindirect-discuss%2Bunsu...@googlegroups.com>
> > .

[Boone, Keith W (GE Healthcare)]

Yes, this is a sample that was being prepared for connectathon testing of the XDM propfile, and containts content generated I believe by the CAPmed system. It is not something that I generated by hand, although I now wish I had used one of that nature, because it's obscuring the point I'm trying to make about packaging.

Keith


_________________________________
Keith W. Boone
Standards Architect
GE Healthcare

T +1 617.519 2076
M +1 617 640 7007

keith...@ge.com
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work

> > nhindirect-disc...@googlegroups.com>

[Arien Malec]

Keith, all --

Do you have a good reference to the XDS Metadata? I've tried to read
the metadata cookbook and the reference in ITI TF V3 4.1, but the
documentation is either incomplete or I'm sufficiently dense enough
that I don't know how to map from, say, the attributes listed in the
documentation to the examples given.

For example, in reading the documentation for formatCode, which is one
of the required attributes, it's listed as an attribute but expressed
as a Classification element, with a nodeRepresentation attribute
labeling it as a formatCode, and the element contains additional
elements (Name, Slot) that in turn contain additional elements and
attributes.

I think the issue is that the XDS metadata spec seems to presuppose
rock solid understanding of the ebRIM specification, and it probably
all makes sense in that context.

Arien

> --
> You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
> To post to this group, send email to nhindirec...@googlegroups.com.
> To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nhindirect-discuss?hl=en.
>
>



--

Arien Malec
Coordinator, NHIN Direct
arien...@nhindirect.org
(510) 761-6473

[Vassil Peytchev]

Arien,

It is a notational issue, which should be improved in the IHE specifications - within the Classification, the nodeRepresentation attribute is the actual code, the Slot within the Classification provides the coding scheme used, and the Name provides the display name.

Using the name of the thing (e.g. formatCode) in the place where the thing would go (value of nodeRepresentation) is indeed confusing.

Hope this helps,

--Vassil

-----Original Message-----
From: nhindirec...@googlegroups.com [mailto:nhindirec...@googlegroups.com] On Behalf Of Arien Malec
Sent: Friday, April 16, 2010 1:51 PM
To: Boone, Keith W (GE Healthcare)
Cc: nhindirect-discuss
Subject: Re: XDM.ZIP data to review [XDM/1.0/DDM]

[Boone, Keith W (GE Healthcare)]

Working on it even as we speak (based on your Mime comments). Reading through the XDS specifications, I can understand why it might be difficult to interpret the XDS metadata specification. It has to do with the difference between having to get it in one reading, and having gotten to understand it through writing an implementation or having lived through the committee meetings and discussions.

Keith

-----Original Message-----
From: Arien Malec [mailto:arien...@nhindirect.org]
Sent: Friday, April 16, 2010 2:51 PM
To: Boone, Keith W (GE Healthcare)
Cc: nhindirect-discuss
Subject: Re: XDM.ZIP data to review [XDM/1.0/DDM]

[Jason Mitchell]

So, did XDS just fail our test for "simple"? If Arien can't get it in "one reading", then I've got no chance in a million readings. I'm not arguing against XDS, just arguing against it as a "baseline". I have no issue with leaving room to build it on as individual (or group) need dictates.

Jason

[dmccallie]

I'm inclined to agree with Jason that XDS/XDM is not "simple enough"
at this point in time.

I certainly think it should be an optional content type, but not a
required type.

The fact that even a non-sophisticated user can un-zip and read XDM
content is a big bonus, but we shouldn't require that everyone be able
to create/zip and send it.

--david

> > nhindirect-disc...@googlegroups.com<nhindirect-discuss%2Bunsubs cr...@googlegroups.com>
> > .

> > > For more options, visit this group at
> >http://groups.google.com/group/nhindirect-discuss?hl=en.
>
> > --
> > Arien Malec
> > Coordinator, NHIN Direct

> > arien.ma...@nhindirect.org

> > (510) 761-6473
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhindirect-discuss" group.
> > To post to this group, send email to nhindirec...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nhindirect-disc...@googlegroups.com<nhindirect-discuss%2Bunsubs cr...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/nhindirect-discuss?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
> To post to this group, send email to nhindirec...@googlegroups.com.
> To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/nhindirect-discuss?hl=en.

[Boone, Keith W (GE Healthcare)]

I wasn't suggesting that XMD be required. If you read my third e-mail, you'll note that. What I was suggesting is that if you are sending a healthcare standard format (CCD or CCR), that it should be required or at the very least strongly recommended. At the point that you have enough technology to create a CCD or CCR, going from that to an XDM zip file IS simple. I guess another demonstration is in order.

Keith

> > nhindirect-discuss+Bunsubs cr...@googlegroups.com>

> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/nhindirect-discuss?hl=en.
>
> > --
> > Arien Malec
> > Coordinator, NHIN Direct
> > arien.ma...@nhindirect.org
> > (510) 761-6473
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "nhindirect-discuss" group.
> > To post to this group, send email to nhindirec...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > nhindirect-disc...@googlegroups.com<nhindirect-discuss%2

> > nhindirect-discuss+Bunsubs cr...@googlegroups.com>

[Brian Behlendorf]

On Fri, 16 Apr 2010, dmccallie wrote:
> I'm inclined to agree with Jason that XDS/XDM is not "simple enough"
> at this point in time.

http://www.w3.org/Protocols/rfc2616/rfc2616.html

I suspect Roy, Jim, Jeff, Henrik, Larry, Paul, and Tim would all avoid
asking people to read it in one sitting to "get" HTTP. The various DNS
and SSL specs aren't exactly Friday night fireside reading material,
either. Maybe those are unfair comparisons, but we might want to be
careful about how we evaluate simplicity here. In the case of HTTP, DNS,
and SSL, there are libaries in lots of different languages with relatively
simple interfaces that allow us to tackle the 99 %ile of functionality.
Re-using any prior standard nearly guarantees additional elements we don't
need; but it could also bring along existing libraries and implementation
experience that a new homebrew spec does not. Plus you can always take a
complex spec, and specify that you only mandate that participants speak
and grok a subset of it or its use in a particular way. Much of the HTTP
spec simply isn't used in modern times, from content negotiation to the
TRACE method. Others got used competently only much later, like the
compression and content-encoding support.

I think we're also dealing with a deficit of documentation. Standards
developed by industry consortia are rarely well documented, because
there's no business model for good free documentation for commercial
standards. IETF standards, successful ones at least, at least have
the public body of discussions around drafts that form a sort of ad-hoc
documentation, followed by prototype or production libraries in multiple
languages that further serve to deliver examples. Sometimes it's just
better to learn about a spec by seeing it in action, by watching the
conversation on the wire or doing a "view source" of the content, than by
starting with the BNF or schema description. It might be possible to
write a "cheat sheet" for XDM/the XDS specs that informally provide all
you really need to know to implement. And if there's some level of
irreducible complexity, that's where we can write code to help.

Brian

[Arien Malec]

There's complexity and there's documentation. http is a relatively
simple standard to write a basic, insecure web server from, and a very
complex standard to build an industrial strength server from (as Brian
knows very well), but it's insanely well documented, has lots of
examples, and it's easish to read the spec and understand the overall
request/response model, key headers, and key status codes. SSL isn't a
fair example, because crypto is necessarily hard.

XDS metadata is, I suspect, pretty simple (the underlying metadata
model could probably be expressed reasonably simply) but it's built on
a complex metamodel (ebRIM), and it's just plain hard to read the spec
and understand how to express all the attributes. I don't think we
should conclude from the fact that I (still) don't get it that we
shouldn't use it, but I *DO* think we should conclude that:

a) If we make it mandatory, we better describe exactly how to use it
(or go back to IHE and work with them to clarify the key standard,
which should be easy since many of the key IHE people are
participating with us) AND
b) We should try to find a good, simple, minimal, well documented,
recommended subset.

I continue to stand by the proposal I put together that allows us to
start with just content type via multipart MIME and extend to full XDS
metadata.

Arien

--
Arien Malec
Coordinator, NHIN Direct

arien...@nhindirect.org
(510) 761-6473

[Vassil Peytchev]

I think one point is still getting lost here - not how complex/simple it is to build the metadata (which is a valid point), but how complex/simple it is for a recipient to get to the information using e-mail.

I agree with Arien's a) and b) below, and they are valid no matter what metadata or which method for expressing the metadata is being employed.

Thanks,

--Vassil

-----Original Message-----
From: nhindirec...@googlegroups.com [mailto:nhindirec...@googlegroups.com] On Behalf Of Arien Malec
Sent: Friday, April 16, 2010 6:38 PM
To: Brian Behlendorf
Cc: dmccallie; nhindirect-discuss
Subject: Re: XDM.ZIP data to review [XDM/1.0/DDM]

[Arien Malec]

Vassil, it's a good framing to think of how a receiver would get at
and interpret the data:

With just standard MIME headers, I have access to a few pieces of info:

1) content type
2) content length
3) any encodings necessary to extract the document
4) From context in the header (domain, origination point)

With that, I can know: this is an HL7 document, and I can extract it
for further processing. I can then figure out other contextual
information from the health care content

If it's a non-healthcare document, I need to either infer context
(from healthcare documents in the same package) or queue for manual
processing.

With advanced uses of MIME-types, I can express subfolders and
relationships between items, but ordinary email support for that is
lacking, and framework APIs may or may not support arbitrary
recursion.


With XDS metadata, I have access to:

1) Relationships between items
2) Author (useful if author is different from From)
3) Class code (with undefined vocabulary because this is not in an
Affinity Domain
4) Event code (with undefined vocabulary)
5) Format code (with undefined vocabulary)
6) Hash
7) Facility (with undefined vocabulary)
8) Patient ID
9) Practice setting code (with undefined vocabulary)
10) Service dates
11) Type code (with undefined vocabulary)
12) Unique ID
13) Folders and subpackages

MIME gives minimally sufficient metadata that verges on insufficient
for this purpose (e.g. gives no standard for patient identification).
XDS metadata gives a great deal of metadata that verges on overkill
for this purpose and has many attributes with undefined vocabularies.

[Arien Malec]

On Fri, Apr 16, 2010 at 2:34 PM, Boone, Keith W (GE Healthcare)
<keith...@ge.com> wrote:
> I wasn't suggesting that XMD be required.  If you read my third e-mail, you'll note that.  What I was suggesting is that if you are sending a healthcare standard format (CCD or CCR), that it should be required or at the very least strongly recommended.  At the point that you have enough technology to create a CCD or CCR, going from that to an XDM zip file IS simple.  I guess another demonstration is in order.

It's funny, because I think the MIME case is workable for a healthcare
standard format, and more problematic for a non healthcare standard
format.

I think the issue here is that I'm thinking computer to computer (push
a referral package to another provider such that it can be imported
into that provider's EHR) and you are thinking computer to human (push
a referral package to a human who needs to interpret the structured
data in a human readable format).

So for computer to computer MIME is fine for healthcare formats (CCR,
CDA/CCD, HL7 v2) since the computer can pull out the patient,
provider, etc. context adequately out of the payload but problematic
for non-healthcare formats (PDF, text) since the computer has to
either infer context from other stuff in the package, or kick it over
to a queue for a human to process and associate with the chart.

For computer to human (or human to human), MIME is fine for
non-healthcare formats, since I can just read the document (as text,
or with a standard viewer) and possibly problematic for non-healthcare
formats. If I have a viewer for the format, no problem. If I don't
have a viewer, it's harder to package the viewer. On the other hand, I
can just package the viewer as another attachment and supply some
human readable instructions.... It's not clear to me that XDM provides
any benefits here, however, over just zipping stuff together, or
adding the viewer attachment, since no human is going to read and
interpret the XDS metadata.

Where XDS metadata helps, I think, is in computer to computer exchange
that handles all the permutations of mixed healthcare and
nonhealthcare content.

Arien