Category Archives: Question

Question: LOINC code for smoking start date

Question:

My team is currently working with FHIR DSTU2, and part of the project that we are working on requires  SMOKING information, particularly the date the patient started smoking.  Part of this work is also mapping this particular information to LOINC, and basically our issue is that we are unable to find anything that refers to a patient’s smoking start date in LOINC.  What would be your suggested work around for the above?

We did find quit date, which good – just not start date.

Answer:

Well, there’s no LOINC code to match 74010-0 (Date quit tobacco smoking). So the best option is to make up your own code, and propose that LOINC add a matching code, then change to use that once that’s done.

You can propose new LOINC codes here: https://loinc.org/submissions/

Question: HL7 v2 referrals in Australia

Question:

It seems there are lots of different ways to format a letter type message in Australian Health IT

  1. Pretend its a path report and use ORU with the appropriate LOINC code. This seems the most common
  2. Do it “properly”: use REF
  3. Use PIT, still around I understand
  4. MyEHR CDA type

And within that

  1. 1/ use the FT plain-text format
  2. 2/ embed as an RTF document
  3. 3/ embed as PDF

So that’s 12 permutations at least and I’m sure I’m missing some. Which options have the best chance of getting parsed/rendered correctly by the current crop of GP software (MDW, Best Practice, Zedmed, etc)

Answer:

Well, I think that right now there is no great answer to this question. I consulted Peter Young from Telstra Health, who is leading a vendor consortium that is working with Australian Digital Health Agency (ADHA) on this particular issue. Peter says:

There is work underway in collaboration between HL7 Australia, ADHA and a number of industry players to create a standard mechanism of sharing messages between clinical applications and capable of being transmitted via SMD based on an HL7 Ref I12. It leverages the recently published pathology messaging profile and is part of a broader program led by ADHA  to improve interoperability between applications. Initially there is a baseline specification that provides essential structured data with a clinical document that can be in  either of RTF, pdf, html or text. The idea is that receiving applications will support any document format; if not natively, at least use a viewer. The work plan also includes extensions to add more structured data.  Most of the major clinical and messaging vendors are involved in the work program.

The link to the simplified profile is https://confluence.hl7australia.com/display/OO/Appendix+8+Simplified+REF+profile

I think that the best bet right now is the REF I12 message, with PDF for the letter. But this is an area of active work.

Question: #FHIR Documents and Composition

Question

What is the relationship between FHIR Documents and  composition resources? Meaning, what is the best way to capture/store in FHIR, documents that are not necessarily related to clinical info (file, images, file reference links to external content systems etc)

If I have several documents that need to be associated to a patient and organizations and was looking for your thoughts on best practices you have seen

Answer

Documents like this – files, images, reference links to content systems – these are best handled using DocumentReference.  Composition is used for documents that have tightly controlled content. a mix of narrative and data.

Question: Extending systems to deal with non-#FHIR type content

Question

What has your experience been with developers, developing on a FHIR model that requires FHIR resources — but also has a need for non-standard FHIR data (something like supply chain data or Blockchain external hashed data). Is the recommendation to shoe horn this into extensions  or have data models that live side-by-side with FHIR?

Answer

There’s no single answer to this question, because it depends on the other kind of data. Generally, there’s 3 approaches I’ve seen:

  1. Use extensions in existing resources (particularly Basic). This approach is only good while the extensions are pretty narrow and limited, and closely related to the existing FHIR functionality
  2. Use some other content model, and figure out how the functionality links. This approach is good where there is another content model. For example, in my server, I use SCIM for managing the user accounts. I use the SCIM content to link a user account to a FHIR resource like “Patient” so that I know which patient the user represents (if any) and I refer to the SCIM user identity in AuditEvent resources (as a URL)
  3. Make up your own content but follow the FHIR patterns – effectively, custom FHIR resources. Use extensions to reference them. This approach is good where you have quite a bit of content/functionality, but there’s no external standard to follow

Which is best depends on what you’re doing.

A note about the custom resources idea: this is legal – you can do whatever you want with the names the FHIR doesn’t define. e.g. [base]/User. And if you choose to put something there, that happens to look a bit like a FHIR resource.. that’s still whatever you want. But things like ‘can I describe it from the CapabilityStatement’ and ‘can I search into the space’ are not technically legal, and there’s always a risk that HL7 will use the name in the next version of FHIR, making your solution locked in to being non-conformant. We’ve investigated making some policy around these questions to make custom resources manageable, but we’ve never managed to get the energy to push agreements over the line.

Question: Validity of AllergyIntolerance extension in #FHIR

Question:

How to extend severity in AllergyIntolerance resource.  Is the following resource where severity is extended done correctly?

<AllergyIntolerance xmlns="http://hl7.org/fhir">
  <id value="uWErIN0G0" />
  <recordedDate value="05/10/1980" />
  <patient>
    <reference value="Patient/DFQA_ghn000003" />
    <display value="Newman, Alice Jones" />
  </patient>
  <substance>
    <coding>
      <system value="RxNorm" />
      <code value="1659592" />
    </coding>
    <text value="ampicillin-sulbactam" />
  </substance>
  <status value="confirmed" />
  <event>
    <manifestation>
      <coding />
      <text value="urticaria (hives)" />
    </manifestation>
    <severity>
      <extension url="http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.3221.6.8">
        <valueCodeableConcept>
          <coding>
            <system value="" />
            <code value="371923003" />
            <display value="mild to moderate" />
          </coding>
        </valueCodeableConcept>
      </extension>
    </severity>
  </event>
</AllergyIntolerance>

Answer:

Severity is a code, with cardinality 0..1 and a required binding to mild | moderate | severe. You can replace the code with an extension, as is done here, so that part is valid. But it’s much better to provide both a code out of the defined choices, so that systems that only know those choices can process the information correctly, while those that know the refined list can process the refined list:

    <severity value="mild">
      <extension url="http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.3221.6.8">
        <valueCodeableConcept>
          <coding>
            <system value="" />
            <code value="371923003" />
            <display value="mild to moderate" />
          </coding>
        </valueCodeableConcept>
      </extension>
    </severity>

Aside: you could map this code to either mild or moderate, yes. Choosing either is better than choosing neither.

There’s several other issues here, though:

  • The URL given that identifies the extension actually identifies the value set, not the extension (aka the data element). The correct thing to do would be to define an extension that use the value set (see at the bottom of the post)
  • According to the value set definition, this is a SNOMED CT code, and the system should be filled out
  • the recorded date format is not a valid XML date
  • the system for RxNorm is not correct
  • manifestation coding can’t be empty

Here it is corrected:

<AllergyIntolerance xmlns="http://hl7.org/fhir">
  <id value="uWErIN0G0" />
  <recordedDate value="1980-10-05" />
  <patient>
    <reference value="Patient/DFQA_ghn000003" />
    <display value="Newman, Alice Jones" />
  </patient>
  <substance>
    <coding>
      <system value="http://www.nlm.nih.gov/research/umls/rxnorm" />
      <code value="1659592" />
    </coding>
    <text value="ampicillin-sulbactam" />
  </substance>
  <status value="confirmed" />
  <event>
    <manifestation>
      <text value="urticaria (hives)" />
    </manifestation>
    <severity>
      <extension url="http://example.org/fhir/StructureDefinition/my-extension">
        <valueCodeableCoding>
          <system value="http://snomed.info/sct" />
          <code value="371923003" />
          <display value="mild to moderate" />
        </valueCodeableCoding>
      </extension>
    </severity>
  </event>
</AllergyIntolerance>

With an associated Extension definition:

<?xml version="1.0" encoding="utf-8"?>
<StructureDefinition xmlns="http://hl7.org/fhir">
  <meta>
    <lastUpdated value="2017-07-12T07:05:27.311+10:00" />
  </meta>
  <url value="http://example.org/fhir/StructureDefinition/my-extension" />
  <name value="RefinedSeverity" />
  <status value="draft" />
  <date value="2017-07-12T07:02:31.9614187+10:00" />
  <publisher value="Health Intersections" />
  <description value="My definition for FHIR extension" />
  <purpose value="an extension" />
  <fhirVersion value="3.0.1" />
  <kind value="complex-type" />
  <abstract value="false" />
  <contextType value="resource"/> 
  <context value="AllergyIntolerance.event.severity"/> 
  <type value="Extension" />
  <baseDefinition value="http://hl7.org/fhir/StructureDefinition/Extension" />
  <derivation value="constraint" />
  <differential>
    <element id="Extension">
      <path value="Extension" />
      <definition value="This is a description of the level of the severity of the problem." />
    </element>
    <element id="Extension.url">
      <path value="Extension.url" />
      <fixedUri value="http://example.org/fhir/StructureDefinition/my-extension" />
    </element>
    <element id="Extension.value[x]:valueCoding">
      <path value="Extension.valueCoding" />
      <sliceName value="Severity" />
      <type>
        <code value="Coding" />
      </type>
      <binding>
        <strength value="required" />
        <description value="This is a description of the level of the severity of the problem." />
        <valueSetUri value="http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.3221.6.8" />
      </binding>
    </element>
  </differential>
</StructureDefinition>

Interconversion between #FHIR and HL7 v2

Question

What advice do you give for introducing FHIR in new software, while continuing to maintain HL7v2 interoperability with client applications that do not speak FHIR?

For example, are FHIR resources the way to go as an internal representation of an application’s health care data?

If yes, is it practical to convert HL7 messages into FHIR resources (e.g. Patient, Practitioner, ProcedureRequest, ReferralRequest, Appointment…)? What open source software do you recommend for converting HL7 messages into FHIR resources (and vice-versa)?

Or is it better to use FHIR for external information exchange only (with outside FHIR clients)?

Answer

I’ve worked with several projects rebuilding their products around FHIR resources. Like all development methodologies, this has pros and  cons. What you get out of the box is a highly interoperable system, and you get a lot of stuff for free. But when your requirements go beyond what’s in the specification, it starts to get hard – FHIR is an interoperability standard, that focuses on the lowest common denominator: what everyone agrees with. Whether that’s a net benefit depends on how far beyond common agreement your going to go. (This, btw, is a demonstration of my 3rd law of interoperability).

It is practical to convert HL7 messages to FHIR resources and vice versa, yes. We’ve seen plenty of that going on. But there’s no canned solution, because to do the conversion, you have to do two things:

  • Figure out all the arcane business logic and information variants and code this into the conversion
  • Figure out how to integrate your conversion logic into your application framework

The upshot of this is that you have a programming problem, and most people solve this by taking a open source libraries for v2 and FHIR in the language of their choice (most languages have one of those) and writing the business logic and application integration in their development language of choice. Hence, there’s no particular open source library to do the job other than the parsers etc. There are some commercial middleware engines that include FHIR as one of the formats that can be supported.

In the FHIR spec, we’ve defined a mapping language that tries to abstract this – so you can separate the business logic from the application integration, and a platform independent business logic that has libraries for whatever platform. That’s an idea that is gradually starting to gather some interest, but is still a long way from maturity.

With regard to using FHIR for external exchange only… what I usually say about this that is that it makes sense to implement FHIR for new things first, and then to replace old things only when they become a problem. And most new stuff is on the periphery, where the architectural advantages to FHIR are really big. But internally, v2 will increasingly become a major service limitation in time, and will have to be replaced. The open question is how long that timeline is. We don’t know yet.

 

Question: CCDA and milliseconds in timestamp

Question:

We are exchanging CCDs over an  HIE. While consuming a CCD from a particular partner, we are having issues parsing the dates provided in the CCD. Most often, we cannot process the effectiveTime in various sections of the CCD.

We have been told that our partner is using a C-CDA conformant CCD. The CCD parser on our side cannot handle any of the effectiveTime values which contain milliseconds, such as:
<effectiveTime value=”20170217194506.075″/>

Our vendor informed us that:

“The schema you referenced (for a CCD) is the general data type specification for CDA. There are additional implementation documents that further constrain the data that should be reported. For example, the sections shown below are from the HL7 Implementation Guide for Consolidated CDA Release 1.1. As you can see, a US Realm date/time field (which includes the ClinicalDocument/effectiveTime element) allows for precision to the second.
The guides for other CCD implementations – C32, C-CDA R2.0, etc. – include identical constraints for /ClinicalDocument/effectiveTime. These constraints are the basis for our assertion that milliseconds are not acceptable in ClinicalDocument/effectiveTime/@value.”

The schemas provided for C-CDA and CDA do allow for a milliseconds value, according to their RegEx pattern. The CCDA schematrons have notes that specify:

The content of time SHALL be a conformant US Realm Date and Time (DTM.US.FIELDED) (2.16.840.1.113883.10.20.22.5.3).

Even though the schematron may not have the checks to flag a millisecond value, they do make that statement, which does not allow for milliseconds.

Please provide guidance on whether milliseconds are acceptable in C-CDAs and/or CCDs.  If milliseconds are not allowed, then why don’t the schemas/schematrons trigger errors when millisecond values are found?

Answer:

Firstly, some background: The CDA schema is a general schema that applies to all use of the CDA specification anywhere. So the schema allows milliseconds. CCDA is a specification that builds on CDA to make further restrictions. Most of these can’t be stated in schema (because schema does not allow for different content models for elements with the same name). So these extra constraints are made as schematron, so they can also be tested for CCDA documents.

The CCDA specification says, concerning date times, that they SHALL conform to DTM.US.FIELDED, and about dates like that, it says:

1. SHALL be precise to the day (CONF:81-10078).

2. SHOULD be precise to the minute (CONF:81-10079).

3. MAY be precise to the second (CONF:81-10080).

4. If more precise than day, SHOULD include time-zone offset (CONF:81-10081).

It sure sounds like you can’t use milliseconds. But, unfortunately, that’s a wrong interpretation. The DTM.US.FIELDED template on TS is an ‘open template’ which means that anything not explicitly prohibited is allowed.

Since milliseconds are not explicitly prohibited, they are allowed.

(Yes, you can then ask, why say “MAY be precise to the second”? this is careless language for a specification, and creates exactly this kind of trouble)

Note: this answer comes from Calvin Beebe (coming HL7 chair) on the HL7 Structured Documents Email List, and I’m just archiving the answer here so it can be found from search engines.

Question: Apple CareKit and #FHIR

Question:

I am very new to FHIR and now i am trying the find out equivalent resource for  Apple carekit data. I think i can use FHIR Careplan & Goal for the CareKit data. Is that right?

Answer:

I’ve not done any work with CareKit, but Apple suggested I talk to Seth Berkowitz at BIDMC, who says:

CareKit is a set of UI and database components that provide a framework to display careplans, collect patient generated data, provide insightful feedback to and from patients via their iOS phones.  By leveraging simple game mechanics and Apple’s design ethos, the UI components of CareKit help motivate patients to comply with their daily medications and activities as part of their care plan.  The assessment component streamlines the collection of subjective and objective data from patients using the phone as middleware. Objective data collection is facilitated through HealthKit, which is Apple’s centralized database on it’s phones that facilitates the sharing of objective health metrics in between apps.  The last component of carekit is a communication module that helps patients share their care plans and results with friends, family, and medical professionals

BIDMC we are integrating our CareKit app directly into our homebuilt EHR so that the app becomes a direct conduit of prescriptions and orders from doctor to patient, and patient generated data from patient to doctor.  Although our short term goal is to benefit our own population of patients, we share Apple’s long term vision of widely disseminating these engaging apps.  To that end, we are trying to leverage FHIR APIs as much as possible to serve as the connections between our EHR and the App.  The hope is that Apps like this serve as a “carrot” to promote more widespread adoption of the FHIR standard.  Our two main APIs using FHIR are a medication search bundle and CarePlan resource.  Our medication bundle leverages our institutions participation in the Argonaut projects

CareKit encompasses several functions which pose potential FHIR interfaces for data download and upload.  To date, my group has focused on leveraging FHIR for data download in order to populate the CareKit “CareCard” (a patient check list of careplan activities) and Carekit “Assessment” or subjective and objective measurements collected on the phone. An overarching question that we’ve been trying to solve is how encode UI / implementation specific data fields within the appropriate FHIR schema.  For example, a careplan activity in carekit is displayed with a title, a subtitle, and more detailed instructions.  For each careplan activity I’ve been using the following mapping

  • Title: activity.detail.code.text
  • Subtitle:  activity.detail.goal (either display or description of a contained resource)
  • Instructions: activity.detail.description

For quantitative measurements that are collected on the phone through the HealthKit database, I define an “observation” activity within the careplan.  The activity.detail.code.coding array defines a LOINC codable concept which is then mapped to Apple’s internal reference system for various physiological measurements (heart rate, blood pressure, daily sodium intake, etc)

Finally, we define certain alert conditions that may prompt a message to the patient after a measurement is obtained.  These alerts are implemented as an extension to the activity.detail.goal.  The extension includes a valueQuantity which is the threshold that triggers the alert and a referenced Flag resource which is the alert prompt to the user.

There’s much more to be done to build an end-to-end CareKit FHIR interface, but that’s what we’ve been working on so far.

Thanks to Seth and also to Pascal Pfiffner, who’s been a trail blazer with regard to FHIR use on iOS (and who maintains the FHIR Swift reference implementation).

Seth noted that with the careplan resource, it feels like they’re pushing the limits of how the careplan is being used in practice – and indeed, that’s true. There’s a lot of active projects using FHIR as the format for exchange underlying shared care/ collaborative care projects that involve the patient, and their various care teams: family, professional, social etc., and this is a new – exciting! – area where there’s not a lot of established knowledge, culture, and practice for us to fall back on. So implementers should expect more change in this area than in the well established ones (patient management, diagnostics, medication administration, billing).