Cologne Roundtable Discussions

Issue topics When is it ok to use ‘code’ rather than CodeableConcept and required or extensible bindings? Negatives on Observation How “stand-alone” are resources expected to be? Negative on FM resources How do we get consistency in determination of isModifier?

Code/Coding + binding strength

Issue Sample ballot item: GF#16700 Issues such as Observation.status, interpretation, dataAbsentReason, referenceRange.type, referenceRange.appliesTo, Patient.gender Concern that documents of clinical interest should not be constrained to code (which prohibits translations) and Required or Extensible bindings (which force translation)

Lloyd’s opinion Object of HL7 is global interoperability when we can and when it doesn’t impose unreasonable expectations on implementers Mapping is a “reasonable” expectation if the number of codes is small the value set covers the space Value set is amenable to mapping from the common terminologies of the vast majority of implementer systems

Lloyd’s opinion (cont’d) Changing from code to CodeableConcept means software can’t use enumerations Does allow translations & original text to provide “original” codes plus free text If required, must always have a code from the required value set though

Stand-alone-ness of resources

Issue See GF#16939 ClaimResponse, EligibilityResponse, EnrollmentResponse, AppointmentResponse cannot stand alone (need Claim, EligibilityRequest, etc. to make sense) Equivalent to an Observation that says “value was 100 mmol/L, see Order 123 for more” QuestionnaireResponse is more stand-alone, but could be argued is not “fully” computable independent of Questionnaire

Issue continued Current models dictate the business model: This means: A request must exist before the ‘event’ can exist Information is intended to be communicated principally to the system that made the request This means: Can’t initiate an appointment by saying “I’d like an appointment, here’s my availability” Can’t initiate an eligibility check, pre-authorization, without an electronic request, etc. Can’t send results of eligibility, pre-authorization, etc. to downstream systems without also sending request

Resources should be context-independent Extensibility mechanism doesn’t accommodate “workflows” outside the 80%, only “elements” outside the 80% Therefore need to try to be workflow-agnostic, even if certain workflows are typical At the same time, initial versions of a resource may focus on what’s known What FMM level constraints should there be for non-workflow-independent resources?

isModifier

Issue Lots of people don’t know how to populate isModifier In some cases, whether something is a modifier is context-specific Depends on how people interpret the resource by default