PHRI Stage 3 Sprint / Implementation Guide Development
Date: 10/03/12
Meetings Logistics Update
 Starting today Riki Merrick will be leading this call.
PHRI CDA Specification
 Erik Pupo provided an introduction: We will be going over section 3 and gather your comments and
suggestions. Please ask questions as we review each section.
 Allergy/Adverse Event
o Riki’s comment on Figure 2: Arrow directly from the allergy observation to severity observation should
be added.
o Riki’s comment (page 23): The table only displays code and name. It is unclear to me that this section is
for the allergy problem. I suggest adding what this is.
o Value Sets table:
 Added a row “Allergy Status.”
 Nikolay: Are there any discrepancies between value set ID and core common?
 Erik: We identified no difference. Allergy reaction codes (NHSN)
 Diagnosis (Health Problem)
o Discussion: Providing implementers with two template options
 Erik: We are allowing implementers to select one of the two templates--either use diagnosis related
template or problem related template.
 Riki: I think Problem seems to be broader than Diagnosis. It looks like we have more sections in the
Problem. We should make a decision to use one template rather than leaving it as an option.
Diagnosis’ entries are optional, that’s why it depends on the type of Problem that’s being described.
We can recommend removing Diagnoses section.
 John Eichwald: If we’re looking at screening that’s being done at the hospital situation, we’ll have
screening result, but not have diagnosis yet. It’ll be more fitting to report on Problem.
 Wendy: You can use SNOMED code in Problem and then identify detailed problems. What does
Diagnosis add that Problem doesn’t cover?
 David Birnbaum: I can see how the optionality is needed.
 Erik: My recommendation is we allow the options and leave it up to implementers to decide which
template to use based on the setting they’re reporting from. This if you want to be high-level,
 Group came to consensus on keeping the two options. We will also add verbiage explaining the
rationale behind providing options and ask implementers to select.
o Value Sets:
 Suggestion: For qualifiers, add notes indicating code systems that implementation guides should
draw from, rather than create a superset value set. Add example values.
 Employment Information
o NIOSH comments related to Employment Information section.
 Kerry Souza and Peggy Filios were on the call from NIOSH to walk the group through the comments.
 Kerry & Peggy: NIOSH had a discussion based on our last call conversation and modified the
comments.




Peggy: We still have outstanding issues e.g., number 5, 3.3.1, states constraints defined in social
history. We cannot agree to this because we don’t know what they are.
 Kerry: Can you define “constraint” in this setting?
 Erik: Yes. It is very similar to requirement. So if you’re asking someone to report public health
information, the receiving entity should know what to expect and the sending entity should know
what to send. Constraint is level of requirement: Level 1 constraint level is the highest; level 2 is a
section level constraint; and level 3 is an entry level constraint. We don’t want conflicting
constraints.
 “SHALL/MUST” vs. “SHOULD.” I recommend we use “this is how you SHOULD…” and don’t
constraint by using “SHALL.”
o Employment Information
 Erik: Employment information: should we define a new “employment information” template or use
social history? The risk associated with using the social history template is stakeholders might want
more granular information.
 Replaced MUST with SHALL in 3.3.1.
 Nikolay’s comment: add “census codes” under type in 3.3.2.
Encounter
o Encounter CDA Section - Detail Table > Reason for Visit
 Nikolay would like to include problem list coded values and tie to observations. Is there any problem
with this approach with existing template? EHRs have to include as well as receives.
 Requires problem list as a common core element
 Erik: I recommend leave it optional and can use either approach -- you can use Reason for Visit
template or tie it to observations. We will include very clearly guidance to indicate this.
 Bob: It’s a common practice to include verbiage that explains they are required to use these
templates and they need to work together.
o Value Sets
 Nikolay: Type needs to be constrained to inpatient, outpatient, phone call, and other (per common
core)
 Bob’s question to Nikolay: This is a report not constraint to report. This is a generic model to convey
information. What would be the value of constraining to those four values? My concern is that if
those are the only values to express.
 Nikolay: Wouldn’t the “other” would cover that?
 Bob: that doesn’t allow for enough granularity.
Exposure
o Rita: There is V3 model for exposure. Data harmonization group can look at it tomorrow, 10/4/12.
o Toxic Exposure Observation Template: We need higher level, toxic is not enough. Exposure type =
chemical, physical, environmental, and other. Group wants to include all eight values. Data
harmonization group to discuss and update tomorrow.
o Bob discussed his concern with constraining values: Implementers may say what we need is something
that doesn’t currently exists, and this requires expansion of the current values and impacts VHR. Erik to
address this concern in the document. If there is an existing values set with more than the suggested
values, then that’s fine.
Facility
o Nikolay’s question: What type of ID is this in CDA?
o






Question: ID includes assigning authority?
 Yes. It is described this in the document.
 Erik to describe this in the document.
o Question: Did we lock down facility ID to OIDS?
 Nikolay: we should express the source, that’s what assigning authority does.
o Facility Type: Nikolay would like to use existing value sets and use Health Service Delivery HL7.
Family History
o Nikolay: Why were some value sets empty?
 Erik: That’s because we haven’t received any recommendation. We will use the existing family
history value type.
Immunization
o Question: There’s a tension between vaccine substance administration in CDA and CDA being able to
carry vaccine. Can you do this piece divorced from the type of report?
 Erik: You have to reference as an external document.
o Comment: We don’t want to use CDA to use vaccination. But we do need CDA that is being used to
report an exposure case and other things in public health so we can do history information on
vaccination.
 Rita: Group should check with Rob Savage regarding VIS in CDA. They’re currently doing work
expressing immunization in CDA.
o David: CMS has a put in a new requirement that health care facilities vaccination report on annual basis.
E.g., number of vaccination staff divided by the number of staff. This will be part of special requirement
in CMS. This does not pertain to HHI.
 Erik: That might be a report specific.
Medication
o No comments/objects from the group.
Order / Diagnostic Test
o Erik: Plan of care is not part of common core at this time.
Physical Exam
o Can use one or more PE sections to capture various types e.g., foot, eye, etc.)
o Question: Do you have any value sets?
 Nothing right now. Could use value set that defines section type (for PE section, can define the
different types of exam that can be provided) Erik can create actual example and we can review
together.
o Common core data element: should see consistency between this and common core – update one or
the other accordingly.
Specimen
o Group to review this section and discuss next week.
Homework:


Erik will send new version of the document by tomorrow and group to review.
We have a profile for case reporting, generic case report, and adverse event on medical device.