This wiki has undergone a migration to Confluence found Here

IG Meeting Notes

From HL7 Argonaut Project Wiki
Jump to navigation Jump to search
  • Bulleted list item

3/22/2016 Review of Patient and AI, Introduction of Vitals and Smoking Status



  • Best practice for given + family + gender but just on may give to many results - EH/BM to add text to IG
    • Context based will provide different levels of search. - FYI
    • Scope of search within enterprise - See use cases


  • stick with broadest search - EH to remove issue from list in IG - resolved
  • VS in DAF is being fixed. - BM to fix VS and to add reference to VS back to IG when constrained.
  • Date range search Decision not to use for problems and allergies -EH remove issue from AI
  • BM/EH: FU with ONC clarification for date ranges for other searches (Observations, Procedures, Medications, Immunizations, Assessments, Plans, Goals, HealthConcerns)
    • BM/EH add LINK to ONC Tracker to issue


  • RE: UNK vs NA to create trackers to IG remove from DAF - BM to fup
  • Business Identifier on Observations? Justification for not requiring is that there is no external assigning authority and no business use outside of database key.
    • Patient generated data?.... still open question but leaning to not requiring in Argo - Keep open issue however pending further comments (Unsure of use cases for applications fetching multiple observations from multiple sources)


  • open issues summary
    • What is in and out ( Which Vitals are in/out )
    • not require to support them all
    • prescribed way to support BP
    • require these High level LOINCs
    • require these units ( metric v english v both )
  • Note: Tracker on BP on Intrepretation. [#9676] interpretation --> EH and OO WG
  • All review IGS and provide feedback

4/7/2016 Review of of Vitals and Introduction of Labs

VR review

  • Todo - add clarifying text. EH 20160603 done
    • extensible at discretion of system
    • subsumption and examples how this is done.
  • issues : add conclusion from discussions/lists EH
    • e.g. for units error issues - Add english units to Vitals where applicable - align with the STU3 observation profile EH 20160603 done

Both VR an Lab

  • add to success - support for all and any and date range for category and should for code + date EH
  • add period and example notation to date. (see spec) EH done 20160606
  • optional to support for lastknown - research how to do this. EH gforge comment [#9964]   returns the most resent thirty records for

    • research how to do by category? EH
  • Add guidance on what to do when too many results - EH to check with spec. ( how does this align with ONC guidelines ) eh placed in the introduction and refer to FHIR core


  • reviewed disparity for DR and Lab - and category code sets - DSTU tracker for OO - EH [#10142]
  • add note that a query on lab will return other "subsumed" category's ( CHEM, Hematology, etc) is system supports those. -EH done
  • several todos to complete IG and mover issues to GIT -EH done
  • DR vs OBs- not likely resolvable without pain -EH done

Next time

  • all to review lab Results
  • review Smoking Status and Lab Results
  • next scheduled profiles/IG

4/19/2016 Review of Issues List, Smoking Status and Introduction of Problems

Issue List=

  • reviewed process and invited participation

Smoking Status

  • Review Decision to align Valueet with regulatory requirements
  • No specific feedback


  • Issue re Concern and how to differentiate using same resource (no action-see below)
    • highlight that will get more than diagnosis with search all Conditions. (no action)
    • need to flesh out categories add problem category and concern? (no action)
      • Distinguishing factor:(no action)

e.g. :DX billed in context of a single encounter vs problems = chronic

  • Groups wants to support 'problem' category
  • Question about Search for active problems
    • Not part of MU2015 cert but Will provide as an example for guidance (EH - done)
  • Question about when can send text
    • CodeableConcept for text when needed (EH.BM todo identify place or places in IG to reference to base for guidacne on this.) EH defined extensible to accommodate this.
  • Question about code set ICD-10 vs SCT
    • OK for Problems but not concerns, etc so if reuse this IG for Concerns this won't work
    • SCT is requirements for MU2015 Problem CCDS
    • Concerns will separate IG/profile for Concerns.

Based on 4/19 Call decision made to limit by category = problems. concertns, diagnosis? ( not CCDS ) This aligns with Code Set = SNOMED and allows for the Condition resource to be use for Concerns and Diagnosis with separate bindings. ( EH done )

Next Time

review problems, labs introduce more stuff

5/3//2016 Review of Sprint Schedule, Resolutions of Issues with Patient, Allergies and Review Problems

5/3/2016 Argonaut Data Query Call


  1. Re-sprint Schedule
    1. Goal
      1. The FHIR Query Team (Sponsor SME’s) will finish providing feedback on the IG’s
      2. The Implementation & Testing group (public, includes sponsors) will then ‘re-sprint’ using the draft IG’s—but only after the Query Team has finished providing comments/feedback

  1. Proposed Re-sprint schedule for the Implementation & Testing group:



TimeLine – proposed dates


Patient(1-6) + Allergies(10) + Problems(8)*

~2 weeks 5/17 - 6/3


Vital Signs(13) + Laboratory Test/Results(11-12) + Smoking Status(7) + Care team members(16)*

~3 weeks 6/3 – 7/1


Medications(9)* + Immunizations(17)* + Health Concerns(21)*+ UDI(18)*

~3 weeks 7/1 – TBD


Procedures(15)* + Plan of treatment(19)*

~2 weeks TBD


Assessment(19)* + Goals(20)*

~2 weeks TBD

numbers in parenthesis refer to 2015 MU CCDS

  • Indicates review not completed by The FHIR Query Team

  1. Updates on existing IGs
    1. Resolution of outstanding issues
      1. Patient
      2. Allergies

Add text to main IG page discussing the binding rule for extensible and Translations

  1. Make binding to substance extensible and refine definition for Argonaut to “If the data type is CodeableConcept, then one of the coding values SHALL be from the specified value set if a code applies, but if no suitable code exists in the value set, alternate code(s) may be provided in its place. If only text available, then just text may be used.” 20160606 EH Done.
  2. Atlernate codes may be provided as in addition to the standards codes defined in the value set. The alternate codes are called “translations” . These translations may be equivalent to or narrower in meaning to the standard concept code. An annotated example is provided below. 20160606 EH Done.

Translation Example:

"code": {
    "coding": [
//NOTE:this is the standard concept defined int he value set
        "system": "",
        "code": "29463-7",  
        "display": "Body Weight"
//NOTE:this is a translation to a more specific concept
        "system": "",
        "code": "3141-9", 
        "display": "Body Weight Measured"
//NOTE:this is a translation to a different code system (Snomed CT)  
        "system": "",
        "code":  “364589006”,
        "display": "Body Weight"
//NOTE:this is a translation to a locally defined code
        "system": "",
        "code":  “BWT”,
        "display": "Body Weight"
    "text": "weight"

  1. Smoking Status

  1. Review Problems IGs
    1. Change clinicalStatus with invariants
      1. required if verificationStatus is not ‘entered-in-error ‘ (A or B!='x')
      2. not present if verification Status is ‘entered-in-error ‘ (not(A and B='y'))
    2. Add note to optional Active status search - explaining that it will not return any entered in error resource because of the invariant.
  2. Next Call
    1. Resolution of outstanding issues
      1. Vitals
      2. Labs
    2. Introduce
      1. Medications
      2. Immunizations
      3. CareTeam

(FYI currently in draft :Medications, Immunizations, CareTeam, UDI, HealthConcerns)

5/23/2016 Provider Directory Call


  1. list of DE needed to be added extensions on Organization

List of Candidate Extensions on Organization:

(starting point ource: Kevin Shekleton and Eric Heflin) Endpoints extensions

  1. URL ( self evident )
  2. URL/transport type (XCA, XDR, XDS.b, etc) (for both send and retreive)
    • add tls or http? codes
    • other attributes related to type
      • asynchonous|synchonous
      • version
      • text name (already in codeableConcept
        SOAP service name: IHE XCDP responder service
        Versions: 1.0, 2.
        Display name: eHealth Exchange Patient Discovery 2010 and 2011 responding gateway service
  3. list of versions of CDA Supported ( e.g. 2.0 , 2.1 etc) codes
    • eh can this be combined with next item
  4. Other file types supported (PDF, jpeg, etc) = ( mime type )
    • Used precoordinated codes instead of mime type or add additional atributes and extensions on the mime type?
      • more expressive than mime type
      • combine attributes such as version, FormatCode, TypeCode, and ClassCode (e.g. to discern between discern between C-32 and C-CDA1.1)
    • Alternatively add additional atributes and extensions on the type?
  5. Purpose of use - treatment, claims, etc. = reason for the request
    • requirement limit scope what could be sent/received
    • Codes
    • activation status
      • use draft endpoint.status codes + "testing"
  6. Technical Assistance Person/Email/Phone
    • contact information "when" things go wrong)
    • use ContactPoint datatype
  7. Endpoint specific information (home community ID, repository ID, direct domain, etc)
    • eg OIDs or other technical identifiers, such as the SOAP IHE XCPD HCID, or the internal document AAID

DEs already in the Organization Resource

  1. Organization Type such as practice, HIE, federal agency, state agency, payor, HIT vendor, etc.
    • code list is example can provide own
  2. Other organization names, required due to prior names.
    • approved FHIR tracker 9625 to allow many

6/7/2016 Data Query Call


  1. Review guides for re-sprint #2
    • (Sprint 2 6/14 - 7/5 (Vital signs, Labs, Smoking, Care Team) Kick-off: Tuesday 6/14 4-5PM ET)
    • Vital Signs
    • Lab Results
    • Smoking Status
  2. Discuss new resource for re-sprint #2
    • Care Team
  3. Look ahead to re- sprints #3 and #4:
    • Two new IGs drafted:
      1. Goals
      2. Assessment and plan of treatment  (Combined CCDS so no Sprint 5)
    • Narrative only’ resources
    • One Issue on search scope is all vs only "active"
  4. Review issues list


  1. Vital Signs IG:
    1. Discussion on LOINC code for “O2 Saturation by Pulse Ox” vs generic “O2 Saturation” code
      1. Enumerate allowed LOINCs for O2 Sat by Pulse Ox - eh done added to wiki
      2. Reopening issue in HL7 Structured Doc WG ( CCDA folks) - eh done
      3. O2 Saturations measures can be laboratory results or vital signs depending on method
      4. EH to open issue to track EH-done
    2. Remove MAP ( mean arterial pressure )from the list of required vital signs concepts EH -done!
  2. Lab Results IG:
    1. Editor to fix omission of search by date to success criteria to mimic vital signs - EH done!
  3. Smoking Status IG:
    1. No need to add search by date since group decided that was not a requirement - no action
  4. CareTeam IG:
    1. Decided searching on CarePlan was better alternative to search by Patient and Patient.careProvider
    2. Decided to search for active CareTeam members - no action
    3. Discussed the value set binding for CarePlan.participant.role - will create an open-issue EH done!
      1. NUCC vs SNOMED code system for provider roles
        • harmonize with CCDA and Provider Directory
      2. Need for non clinical and organization roles
      3. Binding strength = extensible
  5. Reviewed Assessment and Plan of Treatment and Goals IGs:
    1. Invitation to review and comment here: argonaut fhir data query team

7/12/2016 Data Query Call

  Dial-in: 866-951-1151 Code: 5093906


  1. Looking ahead to Sprint #4 currently scheduled for 8/2:
    1. Two new IGs drafted
      1. Procedures
      2. Assessment and Plan of Treatment
        • “Narrative only” resources
        • todos:
          • include category value set EH : not needed since not defining a value-set for careplan just the code in a valueset.
          • fix search notation (add category) - EH: done
          • add status search as Should based notation - EH: done
  1. Any outstanding issues in IGs from Resprint #2 or #3
    • Vital Signs
    • Lab Results
    • Smoking Status
      • Issue #48
        • based on feedback will keep as is (Observation.issued) - close issue
    • Care Team
    • Goal
    • Medications
      • The current MedicationStatement profile for Argonauts requires an effectiveDateTime/Period. However, we’re in a situation where because Med Statements can be patient-reported, very often we will not have an effectiveDateTime/Period documented because we simply don’t know (or we don’t have the confidence to document it in the system).

        Do other servers have this similar problem, and do others feel strongly about a proposal to move effectiveDateTime/Period from a required to a must-support parameter?
        • medicationstatement may not know date of prescribed. from patient information may not get the date. create Issue #50 to track.
      • Issue #46
        • follow up- Eric to reach to server community to get opinion on requirement to support _include if referencing a non-contained resource
    • Immunizations
      • issue #49
        • NO opposition to resolution - applied change and closed issue
    • Device/UDI
  2. Add the DocumentQuery IG to the DataQuery Review 8/16 and Sprint Schedule #5 (8/30)
    • Issue with using DocumentReference to address § 170.315(g)(9) (Application Access—All Data Request)
      • MU may require use of some other custom query or operation instead. Interpretation of rule is an on demand generated query which would return a CCD document vs a reference for an indexed document which is how DocumentReference is designed. create Issue #51 to track..
  3. Next Query Team Meeting:
    • Tuesday August 16th 4-5PM

If you have any comments or questions feel free to ask on the argonaut fhir data query team or contact one of us directly

Reminder: Sprint 4 Implementation & Testing Kick-off call is 8/2 4-5PM ET :

8/16/2016 Data Query Call

  1. Encourage everybody to review and make ballot comments and participate in the ballot reconciliation. (contact Eric or Brett if you have questions about how to ballot)



  1. DocumentReference IG is intended to address the address the MU2015 § 170.315(g)(9) (Application Access—All Data Request) requirement
  2. Source material is Sprint 3, IHE MHD specification, early version of this IG
  3. Issue brought up on last call: Is DocumentReference the right resource for the Job? #51
    • updated discussion to clarify that the DocumentReference could have an operation to generate the metadata for a not yet instantiated document such as a CCD
      • The metadata would include a URL that would generate the actual document on demnad using some other query ( for example a Search on the Binary Resource.)
  4. Please review IG and comment

Remaining open issues

  1. date support #52
  2. [
    • Whether to change effectiveDateTime/Period from a required to a must-support element? #50]
  1. [
    • Whether both medicationCodeableConcept and medicationReference are both mandatory data elements] Seeking consensus on server function before can close out.
  2. Multiple races and ethnicities for patient #42
    • We discussing this at HL7's USRealm task force subcommittee and hope to have resolution by end of month. All this discussion is being taken into consideration there.

Introducing DAF-Core which is open for Ballot.

  1. Based on FHIR STU-3
  2. Updated from DSTU DAF
  3. Based on the Argonaut IG material
  4. Encourage everybody to review and make ballot comments and participate in the ballot reconciliation. (contact Eric or Brett if you have questions about how to ballot)