Spec Factory Metadata Sub-Workgroup Call
Facilitator: Eric Heflin
Note taker: Gregory Morrison
Adam Rabinowitz (VLER Mantec)
Agenda:
Date: 2014-04-23
Time: 3:30 – 4:30PM EDT
Attendees
X Deepthi Rodriguez (Connect)
Minutes:
X
X
Marty Prahl (SSA)
X
Tom Davidson (SSA)
X
Nitin? Jain (VA)
Pradnya Warnekar (VA)
X
X
David Seitz (VA)
Dennis Peterson (VA)
Omar Bouhaddouh (VA)
X
X
X
Minutes:
 Create a new wikipage with initial recommendations with explicit expected values that would
eventually become policy and part of the testing program.
o Objections to the first version of this to be a reconciled version of the VLER VBTR
document version (2013)??
o DOD Details of use of typecode classcode values
o Thoughts on using this as an initial start for partners to expect?
o No objections from the VA side.
o Any other lessons learned? Is there a better version out there?
 AR – noticed exchanging with commercial EHR partners – rather than using multiple document
types – send a C32 with large narratives that are typical to C62. Sending one massive C32. If
software is not designed to capture this (typically would be considered an unstructured
document) Makes things a bit more complex. “Patient Summary Report on Steroids”
o EH – Direction that industry seems to be taking. (Notes as part of C32 or CCDA rather
than separate documents)
o AR – If you want to ask for a particular document seems like you don’t receive it, but is
buried in the additional narratives.
o MP – no policy that the summary of care is a table of contents with pointers to other
content. Perfectly legal to do this – no driving national policy. HPD Summary of Care –
what is in the clipboard? No other documents implemented – even though in a clinical
environment there are. Technology has improved (HL7) – but policy has failed to keep
pace.
o EH – C32 & C-CDA required to be extensible without failures on the receiver side. What
do you think about allowing organizations to include the definitions/concept codes in
the VLER definitions document in their query? Utilize as a “content interface”
 AR – Good idea, wants to run that by his team. Needs to confirm the document
is still valid and accurate.
o MP – do we have multiple LOINC Codes that refer to discharge? Is this the root of all
discharge summaries or are the more discrete LOINC codes/other relationships out
there that represent that same type of note.
o EH – Perhaps we should focus on something simpler, focus more on which standard to
use?
Page 1
o


MP – will have to deal with this migration path when moving forward – will need to
consider dynamically versus statically generated documents. Will also have to work out
versioning for documents.
o EH – what is the minimal work that will be useful and aligned with the future and meet
future needs.
o OB – best to start with metadata to distinguish C32 from C-CDA.
o EH – we do have some constraints already – only 3 codes we can use: formatcode,
typecode, classcode. Is there any controversy about the table (in VLER VBTR 2013). Why
use this instead of a MIME type?
o DR – Refer to FAQ on C-CDA XDS Format Codes
o TD – The link from John M. includes a more complete list of the codes. Unstructured are
well defined. Believes there needs to be a special code for unstructured.
o DR – How does C-CDA Unstructured differ from a CCD unstructured? Or is unstructured
the same regardless of C-CDA or CCD
o TD – ITI profile only recognized PDF and Text (scanned documents). Type codes and
format codes are all over the place. Typecodes are not constrained. Proposed CCDA
formatcode will tell you it’s compliant with CCDA templates for structured document.
LOINC values whose SCALE is DOC in the LOINC database
o MP – we don’t know the relationships here – challenge is we don’t know the correct
relationships/links
o EH – Omar VA – do you have any definition or constrains/processing model based on
the document typecode?
 DP - Not sure will double check to see if anything was implemented or not
 MP – SSA is more heavily depended on the formatcode for processing rules.
Assuming homework was done. Most of the LOINC codes are very consistent.
CCD is constant across the board. Someone may have done this before –
problem is they keep adding document types.
 EH – Looking for guides on the values that users can expect to see in practice
o EH – Typecode seems to be the only variable that we can use. We could publish a list of
triples to correspond with our usage of C32 BC32 and CCDA Care Summary Exchange.
Does everyone agree with that assertion? (no response from group)
o TD – we use have the ability to utilize PFD without a wrapper
o MP – CCD unstructured document – who is producing this? MU2 indicates this is
prohibited? Who is producing this?
EH – Take a stab at creating a table: (Refer to Eric’s Notes)
o EH - Same flavors exist in C32 and CCDA – creates a problem
o DP – role based security, only disclosing necessary information. Will need to look at the
level of granularity. Define the structure as far through as possible. Align with FHIR?
EH – other thoughts? Next steps – clarify the problem statement and send out to group. Will
likely break up between what is short term vs. long term goals.
o DR – should consider starting with a functional item to express what we are exchanging
rather than the format (c32, c-cda etc) then define what other types of documents
express that function/use case.
Workplan
 Broader call for participation.
Page 2





Market Survey
Scope
Meetings – 1 hour per week, with goal to wrap up in 6 weeks.
Target roll out for mid-May
Consensus as common practice and guidance for voting by the end of May
Page 3