Skip to end of metadata
Go to start of metadata

HL7 Notes: Sydney, February 4, 2020 thru February 7, 2020
Tuesday Q1 – PIE /FM

  • Reviewed and adjusted agenda
    • Vocabulary: Discussed work being done surrounding the overall governance and documentation of external code sources.
      • Issues and needs,
        • As APIs are being built need to ensure used code sets are licensed and referenced.
          • A US issue is that developers don't necessarily access the licensed codes from the code source, but rely on internet searches
            • How to police usage (US realm side)?
        • Need the URL/URI to point to the location, explanation of what it is, how to acquire.
        • Need to ID what terminologies and ensure all the agreements are in place
        • Discussed possibility of flagging terminologies where there are no agreements/licensing are in place, or if it is not known
        • Need to document all the use cases.
        • Need an agreed upon method of referring to external vocabularies and how to support/operationalize (agreement with HL7, enforcing the IG authors are complying, respecting IP). Need to know how to handle the external vocabularies.
        • Can be done with the right people. Thought from HTA was each realm would do their own, but really need to have an overarching structure and process in place
          • Considerations:
            • how to make the build so it doesn't blow up the system
            • And what do you need it to do
            • Should there still be a code system/naming system in the IG vs. URL (even if you just had a style)
          • Work from HTA side to establish something (there is HTA/Vocab meeting Wed Q3 to possible LLoyd, Paul to go to this meeting
        • Bottom line.: Need a way to point to external code sources and associated governance to ensure information is correct and any MOUs are in place etc.
    • BPM+ - Special event/health industry workshop on Thursday. Might want to attend as a group. Paul noted that Q2 and Q3 were more technical, but suggested Q1- introduction and Q4 sessions.
  • Connectathon Update:
    • Over 100 attendees
    • 15 tracks
    • Structured data capture:
      • Over 10 participants
      • Populate was successfully working
      • A few improvements were identified
    • FHIR Shorthand: rather than using WYSIWYG tool, or spreadsheet for creating FHIR downstream artifacts, it is a shorthand language to define through text expressions.
      • Change control management is better than a spreadsheet,
      • Could set up a basic profile and use a series of scripts to generate content such as examples.
      • Relatively new and will eventually go to ballot
      • It is not an end user tool.
      • Paul sees it might be tool to create instances of profiles and artifacts and may be able to generate info for the implementation guide.
    • Primary Care Track (practice-to-practice Record Transfer)
      • Gravity Project

      • Gather and Share Social Determinants of Health (SDOH) Information in a Clinical Encounter
      • Use case 1
        • Task from PMEHR system to screen via questionnaire, sends request to screening application and app questionnaire via text and answers back to app go back to PMEHR for use during clinical encounter. Help coordinate social services (perhaps to follow-up if they are accessing the services)
  • Timeline
    • Ballot on scope for FHIR R5 was originally set for May. Not doing this, awaiting meaningful use rule to drop in US and see industry response. Will not be publishing in the beginning of 2021 (could be mid 2021 or later)
      • Lloyd notes if you have issues to let them know what the issue is and urgency for addressing.
      • Tooling with publishing IGs continues to evolve
      • There are FM changes, but Paul notes FM isn't feeling pressure to move to R5.
      • MARY KAY asks if vocabulary is an issue, this is more of an IG thing. There is limited use of external vocabularies in the base spec.

Tuesday Q2 - PIE

  • Industry Updates
    • NCVHS Letter out in December 10, 2019
      • Improve adoption of HIPAA Standards
        • Recommendation 1: provide guidance on data needed to support adoption of standards
        • Recommendation 2: Secure support (i.e., funding) for testing and evaluation of standards and prior to adoption.
        • Recommendation 3: Facilitate a more nimble approach to standards development to better support federal policy objectives, industry business requirements and emerging technologies
    • Any updates related to adoption of the attachments rule? Originally noted in the unified agenda that there might be something in fall of 2019, but nothing came out.
    • Discussed any dental were doing any 275s?
      • Christol indicated they are hoping to do some work to bring up some of their dental this year. They have another group of dental on a separate platform and those will not be migrated this year.
      • DOD – is pushing their vendors to move towards using.
    • ICD-11
      • HHS to conduct research to evaluate the impact
        • ICD-11 will have to be used for cause of death
          • CDC – codes this based in information input
          • Structure is closer to SNOMED
        • Copyright situation for ICD-11 for US and is influx
    • CMS Regs and Guidance for Admin Simplification Enforcement (came out in December)
      • CAQH had an MOU with HL7 – what does that mean?
        • Purpose and scope for the HL7 MOUs purpose isn't clear
    • Ambulance modifiers
      • Not new modifiers, but there are some issues surrounding how CMS is asking the modifiers to be used.
    • NCPDP
      • Put request to expand the length of field to allow for over a million dollars
      • Requires extensive process to get approved and adopted for use
      • Discussed the need for a better way to get changes/corrections published and approved for use
    • ADA is having meeting in Chicago 17-19
      • SNODENT meets during this meeting
      • Dental Summary Exchange Project (See Confluence Page): There is a group (military, Vendors, DOD, FHIR developer etc.) who has been coordinating a work effort to develop a consensus surrounding what data should be exchanged.
        • Planned proof of concept at Connectathon in San Antonio with scaled down use cases
          • Dental to Dental consultation referral and confirmation back
          • Medical to Dental
          • Dental clearance of patient scheduled for transplant.
          • Dental status of a reservist to confirm ability to deploy.
      • Perio attachment needs updates
      • Functional model EHR
        • Dental functional profile -
        • Will be presenting this in Chicago, once they present information to EHR group here
        • There is some vendor involvement on this project.
    • Old Projects: Reviewed old projects listing.
      • Closed Insight #964
      • Cross paradigm artifact (Insight #1347)
        • Will take a vote later after group has opportunity to review
      • Insight #1389
        • Already publishing through WEDI
      • Insight #1402
        • Needs to be cleaned up, not sure how to do that. Some need to extend the STU. Awaiting guidance for some, language for others, should resolve some of these over the next few months.
    • HIMSS: is coming up March
      • Several people will be attending, some will be involved in the DaVinci booth

Tuesday Q3 - PIE/FM

  • Worked on flows needed between 278/275 to payer/TA1 or 999 or 278 back as it relates to FHIR.
    • flow to document X12 to FHIR and back to X12.
    • Black box to Black box (278), what can happen and how is that going to be portrayed in the FHIR world.
  • Discussed error handling


    Black Box (BB)

    Black Box (BB)


    FHIR >

    < FHIR



    FHIR >

    FHIR >
    < FHIR

    < FHIR


    FHIR >

    FHIR > 278
    FHIR < TA1 (resolve)
    278 >

    278 >


    FHIR >

    FHIR > 278
    FHIR < TA1
    < FHIR

    < TA1


    Processing must manage: FHIR to XYZ and Error to XYZ return
  • Transmit or conversion of messages
  • Interpretation and handling (retry or fail) of values messages
  • Timeout on expected responses
  • Responses received after timeout
  • Store and forward

FM isn't sure if they should be defining the error handling but will need to define some of the coding values for providing the response.

  • Synchronous Exchange (stay open) – Sender has "ID" context and may use response identifiers
  • Asynchronous Exchange – Sender is dependent upon "ID" in the response.

Discussions assume: Per one interchange (ISA-IEA) there will only one PA request with applicable documentation

  • Discussed structure of X12 and potential need to split them up, first send the 278 once approved, send the 275 to avoid one accepted and other failed.
  • Request for additional info wouldn't be a failure

FHIR doesn't deal with the transport of things, and therefore doesn't really deal with the failure piece.
The black box will need to keep track of the metadata about the communication so they can tie the transports and tie in the response.
When building FHIR bundle the claim resource will point to the documentation.

  • The FHIR bundle will have a 278 and the 275 which will contain the original FHIR bundle in the BIN segment,
    • 275 only allows for single BIN segment

See link in Wednesday Q2 for details.
Tuesday Q4 - PIE/FM
FHIR Bundle to 278/275 flow

  • Continued review/drafting of flow for using FHIR behind the scenes and turning them into HIPAA mandated transactions.
  • See link in Wednesday, Q2 for details.

Wednesday Q1 – PIE /FM
US Realm Steering Update

  • One PSS was approved for Skin and Wound Assessment.
    • Patient Care is the primary/sponsor
    • Tissue Analytics & Intermountain will be implementing.
  • Discussed accelerators – DaVinci, looking at some of the struggles/issues that accelerator projects are running into (e.g., Terminology, Coverage (education vs resource), data types etc.)
  • US core document reference needs to be corrected for attachment
  • US Realm Extensions review, need to look what is US CORE
  • Quality checklist Items:
    • Profiles built upon US CORE
    • Terminologies align with US Requirements
    • Extensions follow US Realm process

Co-Chair/Steering Update

  • Co-chair handbook being updated
  • New co-chair term timeline/election process
    • Currently voting occurs throughout all quarters and terms begin/end throughout all quarters
    • Moving to calendar year terms. One term = two calendar years.
    • Election process steps (notice of terms up for renewal, nomination process, and voting) will occur at set times through the year.
    • Will be moving to an e-vote
    • No Term Limits, but terms will be staggered.
  • Work group updates
    • The health for all work groups is good
    • New work group for Patient Empowerment
  • Unified Terminology Governance (UTG) new tooling demo during lunch.

FHIR Bundle to 278/275 flow

  • Continued review/drafting of flow for using FHIR behind the scenes and turning them into HIPAA mandated transactions.
  • See link in Wednesday Q2 for details.

Wednesday Q2 - PIE/FM
Completed review of FHIR Bundle to 278/275 flow, details can be found at:
Coverage Identifiers

  • Reviewed crosswalk document provided by Mary Kay
  • Document located at:


  • In Coverage resource identifier can be one to many.
  • Member Identifier (some in other groups wanted it to go from a string to text), but didn't see a Text data type in FHIR

Wednesday Q3 – PIE/FM
EOB Resource, with reference to the Coverage resource

  • Discussed what the value set for coverage type represented as there was a value that seemed different than many of the other values. This is the coverage information for who paid for it.

Gravity Project

  • Lisa Nelson gave an update on the Gravity project
  • Social Determents of health
    • Food Insecurity
    • Housing – Instability & Quality
    • Transportation
  • Factoring the entire Care life cycle
  • Re-using things already developed.
  • Doing the prelim work prior to the connectathon.
  • Working on IG for initial content.
  • Use case 1 tested during connectathon
    • Takes a questionnaire and patient list. Application figures out how to administer the questionnaire (collects consent initially, and then questionnaire to determine food issues as part of annual visit).
    • Tasks can typically be purged, but for this it will be kept and be auditable.
    • They will keep track of who has successfully responded (and will have expiration date) will know if 30% responded will be able to know if the screening request was successful at least to what level.
    • Assessment observation is modeled as a clinical finding.
    • All the questionnaires are built out of the LOINC panel codes.
    • They are looking to close the loop between when they refer someone out to the community and determine whether they are getting the help.

Wednesday Q4 - PIE/FM
JIRA Tickets

    • 24285: Nothing can be done at this time
    • 24174: There needs to be a larger discussion regarding whether line items should be separate resources.
      • In payments work group there are discussion surrounding charge item and should there be additional items on a statement where you are providing more info (do you provide all info or subset of that info).
      • If you have a separate resource for line items, while it will make it smaller, what do you lose? Line items on the claim could represent a rolled-up amount under a single non-detailed code (e.g. REV code for pharmacy is inclusive of all pharmacy charges rolled up into a single line).
      • Statements are not necessarily created in a uniform way.
      • In using the claim resource for PA – they had to have an identifier as additional lines can be created, and they added an identifier to the line to ID when a payor or a provider has created a line. This is not true in the case of claims.
      • This will be discussed again with a larger group. After discussion, not sure there is much to be gained to do this. Discussed what is in X12 claim and associated remittance– there is a line item, this is returned on the remittance.

Thursday Q1 – PIE /FM: Special Event

  • Attended BPM+ workshop (Business Process Management)
    • Advancing Evidence-based Care from "paper" to Practice: The Role of HIT Standards and BPM+ Health –Ken Rubin
    • Using Semantic DMN to Represent Logic in Cognitive Support Tools - Jane Shellum

  • Advancing Evidence-based Care from "paper" to Practice: The Role of HIT Standards and BPM+ Health –Ken Rubin
    • A little context
      • In middle of EHR Modernization over 10 years
      • 1st go live is in a few weeks
      • Keeping pace is a challenge
      • Needs to cross environments, not all Veterans get services only from VA
    • A few challenges and priorities
      • Changes in medical/clinical practices changes too rapidly for humans to keep up (e.g., changing care practice guidelines)
      • These challenges are global
      • Interoperability
    • Why can't best-practices follow the patient through their journey of care
    • ACTS Key Premise and Findings
      • Improving health of patient
      • Advancing the care experience
      • Not adding burden
      • Outcomes
    • What is needed:
      • Roadmap
      • Inventory of Relevant Standards
      • Marketplace/Distribution channel
      • Knowledge Ecosystem etc.
  • Using Semantic DMN to Represent Logic in Cognitive Support Tools - Jane Shellum
    • The Case for Knowledge Management
      • Knowledge most scalable asset if it is actionable and accessible
    • Imperatives for Knowledge Mgmt.
      • Need to facility knowledge curation
      • Know what we know
      • Deliver the knowledge
      • Deliver knowledge-enriched data – puts clinical data in context
    • Role of BPM+
      • Facilitate knowledge curations (human and computer readable)
      • Know what we know – transparent assets
      • Deliver knowledge – model-driven knowledge delivery solutions
      • Deliver knowledge enriched data – spec requirements
    • Current Application of DMN
      • Data Enrichment Logic
        • Take primitive data and formalize the inputs to be meaningful
      • Scoring Tool Logic
      • Recommendation Logic
        • Based on input takes recommended info and compares to where you are for coming up with recommended
      • Human decision-making models for advanced cognitive support (provides this info to clinician to support decisions)
    • Benefits
      • Visibility of knowledge
      • Availability of editing and execution tools
      • Sharability of knowledge with partners customers and ourselves
      • Flexibility of models to different business needs
      • Community of practice
    • Mayo is in the process of putting together info to track the behavioral measures. Outcomes are analyzed elsewhere, but her specific areas is focused on behavioral stuff.

Thursday Q2 – PIE/FM
Sara Armson from Regenstrief presented information on LOINC

  • 3 ways to access LOINC
  • LOINC published 2x per year (June and December). Need to update Relma (current version 2.6.7)
  • Attachment codes
    • HIPAA tab within RELMA
    • Search screen
  • Online tool requires a free LOINC account
  • LOINC table available in .csv and mdb
  • Default settings filter out deprecated codes (change filter if need those codes)
  • They will be moving RELMA capability online and eventually quit supporting the download RELMA
  • From a payer perspective they always ask for the information at the highest level This is request for what documentation needed.
    • Not everything asked for will have an IG (everything won't be CDA)
  • RELMA is marketed as mapping tool, but seems more like a search, is there effort to make it more of mapping tool?
    • Relma does have a mapping portion. Local codes can be loaded, there is some level of auto matching.
  • If someone has done mapping thru RELMA and shares this information, data can be shared with others.
  • Over 900 codes were added in the last release
    • Christol indicated they had requested a couple of different codes to support electronic attachments Anthem is standing up the X12 275 and cDex with a communication request and communication response using LOINC
    • Mary Kay expressed a concern regarding how providers will keep the different implementations straight. No way the systems have this information at the point of care. Concerned about adding additional complexity to an already existing problem.

External code sets -

    • Paul updated a Coverage resource and was able to get it to build, however it isn't what they have been stating it should be.
      • The workaround does not render the information as was expected.

Thursday Q3 – PIE/FM
JIRA Tickets

  • 24285 – can't be resolved until vocabulary issue is addressed.
  • FHIR - 24398 - In an IG PA – the existing wording should clarify the payer should specify what information that is missing.
    • Attachment flow
    • If provider submits a 278 and they get told there isn't enough information. The process is to send back just the 275. In FHIR there is no way to respond to the 278 with a 275.
      • From FM perspective, does there need to have a FHIR operation for just the 275? If needed, this can't be built out until R5. Discuss on a regular FM interim call.
  • 24388 – Require ClaimResponseidentifer for non-rejected prior auth responses.
    • This was part of the error handling discussion with FHIR to X12 and X12 gets a response.
    • During the previous discussion Paul believed the black boxes would have to deal with the failures and is not a FHIR issue: outstanding questions:
      • How do you create a 999 or TA1 in FHIR. (error messages?)
      • What if only one of the 2 txns failed. (e.g., the 278 fails, but the 275 is accepted)
      • What can or cannot be fixed by the black box, not everything can be fixed? (278 not accepted, invalid

Thursday Q4 – PIE/FM: Special Event

  • Attended BPM+ workshop (Business Process Management)
    • Moving Professionals to Curate Knowledge: Experiences from the American College of Surgeons
    • Panel Discussion: The Keys to Advancing Evidence-based Care Practice
    • Wrap up

Friday Q1 – PIE/FM
JIRA Tickets:
25444 – Allow more data types in the SupportingInfo.Value element of EOB Resource
At the time there wasn't a use case that needed a data type beyond what was included.

  • It might be there are additional use cases that weren't considered.
  • It wasn't clear what information could not be expressed. Will go back to Lisa for more info.
  • Depending on what information is missing if it is added might also need to be added to the claim as well.

25618 – Subject of a contract could be a provider or a provider at a certain location.

  • Contract.subject is currently Reference(Any) so it will permit PractitionerRole and not limit to Organization.
  • Is the issue really with the field below Contract.subject?

24285 – Many of the profiles have example bindings PAS #82

  • The example solution as presented to
  • Need to get everyone in the
  • Let us know when we have the green light (and process) to reference X12 value sets

24174 - Claim items should be resources – PAS #23

  • The claim line item has a sequence number. In the US, the PA can have a TRN at the line item – this would currently be reported in an extension to report this.
  • Do they build a second resource for referrals/authorizations etc.
  • From X12 perspective: There is an optional line item control number that is returned on the 835, if none is submitted the line number is returned on 835.
    • This isn't unique
  • For X12 and the PA there needs to be a place to store TRN which is unique.
  • There was discussion surrounding the need to accommodate a place for line number and the unit trace number.
    • Don't really want to use sequence number as it only reflects the original sequence.
  • In the US a prior auth for wound care, could result in a number of items being approved all specific to wound care.
    • Request for specific services (e.g., 4 items), 2 of those items are approved and then an additional 2 unrequested items approved.
    • What if you need to make changes to the services approved, or add additional services.
      • Is it a new PA in the US or is it a modification of an old PA?
        • In X12 you would send a new EDI txn stating change to one already on file. (Send info from the original Authorization)
      • Need to walk through the use cases and how it works in FHIR
    • Discussed whether some things should be backbone element vs. Extensions.
  • Regarding Option 1: There is a need to be able to refer to elements within arrays and the "tag" provided by the sequence provides the functionality. For example ClaimResponse adjudications and add items refer to items. There is no way to reference an element with an array. e.g. item(thumbs down)
  • Regarding Option 2: There is a need to both a "line number" and a line identifier to reference and distinguish billed (multiple) services, for example in X12 278 transactions, therefore both elements should exist to reflect the separate concepts. The question remains, given the need for an item identifier in the US X12 278 messages for an item.identifier as to whether the element should be an extension or a native element. FM will research other countries prior Auths to see if the element is used elsewhere.

Friday – Q2 PA/FM

  • Mary Kay reported that Paul and a subgroup of Financial Management are working on Statements/Payment, there will be a PSS coming through and PA might see some changes to invoices.


  • 22726 – Guidance for Encounter period start and stop times
    • PA suggested Encounter period start = admission date and Encounter period stop – discharge date.
      • This isn't necessarily true when there isn't an admission involved.
      • There can be multiple encounters that happen during the duration of an inpatient state.
      • This is additional guidance for a particular circumstance essentially for the hospital stay from a billing perspective.
      • Discussed the addition of status codes for discharged
      • Vote: Motion to approve guidance, new code 1 Brian motioned, MARY KAY seconded - 19, 0, 0
  • 24014 – Inconsistent modeling attributes in Claim and Encounter dx and procedures
    • Ranking vs. Sequence
    • Believe these are different for a reason
    • Assign to FM to follow-up to Floyd.
  • 14409 – ChargeItem needs a "Product" reference
    • This appears to be an old tracker number and is something that was pre-applied.
    • Is ChargeItem service only have a single product?
    • Motion: Brian/MARY KAY Agree and change to codeable reference data type for R5 (19,0,0)

Encounter Resource

  • PA presented possible restructuring of Encounter
    • Categorized elements that will always be at top
    • Elements related to specific movements together

  • No labels