201801 Automated Profiling From Domain Models

Track Name

Automated Profiling From Domain Models

Submitting WG/Project/Implementer Group

Clinical Interoperability Council, Cancer Interoperability Group

Justification

There is a practical gap between documenting the clinical content in a healthcare domain via a domain analysis model, and the ability to deliver a corresponding FHIR implementation. While it is possible with existing manual tools to create FHIR Profiles in small numbers, when a domain requires 20, 50, or 100 profiles, efficient specification and automation is required. This track will to test a proposed methodology for creating FHIR profiles that should make it possible to convert a domain analysis model to a set of FHIR profiles in a relatively simple, efficient manner.

For this connectathon, the decision has been made to specify one medical domain to be modeled; that of breast cancer. Focusing on one domain will allow for comparison of the modeling efforts more easily.

This track will also test the accuracy of profiles generated, by generating patients that conform to the profiles and exchanging them between servers/testing for compliance.

NOTE: This Connectathon track is agnostic to the approaches to logical modeling and FHIR Profiling. It is being supported by the Standard Health Record team, but any and all methods of modeling and profiling are welcomed and encouraged.

Proposed Track Lead

Mark Kramer, mkramer@mitre.org
Michael O'Keefe, mokeefe@mitre.org
See Connectathon_Track_Lead_Responsibilities

Expected participants

Participants that we have reached out to, or who have expressed interest in the connectathon topic:

• Clinical Interoperability Council (CIC)
• Substance Abuse and Mental Health Services Administration (SAMHSA)
• College of American Pathologists (CAP)
• Wayne Kubic
• IHE (unknown participants)
• Travis Stenderson

Roles

Profile Creator

The Profile Creator will come to the Connectathon with an unstructrued (e.g. non-FHIR) analysis model of a particular medical domain (cardiology, cancer, radiology, etc.) developed by or in conjunction with a domain subject matter expert. They will also arrive at the Connectathon with (paper or FHIR) patients that exercise the model.

During the Connectathon, the Profile Creator will translate these paper models into the modeling language, whether the creator is using SHR or otherwise, from which FHIR profiles can be generated.

The Profile Creator will then upload these profiles to a FHIR server, either a publicly-available one controlled by the Creator, or one of the ones listed on the Connectathon page

Profiling domain complexity

In order to make it easier for newcomers to profiling/modeling to join this track, there will be 3 different levels of domain complexity within the area of breast cancer.

• Easy: Cancer Staging
  • Cancer staging assigns a grade to a tumor based on size, location, and metastasis status
• Harder: Cancer progression
  • Modeling the progression of cancer through diagnosis and treatment, including side-effects like chemotherapy toxicity
• Bonus: Additional modeling, such as:
  • Tumor genetics
  • Tumor receptor status
  • Tumor pathology

Resources for Profile Creators

• https://lightmyfhir.org/2017/09/10/fhir-profiling-made-easy/
• https://github.com/standardhealth/shr_spec
• http://standardhealthrecord.org/

Profile Server

The Profile Server is the actual FHIR server that accepts the FHIR profiles. The Profile Creator will then generate and upload FHIR patients that conform to the generated FHIR Profiles to the Profile Server.

http://clinfhir.com/ is an option for building patients to upload to the Profile Server, as it allows for building linked resources that conform to profiles.

Patient Endpoint (optional)

The Patient Endpoint is a FHIR client that requests the FHIR patients from the Profile Server, and validates their adherence to the FHIR profiles generated by the Profile Creator. This may be done in a manual or automated fashion.

Scenarios

Develop Clinical Domain Model

Action: Profile Creator creates a logical representation (SHR or otherwise) of their clinical model

Precondition: Profile creator must have developed an unstructured clinical model prior to the connectathon

Success Criteria: tooling successfully processes clinical model into FHIR profiles

Bonus point:

Upload model to FHIR server

Action: Profile Creator uploads FHIR profiles to a FHIR server

Precondition: Profile creator must have developed the logical model and generated FHIR profiles from it

Success Criteria: FHIR profiles successfully upload to the server

Bonus point:

Create Resources conforming to the Domain Model in FHIR Server

Action: Profile Creator builds patients/other FHIR resources that exercise the domain model being built

Precondition: Profile creator should have example patients to build from/clinical knowledge to build resources

Success Criteria: Patients and associated resources are successfully uploaded to the FHIR server

Bonus point:

Validate Domain Model Resources against FHIR Profiles

Action: Profile Server or Patient Endpoint request and validate the Domain Model resources against FHIR profiles

Precondition:

Success Criteria: Patient Endpoint or Profile Server successfully validate valid resources (and reject invalid resources)

Bonus point:

Security and Privacy Considerations

none